BLOG
SLIDE
目次
- はじめに
- サービス紹介
- プロジェクト概要
- 開発PMというお仕事について
- 炎舞DBにおける開発PMの役割
- プロジェクトの制約
- クリティカルパスの設計
- 完了定義による進行管理
- QAスコープの再設計
- 兼任チームでの進行管理
- 確認会の設計
- 発生した問題と改善
- 意識していたこと
- おわりに
はじめに
サイバーエージェントに2024年新卒入社し、Sumzapにてエンジニアとして業務に従事している水田です。
本記事では『真 戦国炎舞 データベース』の開発において、開発PMとして行った進行設計と運用についてまとめます。
本プロジェクトは小規模チームかつメンバー全員が兼任という制約の中で、半年以内の公開を前提として進行しました。
単純なタスク管理ではなく、外部依存（QA・運用）を前提にしたスケジュール設計を求められた点が特徴です。
サービス紹介
『真 戦国炎舞 データベース』（以下、炎舞DB）は、サムザップが運営するスマートフォン向けゲーム『真 戦国炎舞 -KIZNA-』（以下、戦国炎舞）のカードやスキル・奥義などの情報を横断的に検索、閲覧できる Web データベースです。
キーワードによるカード（大将、武将・智将）およびスキル・奥義の検索、複合条件によるフィルタリング、カードの基本情報や所有スキル、スキル詳細などを調べることができ、プレイヤーがより戦略的にゲームを楽しむための情報を提供しています。
プロジェクト概要
炎舞DBは、ゲーム内のカード・スキル・奥義情報を横断検索できるWebデータベースです。
プレイヤーが戦略検討に利用することを想定しており、検索精度とデータ更新の正確性が品質要件の中心となります。
体制は以下の通りです。
- 開発PM
- プランナー
- フロントエンドエンジニア
- バックエンドエンジニア
- デザイナー（序盤・終盤で別アサイン）
全員が専任ではなく、他施策と並行しての参加でした。
開発PMというお仕事について
本題へ入る前に、まずは開発PMという役割について、簡単にご説明します。
開発PMとはプロダクト開発において、プロジェクトの計画策定、QCD（品質・コスト・納期）の管理、チームの進捗・課題・リスクを包括的に管理し、プロダクトを牽引する役割を果たします。
ここからは、今回のプロダクト開発での私の役割と、実際に意識していたことを紹介していきます。
炎舞DBにおける開発PMの役割
炎舞DBにおける開発PMの役割は以下の通りに定義していました。
- リリース時期から逆算した進行設計と、後続工程を止めないための依存関係整理
- 役割別の完了条件を明確にし、認識ズレによる手戻りを減らすこと
- QAチームや関係者と相談しながら、限られた期間での進め方を調整すること
- 全体の進捗を可視化し、ブロッカーを早期に見つけて解消すること
プロジェクトが遅延しない構造を設計することを最も重要なミッションと考え、業務を進めていました。
プロジェクトの制約
本案件の制約は以下です。
- メンバー全員が兼任
- QAリソースはゲーム施策優先
- マスタ更新頻度は運用中ゲームに合わせるので非常に高い
- ズラせない公開時期が設定されている
この条件下での最大リスクは
QA開始の遅延→品質担保が薄いまま公開 お客様が求めている機能を持っていないミニマム状態での公開
の2パターンと考えていました。
そのため進行設計のKPI（Key Performance Indicator：重要業績評価指標）を細かく設定し、「QAリソースを最大限無駄にさせないこと」を最も意識していました。
クリティカルパスの設計
本プロジェクトはリリーススケジュール優先であり、かつゲーム施策と異なりリリース後に仕様が大きく変化しにくい性質がありました。
依存関係を整理し、進行上特に止めてはいけない流れをクリティカルパスとして定義していました。
クリティカルパス
具体的には、以下の流れを優先度の高い進行ラインとして扱っていました。
- 最低限デザイン確定
- フロント部分の動作確認
- フロントとバックエンドの疎通確認
- マスタから炎舞DBへの反映安定化
- QA開始
一方で、ブラッシュアップ対応や自動更新フローの最適化など、リリース判定に直結しない項目は並行で扱う前提に切り分けていました。
また、QAはゲーム側の開発リソースに依存しているため、QA開始時に認識ズレが起きないよう、前提条件を事前に整理・明文化する運用にしました。
そのために、このクリティカルパスは後述する完了定義とあわせて、チーム全員の視界へ必ず入る位置に配置し、認識のズレを防止しました。
完了定義による進行管理
各フェーズで役割別に完了定義を明確にしました。
各期間での完了定義を役割ごとで明確にすることで、「完了の認識差による手戻り」を防止するように心がけていました。
また、誰かが「終わった」と思っていても後工程では未完了、という状態は開発で起こりがちです。 その対策として、後続で作業の待機時間が極力最小化することを目的に、完了条件を役割ごとに明確にすることを意識しました。
とくに兼任体制では、口頭や暗黙知ベースで進めるとズレが発生しやすいため、完了定義を進行管理の土台として扱っていました。
以下に示しているのが、実際に定義した内容となります。
システム設計期間：システム設計や運用フローについての設計期間 - 達成目標 - PL：全てのセクションが手を動かすにあたって足りない情報がない状態 - FE：サイトの構成/サーバーとの疎通/デザインなど、開発に必要な準備が全て終わっている状態 - SE：システム設計の概要認知/FEとの作業内容すり合わせを完了し、認識の齟齬がない状態 - DE：デザインの方向性が決まって作業を進められている状態 機能設計期間：実装や作業の前段階準備期間 - 達成目標 - PL：各機能に対しての詳細仕様が完全に定まっている状態 - FE/SE：システムの運用方法が決まっており、実装する際に手が止まらない状態 - DE：FEの実装に必要な最低限の画面デザインとパーツが完成している状態 実装期間：着手期間 - 達成目標 - PL：確認会を円滑に実施できる状態、運用へ向けてのドキュメントや方針が整備されている状態 - FE/SE：仕様書に書かれているサイトの動作を担保している状態 - DE：デザインとパーツが全て完成し、サイト上で見えている状態 BU期間：ブラッシュアップ対応期間 - 達成目標 - 全：確認会などで発生したBU項目を消化できている状態 QA期間 - 達成目標 - 全：リリースへ向けた致命的な不具合が全て取れている状態
QAスコープの再設計
本施策では、検索条件の組み合わせが非常に多く、加えて複数マスタを横断して結果を表示する構造だったため、網羅的なQAが現実的ではありませんでした。
一方で、QA期間は限られており、仕様変更やブラッシュアップ対応も並行して発生していました。
そのため、開発PMとしては「すべてを同じ粒度で確認しようとする」のではなく、QAチームとも相談しながら、限られた期間の中でどの観点を優先的に確認するかを整理することを重視しました。
特に重要だったのは、検索機能が利用体験として成立しているか、そしてリリース判定に直結する論点を見落とさないことでした。
私は、確認観点の整理と優先順位付けを通して、スケジュールと品質確認の両立を図っていました。
具体的には、以下の方針です。
表示確認：QA対象
- 画面レイアウト崩れ
- 主要端末・ブラウザでの表示確認
- 検索導線やUIの基本動作確認
検索結果の妥当性確認：重点QA対象
- 単一条件の確認をベースに実施
- 複合条件は代表パターンに絞って確認
- 詳細確認は各パターンで数件をサンプリングして実施
データ整合性・リリース境界の担保：運用／実装で担保
- 公開日時やリリース日によるフィルタ
- リリース前データを表示させない制御
- 必要に応じてサーバー側で日時を想定した挙動を確認する
ブラッシュアップ項目：内部検証＋リリース後対応
- 致命度の低い改善項目はQAの主対象から外す
- 期間内はSバグを優先
- 一部のBU項目はリリース後の追加対応に回す
特に難しかったのは、検索結果の「正しさ」を誰がどう担保するかでした。
カード絞り込みDB・スキル絞り込みDBともに、組み合わせパターンが膨大で、すべてを人手で照合するのは非現実的でした。
また、複数マスタを跨いでデータを参照しているため、単純にCSVを出して突合すれば済む状態でもありませんでした。
そこで、QAでは以下に絞って確認方針を作りました。
- 全組み合わせの網羅は目指さない
- 単体条件はしっかり見る
- 複合条件は代表パターンに絞る
- 各パターンで検索結果の詳細を数件確認する
- 件数整合や境界条件は、ゲーム本体との比較や運用・実装側の補助で担保する
この切り分けによって、致命的不具合の検出範囲は維持したまま、QA依存の工数を圧縮しました。
言い換えると、品質を一律に薄めたのではなく、ユーザー影響の大きい領域に検証を集中させる設計へ切り替えたということです。
結果としてこれは、単なるQA削減ではなく、「限られた工数の中で、致命的な不具合やユーザー影響の大きい領域に検証を集中させるよう、品質保証の進め方を設計した」という意思決定でした。
兼任チームでの進行管理
この案件は兼任体制だったため、最初に引いた計画をそのまま守る進め方は機能しませんでした。
仕様変更、QA観点の整理、ブラッシュアップ対応、不具合修正が並行して動く中では、見積もりの精度そのものよりも、変化に応じて進め方を更新できることのほうが重要だったからです。
そこで進行管理では、
- 週次定例で稼働見込みや進捗を確認する
- 実際の進捗と残タスクを踏まえて見込みを更新する
- ブロッカーを同時に可視化する
という運用を徹底しました。
特に意識したのは、タスクの遅れそのものよりも、「何が後続工程を止めるか」 を先に捉えることです。
たとえば本案件では、検索仕様の確定、QA確認範囲の整理、検索結果の正否判断フロー、リリース前データの表示制御など、未整理のままでは開発やQAへ影響する論点が複数ありました。
こうした項目は作業タスクとしては目立ちにくい一方で、放置すると全体進行を止めるため、早い段階で論点化し、担当と判断先を明確にしていました。
優先順位は、重要度の印象ではなく、後続工程を止めるかどうかを基準に判断しました。
その結果、限られた稼働を、QA開始やリリース判断に直結する項目へ集中させることができました。
一方で、ブラッシュアップ項目の一部はあえて後ろに倒し、リリース後対応に回しています。
兼任チームでは、全タスクを平等に前に進めようとすると、結果としてどこも中途半端になりがちです。
この案件では、進行管理を「全体を均等に回すこと」ではなく、止まると致命的な箇所を見極めて、そこに稼働を寄せることとして設計しました。
確認会の設計
確認会の設計自体は、プランナーさんを中心に組まれていましたが、開発PMとしては、そこで得られるフィードバックが後続の仕様整理や優先度判断にどうつながるかを重視していました。
この確認会は、単なる完成品チェックではなく、炎舞DBのフロント（PC・スマホ）を実際に触り、サービス要件を満たせているかを確認する場として設定されていました。
確認したかった主な観点は、以下のようなものです。
- 目的の機能や情報に直感的にたどり着けるか
- 欲しい情報に対する絞り込み条件は適切か
- メニューボタンや文字入力欄が使いやすく配置されているか
- フォント、色、コントラストは適切か
- PC、スマホ、タブレットで可読性や操作性が担保されているか
参加者もDBチーム内に閉じず、ゲーム開発チームやQA、プランナー/ディレクターなど複数職種に広げていました。
これは、仕様レビューだけでは見えにくい利用体験上の違和感を早めに拾うためです。
実際に、文脈を理解しているゲーム開発メンバーに触ってもらうことで、検索導線や可読性、UI上の迷いといった、チーム内レビューでは出づらい論点を拾うことができました。
この観点での確認が入ったことで、後続のブラッシュアップや仕様調整の優先順位付けにもつながりました。
発生した問題と改善
確認会を経て顕在化した差分による手戻り
一部の実装は、その時点で見えている要件を前提に先行して進んでいましたが、確認会とその後の確認を通じて、当初想定との差分が明確になりました。
実際には、検索導線の入り口を分ける対応や、トップページのボタン素材追加、検索結果や詳細画面の項目変更などが必要になり、一部コンポーネントの作り直しも発生しました。
これは、画面や導線として一度成立して見えていても、実際の利用文脈で確認すると不足や違和感が見つかることを示していました。
この経験から、ブラッシュアップ期間以降は、
- 仕様整理が終わっていない項目は未確定として明示する
- 後続のレビューで差分が出そうな論点はブロッカーとして扱う
- 見た目の着手しやすさより、手戻りの少ない順序を優先する
という運用に切り替えました。
見かけ上の進捗を前に進めるよりも、後で作り直さなくて済む状態をつくることのほうが、兼任体制では結果的に重要だったと感じています。
意識していたこと
本プロジェクトで意識していたのは、「限られたリソースの中で、どこを止めず、どこを守るか」を明確にすること でした。
そのため、進行上の判断軸として特に重視していたのは次の3点です。
依存関係ベースで進行を組み立てること
タスクの多さや見た目の重さではなく、その対応によって次の工程に進めるかどうかを基準に優先順位を判断していました。
仕様整理、開発、確認工程はそれぞれ独立しているように見えて、実際には強く依存し合っています。そのため、後続を止める論点を早めに見つけて潰すことが、結果的に全体最適につながると考えていました。
役割ごとの完了条件を明確にすること
兼任体制では、認識差がそのまま手戻りにつながりやすいため、着手条件・完了条件をできるだけ明文化し、判断基準を揃えることを重視していました。
誰かにとっては「終わっている」状態でも、次の役割から見ると不足がある、というズレが起きると、その分だけ確認や差し戻しのコストが増えてしまいます。そうしたロスを減らすために、役割ごとにどの状態をもって完了とするかを揃えながら進めていました。
利用体験に関わる確認を早めに入れること
確認項目を一律に増やすのではなく、どこを重点的に確認すべきかを早い段階で見極めることも重視していました。
特にこの案件では、検索機能や導線、可読性といった利用体験に関わる要素が、リリース後の評価に直結します。実際に触って確認する機会を早めに設けることで、机上では見えにくい違和感や認識差を早い段階で拾い、後半で大きな手戻りにならないように進めていました。
結果として、仕様未確定のまま進めることによる差し戻しを減らし、再作業を前提にしない進行へ近づけられたと考えています。
おわりに
本プロジェクトでは、単なるタスク管理ではなく、
依存関係・品質・体制制約を踏まえて進行構造そのものを設計すること を、開発PMとして強く意識して取り組みました。
兼任体制の中で、仕様変更、QA方針の見直し、不具合対応、ブラッシュアップ対応が並行して発生する状況では、
与えられた計画をそのままなぞるだけでは、スケジュールだけでなく品質も守れません。
そのため、
- 何を先に決めるべきか
- どこをQAで担保するか
- どこを運用や実装で支えるか
- どの条件が揃えば次工程に進めるのか
といった点を整理しながら、進行を組み立てていきました。
改めて実感したのは、開発PMという役割は、進捗を見るだけの仕事ではないということです。
技術的な理解を前提にしつつも、それ以上に、
- 関係者間の認識を揃えるコミュニケーション力
- 制約の中で現実的な落としどころを作る調整力
- 最終的な判断を引き受ける責任感
が強く求められる仕事だと感じました。
今回の経験を通じて、
「どう進めるか」を設計すること自体が、開発PMの大きな価値である という感覚を、以前より明確に持てるようになりました。
この経験は、今後のキャリアにおいても大きな財産になると考えています。
この記事が、開発PM業務に興味のある方や、限られた体制・短いスケジュールの中で開発を進める方にとって、ひとつの参考になれば嬉しいです。
