memo.kappa-lab.com

AssetBundleなどリソースをWWWクラスでロードする場合、多重読み込みとかUnloadとか色々めんどくさい上にLoadFromCacheOrDownloadとnew WWW()で挙動が変わってくるのでメモ。あ、Unity4.6の話です。

まずは正常系
同一URLを読み込んでいるが、適切なタイミングでUnloadすれば問題は起きない。

var www = WWW.LoadFromCacheOrDownload ("smpl.unity3d",1);
yield return www;
Debug.Log (www.error);//エラーなし
Instantiate (www.assetBundle.mainAsset);//表示

www.assetBundle.Unload (false);//ここでunload

var www2 = WWW.LoadFromCacheOrDownload ("smpl.unity3d",1);
yield return www2;

Debug.Log (www2.error);//エラーなし
Debug.Log (www2.assetBundle.mainAsset);//name取得
Instantiate (www2.assetBundle.mainAsset);//表示

6行目で

www.assetBundle.Unload (false);

しているが、2度目のLoadFromCacheOrDownloadまでに必須で実行。
例えば以下のタイミングだとエラーが出る

var www2 = WWW.LoadFromCacheOrDownload ("smpl.unity3d",1);

www.assetBundle.Unload (false);//遅いunload

yield return www2;

Debug.Log (www2.error);//Cannot load cached AssetBundle. A file of the same name is already loaded from another AssetBundle.
Debug.Log (www2.assetBundle.mainAsset);//You are trying to load data from a www stream which had the following error when downloading.
Instantiate (www2.assetBundle.mainAsset);//NullReferenceException: Object reference not set to an instance of an object

次にnew WWWな場合

var www = new WWW ("smpl.unity3d");
yield return www;
Debug.Log (www.error);//エラーなし
Instantiate (www.assetBundle.mainAsset);//表示される

var www2 = new WWW ("smpl.unity3d");
yield return www2;

Debug.Log (www2.error);//エラーなし

www.assetBundle.Unload (false);//ここでunload

Debug.Log (www2.assetBundle.mainAsset);//name取得
Instantiate (www2.assetBundle.mainAsset);//表示される

11行目になってようやくUnload実行でもok。なんとwww2.assetBundle.mainAssetを参照するまで問題なく動作する。さすがにそれ以上粘るとnull pointer系のエラーが出ます。

Debug.Log (www2.assetBundle.mainAsset);//The asset bundle 'hoge' can't be loaded because another asset bundle with the same files are already loaded
www.assetBundle.Unload (false);//ここでunload
Instantiate (www2.assetBundle.mainAsset);//NullReferenceException: Object reference not set to an instance of an object

あくまでもUnity4.6かつMacエディター上での挙動なので精査してませんが、実機でも同じようなもんじゃないかと。相変わらずネットワーク周りは貧弱この上ない。Unity5で改善されたって話だけど期待していいのだろうか...

Flash/Web界隈で仲良かった人たちと話す機会があると、「あの頃は良かったよね」みたいな話がよく出てくる。

「あの頃」とはつまり、キャンペーンサイトが百花繚乱にローンチされ、Flasher達がゴリゴリと制作を行い、技術ブログを書き、勉強会を開催し、お互いに切磋琢磨していた頃である。そうした中で我々は多くを学び、貴重かつ豊富な経験を得る事ができた。

「あの頃」のダイナミズムは特定の人物や企業によってもたらされていたものではない。個人が技術を公開し、議論し、あるいは表現する事でコミュニティが拡大し更に大きなムーブメントへと繋った。そうした活動そのものが個人の成長機会となり、またセルフブランディングとしても機能した。少なくとも駆け出しフリーランスの僕にとって十分なメリットを享受することができた。

もちろんFlashがプロプライエタリという点から、企業からの恩恵が無かったわけではない。ひょっとするとAdobeの仕掛けた壮大なマーケティグ戦略の一環だったかもしれないが、もしそうだったとしても「あの頃」は一向に色あせる事はない。ま、そんな手練手管があるならiOSにFlashにのってるだろうって話だが。

話が逸れたので戻そう。

