ゲーム業界のプロジェクトマネジメントの資料

スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がとても良かったのでリンクしておく。

【元ネタ】
スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がスゴイ！ at ミネルヴァの梟は黄昏とともに飛び始める

【1】ゲーム業界のソフトウェア開発案件を元にしているが、仕様・納期・人員・品質などの要素が当初見積りよりもわずかに増えるだけで、実績工数が10倍以上に膨れ上がることを簡単な例で説明している。
更に、10倍に膨れ上がった工数は、仕様を減らし、納期を延ばし、人員を大量投入し、品質を落とし、更に開発者の労働時間を80％増やせば帳尻が合うという話から、簡単にデスマーチに陥ると説明しているのが分かりやすい。
実際は簡単なモデルでは説明できないだろうが、感覚的にはフィットする。

プロジェクトがデスマーチに陥るきっかけは、各要素の些細なギャップから生まれる。
それらが積み重なって、メンバーはおろかマネージャもプロジェクトをコントロールできなくなる。

【2】興味を惹いたのは、プロジェクト管理の手法として、WF型開発とAgile開発の良い所取りで説明していること。その説明を読むと、過去の経験に裏打ちされているのだろうと納得する点はある。

「用意周到な事前対処」はWF型開発における「前工程の品質確保」。
「積極的な事後対処」はAgile開発における短いサイクルのPDCサイクル(Plan-Do-Check)。

前者はリスク分析マトリクスを連想させる。
つまり、重要度の大きいリスク、頻繁に起きる中程度以上のリスクはあらかじめ事前に対策を立てておき、予防したり対応策を即座に取れるように準備しておく。
あるいは、影響度が低いリスクは放置したり、都度対応で逃げるようにリスクを分けておく。
PMBOKでも立上げ・計画・実行・監視・終結プロセスの中で計画プロセスを最も重視しているのは、計画を立てる段階で自分の頭でシミュレーションしながら、予想できる範囲内のリスクに対応できる準備を整えること。
駄目なマネージャは、計画プロセスの成果物の品質が悪くて、何の準備もなくいきなり海に飛び込もうかとしているかのようだ。

後者は、イテレーション単位のインクリメンタル型開発。
XPの小規模リリースがこのプロセスの本質。
つまり、イテレーション終了時には必ずアウトプットが出来上がるように、少しずつ作っていくこと。
駄目なアジャイル開発のプロジェクトは、そもそもアウトプットが作れなかったり、イテレーションという定期的なサイクルを守れず、イテレーションが長くなりがちになったりする。

アジャイル開発だからと言って、手抜きをしたり、計画を立てないのは違う。
また、せっかくイテレーションという定期的なサイクルで開発しているのに、要求や作業量やリスクをイテレーションで制約をかけることができていないのだ。

計画(双眼鏡)も設計(地図)もブラッシュアップして、不測の事態を避けたり、それに気づきやすくするようにするのが大事。

アジャイル開発の落とし穴の説明も面白い。
これは、漸進型開発(インクリメンタル)と反復型開発(イテレーティブ)の使い分けで解決できると思う。

【3】実際のプロジェクトの進め方の話はとても興味深い。
Scrumのやり方に似ているなあと思った。

但し、いくつか参考になった点はある。
一つは、1点見積りではなく2点見積りにすること。
2点見積もりは最小工数と最大工数の2つで見積もり、バッファ＝最大の見積工数－最小の見積工数として、バッファの半分までで完了できるなら高評価を与える仕組み。
この見積もりを使うと、最小工数までにある程度のアウトプットを作ろうとするし、最大工数までには必ずアウトプットを出そうとするから、学生症候群やパーキンソンの法則という心理学的要素をはねのけることができると言う。

又、PMBOKなどで良く出てくる3点見積りは1点見積りと同じ心理になるので良くないと言う。
何故なら、見積りの最小工数や最大工数よりも平均工数に着目してしまい、2点見積りのような心理効果が発揮されないらしい。
確かに3点見積りは手間がかかるだけで、なかなか見積りにくいと思う。

実際の見積もり手法はプラニングポーカーをやっているようだ。
スクエアが通常のScrumと違うのは、最小工数と最大工数の2枚の見積もりカードを出す点。
それ以外は、一斉にカードを出したり、メンバー同士で食い違ったら互いに説明し合って修正していく点はScrumの見積りに似ている。

二つ目は、PDCサイクルを1日・1週間・1スプリントで意識的に使い分ける運用をしていること。
各メンバーのタスクは1日単位でタスク管理ボードというアナログのかんばんで管理する。
チームは、メンバーの週報を元にチーム定例を週1回開き、進捗確認や課題管理を行う。
そして、スプリントの始めにスプリント計画を立てて、スプリント終了時にメンバー全員でふりかえり会議を行う。
この辺りの話は、XP の開発プロセスの考え方と同じように思える。

- eXtreme Programmingの魅力を探る

更に面白いのは、スプリントふりかえり会と一緒に、成果物発表会を行っていること。
要は顧客の受入テストないしデモなのだが、チーム同士でスプリントの成果物を披露することで、モチベーションが上がるらしい。

この資料を読んで、プロジェクトマネジメントの手法は、業界に関係なく共通のコンテキストがかなりあるように思った。