2015年3月 Archives

« 2013年12月 2015年4月 »

近況報告

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

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

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

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

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

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

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

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

なんでもメール

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

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

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

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

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

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

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

賢者はRedmineを使い、愚者はSpredsheetを使う

こんにちは、空飛ぶ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が今後、どこまで開発管理機能を搭載するかに興味がある。

ぼくのかんがえたさいきょうの...

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


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


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

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


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

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

追記:

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

RSS + Contuct

  • rss
  • email

Credit

Copyright (C) 2007 kappa-lab.com.
All Rights Reserved.