「あの頃」によって得た教訓は「アウトプットを続けコミュニティに寄与すれば、必ずリターンがある」だった。スキル的にもビジネス的にもこのロジックは効果を発揮し、何よりも楽しかった。特にスキルアップや学習における快適指数は非常に高く、それは快適どころか快楽といって過言ではなかった。なにせ、重箱の隅を突くようなTipsに賞賛が送られたからだ。

しかし、上記の教訓を誰かに話しても手応えは希薄だった。もちろん真っ向から反対される事はないが、「まあ、そうだよね。けど効率悪そう」みたいな反応が多い。なぜ伝わらないのか。長らく悶々としていたが、ある時これは「成功体験の押しつけ」なんじゃないかと自省するに至った。

「アウトプットを続けコミュニティに寄与すれば、必ずリターンがある」という教訓が真だとしても、万人がそれを好み採用するとは限らない。人によっては「コミュニティとは無関係に自分のスキルを高めたい」と考えるかもしれないし、「アウトプットは必要なく仕事にだけ適応できればよい」と考えるかもしれない。僕が楽しいと思ったやり方が楽しくない人もいるだろうし、そもそも「楽しさとかいらない」という考えもあるだろう。

こうなってくるとますます人を育てるのって難しいなーという話に成ってくるんだけど、一応わたし、フリーランスなんですよ。おわり。

前回書いたエントリーの最後の方で「車輪の再発明」に触れたが、我が人生に於いて一度だけ正社員として働いた某社の社長の言葉を引用しよう。

うちの会社は自分たちで、やり方を考えてやっている。Ｓ○ＮＹ（伏せ字に成りきれてないのはご愛嬌）はすごいかもしれないけど、それはＳ○ＮＹが優れたシステムを持っているからで、個々人がその恩恵に預かって仕事をしているに過ぎない。

うん、いま思い返しても○森さん（これまた伏せ字に成りきれてないのはご愛嬌）の元を離れたのは必然だったと再認識できる。

ちなみに周囲に居るＳ○ＮＹの人は個人としても優秀な人ばかりだが、彼の言う通り、優れたシステムのお陰で仕事を全うしてるかもしれない。だが、それのどこにケチをつける必要があるだろう。彼らが優れたシステムの上に自らの能力を上乗せして、更にバリューを出すのは当然だ。それとも既存のシステムに頼らず、その優れた能力を使って独自システムに固執したほうがいいのだろうか。まさかね？

この、「俺たちは自力でなんでもやってきたし、これからもやっていくぜ」的なスタンスは、既存システム導入の忌避につながり、独自システム構築という車輪の再発明を容認する。しかも、碌にリサーチもしない場合が多い。結果として、本来必要ではなかったリソースの浪費になってんじゃないかなーと強く思う。

そして、「俺たちは自力で...」と言っているが実際には何かしらの既存のシステムに依存している。彼らはそのことに気がつかないだけだ。結局、システムへの洞察と分析、および学習が不足してるだけなんじゃないのかな。

追記:

あ、一応断っておくけど、イノベーションを否定するコンサバのダークサイドに堕ちない様に留意する必要がある。でもその話はまた。

こんにちは、空飛ぶRedmine教団の末端信徒、kappaLabです。最近ようやく拙僧がjoinしているプロジェクトがRedmineベースに移行され、SpredSheetと縁を切る事ができそうです。

タスクの作成から、担当者/優先度/期日の設定、仕様の策定など諸々をRedmine上に集約して運用してます。まーどこでも普通にやってる事を普通にやろうぜって話なんですが、やっとここまできました。

では今までどうやっていたのか、何が悪かったのか、以下に列挙しましょう。

• タスクをSpredSheetで一覧化、各自修正


• 上記リストにステータスや、期日を記載


• タスクに関する仕様は別途SpredSheetを用意(いいのそれで？)


• 上記リストにカラム追加、仕様のurl記載


• 上記リストにカラム追加、チケットのurl記載(なんの冗談？)


• 上記リストをQAチームに投げて動作検証


• QAチームから動作項目明記しろってクレーム(当たり前)


• 上記リストにカラム追加、動作項目記載(どこまでいくんだ)


• 上記リストにカラム追加、不具合項目記載(もうやめて)


• 差し戻った上記リストはもちろんカオス

みたいな感じ。このフローを持ってマネジメントとほざくPMは万死に値するだろう。

