［SQEXOC］プロジェクトを失敗させないためには？　スクウェア・エニックスで実施されているプロジェクト管理術公開

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

　10月8日，東京・新宿で開催された「スクウェア・エニックス オープンカンファレンス2011」で，同社CTO/テクノロジー推進部担当コーポレートエグゼクティブ 兼 ジェネラルマネージャー/新世代ゲームエンジンLuminous Studio プロデューサー 兼 テクニカルディレクター/リアルタイムテクノロジーデモPhilosophy プロデューサー 兼 総合ディレクター/FINAL FANTASY XIV テクニカルディレクター橋本善久氏によって「ゲーム開発プロジェクトマネジメント講座」と題した講演が行われた。
　肩書きからも分かるように橋本氏は，さまざまなプロジェクトを担当している。そんな氏により，スクェア・エニックスで実際に使われているプロジェクトマネジメント手法が紹介された。

　冒頭，橋本氏は「なぜプロジェクトは失敗するのか？」と問い，プロジェクト失敗のポイントを6種類挙げた。すなわち，

• スコープの問題（仕様変更）
• 品質の問題
• コストの問題
• 時間の問題
• リソースの問題（人員など）
• ビジネスの問題

だ。これらのポイントが複雑に絡み合ってプロジェクトの予定に誤差が生じてくる。


　上記のように，プロジェクトの失敗というのにもいろいろあるのだが，講演では，主に時間的な失敗に焦点を当てて話が展開されていたので，以下の記述も基本的に時間的な問題のみを念頭に置いて読んだほうが分かりやすいだろう。


　話を戻そう。では，その誤差はどれくらいになるのかと，橋本氏は試算を始めた。かなり単純化された例だが，まず，変動要因を8つ挙げ，それぞれでエラーが発生した場合を以下の図のように見積もり，その累計が10倍もの誤差になりうることを指摘した。2年で開発する予定のものだと，20年かかる計算だ。もちろん，これらの要因がすべて掛け算で効いてくる状況ばかりではないだろうが，かなり大きな変動になる可能性があることは間違いないだろう。


　では，どうやって対処するか？　仕様の縮小，人員追加投入，開発期間延長，品質の妥協などを行ってもまだ足りない。最終的には，労働時間を大幅に拡大することで辻褄を合わせることが多いのは，ソフトウェア業界共通の問題といえるだろう。
　こういった悲劇も，各項目での見積もりエラーによって引き起こされているものだが，「プロジェクトの正確な予想なんて不可能」であると橋本氏は語る。


　では，プロジェクトマネジメントに意味はないかというと，そうではなく，プロジェクトは不確実なものであることを前提にしたプロジェクト管理をすることが重要だと橋本氏は説く。そして氏は，その要点を「プロアクティブな対応」だとしている。事前対処型の進行にすることでプロジェクトの制御が可能になるのだそうだ。


　不確実性を前提とした事前対処策としては，

• 不確実性を減らす
• 不確実でもよいことにする

といった2つの方向性が示された。「不確実性を減らす」というのは，プロジェクトの見通しをよくし，見積もり精度を上げたり，最初からリスクの少ない仕様にしておくというもの。「不確実でもよいことにする」というのはちょっと分かりにくいが，講演では，仕様の作り方で，RPGでの「街」が例に挙げられた。NPCやモデリングデータも多くて実装が簡単ではないという場合，最悪，街がなくてもゲームの進行に問題がないような仕様にしておくという対処法だ。これらを簡単にまとめると，（ありがちだが）「アジャイル開発手法を活用しよう」ということになる。

　アジャイル手法にもいろいろあるのだが，ほぼすべてに共通するのが，小スパン期間で小規模開発のイテレーション（計画−設計−検証の反復）を回していくという部分だ。そのメリットについて例を挙げながら解説されたのだが，かなり一般的な内容なのでここでは割愛する。要は「軌道修正しやすい」ということだ。
　では，イテレーションを細かく回せばすべて解決かというと，そうではないという。橋本氏は，犬小屋を作る場合と高層ビルを建設する場合を例に，大規模開発では綿密な計画を立てて作業していくことが不可欠と説いた。　完全な設計と仕様策定をしたうえで開発にとりかかる手法が，（アジャイル勢に悪とされることの多い）ウォーターフォール型開発であるわけで，工業分野では常識的なことが，ソフトウェア開発ではなぜかおろそかにされているという。大規模開発ではアジャイル手法を取り入れたからといって，ウォーターフォールで必要とされた綿密な調査・設計・計画からは免れられないということを強調した。


