Skip to the content.

進行を任されたら、何が変わるのか——制作進行を任されたら①

1. 自分の仕様から、工程の前後へ

イベントの会話テキストを書き終えた。確認も頼んだ。ところが、翻訳担当から「どの版を訳せばよいのか」と質問が来る。音声の担当は、収録する台詞が確定するのを待っている。自分の作業は進んだはずなのに、その先の作業が動いていない。

たとえば、こんな場面に目を向けるのが制作進行の仕事である。新人から中堅へ上がる時期に、担当の仕様づくりとあわせて制作進行を任されることは珍しくない。編者もプランナーとして、ローカライズの取りまとめや制作進行を担当した経験がある。

仕様を考えるときは、まず自分が受け持つ遊びや機能を形にすることが中心になる。進行を受け持つと、担当者の手元で進んだ仕事が、次の担当者の仕事につながっているかまで見る必要がある。

ここでいう 工程 は、仕様づくり、実装、翻訳、検証など、制作を構成する作業のまとまりである。ある作業に必要な情報や成果物を先に用意する側を 上流 、それを受け取って作業する側を 下流 と呼ぶ。企画やエンジニアリングで用意した内容が、ローカライズやサウンドの作業へ届くまでを見渡すことになる。ただし、上流・下流は受け渡しの前後を指す言葉であり、職種の序列ではない。実装に必要な音声をサウンド側が先に渡すなど、関係は作業によって変わる。

本シリーズ「制作進行を任されたら——中堅プランナーへの足掛かりとして」は、 「次の工程が受け取れる状態で渡せているか」 を判断軸にする。第1回では、その判断の土台になる、進行の立ち位置と「進捗が見える状態」を考える。


2. 進行は、誰の代わりでもない

制作進行の立ち位置を考える例として、CEDEC 2018で紹介されたディライトワークスの体制を見てみよう。2018年8月24日の講演「ディライトワークス流、プロジェクトマネージャー入門 ~FGO PROJECTを支える制作進行テクニック~」では、プロジェクトごとにプロデューサー、ディレクター、PMの3人を1セットで置く体制が紹介された。PMは プロジェクトマネージャー の略で、プロジェクトの進行を計画・調整する役割を指す。講演では、同じ略称を使うプロダクトマネージャーとは別の職種だとも補足されている。[1]

講演レポートで示された分担は、次のとおりである。[1]

役割 紹介された担当範囲
プロデューサー 予算を含むブランディングの価値などの管理
ディレクター ゲームの面白さを追求する品質管理
PM 企画、グラフィック、エンジニアなど各セクションのディレクターやリーダーとやり取りし、前後の工程を把握して調整する

これは当時の一社の体制の例である。会社やプロジェクトによって、呼び名も担当範囲も異なる。

CEDEC 2018で紹介されたディライトワークスの体制の例。プロデューサーが予算やブランド価値、ディレクターが面白さや品質を担い、PMは企画・グラフィック・エンジニアなどの責任者と双方向に連絡して前後の工程を調整する。

出典:講演レポートの役割分担をもとに作成。[1]

この分担を手掛かりに、本稿では進行の役割を、 決めるための情報を揃え、決まったことを次の工程へ流す人 と整理する。予算や品質について最終判断をする人と、判断に必要な状況を集める人を分けて考えるのである。

プランナーが進行を兼ねるなら、この区別は自分の中にも必要になる。仕様の担当者として案を出すことと、関係者の判断を揃えて制作を動かすことは、違う仕事だからだ。

たとえば、演出の追加案を自分が考えた場合でも、その案をすぐ制作指示に変える前に、誰が採用を決めるのか、何の作業が増え、どの予定に影響するのかを揃える。進行を任されたことだけを根拠に、面白さや費用の判断まで引き取ると、担当者が何を承認済みと受け止めればよいかが曖昧になる。

まず上司や各職種の責任者と、仕様・品質・日程について誰が判断するかを合わせておく。そのうえで、自分はどの範囲の調整を任されているかを把握することが出発点になる。


3. 「進捗が見える」とはどういう状態か

同講演で、ディライトワークス 企画部 第二セクションマネージャー/プロジェクトマネージャーの芦田夏希氏は、「どんな些細なことも全ての作業をタスク化する。」を基本に挙げた。 タスク とは、担当者が実行する個々の作業のことである。タスクには「誰が」「何を」「いつまでにするか」を記し、チームのメンバーから見える形にする。期限を決めることで、ミーティングや作業の洗い出しなど、次に取る行動も見えてくるという。[1]

この考え方を受け渡しに当てはめると、見える状態とは、 どこで止まっていて、次の誰に影響するかが分かる状態 だと考えられる。

冒頭の架空の例なら、「会話テキスト:確認中」とだけ書かれていても、翻訳担当は作業を始められるか判断しにくい。次のような情報があれば、状況は変わる。

知りたいこと 架空の例での記載内容
誰が何をするか 仕様担当が、会話テキストの最終確認を責任者へ依頼する
いつまでか 翻訳開始予定日の前日までに確認結果を受け取る
今どこで止まっているか 責任者の確認待ち。選択肢の台詞が未確定
次の誰に影響するか 翻訳担当と、収録対象の台詞を整理する音声担当
次に誰が動くか 進行担当が責任者へ回答予定を確認し、受け渡し予定を関係者へ共有する

