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

２４．「プロデューサーにいつ見せるか？」

「ワークフローを作ってください」

　比良賀さんからの、それは強めの要望として会議の場で出された。

　先日決めたスケジュールを提示し、それぞれの仕様書のレビューを行っている最中のことだ。

　問題となったのは、「どのタイミングで伊佐崎がチェックするのか」ということ。総合プロデューサーによるクオリティチェックは必須だ。それはわかっている。

　しかし一方でこれは非常にデリケートな問題でもある。

　すべてを細かくチェックするようなマイクロマネジメント（※）をすれば、また前回の二の舞だ。こちらとしては出来るだけ、チェックは少なくしたい。

　一方で、一切チェックをせずに完成し、後から「こんなんじゃダメだ！」とちゃぶ台返しを喰らうようでは元も子もない。

「どのタイミングでこちらがクオリティチェックを行うのか、また、ガモノハスさん側のチェックもどのタイミングで行われ、誰がそのクオリティに責任を持つのか、明確にしてください。それでどうですか？」

　それはこちらへの提案というよりも、伊佐崎への提案だった。

　こちらのスケジュールと仕様を提示された伊佐崎が、また細かい修正指示と「レポート提出」を求め始めたのだ。

　修正指示はともかくとして、レポートについては事前に比良賀さんに相談をしていたところだった。スケジュールが厳しい中、それは絶対に回避しなくてはならなかった。

　そこで、伊佐崎がその話をし始めようとしたところで比良賀さんが助け船を出してくれたのだった。

「ここまで仕様が出来ているのであれば、製作意図をいちいち提出するまでもないでしょう。書類を見ればある程度わかりますし、概要書に記された方針はこちらも納得できるものです。なにより、確かに時間がない」

　比良賀さんがガモノハス側との仕切りを一任されているのは伊佐崎も把握している。それにどうやら、比良賀さんは発注元企業内でも独自の立ち位置を確保しているようだった。

　渋い顔をしている伊佐崎に、比良賀さんが重ねて言う。

「だから開発の細部についてはガモノハスさんたちに任せた方がいいでしょう。

ただ、クオリティに関して、こちらもしっかりとコントロールをしなければならない」

「……それはもちろんだ」

「なので、そのフローを今のうちに作っておきましょう。お願いできますね？」

「わかりました。こちらとしても、仕事の進め方は決めておかなければいけません。クオリティチェックのトリガーについてはこちらが持つことになると思いますが」

　俺と比良賀さんのやり取りに、伊佐崎も頷いた。

　＊　＊　＊

「そう、どちらにせよワークフローは決めないといけないんだよな」

　会議が終わってから、眞山が言う。その隣にいた郷山さんが、椅子を半回転させてこちらに向き直った。

「今回、タスク管理ツールはどうするの？　Redmine？」

「うーん、あれ、放置されると意味ないんだよね……」

「そこはディレクターがちゃんと見てもらわないと！」

「いやまぁ、そうなんだけどさ」

　タスクの進捗管理は集中的に行われなければ意味がない。それをどのように管理するかも、悩みの種だった。なにしろ参加メンバーが多いのだ。

　眞山と郷山さんと、３人で頭を突き合わせ、伊佐崎によるプロデューサーチェックのタイミングをあわせて考える。

「プログラマ側はこちらで管理するよ。タスクを細かく分けて、Redmineにチケットとして登録してく。メンバーはそれだけ見ればいいようにして、週イチのミーティングでひとつひとつ進捗を確認する」

「わかった。それじゃぁ、チケットが更新されたら、担当プランナーにも通知がいくようにウォッチャー（※）入れといてもらって」

「で、進捗の中に『Pチェック』っていうステータスを用意する。プロデューサーのクオリティチェックがOKになったら、次のステータス（※）に進めるようにする、と」

　この辺りはデザイナー側の仕事とも関わる話だった。

　ＵＩデザインやエフェクトなどについてはプログラムとも密接に関わるものだし、見た目的に伊佐崎も非常に気にするところでもあった。

　そうしたものは事前にプロデューサーチェックを行うようにし、「こういう完成形になります」というのを早い段階で確認しておく。プログラム上で実装をした後は、ボタンのレスポンスや挙動、操作のしやすさなどを確認するにとどめ、見た目の調整は後からしないように進める。

　完成してからひっくり返る、というのが一番怖い。

　だから、出来たものは俺の方で取りまとめを行い、その都度比良賀さんへ投げて確認をとるという流れを作った。比良賀さんの方では伊佐崎に確認を取りつつ、物によっては他の担当者に投げて意見を聞いてもらう。

　ＵＩ、３Ｄモデル、演出など、各項目についてどのタイミングで確認をしてもらい、そして伊佐崎の見ていないところではどのように開発が進んでいるのかも合わせて一覧にした資料を作成し、提出すると、伊佐崎は納得をしたようだった。

　――つまり、それが比良賀さんの目論みだったのだろう。うまいこと動かされてしまったようだ。

　そして開発が進み始めた。奔走をしている内に、いつの間にかα２版まであと２ヶ月を切っていた。

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

※ウォッチャー

…タスク管理ツールの機能のひとつ。

　あるタスクが記載された「チケット」を担当者が更新すると、「ウォッチャー」に設定された人間にもメールで通知が飛ぶようになる。

　ディレクターだからって全部のタスクに「ウォッチャー」を入れるとメールがえらいことになって返ってタスク管理ツールを使わない元になる。

※ステータス

…タスクの状態のこと。

　登録された直後は「新規」、そのタスクを振られた担当者が確認したら、ステータスを「進行中」とし、実装ができたら「実装済み/確認待ち」、確認が取れたら「完了」とするなどして管理していく。

　このステータスをちゃんと進めて、しかもその進めるタイミングに共通認識が出来てないと荒れる。