工程表を作る——制作進行を任されたら②

1. 一覧はできた。その先で誰が待っているか

会話テキストを書き終えたのに、翻訳と音声の作業が動いていない。第1回で取り上げた架空の現場の続きを考えてみよう。

確認待ちの台詞を洗い出し、誰が何をいつまでに行うかも一覧にした。ところが、翻訳担当が確定稿を受け取れる日と、音声担当が収録を始められる日を尋ねられると、すぐには答えられない。各タスクの期限は見えるが、その期限が次の作業とどうつながるのかが見えていないのである。

第1回で紹介したCEDEC 2018の講演レポートでは、タスクに「誰が」「何を」「いつまでにするか」を書く考え方が示されていた。[1] 今回はその一覧に、前後のつながりと余裕を加え、工程表にしていく。

シリーズ共通の判断軸は、 「次の工程が受け取れる状態で渡せているか」 である。第2回では、この問いを工程表の上で確かめる。家庭用ゲームの開発の節目と、運営型タイトルの更新の周期の両方から考えよう。

2. 工程表は「受け渡しの地図」

本稿では、タスクの一覧に 「誰の成果物を、誰が待つか」 を足したものを、工程表の土台と考える。日付に沿って作業を並べるとき、次の作業を始めるための条件までつなぐのである。

冒頭の架空の例なら、翻訳に使う会話テキストを確定し、その翻訳を収録に使い、音声を実装してゲーム上で確認する、といった流れになる。ただし、翻訳と収録の順序は、収録する言語や制作体制によって変わる。ここでは、翻訳した台詞を収録する場合を例にする。

この関係を矢印でつなぐと、期限を一つ動かしたとき、どこまで確認し直す必要があるかが分かる。待たれている作業の遅れは、その先で待つすべての作業に影響しうる。途中に余裕があれば吸収できるが、余裕を使い切れば後の予定も動く。

進行としてまず見つけたいのは、 どの作業が遅れると全体の終わりが動くか である。会話テキストの確定が遅れたとき、翻訳だけを見るのではなく、その先の確認完了までたどる。イラストを待つ実装があれば、その流れも合流させる。こうして、次の節目に間に合うかを、作業のつながりから考えられるようになる。

3. 並行させるために、先に作るものを決める

すべての作業を順番待ちにすると、後の工程が長く待つことになる。並行して進めるには、どこまで用意すれば別の担当者が作業を始められるかを決めたい。

CEDEC 2012では、スクウェア・エニックス 開発部 ドラゴンクエストX デザインセクションマネージャーの荒木竜馬氏が、『ドラゴンクエストX』の開発進捗管理を紹介した。肩書きは講演当時のものである。マップ制作では、ひな形となるマップができた段階で、3つのセクションが並行して作業に入る流れを組んでいた。[2]

完成したマップを全員が順に待つのではなく、次の担当者が使えるひな形を先に渡す。その区切りがあれば、各セクションは自分の作業を進められる。

『バンドリ！ ガールズバンドパーティ！』（以下、『ガルパ』）のCEDEC 2019の事例にも、並行して進めるための順序が見える。講演したのは、Craft Egg 開発部 キャラクター演出チーム リーダーの井上順行氏と、同開発部 プロジェクトマネージャーの佐藤崇徳氏である。こちらも肩書きは当時のものだ。水着イベントの例では、別のセクションがシナリオとイラストを並行して進めつつ、シナリオを先に作ることで、イラスト、ジャケット、ロゴの統一感を保っていた。[3]

この二つは、それぞれ当時の一社・一タイトルの取り組みである。そこから本稿では、並行作業を組むときの要点を、 「何ができたら次が始められるかを決める」 ことだと整理する。先に作るものがあれば、後の担当者も共通の内容を手掛かりに判断できる。

架空の会話イベントなら、会話テキストの確定後、翻訳とイラスト制作へ分かれ、音声とイラストが揃ったところで実装へ合流する、と表せる。実際の順序は担当者と確認して決める。先に始められる工程と、成果物が揃うまで待つ工程を区別することが大切だ。

図1：受け渡しのつながりと余裕の置き場所。作業期間や余裕の長さを表す縮尺は設けていない。

4. 余裕を置き、減り方を見る

受け渡しには、見積もりより作業が延びたり、確認後に直しが必要になったりする可能性がある。工程表には、その変動を受け止める 余裕（バッファ） も置いておきたい。

