プラチナゲームズPMが解説「Flow PT」が『NINJA GAIDEN 4』開発チーム全体の土台となるまでのドキュメント

１「プロジェクト管理が抱える課題」

ゲーム開発のプロジェクトでは開発途中から以下の2つの課題が顕在化することが共通しているという。
1つ目は「全体の状況が不透明になること」。各セクションやプロジェクトごとに、それぞれ異なる管理方法やツールを使っているため、データの形式や更新のタイミングが異なり、共通の観点で状況を確認することができず、プロジェクト内部からも外部からも全体状況が不明瞭になってしまう状況が生じていた。

２つ目は「横断的な計画調整のコストの高騰」。開発現場では複数のツールを状況や作業に応じて使い分けることが一般的であるため、複数のフォーマットで各種管理が行われる。そのため、データを連携する際にはデータの変換や手動作業が必要となり、大きなコストが発生していた。

村上氏の分析によると、これらの課題が発生する原因は「序盤の時点で終盤を見据えた管理ができていないため」だという。開発の序盤は人数も少なく複雑性も低いため簡易的な管理で十分だが、中盤にかけて人数も増え複雑性が高まるのと合わせて、プロジェクト管理も発達していく必要があると説く。

レベル3のイメージ。メンテナンス負担の大きい複雑なエクセルガントの乱立。視認性数値に基づかない感覚的な情報が複雑に絡み合う。

２「Flow PT 導入背景」

このように、村上氏も自身の経験としてExcelによるガントチャート運用の難しさを感じていた。そんな折に見つけたのがFlow PTだった。特に魅力を感じたのはガントチャートの視認性と操作性だったという。ゲーム開発では非常に多くの情報を扱うため、1画面で様々な情報を表示させる必要がある。「Flow PTは余白も最小限で、レイアウト編集もしやすく情報をコンパクトに表示できる点も魅力です」、「強力なフィルター機能のおかげで情報整理と計画のシミュレーションもできます」とメリットを挙げ、Flow PTが基本的な要件をカバーできるツールであると判断し、村上氏がこのプロジェクトに参加した時点でFlow PTの導入に向けて動き出した。

管理職への伝え方に際してはFlow PTの「期待」と「展望」をアピールした。

前者は状況が"見える化"されることで、全員が状況変化の予測と対応が可能になる。後者は要素やタスクなどの様々なデータが全てFlow PTに集約されることで、要素の変更による影響や調整がFlow PT内で完結できるようになり、データ管理に関する報告やコミュニケーションの基盤としても活用できる。これらにより、プロジェクト管理を全員で行なう状態を目指し、各自がリスクに気づき自律的に調整するチームへと発展させることが可能になる。

３「Flow PT 利用開始までの流れ」

次に村上氏はFlow PTの普及に向け、試作サイトの作成とディレクターらリーダースタッフたちへの提案を行なった。大きな効果を発揮したのは動画による紹介だった。構築した画面を操作しながら、設計思想や使い方を村上氏が一人語りする内容で、これがディレクターから好感触を得て、全体導入を開始。チーム内でも導入に対する強い抵抗はなく、全セクションで使う流れが出来たという。また、試作サイトでは当時想定されていた物量とタスクを仮登録し、量産時を想像させる状態を構築した。プラチナゲームズでは、すでに他のプロジェクトでFlow PTを使っていたが、利用範囲は限定的で、プロジェクト管理には主にJIRAやExcelが中心のツールとして使われていた。今回のプロジェクトでは、予定していたタスクやスケジュール管理に加え、外部への発注業務やリーガルチェック業務もFlow PTで対応することになった。

利用開始までの3ステップ

4「費用対効果」

費用対効果について、村上氏は「十分な費用対効果がある」と、結論から述べた。

プロジェクト管理の具体的な作業には、これまで述べてきた調整や確認の作業があり、仮に80名分の管理作業を行う場合は、毎日3時間ほど費やされると試算。加えてヒューマンエラー対策や整合性チェックなどで関係者を巻き込むことになるため、Flow PTのライセンス料（年額32000円／人）は十分に費用対効果があり、「管理作業にかかる時間を減らし、最新の状況を見つつ意思決定ができる点が非常に旨味だと思います」と語った。

１「ユーザー権限設定」

東氏は実際のFlow PTをどのように設計運用をしていったかを現場での画面に基づき紹介した。「最初に『誰が何にアクセスできるか』を明確にしておくことが重要」という。まず、導入にあたっては、チーム全体が安心して運用できる土台を目指し、ユーザー権限の整理から着手したという。

ユーザー権限の設定における注意点。データ消失を招く「削除権限」はメンバーから除外し、消去操作ができるのはPMやリーダーなど責任のある立場の人だけに限定した。また、表示物が変化する「ビュー＆フィルター保存権限」はPMのみに限定した。これは全体に反映できてしまうと他の人にとって見づらくなってしまったり、情報の混乱が起きてしまうため。