これ、全部Redmineでやればいいから。なんならTracでも良いから。QAもデベロッパーもデザイナーもみんな不幸になるから。

チケットドリブン

ではどうやってSpredSheet地獄から抜け出したかというと、単純にチケットを切って、情報を集約させただけ。

例えば、PMから「進捗をSpredSheetに記載してちょ」と依頼があったら、「チケットみてちょ」と返す。（決して記入してはならない）

あるいはデザイナーから「画像名どうしたらいい？」と聞かれたら「#xxxのチケットに記載してるよ」と返す。（決してチャットで返信してはならない）

あるいはPMから「QAへの確認事項一覧を(ry」と依頼があったら、「確認事項のチケットまとめたチケット作ったから、そのままQAに投げれば良いよ」と返す。

スケジュールに関してはガントチャート見れば良いし、次期バージョンの機能一覧とかリリースノートはロードマップに記載すれば良い。

とまあ、そんな感じでRedmineの権化の様に過ごしていたら、少しずつRedimineベースというかチケットドリブン開発っぽくなってきた。

ちなみに、開発会社によっては（特に大手SIerとか？）チケットの消化数で個人の人事評価につながる場合もある。このKPI測定みたいなやり方が良いか悪いかはともかくとして、一つの目安にはなるだろう。

また、過去に参加したPJでは、議題を設定してMTGを行い、承認を得る事でタスク完了としてKPIを測定、チーム内でマンスリーのMVPを選出していた。これは完全にチケットでやるべきだったな、と今にして思う。

さらに、とある大規模開発では、子会社のQA専門会社に数百件あまりの「確認待ち」チケットを投げた際、「経験則からn%のチケットは差し戻しになる、従って現状のリリーススケジュールは全く現実的ではない」と返答があったらしい。これには舌を巻いた。

賢者は歴史に学び、愚者は経験に学ぶ

表題はご存知オットー・フォン・ビスマルクの格言である（今ググったけどね）。ところで歴史はしばし改竄される。当然ビスマルクさんもそんな事は百も承知で、直訳は以下の通りだ。

愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避けるため、他人の経験から学ぶのを好む。

wikipedia

これには二つの教訓が含まれていると思っている。

• 主観的事実より、第三者視点（客観的事実と言い換えたい）から学べ
• 前例を有効活用しろ、既出の失敗を繰り返したり車輪の再発明をするな

客観的事実に関しては先に述べたQA専門会社からの「経験則からn%のチケット〜」が好例だ。我々は自らのチケットおよびスケジュールの信頼性を他者（QA専門会社）の経験と知見によって審査する事ができたからだ。

車輪の再発明に関しては、既存のソリューション使えばいいです。もちろん、冗長だったり、かゆいところもあるでしょう。完全なフィットは望めないと思います。

でもね、多くの場合は独自方法の構築と学習コストより、既存ソリューションの導入の方がコストパフォーマンスが良いはずです。新しく入ってきたチームメンバーもキャッチアップしやすくなります。むやみに「ぼくのかんがえたさいきょうのマネジメント方法(もちろんSpredSheetさ！)」を導入すんなって話です。

まとめ

長々と書いてきたけど、注意すべきはたった二点。

• 情報の集約
• 既存システムの有効活用

これだけだ。念のため断っておくがRedmineに拘る必要はなくて、情報を一カ所にまとめて運用できるシステムがあればなんでもいいと思ってる。個人的にはgithub/gitlabが今後、どこまで開発管理機能を搭載するかに興味がある。

なんでもメールを使う人がいて、

ダイヤ乱れで遅刻の連絡（これはok）
来週の早退する日程の連絡（これもまあok）
一ヶ月間の稼働時間報告（そろそろヤバい）
一ヶ月間のチームメンバーの勤怠状況（限界点突破）
バイトを含めたシフト状況（憤死）

個人的には「一ヶ月間の稼働時間報告」あたりから何らかのシステム導入を検討すべきで、更に「一ヶ月間のチームメンバーの勤怠状況」や「バイトを含めたシフト状況」へ複雑化していくなら都度最適なソリューションを探すべきだと思う。

ま、メールは極端な例で（地元の結婚式二次会とかならあり得る）実際には「何でもエクセル」とか「なんでもチャット」などが実務で見聞きする事例だ。

そして、勤怠管理を寓話として選んだが、本当にしたい話は「進捗管理」とか「タスク管理」といったプロジェクトマネジメントだ。もちろん業界としては答えは出ている。「Redmine使いましょう」とか「スプレッドシートでガントチャートとか馬鹿なの死ぬの」って話に過ぎない。

しかし、残念な事に今日が2015年である事を疑いたくなるようなマネジメント（って呼んでいいの？）は存在している。なぜそうしたプロジェクトが産まれるのか、なぜそのことに疑問を抱かないのか、謎と闇は深い。

偉そうな事ばっかり言ったけど、自分自身もモダンな開発手法をバッチリ追えてるとは口が裂けても言えない。n年後に「あいつ、Redmineだのticketだの、老害かよ」って言われないように精進したいと存じます。

前回のエントリーから一年以上が経過していますが、簡単に近況報告。

某ソーシャル系ゲーム会社と、半ば専属契約みたいな関係がここ数年続いております。

当初はケータイ向けカードゲームの案件が多かったけど、最近はスマートフォン向けゲームアプリが主体。その間には所謂「側ネイティブ」と呼ばれる、ネイティブアプリとしてリリースしてるけど、実体はwebviewでhtml描画、リッチ表現はcreatejsとかjs系の技術でゴニョゴニョ。っていうのもあった。

でまあ、ここ一年くらいはUnity。CocosとかUnrealとかを横目に見ながら、SendMessageに悪態を付きながら開発。ちなみにUnityに関しては「ゲーム開発の民主化」みたいな大義を掲げているわけですが、見事に「衆愚と大衆迎合の罠」にハマったというのが個人的な評価。

フロントエンド開発、特にGUI開発に於けるツールや言語はトレンドが変わるものの、大きなパラダイムシフトなどはなく、同時に進化もしてない印象。今後10年に至っても、使われるデザインパターンや設計思想は変わらないんじゃないかと。せいぜいMVCの派生系が新たに生まれる程度なんじゃないかな。

そんな中、開発手法やプロジェクト管理ツール周辺は着実に進化を遂げている気がする。ビルドツールやCIツール、gitクライアントや、branch設計(git-flowとか）などなど。面倒くさい作業は自動化してコードを書く事に集中するのだ。（実はコードを書く事すら最小限にとどめて、新たな地平に向かってるんじゃないかとさえ感じている）

話を個人的なレベルに戻すと、joinしているチーム内でスキルや国籍、言語などがバラバラってことはもはや珍しくないので、「空気読んで開発すすめて」は一切通用しない。でもって、チーム内で開発者を育成しなければならなかったりするのでいよいよ大変。そんなわけでcoolでヤバい開発手法を一刻も早くフィットさせるっていうのが現在の至上命題だったりすんだけどね。

と言うわけで気が向けばこのブログももうちょっと構っていこうとおもいます。

連休最終日は臀部の痛みに耐えて演劇を鑑賞。

「Gracia～ガラシャ～」

端的に申し上げて非常に良かった。臀部の痛みを補ってあまりある内容だった。

小学生からの友人が出演しているので観に行った訳だが、映画は観れど演劇は不慣れ。最後に観劇したのは一体いつだったか。そう、おそらく5,6年前に長男（＆保育園のお友達わんさか）と観たオズの魔法使い以来である。

そんな演劇不毛地帯ことkappa-labであるが、友人への感謝もこめて感想をメモ。

その一、テンポ
まず開演早々、そのテンポの良さに驚くこととなった。台詞のスピード、役者の振る舞い、場面転換、全てがスピーディーに転回する。特に場面転換に関しては非常にサクサクと切り替わる。Twitterの纏めを読んでいるかの様に、適切に情報を分離させ繋げて行く。この瞬間「あ、これなら最後まで多分飽きないわ」と思う事が出来た。最近の演劇のトレンドなのかもしれないが、観劇素人にとっては非常に親切設計。

その二、ストーリー
本作は安土桃山から関ヶ原に至る戦国時代の現代劇版だが、登場人物の史実上のウンチクをしらなくても楽しめる。また、この手のアレンジでは常套手段となる、各国の企業化もよくハマっていた。アレンジついでに言及しておくと、宣教師がこれまたオイシイ感じだった。あの辺の笑わせポイントはもっと盛り込んでも良かったんじゃないかな。祝賀会（？）で社交ダンス踊る所とかもアイデアは好きなのでもっと活かしてほしいポイントだった。

その三、信長
信長は本作において主人公じゃないんだけど、信長役を失敗すると大コケしますよね。そういう意味では、これはバッチリ。非常に優秀な悪役に演じておられました。辣腕で清濁併せ呑むタイプ。彼なりの理念や信念があるようだけど手段は選ばず時に残酷。そして周りは付いて行けない、みたいな。多くの人が抱いているであろう信長象を再現されていました。

ちなみに女性秘書の森蘭丸（可愛い）が信長と愛人関係なんだけど、ボディタッチが割とあって（つっても肩組むとか、胸元に手紙差し込むとか）、その瞬間僕の中のDTが発動しちゃいまして「え、そんな近くていいの」みたいな。あとネタバレだけど信長によるケシカラン場面とかもあって、その瞬間僕の(以下略

その四、石田ミツナリ
はい、お待たせしました。我が友、ミツナリ。信長は前述したようにバッチリでしたが、ミツナリもバッチリでした。まず彼をミツナリにキャスティングしたスタッフを讃えたい。こういう「信長ほどの大悪党じゃないんだけど、裏でコソコソ工作する面倒臭い中悪党」は彼しかいないでしょう。中学生の頃から小太りだった彼ですが、「やっぱ中悪党は小太りだよね」の定理に則った抜群のプロポーションは健在でした。欲を言えばもう少し嫌らしさをコネクリ回してもいいかも。ひょっとすると一般の石田三成の印象とは若干異なるかも知れないが、本作でのミツナリは非常に作品にフィットしていたし、彼の演技（体型は演技じゃないんだぜ！）も同様だった。

まとめ
というわけで、非常に悪党達の出来のいい作品でした。そういう意味では主人公達、明智ミツヒデとタマ、ヒデキヨ達は善人ではあるが非力すぎた気が...。もちろん、本作の終わりかたが悪い訳ではないので好みの問題ですが。あえて個人的な好みを申し上げるなら、「善人でも良いんだけど、最後に悪党達を一泡吹かせてやれれば違うカタルシスが生まれたんじゃないかな」ってところ。

そんな訳で、終わって気付くと2時間半の舞台。あっと言う間だった気がします。ちなみにお尻が痛かったのは、椅子っていうか、箱＆座布団が固かったから。いつか彼がフカフカのシートが完備された劇場で公演するのを楽しみにしつつ感想とさせていただきます。

既存コンテンツの動作確認のためiOS7を触ってる。webkit周りでいくつかの修正が必要になりそうな気配だけど、それは置いといて「フラットデザイン」について第一印象をメモ。

すでに言及されてるけど「フラットデザイン」は特に新しい概念ではない。シンプル/ミニマルなGUIデザインは2000年頃のwebでよく見られた。

従って、初代iPhoneが出たとき、GUIデザインに関して驚かざるを得なかった。それらはスキューモーフィズムと呼ばれる現実空間上にある陰影や光沢を取り入れた手法だった。明らかに僕の観測範囲であるwebからすると「シンプルでない」「グラデーション/質感過剰」なデザインにみえた。それでも総評は「ミニマルデザインから質感重視へのデザインは後退の様な気がするけど、やっぱ質感良いよね」だった。つまり「さすが、アップルゥ！！俺たちに出来ない事を平然と（ry」と感嘆したのであった。

それからおよそ6年、iOS7はフラットデザインへ移行すると発表された。これは「回帰」であると同時に「正当な進化」に成るだろうと期待した。やはりスクリーンメディア/デバイスの行き着く先は「シンプル/ミニマル」なのだと、本来のロードマップが高らかに宣言されたのだと、そう思った。

だがしかし、新たなsafariアイコンを実機で見た瞬間、期待が外れた事を悟った。

この、シンプルだけど残念な感じを我々はよく知っている、そうAndroidがそれだ。

もちろんUIは使ってるうちに手になじみ評価が替わる。もう少し時間をおいて評価するのが筋ってものかもしれない。ひょっとすると半年後に、「やっぱフラットデザインいいよね」と言ってるかもしれない。そうなる事を願いつつ、とりあえず初見の感想をログとして残しておく。