『ドラゴンクエストX』の事例では、CCPM（クリティカルチェーン・プロジェクトマネジメント）の考え方を取り入れ、タスクごとに最短と最長の見積もりを出し、その差をバッファとして加えていた。一定の開発期間の区切りであるイテレーションごとに、各タスクで消費したバッファを合計し、減り方を把握した。荒木氏は、使い切るまで待たず、半分から3分の2を消費した時点で対策を取ったと説明している。[2]

この割合は、同事例での対処の目安である。自分の工程に当てはめるなら、残りの作業と、予定を組み直すのに必要な時間も見て、いつ相談を始めるかを決める必要がある。

『ガルパ』では、ステージング環境での確認の日と、リリース申請の日の前に、それぞれ1営業日の空きを設けていた。ステージング環境とは、本番に近い状態で動作を確かめるための環境である。[3] 確認や申請という動かしたくない予定の前に、余裕の置き場所が見える例だ。

本稿では、余裕は個々のタスクの中に隠さず、 どこに置き、どれだけ減ったかを見えるようにする と整理する。図1では説明のため、確認後から次の節目までに置いたが、これは二つの講演の工程を再現したものではない。

架空の会話イベントで翻訳が延びたなら、収録以降の予定にどの程度の影響があり、どこの余裕で受け止めるのかを確認する。期限の欄だけを据え置くと、後の担当者の作業時間が知らないうちに縮む。残る余裕が減ってきたと分かれば、対象範囲や順序の見直しを、判断する人へ早めに相談できる。

5. 節目を置き、全員で確かめる

家庭用ゲームの開発では、アルファ、ベータ、マスターアップなどの節目に向けて工程を組む。こうした節目を マイルストーン と呼ぶ。アルファやベータの定義はプロジェクトによって異なるため、名前とあわせて、 「その時点で何が満たされているか」 をチームで合意しておく。

たとえば架空のプロジェクトなら、「主要な遊びを一通り実機で試せる」「対象範囲の素材が入り、通して確認できる」など、到達したい状態を具体的にする。その状態から逆にたどれば、どの素材や実装をいつ受け取る必要があるかを考えられる。出荷に向けた最終版を確定するマスターアップについては、QA・デバッグとマスターアップで詳しく扱っている。

実物を触る機会も、工程に入れる

『ドラゴンクエストX』では、2か月ごとの区切りに、チーム全員が半日から1日かけてゲームを遊ぶ会を開いていた。ディレクターは集まった意見を精査し、次のイテレーションの計画を立てた。2か月という長さも、試行錯誤を通じて決まったものだった。[2]

『ガルパ』では、動作確認会に加え、QA（品質保証）の中盤に全員が実機で触る「おさわり会」を開き、意見をスプレッドシートに集めてプロデューサーが精査していた。早い段階で動かして確かめ、バグを直しきれない事態を避けるための取り組みである。[3]

工程表を考えるうえでは、制作の完了予定だけでなく、実物を触って意見を集める機会と、その結果を受けて調整する時間も置きたい。全員で確認する日が決まれば、そこまでに何を動く状態にするかも具体的になる。

要望の取捨選択には、『ドラゴンクエストX』で狩野モデルを用いた優先度の整理も紹介されている。[2] 本稿では、必須のもの、期待されるもの、あればうれしいものを分け、次の節目までに何を優先するかを判断する手掛かりとして捉えたい。

日々の変化を拾い、工程表へ戻す

同作では毎日15分の定例で進捗を確かめ、問題の早期発見につなげていた。荒木氏は、座ると話し込んで長引きやすいため、立ったまま行うことを勧めている。[2] 編者も、毎朝のスタンドアップミーティングを行っていた。

本稿の判断軸に沿うなら、日々の定例で知りたいのは、次に渡す予定が変わっていないか、誰かが待つ状態になっていないかである。見つかった変化を工程表へ戻すことで、一覧と実際の作業が離れにくくなる。

『ドラゴンクエストX』のロードマップには、誰が、いつ、どのくらいの期間、何を担当するかが、人員の異動も含めて記され、状況に応じて書き換えられていた。[2] 工程表も、作成時の予定を土台に、現状と次の見通しを書き換えて使うものだと考えられる。担当や受け渡し日が変わったら、その先の予定までつながりを確かめ直す。

6. 運営型の周期を一枚にする

運営型タイトルでは、長期の計画と、目の前の更新の周期をつなぐ必要がある。

『ガルパ』では、プロデューサーが通年計画、半年の詳細計画、優先度を考慮してロードマップを作っていた。優先度の高い案件から仕様を決め、関係者への説明・認識合わせを行うオリエンテーションを経て見積もりを出す。その見積もりをもとに、PMが投入するバージョンを決める流れである。[3]

