ケース2: アジャイル新規事業（モバイルアプリ MVP）

要件不確定・変化対応が必要な新規事業ケース。スクラムを中心とした判断練習。

プロジェクト概要

背景

スタートアップB社のヘルスケアモバイルアプリ
ターゲット市場は20代〜40代女性、競合多数
仮説検証ベースで MVP を3ヶ月でリリース、市場フィードバックで反復改善
期間: 6ヶ月（フェーズ1: MVP 3ヶ月、フェーズ2: 改善 3ヶ月）
チーム: PO 1名、SM 1名、Dev 5名
予算: ¥40M

ステークホルダー

役割	関心
CEO（スポンサー）	売上・市場シェア
PO（プロダクト責任者）	顧客価値・市場適合
投資家	ROI・成長指標
主要顧客（フォーカスグループ）	使いやすさ・価値
マーケティング部	リリース時期・PR

アプローチ

スクラム（2週間スプリント、MVP重視）
データ駆動（Lean Startup の Build-Measure-Learn）

シナリオ1: 役割の混乱

状況

あなたが PM としてアサインされた。キックオフでCEOが「PMが全責任を持って優先度を決めて、開発タスクも割り当ててほしい」と言う。

質問

最適な対応は？

選択肢

A) CEOの指示通りすべて自分で決める B) CEOに対し、スクラムの役割（PO=価値最大化、SM=プロセス、Dev=自己組織化、PMはスクラムでは存在しない）を説明し、自分はサーバント型でPMロールを限定。POを別任命してもらう C) スクラムをやめてPredictiveに切替 D) チームに丸投げ

PMI流解説

正解は B。

アジャイル文脈で PMが命令者になるのは反パターン
スクラムの役割を理解させる
PMロールは「組織との橋渡し」「ガバナンス」「予算管理」「ステークホルダー」に限定
POは別途任命（プロダクト知識を持つ人）

PMP試験では「PMが全部決める」選択肢は 常に誤答。

学習ポイント

アジャイルではPMはサーバント
役割を尊重する
ステークホルダー教育もPMの役割

シナリオ2: 変化する要件

状況

スプリント2の途中、CEOが「競合がX機能を出した。我々もスプリント中に追加で実装してほしい」と要求。

質問

最適対応は？

選択肢

A) 即時スプリントに追加 B) 拒否 C) POにバックログ化を依頼。POは現スプリントの優先順位と比較して、次スプリントから着手するか、現スプリントゴールを変更すべきか判断。スプリント中の保護は原則だが、スプリントゴールが意味を失うなら早期終了→再計画も選択肢 D) PM一存で変更

PMI流解説

正解は C。

スプリントの保護は重要だが、絶対ではない
スプリントゴールが意味を失う場合、スクラムマスター主導でスプリント早期終了 も選択肢（実用上稀）
通常は 次スプリント へ
意思決定は PO が行う

学習ポイント

スプリント保護は原則
ただし価値が変化したら再計画OK
POの判断を尊重

シナリオ3: ベロシティの揺れ

状況

スプリント1: 30pt、スプリント2: 25pt、スプリント3: 18pt と減少傾向。CEO は「予定の機能数が減ってしまう、チームを増員すべき」と要求。

質問

最適対応は？

選択肢

A) 即時増員 B) チーム解雇 C) リトロでベロシティ低下の根本原因（バックログ品質、技術負債、外部依存、チーム疲弊）を分析。Brooks's Lawから安易な増員は逆効果と理解。原因に応じた施策（リファインメント強化、ペアプロ、ストーリー分割改善）を実行 D) ベロシティを目標化してプレッシャーを上げる

PMI流解説

正解は C。

Brooks's Law: 「人を追加しても遅延は加速する」
ベロシティ低下は症状、原因はリトロで分析
安易な増員は新メンバー教育コストで逆効果
持続可能なペースを尊重（アジャイル原則8）

学習ポイント

ベロシティはコミットメントでなく予測指標
増員の罠
リトロが核

シナリオ4: ステークホルダー対立

状況

PO（マーケ出身）と Dev リード（エンジニア）の意見が技術選定で対立。POは「市場標準のXフレームワークで早く出したい」、Devは「将来の拡張性を考えるとYの方が良い」。

質問

PM/SMの最適対応は？

選択肢

A) PMが裁定 B) PO優先 C) 両者を集めて協働的問題解決（Collaborate）。Trade-off（短期速度 vs 長期保守性）を明示。MVPフェーズの目的（市場検証）を再確認し、技術的負債管理計画も合意。判断はPOがチームの意見を踏まえて行う D) スポンサー裁定

