大炎上プロジェクトを立て直した話をする。

大炎上プロジェクト、立て直す。

２３．「スケジュールを作れ」

　本格的な開発がスタートした。

　まずは開発概要書に従い、これまでに作られた機能を整理して流用、改造などの算段をつける。

　とはいえ、プログラマのほとんどは経験の浅い新人だ。設計を任せられるはずもない。

　そういう人員は、実作業に先立ってプログラムコードを読み込み、どこでどういう処理をしているか、確認をしてもらう。

　並行して、ヘルプで入った環境整備担当の郷山さんが今回のプロジェクトでのコーディング基本ルールを用意してくれた。人によってバラバラになりがちなプログラムの書き方を統一するルールだ。地味だが、効率的な開発をするには非常に重要な、効果の高い仕事だった。さすがベテランである。

　その他、環境整備だの仕様検討ミーティングだのをしているうちに、瞬く間に一週間が過ぎてしまっていた。

「いい加減、スケジュールを立てないと……」

　全体のスケジュールは、ただ進捗を把握するためのものではない。なにをどのような順番で実装し、いつごろなにが完成しているのか――その計画を立てるためのものだ。

　例えば、バトルそのものが出来ていないのに、召喚獣の演出だけを先に作っても仕方ないのだ。また、手空きになる人員が出ないように、順番と分担とをバランスよく考えながら作り上げる作業計画――それが「スケジュール」だ。締切はその結果として設けられるのが理想。

　まず、残り１１か月の開発期間をいくつかに区切る。便宜上、最初の４か月を「α２」、次の５カ月を「β２」、そして最後の２カ月をデバッグ（※）の期間として「マスター」（※）とした。

　そして、それぞれの開発期間でなにを実装していくのかを決めていく。これは伊佐崎たちとも調整が必要な部分だ。特にα２版で開発する内容については、それでそのゲームが面白いかどうかを判断しうるものにしなくてはならない。

「……ただ、そこでもし面白くない、ってなっても、作り直す時間はないんだよなぁ」

　眞山がボヤく。

　――そうなのだ。そもそも、期間ありきで決められているスケジュールでは、「検証」や「試行錯誤」の時間は確保できず、とにかく作りきって終わり、となる場合が多い。

　某大型RPGタイトルのように、売上が確実に見込めるものであれば、こだわっていつまでも作っている、ということもあるかもしれないが、大抵の場合、そんな予算も、それに時間もないのが普通だ。期間がズレれば、企業の経営計画そのものがズレてしまう。

　それでも、今回はα２版のあとに、１カ月の「検証期間」を確保することに成功していた。比良賀さんが交渉してくれたお陰だ。

　だが、大幅に作り直すには時間が足りない。そうなったらそれこそ、またデスマーチが確定してしまう。だからなるべく、α版をしっかりと作り込みたかった。

「この前の開発概要書で、それぞれの開発にどれくらいかかるかある程度見積もりはできるけど、やっぱり詳細な仕様書がなる早で必要だな」

「そうねぇ、クオリティの担保って意味でも、仕様書があればもう少し具体的な話ができるよね」

　――と、そんな話をしている時、俺のPCのディスプレイの隅に、チャットツールのポップアップウィンドウが表示された。

「……ん、宮谷くんだ」

「です。今送りました」

　後ろから声がして振り返ると、いつの間にか宮谷くんが背後に立っていた。

「……なんでチャットをわざわざ？」

　そう言いながら、宮谷くんから送られたチャットのウィンドウを開くと、そこにはファイルサーバーのパスが記載されていた。俺はマウスでそれをダブルクリックし、フォルダを開く。

「……え……え！？」

　そこには「DM2_仕様書」と書かれたフォルダ――その中には、機能ごとに階層分けされたフォルダがさらに置かれ、Excelやパワーポイントで作られた仕様書が置かれていた。

「一応、これでひと通り。粗はあると思いますが……」

「い、いや、仕様書作成はお願いしたけど、こんなに早く……」

　宮谷くんが主要な仕様を完成させたら、他のプランナーも手伝って全体の仕様書を詰めていくつもりだったのだ。しかし、そこにはほとんど全体の仕様書が網羅されていた。

「今回はやることも明確だったので」

　涼しい顔で言う宮谷くん。手の早さは知っていたが、これほどとは――

「でもプログラマの検証はしてないよね？　ちゃんとこれで組めるか精査がされてない仕様では……」

　横から眞山が言うのを、俺は留めた。

「いや、一度全部仕上げてあるんだから、これから精査をすればその方が早い。手分けして取りかかろう。宮谷くん、ありがとう」

　宮谷くんは普段使わない筋肉を使い、笑った。

　俺はスケジュール表に向き直る。そういうことなら、スケジュールの組み方も変わってくる。

「眞山、仕様書を精査しながら、機能の見積もりをしよう。その上で、担当のプログラマとプランナーとを割り振る」

「わかった。いつ」

「今、ここで」

「……マジか」

　そこから半日丸々かけて、俺と眞山はExcel方眼紙と睨めっこを続け、スケジュールを組み上げていった。

　各機能が何日くらいで対応可能か、という作業見積もり、そして担当人員を割り振り、担当人員によって例えば新人プログラマであれば見積もりを多めに取る。ただし、開発が可能な順番というものもあるので、それも入れ替えながらスムーズな流れを試行錯誤する。

　スタッフのスキル、開発の順番、機能の開発コスト――複数の要素をあれこれと組み替えるパズルは非常に難解で、時には強引な解（「ここは休日も出てもらおう」とか）なども駆使しながら、俺たちはスケジュールを組み上げた。

「……完璧だ……」

「……まぁ、どうせこの通りにはいかないんだけどな……」

　それでも、指標があるとないとではまったく話が違う。

　遅れるにしても、「どれだけ遅れているか」がわからなければ取り戻しようもないのだから。

　俺は宮谷くんに心の中でまた頭を下げながら、それをA3用紙にプリントアウトして社内に貼りだした。

　DM２版、リリースまであと１１ヶ月弱。

　そして、次の締め切り、α２版まではあと、3カ月弱。

---------------------------------

※マスター、デバッグ

…β版まででひと通りの開発は終えた上で、最終調整、およびプログラムの不具合（バグ）を修正する期間を「マスター期間」と呼ぶ。このうち、バグ修正についてを「デバッグ」と呼ぶ。

　β版までですべて開発は終えているはずなのに、マスター期間に入ってもずっと開発が続いていることが多い――というか大抵そうなるが、マスター期間はバッファではないぞ。