2 エンティティ設計

エンティティとは Flow PT の中に存在する「実態」を指す。Flow PTに最初から存在する「ショット、アセット、タスク、ノート」も「実態」として扱われる。今回のプロジェクトでは、ゲーム要素の構造に合わせてエンティティとパイプラインステップの両方を定義・設計した。

キャラクターエンティティでは、主人公や敵キャラなど、個々のキャラクターごとに必要な情報をフィールドとして持たせた。このエンティティを見れば、ヤクモ（主人公）のタイプは人型。雑魚１は人型、雑魚２は４足動物。パイプラインステップも実装済みか未着手かの状況がひと目でわかる

代表的なエンティティとして「ステージ」と「エリア」がある。ステージは、複数のエリアで構成されており、その状態をFlow PT側で実装する。簡易的なレイアウト完了後、作業者分担と合わせてエリア分割をする。

「ステージ」はゲームプランナー、アート、背景、VFX、SE、プログラマーといった複数のセクションで共有されるタスクの管理に使用した。エリアをまたいで影響するようなタスクで使用した。「エリア」は背景セクションのみが使用。エリア内を完成させるために、最適化作業を含めたタスクを管理する用途だ。こうして用途ベースでエンティティを分けておくことでチームごとの見やすさ、情報の整理確認がしやすくなったという。

キャラクターアニメーションにおけるエンティティの例。「キャラクター」、「アクション」、「アニメーション」という3つのエンティティを階層的に設計した。ミクロなモーション単位ではなく、マクロなアクション単位で連携させることができる。

システム系エンティティの例。「コンポーネント」は追加で必要となったカテゴリを追加するためのもの。例えば表示テキスト、プログラムタスクとの紐付けなど用途がはっきりしていないものを暫定的に登録し、チーム内で整理・合意された後に必要に応じて分類を進めていく使い方を実施した。「UI」はメニュー画面やステータス画面などゲーム内に登場するUIを1画面ごとに登録管理する用途で使用した。画面単位で分けることで、ゲームデザイナーやUIプログラムのセクションがスムーズに連携できる構成とした。

クライアントレビュー（プラチナゲームズからTEAM NINJA）とリーガルチェック（TEAM NINJAからマイクロソフト）の例。2つの異なるレビュープロセスに対応するため、専用のカスタムエンティティをそれぞれ分けて実装した。レビュー対象となるアート、キャラ、シネマ、プロップなどの素材や動画をFlow PTにアップロードし、それぞれのエンティティからコメント、確認、承認のやり取りができるようにした。レビューの状況やコメントの内容も一覧で可視化できるようにして、チームや会社をまたぐレビュー依頼もFlow PT内で一元的に管理できる。

3 タスク運用

つづいてタスク運用とルール周りの実態について話が及んだ。タスク管理ではステータスを細かくしすぎることで、かえって今どんな状態なのか分かりにくくなってしまうケースがある。今回はそういった混乱を避けるために、あえてシンプルなステータス構成にして、見ればすぐに状況が分かるという運用を目指したという。

プロジェクト初期には増員予定のスタッフや外部発注先が未確定なタスクも多く、全てのタスクにユーザーをアサインするのは現実的ではなかった。そこで無理にアカウントを追加せず、仮のグループユーザーでアサインする方法を採用した。Flow PT上ではタスク担当にユーザーかグループを指定できるので、まだ人が決まっていない工程には「担当者1」などの名前をつけたグループを作っておいて、後から正式に担当が決まったタイミングで置き換えるという運用を実施した。

その後、実際に作業を始めてみると、見積もりが甘かったり、掛け持ちが追加されていたり、予定より遅れるケースが当然出てくる。そこでFlow PT上では現実的な見通しを更新していくことを重視して、終了日がずれてもその理由と見直しを定期的に共有するというスタイルを採用した。タスクごとの試算人日も活用し、基本的に初期設定や見積もりとのずれを厳しく管理するのではなく、定期的に残りどれぐらいかかりそうかについてリードと話をすることで、より実態に即した予定になるべく終了日を調整していくアプローチを取った。

4 ビュー設計

Flow PT上におけるビューとは、タスクや要素の一覧を、用途に応じて見やすい形で切り替えられる画面のこと。立場によって確認したい情報や詳しさのレベルが異なるため、Flow PTでのビュー設計がとても重要な要素だった。そこで、「必要な人が、必要な情報だけ」を見られるようにビューを設計。見る人が迷わず使えることを重視した。

これはエネミー01から04に対しキャラクターとアニメーションそれぞれのセクションが参照するビューを分けて構成した例。別々のエンティティで、工程や確認したい粒度も異なるため、各セクションが使いやすいように項目や構成を調整して個別に設計した。

