TRPG×AI連携サービスの裏側。27名の大規模チームをまとめたPMO兼プランナーのタスク管理術

こんにちは。ゲーム業界で20年以上、企画・仕様策定・進行管理・品質管理に携わってきたプランナーです。

今回は、TRPG（テーブルトークRPG）とAIを組み合わせたWebサービス「CsCat」の開発で、PMO兼プランナーとしてプロジェクトに参加した経験をご紹介します。

「人数が多いプロジェクトでは、誰が何を担当しているのか分からなくならないのか」「PMOは進捗表を更新するだけの仕事なのか」と疑問に思う方もいるかもしれません。

実際、27名規模のチームでは、タスクを登録するだけではプロジェクトは回りません。仕様の認識差、確認待ち、職種間の依存関係など、一覧表だけでは見えない問題を早めに発見し、解消する必要があります。

この記事では、「CsCat」がどのようなサービスだったのか、そして私がタスク管理で意識していたことを、現場の視点からお伝えします。

TRPG×AI連携サービス「CsCat」とは

「CsCat」は、TRPGとAI技術を融合したWebサービスです。

TRPGとは、参加者同士が会話をしながら物語を進めるロールプレイングゲームです。「CsCat」ではChatGPTの仕組みを活用し、物語の生成やキャラクターとの対話など、AIならではの遊び方を提供することを目指していました。

私はPMO兼プランナーとして、AI連携機能やゲームロジックの仕様書作成、エンジニア・デザイナーへの制作指示、Redmineを使ったタスク発行と進捗管理、スプリント定例の進行、課金代行サービスの調査、実装後のデバッグなどを担当しました。

PMOは、プロジェクトを円滑に進めるための管理・支援を担う役割です。一方、プランナーはサービスの仕様やユーザー体験を設計します。

私は二つの役割を兼務していたため、「予定どおり進んでいるか」だけでなく、「そもそも作る内容が正しく伝わっているか」まで確認する必要がありました。

27名のチームで難しかったこと

大規模なチームで特に注意したのは、タスクの「登録」と「理解」は別物だということです。

Redmineにチケットが存在していても、担当者によって完了条件の解釈が違えば、レビュー時に手戻りが発生します。

また、あるタスクが別の仕様決定や素材の完成を待っている場合、担当者本人に作業時間があっても着手できません。表面上は担当者の作業が止まっているように見えても、実際には別の判断や作業を待っているケースがあります。

特にAI連携機能は、通常の画面仕様だけでなく、AIへの入力条件、返答内容、想定外の出力が起きた場合の扱いなど、検討すべき項目が多くなります。

仕様書を作って終わりではなく、実装担当者と認識を合わせ、実際の動作を確認しながら調整することが欠かせませんでした。

そのため私は、進捗率だけを見るのではなく、次の点を把握することを重視しました。

• 現時点で何が決まっていないのか
• 誰の確認や判断を待っているのか
• 遅れた場合、次に誰の作業へ影響するのか
• 完了と判断するために何が必要なのか

単純に「進んでいますか」と確認するのではなく、作業を止めている原因を見つけることが重要です。

実践した3つのタスク管理術

1．タスクを「作業名」ではなく「完了条件」で管理する

「AI会話機能を実装する」とだけ書かれたタスクでは、どこまで終われば完了なのか判断できません。

そこで、担当者、期限、成果物、確認者、完了条件が分かる状態にし、必要に応じて「仕様作成」「実装」「動作確認」「修正」といった単位に分けて管理しました。

例えば、実装自体が終わっていても、動作確認やレビューが完了していなければ、ユーザーへ提供できる状態ではありません。

一方で、タスクを細かくしすぎると、チケットの更新だけで時間を使ってしまいます。重要なのは、第三者が見ても「現在どの段階にいるのか」を判断できる粒度にすることです。

タスクの件数を増やすことが目的ではなく、遅延や認識差を早く発見できる状態を作ることが目的です。

2．定例会を「進捗報告の場」だけにしない

スプリント定例では、各メンバーの進捗を順番に読み上げるだけではなく、停止しているタスクや判断が必要な項目を優先して扱いました。

順調なタスクの説明に時間を使うよりも、次のような問題を共有する方が、プロジェクト全体には効果があります。

• 仕様確認が必要で作業が止まっている
• 他職種の作業完了を待っている
• 想定より検証に時間がかかっている
• 担当者だけでは判断できない問題が発生している

問題が共有されたら、その場で次の対応者を決めます。

会議の目的は報告ではなく、次の行動を明確にすることです。「誰が」「いつまでに」「何を確認するか」まで決めることで、会議後にタスクが再び止まることを防ぎました。

3．Redmineと会話を使い分ける

Redmineは、対応履歴を残し、担当者や期限を明確にするために有効です。しかし、文章だけでは細かなニュアンスが伝わらないこともあります。

特に、AIの挙動やゲームとしての面白さなど、正解が一つではない仕様は、チケットの文章だけで認識を合わせることが難しくなります。

そのため、認識差が生まれそうな仕様はSlackや定例会で直接確認し、決定した内容をRedmineや仕様書へ戻すようにしました。

会話だけで決めると記録が残らず、ツールだけに頼ると認識差を見逃します。

「話して認識を合わせ、決定事項を記録して共有する」という往復が、手戻りを減らすうえで重要でした。

PMO兼プランナーだからできたこと

PMOとして数字や期限だけを追っていると、遅れている理由を「担当者の作業が遅い」と判断してしまうことがあります。

しかし、プランナーの視点で仕様を見ると、原因が説明不足や判断材料の不足にあるケースも少なくありません。

私は仕様書を作る側でもあったため、タスクが止まった際には、進捗を催促する前に次の点を確認できました。

• 仕様に曖昧な部分はないか
• 実装に必要な情報が不足していないか
• 担当者によって解釈が分かれる表現になっていないか
• 関係者の判断を待つ必要がないか

タスク管理は、人を急かす仕事ではありません。

メンバーが作業を進められる状態を整え、問題が大きくなる前に障害を取り除く仕事だと考えています。

これまでゲーム企画、制作進行、品質管理を長く経験してきたことは、エンジニアやデザイナーなど、職種ごとの事情を理解しながら調整するうえで役立ちました。

AIのような新しい技術を扱うプロジェクトでも、最後に重要になるのは、目的・仕様・担当・期限をチームで共有し続けることです。

まとめ

27名規模の「CsCat」開発を通じて、タスク管理で重要だと感じたのは、次の3点です。

• タスクは完了条件が分かる粒度で作る
• 定例会では報告よりも障害の解消を優先する
• 会話で認識を合わせ、ツールへ決定事項を残す

PMOやプランナーに必要なのは、管理表をきれいに保つことだけではありません。

メンバーが迷わず動ける環境を作り、企画と開発の間をつなぐことが本当の役割です。

大規模な開発やAIを活用したサービスに興味がある方にとって、今回の経験がプロジェクトの進め方を考えるヒントになれば幸いです。