規模の拡大に強い開発体制とは

今年のCEDECでは開発プロセスやプロジェクトマネージメントに関するセッションが多くありました。本当に多かった為に自分は全てのセッションを見れていません。

近年プロジェクトマネージメントが注目されて来た事もあり、安定したスケジュールでリリースを行うノウハウは共有されてきましたが、どうしても特定人物に負担が集まる傾向が何処でもあり、その解決の糸口になるセッションを探していた所、注目のセッションがありました。

「CEDEC2012」スケールアウトできる開発体制構築の取り組み
http://jcgs.co.jp/presentation/CEDEC2012-C12_P0206_public.pdf


とても、ためになる話が多かったのですが、規模の拡大を行う為に標準化で対応しようとしていた事が少し気にかかりました。


使用する技術の標準化を行う事で、誰でも標準化された技術の恩恵を受ける事が出来ますが、自分の経験では標準化自体がボトルネックを生みだす原因になった事が多くあります。

技術を標準化するという事は、みんなで集まって話し合ったり、誰かに決めてもらうなりして、基準を決める必要があります。

そして標準化を行うプロセスは、関わる人数が多くなればなるほど変化に対応出来なくなって行き、標準化自体がボトルネックになって行きます。


同じような問題がゲーム開発プロジェクトでも起きています。

日本のゲームデベロッパーでは通常、トップのプロデューサーの下にディレクター、その下は職種ごとリーダーが設定されて組織が作られます。

この体制はトップに明確なビジョンがあり、解決すべき問題が事前に分かっている場合には、とても有効です。

しかし新しいチャレンジを行っているような場合には、意思決定やタスクの配分を行う頻度が多くなるため、ディレクターや職種のリーダーがプロジェクトのボトルネックになります。

限られた人間が意思決定を行う形式では変化に対応する事が難しいのです。
また大勢の人を集めて意思決定を行う事も困難です。


この問題に対して、スクラム等のアジャイルな開発プロセスを導入しているプロジェクトでは、一つの解決策を提案しています。

目的のユーザー体験を実現する為に、職種を横断してプログラマやゲームデザイナー、アーティストを集めた、一つの小さなチームを作るのです。

小さなチームでは、大きな目標をディレクターやリーダーから提示されますが、仕様や実装について細かな指示や確認は必要とされません。

このような体制ならば、想定外の問題が発生してトライアンドエラーが多くなっても、ディレクターや職種のリーダーに負担は集まりません。

プロジェクトの規模の拡大に対応できます。


実際に自分は、このプロジェクトチームの中に、小さなチームを作る方法を運用した事があります。
当時の自分はプロジェクトの重要な立場を二つ兼務していた為に、仕事量がキャパシティーを超えていました。
小さなチームにある程度の権限を委譲する事により、自分がボトルネックになる事は避けられましたが、各チームの結果は、うまく行ったチームと上手く行かなかったチームがありました。

比較的、ゲーム開発経験が長い開発者がアサインされた小チームはうまく行きましたが、経験の少ない開発者がアサインされた小チームは多くの問題が発生しました。
チームには一通りの事を自分達で完結出来るだけの能力が必要でした。


個人をリスク要因にせずに、規模を拡大できる開発体制とは二つの意味があると思います。
個人が持っている能力をみんなで共有する事と、特定個人の仕事量に全体を依存させない事です。

どちらも重要な事だと思いますが、規模拡大のために必要な手段は、直面している問題と自分たちが置かれている状況により、異なってくると思います。

自分の感覚では、プロジェクトチームの組織のあり方についての議論が少ないような気がしていたので、このようなエントリを書きました。

このような議論が活発になる事を期待しています。


最後に今年のCEDECでは小チームへの権限委譲について話されていたセッションがあったため紹介いたします。
CEDiLに資料がアップされたらダウンロードする事をお勧めします。

バックログをゲームデザインドキュメントとして使う
http://cedec.cesa.or.jp/2012/program/BM/C12_P0232.html