スクウェア・エニックスの橋本善久氏がプロジェクトマネジメントの手法を紹介。「Agile do IT!」で行われたセッションレポート

　2012年3月19日，ディー・エヌ・エーの主催で，ソフトウェア開発者やプロダクションマネージャーを対象とした講演・ディスカッションのイベント「Agile do it!」が開催された。3月16日に大阪で行われた「Agile Japan」のスピンオフとなる今回のイベントでは，“マスター・センセイ”と称される「The Agile Samurai: How Agile Masters Deliver Great Software」（邦題 アジャイルサムライ−達人開発者への道−）の著者Jonathan Rasmusson氏を迎えてのトークセッションや，ヤフー，ディー・エヌ・エー，スクウェア・エニックスといった各社におけるアジャイルやスクラム（アジャイル開発の手法の一種）に関する取り組み事例の紹介が行われている。

　イベントのタイトルにも用いられている「Agile」（アジャイル）とは，「敏捷な」「活発な」といった意味の英単語で，転じて，より効率よく迅速にソフトウェアを開発するための手法の総称として用いられているものだ。
　そんなイベントの中から，本稿ではスクウェア・エニックスの橋本善久氏によるセッション「ゲーム開発プロジェクトマネジメント事例紹介〜不確実性を乗りこなせ〜」のレポートをお届けしよう。

スクウェア・エニックス CTO 橋本善久氏

　まず橋本氏がどういった人物なのかを紹介しておくと，氏はスクウェア・エニックス テクノロジー推進部のジェネラルマネージャーとしてゲームエンジン「Luminous Studio」のプロデューサー兼ディレクターや，ハイエンドリアルタイム映像作品「Philosophy」のプロデューサー兼ディレクター，さらに「FINAL FANTASY XIV」のテクニカルディレクターも務めている人物である（関連記事）。
　橋本氏は，AAAクラスのゲームタイトルを開発するため，より良いゲームエンジンの制作とプロジェクトマネジメントに注力しており，年々高度化・複雑化を重ねているゲーム開発の現場においては，地に足の着いたプロジェクトマネジメント方法論の構築が急務だという。今回実施されたセッションでは，橋本氏が実際にスクウェア・エニックスで行っているプロジェクトマネジメントの考え方と手法が紹介されていった。

　セッションに登壇した橋本氏はまず，「プロジェクトの初期に立てた計画はどれほどの誤差を生むのでしょうか？」と聴衆に問いかける。プロジェクトは，細々としたエラーが往々にして発生するものであるため，そうしたエラーが積み重なることを考慮して誤差を試算してみると，なんと「当初の計画比で約10倍」という驚くべき誤差が出てきてしまうこともあると橋本氏は言う。

　10倍というと現実味のない数字に聞こえるかもしれないが，実際のところ，さまざまなプロジェクトの現場で日常的に誤差は発生している。その誤差を解決するために，仕様の削減，人員の追加投入，期間の延長，品質の妥協，そして労働時間の増加，といったいわゆる「デスマーチ」が敢行され，強引に修正されることも少なくないと橋本氏。氏が挙げた解決策の例は，セッションの来場者たちにも思い当たるところがあるようで，客席からは苦笑の声も漏れ聞こえていた。

　そういった誤差の数字と解決策の例を元に橋本氏は，「プロジェクトの正確な予想は不可能」だと断言する。そのうえで，「プロジェクトとは不確実なものであるという前提があるからこそ，用意周到な事前対策と積極的な事後対策を実践することで，プロジェクトを制御することが可能になる」という。
　ここでの事前対策とは，計画規模自体を小さくして確実性を高めたり，あるいは，いわゆる「トカゲのしっぽ」を増やすことで有事の際に切り捨てられるようにしたりするプロジェクト設計である。


　具体的なプロジェクトマネジメントとしては，「調査する」「戦略を立てる」「設計する」「計画する」「スプリント」といった手順が重要だと橋本氏は語る。

