開発を確実に炎上させる3つのこと

ゲームにオンライン要素が加わって随分経ち、注目はPC からスマートフォン等のモバイル向けに移りつつある。筆者の本業であるコミュニティサービスがオンラインゲームと親和性が高いこともあり、PC、フィーチャーフォン、スマートフォン向けの、アプリ・公式サイト・ブラウザゲームなどさまざまなプラットフォーム向けオンラインゲームの構築や開発支援に携わってきた。また、柔軟さが求められるゲームとは一見対極にも見える、エンタープライズ系システムの設計・構築を手がけたこともあるためなのか、最近はリリース直前や予定日を過ぎた、いわゆる“ 炎上案件” の火消しに呼ばれることも多い。こういった火災現場で共通している“ 出火原因” を述べる。

原因1：人間は間違える動物であるという原則を忘れる

PC、モバイル向けであろうが、コンシューマゲーム機であろうが、デジタルゲームの全てが、ソフトウェアとして実装されることに変わりはない。また、その全ては人間が設計し、実装していることにも変わりはない。人間はよく忘れるのでメモを書くが、これはシステム開発で言えば設計書などを書いたドキュメントに相当する。また、人間はよく間違えるので万が一間違えても最悪な事態が起こらないように予防措置を取るが、プログラミングで言えば関数引数の値域妥当性チェックを厳密にし、不正値が渡されれば確実にエラー処理し、また、それにより不具合を早期発見できるようにすることなどに相当する。火消しのためにコードレビューをすると、ほとんどの場合、ドキュメントといえば初期の企画書程度で、「仕様書＝ソースコード」となる。そのソースコードにしてもコメントもエラーチェックも不十分で、本来期待している動作が何かを推測することすら容易ではない。開発者同士の共通認識の土台となるドキュメントがないことが、認識のズレと間違いの拡大の要因となっていることは多い。

原因2：方法論に惑わされる

“ ソフトウェア工学” は既に歴史のある工学分野だが、最近になり、ようやくゲーム開発現場でも取り上げられるようになった。この分野でここ最近もっとも頻繁に耳にする旬なキーワードは“ アジャイル” だ。アジャイルソフトウェア開発手法は、1 ～ 4 週間程度の比較的短い期間で、計画、要求分析、設計、実装、文書化という工程を反復して行うことを特徴とする。ところで1988 年には設計からプロトタイピングまでを6 ヶ月から2 年程度で繰り返し行う“ スパイラルモデル” という開発手法が提唱されている。また、ソフトウェア開発に限定しないプロジェクト管理一般の手法として、Plan（計画）/Do（実行）/Check（評価）/Act（改善）を反復的に行う“PDCA サイクル” がある。これらは「設計/ 計画→実装/ 実施→改善のために反復」という本質的な特徴が共通しているだけでなく、これらの言葉を用いるまでもなく、開発においてごくごく当たり前に行われることである。方法論とはあくまでも手段としてのベストプラクティスの1 つであり、言葉が定義されることによって目的が最適化されるような銀の弾ではないのだが、プロジェクト管理、設計方法などさまざまな局面で1 つの方法論だけにこだわりすぎていることは多い。

原因3：何のためにそれをするのか目的を共有しない

ソフトウェアをプロダクトという面から見ると、スケジュール、売上、予算など達成すべき目的がある。多くの場合、目的達成に必要な専門分野を持つメンバーによるチームが構成されるが、開発が進めば進むほど各自の専門性が高く局所的な部分に集中していくあまり、局所最適化に陥りがちである。チームとしての目的と、それに向けて各々が何をしているのか常に強く認識が共有されないことで過剰な局所最適化を招き、仕様改善の硬直化もしくは過剰な変更やスケジュール遅延など、目的達成から遠のいていることは多い。

このように、何のためにそれをするのか常に目的を共有し、共有を確実にするためにドキュメントを作り、そして目的を達成するための最適な方法を選択する柔軟さを持つための手間を惜しむと、開発は確実に炎上する。