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

８．「リーダーは誰」

　仕様書がない中でも、締切は細かく設定される。

　一体、どうやってプログラマが作る内容を決めているのかというと、つまり口頭での指示、ということになる。

　会議で決まった内容を、会議室から飛び出してきた河原さんがプログラマたちに伝え、プログラマは聞いた内容を頼りに実装をしていくことになる。

「最近流行りのアジャイル開発（※）らしいよ」

「……絶対ちがうと思う」

　そんな会話がされる間にも、次の締切が迫ってくるという有様だった。

　それでも、アルファ版の開発開始から２カ月ほども立つと、曲がりなりにも動くものが出来て来ていた。

　そしてそれがまた、次の問題を呼ぶこととなる。

「……あれ？　ここってどうなってるの？」

　眞山が声をあげる声が、少し離れた自分のデスクにまで聞こえてきた。

「え、どういうこと？」

「ここが、ほらこうなってるんだけど……」

「あ……ああ……合わないね……」

　眞山のところに、先輩格のプログラマがやってきて話を始め、そこに他のスタッフも集まってきていた。

　後から聞いた話だったが、その時眞山が実装していたバトル内のグラフィック演出と、先に実装されていたバトルでのキャラクターのデータ処理に整合性がとれない、というのだ。

　宮谷くんがそこへやってきた。眞山たちから説明を受け、頭を抱えて頷く。

「……わかった、なんとかします」

　原因は明白だった。

　何人かのプランナーが発注元企業の担当者とそれぞれに打ち合わせを行い、お互いに整合性を取らないまま、プログラマに「とりあえず」の実装を伝えていたのだ。

「だから仕様書を早く作れっていってんだろ！」

　眞山が大声を上げるのが聞こえた。隣の先輩プログラマが眞山をなだめる。

　怒るのももっともだ。締切に追われているというのに、作ったプログラムをほとんど作り直さなければならないのだから。

　仕様書はまったく出来ていないわけではなかった。

　宮谷くんがいつも深夜まで残業をしながら、会議の内容をひとつずつドキュメントにしている。

　しかし、ほとんど会議に時間を取られ、会議のたびに話す内容が変わるという状況で、作られた仕様書はどんどん内容が古くなっていくという有様。

　この時、眞山が大声を出したためか、業務改善のための会議が伊佐崎たちと持たれることになった。

「会議が多すぎて、プランナーの作業時間が確保できません。仕様書が間にあわず、実装に影響が出ています」

「なるほど、会議を減らす必要がありますね」

「そうしていただけると」

「しかし、それぞれの会議の内容は必要なものなので」

「どうしましょうか」

「……」

「……」

「全体定例、やめましょうか」

「そうですね、全員が参加するのは無駄ですし」

　――と、そんな流れで、全員が参加して進捗を報告し合う全体の定例ミーティングは廃止となり、宮谷くんは仕様書を書く時間を取ることができるようになった。

　この話のオチについてはもうわかると思うけど、整合性の取れない仕様はここから更に加速していくことになる。

　当たり前だ、それぞれのセクションが勝手に作ってるんだから――

　＊　＊　＊

　ある日のこと。

　ガモノハスではプロジェクトチーム単位での会議の他にも、プログラムチーム、デザイナーチームなど、職種毎に集まってする社内定例会議の時間がある。

　プランナーチームもまた、水曜日に３０分程度集まって、それぞれの担当プロジェクトについて報告するのが常だった。

「……それじゃ、次はDMプロジェクトの報告をお願い」

　プランナーチームのマネージャーがそう言うと、会議室に沈黙が降りた。

　田山はなにも言わない。河原さんも言わない。宮谷くんも言わない。

「リーダー、田山さんでしょ？」

　誰かが言った。

　田山はわざとらしく驚いてみせる。

「え？　俺は伊佐崎さんと話をする窓口であって、リーダーではないよ？」

　――？？？

　会議室に集まったプランナーたちの頭上に？マークが浮かんだのを俺は見た。

「……まぁ、別に誰でもいいんだけど、じゃぁ誰が報告するの？」

　事なかれ主義ここに極まれり、といった様子のマネージャーが水を向ける。

「宮谷くんでいいんじゃない？」

「え……僕っすか？」

「だって一番仕様を把握してるの宮谷くんだもん」

　田山から投げやりにそう言われ、宮谷くんは戸惑いながら手もとのメモを見、報告を話し出した。

　――なんなんだろう、この男は――

　元々いけ好かないと思っていた相手だったが、この時ばかりはもはや、恐怖感さえ覚えた。

　そして、ゲームの全体像を誰も把握しないまま、プロジェクトは暴走を始める。

　次の締切、α版プログラムの提出は、残り３カ月強に迫っていた。

－－－－－－－－－－－－－－

※アジャイル開発

…小規模な開発チームを作り、短期間に決定、実装、テスト、修正を繰り返すことでフットワークの軽い開発を目指すチームマネジメントの手法。

　「仕様書を書かなくてもいい」と曲解したIT業界で一時期大流行し、多くのプロジェクトを炎上させた。