　「戦略を立てる」というプロセスでは，入力と出力を念頭に置いて，入力のコストや出力されるものの価値などを概算したり，どの優先度が高いかなどを試算したり，どこから決定していくかなどを考慮したりする「プロジェクトの天秤」という考え方を紹介。また，プロジェクトの天秤に伴う「開発戦略マトリクス」や「商品の価値空間」といった要素も解説した。
　「計画する」プロセスでは，例えば，あるタスクを“4日で終わらせる”とするとした場合，完了の1点のみを考えた「1点見積もり」と，途中経過も考慮に入れた「2点見積もり」とを比較し，「2点見積もり」のメリットが語られた。「2点見積もり」では，「1点見積もり」よりもタスクへのモチベーションが高いまま維持できるとのことだ。ほかにも，プロジェクト日数を決める場合の目安として，「準備」「実装」「仕上げ」といった3つのプロセスをそれぞれ同じ長さで仮定する「1:1:1の法則」を紹介している。
　「スプリント」とは，2週間もしくは4週間のような短い期間を単位としてプロジェクトを管理する方法（ないし，反復期間）を指す。「タスク管理ボード」や「朝会」などを導入し，プロジェクトの進行度合いを班内で把握できるようにしたり，プロジェクト終了後に「振り返り会」を実施したりすることでメンバーのモチベーションを上げるメリットがあるという。


　橋本氏はアジャイルについて，「私たちがやっていることがアジャイルか非アジャイルであるかについては，あまり興味がないというスタンス」だという。その一方で，ソフトウェア開発の現場においてアジャイルが「楽をするための免罪符」的に曲解されていることを危惧する。
　橋本氏は，アジャイルに対してそうした誤解が起こる理由を，「建物を建てる」という例を用いて紹介した。1人でも作れる「犬小屋」と，建築に多くの人数が必要となる「超高層ビル」という対照的な建物を挙げ，「これらに同じ方法論は通用しない」という。超高層ビルを無計画で建てようとする人はいないが，ソフトウェア開発の現場ではそうしたことが往々にして起こると橋本氏。ソフトウェア開発では，規模や問題が見えにくいため，問題が表面化してどうしようもなくなるまで“とりあえず作る”ことができてしまうことが理由とのことだ。

　こうした建物の例を踏まえて「不確実性を乗りこなす」という本題に戻ると，「事前対策」は“防火”，「事後対策」は“消火”に該当すると橋本氏は言う。つまり，ひたすら防火活動をしたところで，出火の可能性はゼロにならないため，消火活動に失敗すれば“大炎上”してしまうというわけだ。もちろんその逆も然りで，防火活動をせずに消火活動だけに頼ってしまうと，消火しきれずに“大炎上”の結果を招いてしまう。防火と消火の両方に質の高さが要求されるのだ。
　しかし，いわゆる「ウォーターフォール型」開発モデルの場合は防火しか行われず，また，間違ったアジャイルの場合は消火しか行わなれない。そのため，橋本氏は，ウォーターフォールとアジャイル，それぞれの持ち味を活かすことが重要だと強調する。

　こうしたプロジェクトマネジメントを実践している橋本氏だが，今後は各職種の特徴に合わせて方法を調整したり，タスク管理システムをアプリケーション化したりといった方法でより効率アップを図っていくそうだ。
　橋本氏は最後に「プロジェクトマネジメントをうまく行うコツは，そのやり方をなぜ行うのかを常に深く考察し，心理力学や情報の流れを徹底的に意識したうえで，論理的に仕組みを組み上げながら改善し続けること」と語る。「思考停止しない」ことこそがプロジェクトマネジメントをうまく行う最大のポイントであると述べ，講演を締めくくった。

　なお，今回のイベントは定員150名が満員御礼となるほどの人気ぶりで，ソフトウェア開発者の間でアジャイルの注目度の高さがうかがえるものだった。現場における実践的な話が中心ではあったが，ソフトウェア開発に直接は携わっていない人にとっても，学べる部分の大きいセッションだったと言えそうだ。