　以降はで，スクウェア・エニックス　テクノロジー推進部で導入されているプロジェクトマネジメント手法の解説が行われるのだが，大規模開発での開発の細部にスクラムをベースにしたと思われるアジャイル手法を取り入れた独特なものとなっている。

橋本氏のプロジェクトマネジメントの実際

　橋本氏は，プロジェクトマネジメントの要点として以下の4点を挙げ，今回は計画と制作の部分に絞って同社の取り組みを絡めて，ゲームでの大規模プロジェクトの進め方について解説していた。

• 調査
• 設計
• 計画
• 制作

　これらのうち，プロジェクトでの計画部分の進め方を，氏は3段階に分けて紹介した。

• タスクを列挙する
• タスクを見積もる
• 優先度をつける

　タスクの列挙では，ユーザーストーリーに基づいた項目出しを行う。

　「ユーザーストーリー」とは，「ゲームで実現したいことを文章で表現したもの」であるとし，特徴としては語尾が「できる」になるものが多いとのこと。要点としては漏れをなくすことが重要で，内容的に重複するものがあってもかまわないのでできるだけ多くの要素を挙げることだそうだ。多くの人がリストを持ち寄り，マインドマップツールなどを使ってまとめるとよいとのこと。

　続いて，「フィーチャー」とは，ユーザーストーリーを実現するために制作しなければならない機能などを挙げたものとなる。「〜システム」などの名詞形になることが多いという。作業上は，大きな作業のまとまりとして扱われ，同じフィーチャーで複数のユーザーストーリーが実現できることも少なくないという。


　フィーチャーを，個人の作業単位にまで分割したものは「タスク」と呼ばれている。1日あたり1，2タスクがこなせるような作業量にまで分割していく。ただ，すべての作業をあらかじめタスクに分割するという作業は現実的ではないので，タスク分割は作業を進めながらLOD（Level of Detail）的に行うのがよいとのこと。

　さて，このタスクを実際に進めていくうえでの作業は，タスクの列挙（タスクの分解時に終わっている），タスクの見積もり，タスクに優先度を付けるといった3段階で行われるとし，タスクに優先度を付けた時点ですでにスケジュールが出来上がっていると橋本氏は解説した。

　まず，見積もりには，1点見積もりと2点見積もりがあると紹介し，2点見積もりのメリットを解説していた。1点見積もりとは，「締め切りは4日後」といった感じで，単一の期限を設けるもの。2点見積もりとは，「締め切りは最短3日後，最悪でも5日後で」といった感じで期間を設定しておくタイプのものを指す。

　1点見積もりだと，とりあえずできあがると，それ以上できるのにやらない（パーキンソンの法則），ギリギリになるまで手をつけない（学生症候群），いったん締め切りを超えてしまうと，あとはいくら遅れても同じと考える（のど元過ぎれば熱さ忘れるの法則）といった問題が発生しやすいのだという。

　2点見積もりだと心理学的にそういった問題が置きにくく，統計的には，だいたい4日でちゃんと仕上がることが多いのだそうだ。ちなみに，2点見積もりの期日の決め方は，それぞれ確度20％くらいのところを設定するとよいとのこと。「すごく順調にいけば3日でできるけど，まあその確率は20％くらい」「難航したら5日かかるかも。確度20％くらい」といった感じで見積もりを行うわけだ。


　さて，当初からの，プロジェクトの誤差を少なくして軌道修正を素早く行おうという目的からすると，この見積もり部分の精度が非常に重要になることは簡単に想像できるだろう。いかにしてこの部分の精度を上げるかについて，面白い手法が取り入れられていた。担当者と上司を含む何人かで「見積もりポーカー」という期日が書かれたカードを持ち寄り，それぞれが妥当と考える2点見積もりの期間のカードを一斉に出すのだそうだ。

　もちろん，ばらつきは出るのだが，なぜ期間が必要と思うのか，なぜ期間が短縮できると思うのかなどについて意見を交換し，再度カードを出す。これを何回か繰り返すと，見積もり期間が収束していき，タスクを繰り返していくにつれて精度も上がってくるという。