これは表の項目を増やすこと自体が目的なのではなく、次の行動を決めるための情報を揃える例である。今の担当者の作業が終わる見込みと、次の担当者が受け取れる見込みを、同じものとして扱わないことが大切だ。

遅れが分かった時点で、翻訳の開始予定にも影響するなら、それを関係者が判断できる形にする。「確認中」の一語のまま予定日まで待つと、翻訳に使う時間だけが縮むことになる。

タスクの一覧に前後のつながりが加わることで、誰に何を確認すべきかが分かる。下流へのしわ寄せを避けるための相談も、そこから始められる。


4. 受け取る人のために、情報を整える

同講演で、ディライトワークス プロジェクトマネージャーの戸田圭祐氏は、PMを「コミュニケーター」「情報のフィルター」と表現した。専門性の異なる人の間で情報を整理し、表現を調整し、不足する情報を補いながら、問題の解決に適した対応を手配する役割である。[1]

工程の間では、同じ「終わった」という言葉でも指す状態が違う。たとえば、次のような架空のやり取りを考えてみよう。

エンジニアから「イベント画面の実装は終わった」と連絡が来た。進行担当が確認すると、画面は動くが、表示文言は仮のままで、テスト用のゲームにもまだ反映されていなかった。一方、検証担当は「実装が終わった」と聞いて、確定した文言を画面上で確認できると受け止めていた。

この場合、次の工程へ渡す情報は、たとえばこうなる。

イベント画面の動作部分は実装済み。表示文言の差し替えとテスト用ゲームへの反映が残っている。検証開始日は、その反映予定を確認してから共有する。

「終わった」を受け取る工程が使える言葉へ直すとは、こういうことである。担当者の報告を否定する必要はない。何が済み、何が残り、次の人はいつ何を受け取れるのかを補えばよい。

また、情報のフィルターになることは、都合の悪い情報を隠すことでもない。たとえば強い調子の催促を、受け手が行動できる依頼へ整える場合も、期限や困っている理由まで削ってしまうと調整に使えなくなる。表現を整えつつ、判断に必要な事実は残す。

進行がすべての専門判断を代行する必要はない。分からない点は当事者に確認し、必要なら直接話してもらう場を設ける。その結果を、関係する工程が使える形で残すことが役割になる。


5. 開発の節目と、運営の周期を見る

家庭用ゲームの開発では、アルファ、ベータ、マスターアップなどの マイルストーン 、つまり開発上の節目に向かって工程を進める。アルファやベータで何を満たすかはプロジェクトによって異なるため、名前とあわせて到達すべき状態を揃える必要がある。マスターアップは、出荷に向けた最終版を確定する節目である。

一方、運営型タイトルでは、イベントや定期アップデートの周期の中で、次の更新を検証しながら、次の次の更新の仕様や素材を準備する。同じ職種が複数の更新を並行して受け持つため、どの更新に向けた受け渡しかも見える必要がある。

場面 進行として目を向けたいこと
家庭用ゲームの開発 次の節目に必要な状態に向けて、各工程がつながっているか
運営型タイトルの更新 更新ごとの準備・制作・検証が重なる中で、必要な相手へ必要な時期に渡るか

どちらにも共通するのは、担当者の完了報告と、次の工程の開始条件をつなぐ視点である。工程表としてどう表すかは第2回で扱う。

出荷までの終盤を先に知りたい場合は、QA・デバッグとマスターアップが参考になる。運営型タイトルを含むスマートフォンゲームの初回公開については、リリース前スケジュールとプランナーのチェックポイントも参照してほしい。


6. 次の工程が受け取れる状態を、順に考える

制作進行を任されたら、まず自分の担当範囲から、作業と受け渡し先を見てみるとよい。誰が何をいつまでに行うのか、今どこで止まっているのか、その先で誰が待っているのか。その情報を関係者と共有できれば、次に必要な確認や相談を始められる。

本シリーズは、この 「次の工程が受け取れる状態で渡せているか」 という問いを、全6回と番外編で順に具体化していく。

個別の発注や音楽制作の実務には、外部クリエイターへの発注ガイドと劇伴制作の進行管理実務がある。必要な工程に進んだとき、あわせて読める記事である。

体系的に学ぶための参考書としては、下田紀之『ゲーム開発プロジェクト管理の基本』(技術評論社、2024年)がある。出版社の公開目次には、タスク管理、マイルストーン管理、リリースまでの進め方、ゲーム運営プロジェクト管理、管理ツールの利用などが並ぶ。本シリーズとあわせて学ぶ範囲を探す際の候補になる。[2]

自分の仕事が終わったところから、次の人の仕事が始まる。その間にある確認待ちや情報の不足を見えるようにすることが、進行としての最初の一歩である。

References

1. 編集部・山岡広樹「【CEDEC 2018】チーム管理を行うディライトワークスの『PM』についての基礎を紹介…FGO PROJECTの事例や今日から使えるPMテクも!」 — gamebiz、2018年8月29日。2018年8月24日の講演レポート。役割分担、タスク化、情報のフィルターについての記述・引用は同レポートによる。肩書きは講演当時。

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


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