PMI流解説

正解は C。

アジャイルでは 対話と協働
技術選定はチーム責任、POが価値の優先順位を提示
フェーズ目的（MVP=市場検証）を踏まえる
技術的負債を意識した選定

学習ポイント

Conflict は Collaborate
技術選定 ≠ 個人選好、価値起点
短期 vs 長期のトレードオフ可視化

シナリオ5: 早期検証の結果

状況

MVPリリース後の最初の2週間、ダウンロード数は予想を下回り、UI/UXのフィードバックが多数。一方、想定していなかった機能Xへの要望が予想外に多い。

質問

次のスプリント計画で何を最優先すべきか？

選択肢

A) 当初計画通り進める B) ダウンロード増のためマーケに大投資 C) POが市場フィードバックを分析し、バックログを再優先順位付け（pivot or persevere）。UI/UX改善＋機能X追加を優先するなら、当初計画の機能を後回し or 削除する判断。データ駆動で意思決定 D) MVPを撤回

PMI流解説

正解は C。

Lean Startup の Build-Measure-Learn
データに基づく pivot or persevere
バックログは固定でない、価値最大化のため動的
当初計画の固守はアンチパターン

学習ポイント

アジャイルは検証ベース
データで判断
バックログは生きている

シナリオ6: 投資家への報告

状況

3ヶ月のMVPフェーズ完了報告で、投資家から「ガントチャートとEVMで進捗を示してほしい」と要求。アジャイルで運営しているのでガントチャートはない。

質問

最適対応は？

選択肢

A) ガントチャートを後付けで作る B) Predictiveに切替 C) Burnup Chart、Velocity Chart、リリースバーンダウンを使い、ステークホルダーが理解できる言葉で進捗・価値・残作業を説明。ハイブリッド報告（マイルストーン＋イテレーション）で互換性を確保 D) 報告拒否

PMI流解説

正解は C。

ステークホルダーが伝統的な指標を求める場合、翻訳するのもPMの役割
ハイブリッド報告フォーマット
価値・データを伝える本質は変わらない

学習ポイント

ステークホルダー言語に合わせる
アジャイルでも進捗・価値の可視化は必要
ハイブリッド報告

シナリオ7: チーム疲弊

状況

3スプリント連続で残業が増えている。CEOが「もっと早く」と毎週圧力。チームメンバーが「やる気が落ちている」と1on1で漏らす。

質問

PMの優先行動は？

選択肢

A) CEOの圧力に応じてチームを督促 B) スコープ削減を一方的に決定 C) CEO（スポンサー）と1on1で価値・スピード・持続可能性のトレードオフを議論。チームには心理的安全性を確保し、リトロでプロセス改善（WIP制限、技術負債返済、機能カット）を提案。アジャイル原則8（持続可能なペース）を共有 D) チーム解散

PMI流解説

正解は C。

持続可能なペースは アジャイル原則
スポンサーへの教育・期待管理もPMの役割
心理的安全性を維持
スコープと品質と速度のトレードオフを共有

学習ポイント

持続可能なペース
スポンサー期待管理
心理的安全性

シナリオ8: 解散と次フェーズ

状況

6ヶ月プロジェクト完了。投資家からフェーズ3として継続予算が承認された。チーム3名が「次プロジェクトに行きたい」と話題に。

質問

PMの最適対応は？

選択肢

A) 全員引き止め B) 完全解散 C) レトロスペクティブで全員のキャリア意向を聞き、知識継承計画＋新規メンバー受入計画を作成。希望者は次PJへ送り出し、新規メンバーには丁寧なオンボーディング D) 自分が決める

PMI流解説

正解は C。

メンバーのキャリアを尊重（サーバント）
知識継承（前ケースと同じ）
チーム再形成（タックマン Forming に戻る）

学習ポイント

メンバーキャリア支援
知識資産化
チーム再構築

全体の学び

アジャイル/スクラム特有のPMI流原則

PMは命令者でなくサーバント — 役割を尊重
スプリント保護は原則だが、価値が変化したら再計画OK
ベロシティはコミットメントでない — 予測指標
対立は対話と協働 — トレードオフ可視化
データ駆動の pivot or persevere
ステークホルダー言語に合わせる — ハイブリッド報告
持続可能なペース — メンバー消耗禁止
メンバーキャリア支援 — サーバント

Predictive ケース1との対比

文書（憲章）vs 対話（PO/POビジョン）
CCB vs バックログ優先順位
EVM vs Burndown/Burnup
計画固定 vs バックログ動的
共通: 倫理・心理的安全性・価値最大化