　見積もりからスケジュールができた段階で，実際の制作に取り掛かる。なお，開発部分についてのイテレーションについては，「スプリント」というスクラムの用語が使われている。
　橋本氏が進めている手法でのスプリント期間は4週間で固定だそうで，一般的なアジャイル手法と比べると長めな感じではある。スプリントの初日に，タスクや見積もりの細分化などを行い，最終日には振り返りを行う。毎日の朝会から始まり，1日単位，週単位の計画を立てるなど，スプリント期間は長めだが，かなり細かくマネジメントされている。スプリントの終わりには成果物発表会が行われるとのことだが，成果物という形での発表がない場合もあるとのこと。アジャイル手法によっては，必ず成果物を出すことを重視しているものもあるのだが，そのあたりは柔軟な構成のようだ。


　タスクの進行状態は，掲示板に付箋を使ったタスク管理ボードで一覧できるようにしているという。見積もり期間に対して早めに上がったものには青い付箋，通常のものは黄色い付箋，遅れたものは赤い付箋といった感じで，一目で状況が分かる。他社の事例でもボードを使ったものが多いが，こういった部分はあえて電子化しないというのが一般的なようだ。




　こういったプロジェクトマネジメントを導入しての効果としては，やはりプロジェクトの見通しが立てやすいことや軌道修正が簡単なことなどが挙げられていた。参加メンバーも，残業のプレッシャーから解放されるなどメンタルな好影響も出てきているという。
　今回紹介された手法は橋本氏独自のものだが，その詳細については，橋本氏が現在書籍化を進めているとのことなので，興味のある人は発刊を待とう。


　今回は，プロジェクト管理の重要性とアジャイル手法の有効性について紹介されたわけだが，少しもやもやしたものが残った人もいるかもしれない。
　ちょっと意地悪い見方をしてみよう。
　冒頭に挙げた例のように，100人月で見積もっていたものが，破綻して実は結局1000人月のプロジェクトになったという事例があったとして，そのプロジェクトの成果物と，きちんとプロジェクトマネジメントができて100人月で作られた成果物がはたして同じものなのだろうかいった疑問は残る。というか，違うモノになるのが普通だ。一般的なソフトウェア産業の場合，ちゃんと仕様を満たしていればプロジェクトは成功なのだろうが，ゲーム業界の場合，そうはいかない部分もある。
　仮に，最終的な成果物が同じになるとすると，おそらくかかるコストもほぼ同じ。デスマーチ時の，山のような残業を回避するハッピーなマネジメントモデルだと，開発期間は必然的に長くなるのだが，それはそもそも許されるのか。冒頭の例での8割増しの労働時間の代わりに，8割増しの作業効率になったりするのか。
　8割はともかくとして，作業効率自体はおそらく向上すると思われるが，マネジメント手法の導入自体によって増える作業量というものもある。前述のように，残業なしで作ると，みんな忘れた頃にゲームができあがるようなスケジュールになる可能性もある。
　また，仕様から極力リスクを排除していくと，あまり画期的な部分のないゲームができそうだというのはなんとなく分かる話だろう。

　じゃあ，プロジェクト管理に意味はないのかというと，そうではない。大きなリスクを避けるには非常に有用で，プロジェクトの見通しをよくすることも大事なことだ。しかし，さらに，開発効率を上げる方策とリスクの高い開発が許される部門が加わることで，プロジェクト管理は大きな意味を持ってくる。すなわち，Luminous Studioの開発と研究開発部門の存在である。
　Luminous Studioによって，高品質なゲームが低労力で作れるようになることが期待される。また，もともと社運を賭けた大型タイトルで新規開発技術を満載しようと考えるほうが無謀なので，研究開発部門で技術的なめどをつけてから導入する流れができれば，低リスクで大型プロジェクトを進めることがが可能になるだろう。現在，スクウェア・エニックスは，こういったものをまとめて活用することで，ゲーム開発体制を根本から変えようとしているように思われる。実際にこれらが効果を発揮するのはもう少し先のことかもしれないが，うまく回れば日本のゲーム業界にとっては革命的なことになるだろう。同社の今後の動向に注目してみたい。