ただし、キャラとアニメーションの間にはスケジュール上の依存関係もあるため、全体の流れを確認するには2つのビューを行き来する必要があった。そこで、仮モデルと仮アニメーションの進行状況を1画面で同時に見られる「一体化ビュー」も別途用意した。関連する工程がひと目で把握できる構成にすることで、進捗確認や調整がしやすくなる。右図では仮モーションが仮モデル作成よりも前に来ているため、セクションをまたいだときの不整合がすぐに分かる。

5 運用の裏側とPMの声

つづけて、Flow PT実際の運用の中で試して見たものや設計、工夫、続けて使われたもの、見送ったものなど、率直な意見が開示された。成功した取り組みはスプレッドシートの埋め込みだった。Flow PTのトップビューには、別で管理していたスプレッドシートのマイルストーン表をそのまま埋め込んで表示できるようにした。これにより、進行確認のために個別の資料を開く必要がなく、Flow PT上で全体スケジュール感をまとめて見られるようになった。更新が必要な場面では、Flow PT上のビューはそのままでスプレッドシート側だけを更新すればよいという構成にしていたので、運用上の手間も少なく、現場で自然に定着していった。

一方で見送った取り組みはノート機能の全体導入だった。当初から全体的な導入は見送り、進捗の共有手段としても一部使用に留めた。現場では直接見せて確認してもらうやり取りが多く、元々使い慣れていたSlackや、画面を直接見てやり取りをする方が即時性の面でも評価されていた。そのためあえて従来のやり方を残す判断をしたという。

ここまでのまとめとして、東氏はFlow PTを導入して、実際にどんな効果があったのかをPMの立場から語った。

効果の１つ目は「見積もり精度の向上と計画立案の効率化」だ。Flow PTでは物量や工程といった情報をあらかじめエンティティにまとめておけるため、「このキャラは何工程あるのか」「全体で何人月ぐらいかかりそうか」といった試算が行いやすくなったという。従来はそうした情報がスプレッドシートや個別管理の中に分散していて、見積もりの度に関係者に確認したり過去事例を引っ張ってきたりと、どうしても手間がかかってしまっていた。Flow PTを使うことで完了までの流れがあらかじめ見えるようになり、完了時期から逆算して初期スケジュールを組む精度も明らかに上がったと実感した。

効果の２つ目は「情報一元化による確認・会話効率の向上」だ。従来はスプレッドシートや口頭でのやり取りなど情報が色々な場所に分散していて、「誰がどこまで終わっているのか」「確認したい内容はどこにあるのか」といった確認がどうしても煩雑になりがちであった。Flow PTを使うことで「見れば大体の状況が分かる」という状態が作れ、「まずはFlow PTを見てから聞く」という行動も自然に定着していった。結果として、Flow PTが確認やコミュニケーションの起点として機能するようになり、やり取りがスムーズに進む場面が着実に増えてきたという。

効果の３つ目は「ビュー調整による場面対応力の向上」だ。職種やセクションによって注目するポイントは異なる。例えば、キャラセクションではキャラ単位の進捗、アニメーション側では特定の技が未着手かどうかなど、人によって見たい粒度や項目は異なる。Flow PTではビューを用途別、目的別に分けて運用し、リードチェック用の一覧ビューやセクション進捗用のタスクビューなど、使用者に合わせ見やすい形で整えることで定着しやすくなった。ツールを活かす上でもこの調整は重要なポイントになった。

効果の４つ目は「導入コストに見合う十分なリターン」。Flow PTは他ツールに比べて構造やルールが独特なところもあるので、初めは戸惑うメンバーもいたが、他セクションとの連携や進行確認の中でFlow PTを使う場面が増え、位置付けやタスクの流れが見えることで自然と使用頻度が上がってきたという。

最後に東氏はPMとして今回の導入を振り返り、「Flow PTは単なる管理ツールではなく、チーム全体で共通の土台として使える仕組みになった。共通言語として運用できる地盤になった」と述べた。導入まで試行錯誤やルールの整備などがあったが、それらを積み重ねていく中、「まずはFlow PTを見る」「ここに載せていく」という文化が少しずつ自然に根付いていったという。

そして、プロジェクト段階に応じた管理手法の使い分けが大事だと強調した。ゲーム開発プロジェクトの序盤はフィーチャーベースの「コト管理」が必要だが、中盤以降はFlow PTの得意とするエンティティベースの「モノ管理」が重要になる。これは「何ができるか」よりも「すべてが完成に到達しているか」が問われるためだ。そして「ミクロな管理支援に追われるのではなく、マクロな要素（物量）管理に集中しやすい状況を作れることも Flow PTの優位な部分だと感じています」とPMの観点から語り、講演を締めくくった。