同事例では、開発は月1回程度の周期で進む一方、イベントや楽曲配信、誕生日の施策などの運用では、それより短い期間でデータを更新していた。紹介された7月の例では、月3回のイベントに加え、キャンペーンガチャ、誕生日データ、楽曲、ログインボーナスの追加などが並行して開発されていた。施策ごとにネタバレをどこまで許すかも判断し、バージョンへ割り当てている。[3]

この例から考えると、工程表には「イベントを公開する日」と「必要な内容をバージョンへ入れる日」の両方が必要になる。公開日が先でも、データを入れる都合で制作や検証の期限が早く来ることがあるからだ。

図2：更新ごとにずれて進む工程と、同じ週に重なる作業。

本稿では、 次の更新の検証と、次の次の更新の制作を、一枚の工程表で見えるようにする と整理する。更新ごとに横へたどれば、公開までの受け渡しが分かる。同じ週を縦に見れば、複数の更新の作業が重なり、同じ担当者に確認や制作が集中していないかを考えられる。

架空の更新Aの検証と更新Bの制作を同じ担当者が受け持つなら、それぞれの工程が単独では間に合いそうでも、同時に進められるかは別に確かめる必要がある。どの作業がどの更新に向けたものかを明記すると、この重なりを話し合いやすくなる。

『ガルパ』の事例では、ストアへの申請は公開の1〜2週間前に行っていた。[3] これは当時の同作の日程の例であり、審査にかかる期間を保証する数字ではない。申請からの逆算を詳しく知りたい場合は、スマホゲームのリリース前スケジュールを参照してほしい。

7. 工程表の上で、次へ渡せるかを確かめる

タスクの一覧に受け渡しのつながりを加えると、誰が誰を待つかが見える。そこへ余裕と節目を置けば、予定が変わったときに何を確かめ直すかも分かる。

「次の工程が受け取れる状態で渡せているか」を、工程表では次の観点から確かめたい。

• 待っている人がいる作業はどれか。その遅れは、どの工程や節目まで響くか。
• 並行して始められる作業はどれか。開始に必要な成果物は決まっているか。
• 余裕はどこにあり、どれだけ減ったか。手を打つ時期を共有できているか。
• 次の節目で、何が満たされているべきか。実物を確かめる機会はあるか。
• 同じ週に、どの更新の制作と検証が重なるか。担当者の予定は両立するか。

関連する範囲を体系的に学ぶための参考書には、下田紀之『ゲーム開発プロジェクト管理の基本』（技術評論社、2024年）がある。出版社の公開目次には「マイルストーン管理の進め方」「ゲーム運営プロジェクト管理」などが並び、今回のテーマをさらに学ぶ範囲を探す手掛かりになる。[4]

工程表で受け渡しをつなぐと、その起点となる仕様をいつ、どの状態で決めるかが次の課題になる。第3回「上流を固める——仕様の確定と変更の管理」では、制作を始めるための仕様と、その後に生じる変更をどう扱うかを考える。

References

1. 編集部・山岡広樹「【CEDEC 2018】チーム管理を行うディライトワークスの『PM』についての基礎を紹介…FGO PROJECTの事例や今日から使えるPMテクも！」 — gamebiz、2018年8月29日。2018年8月24日の講演レポート。タスクに記す情報について参照。

2. 大陸新秩序「［CEDEC 2012］『ドラゴンクエストX』における開発進捗管理法とは？ セッション『大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜』レポート」 — 4Gamer.net、2012年8月21日。2012年8月20日の講演レポート。荒木竜馬氏による並行作業、バッファ管理、プレイ会、日々の定例、ロードマップの事例。肩書きは講演当時。

3. 山岡広樹「【CEDEC 2019】『ガルパ』の施策を支える開発・運用フローを紹介…スムーズな進行管理の秘訣は“チームワークの高さ”にあり！」 — gamebiz、2019年9月12日。2019年9月5日の講演「バンドリ！ ガールズバンドパーティ！を支える開発・運用のしくみ」のレポート。計画、並行制作、確認会、余裕、開発・運用周期の事例。肩書きは講演当時。

4. 下田紀之『ゲーム開発プロジェクト管理の基本』書籍案内 — 技術評論社、2024年2月10日発売。書誌情報と公開目次に基づく参考書の紹介。書籍本文を本稿の論拠には用いていない。

この文書は、Perplexity、Claude、ChatGPT の3つのAIの支援を受けて著述されたものです。引用画像を除き、MIT License にて提供されています。