ステークホルダー管理
ストーリー
「プロジェクト計画を立てたら、次は関係者の期待を管理する必要がある」
渡辺マネージャーが続けた。
「技術的に完璧でも、ステークホルダーの期待と ずれていたら『失敗プロジェクト』になる。 逆に、多少の遅延があっても、適切にコミュニケーションしていれば 信頼は守られる。期待をコントロールする技術を学ぼう」
ステークホルダーとは
プロジェクトに利害関係を持つ全ての人をステークホルダーと呼びます。
ステークホルダーの特定
コンビニ決済機能追加プロジェクトのステークホルダー:
社内:
├─ 経営層（CTO、事業部長）
├─ プロダクトオーナー（PO）
├─ 開発チーム
├─ QAチーム
├─ デザインチーム
├─ カスタマーサポート
├─ 営業チーム
└─ セキュリティチーム
社外:
├─ 決済代行サービス（外部ベンダー）
└─ エンドユーザー
ステークホルダーマッピング
影響力 x 関心度マトリクス
関心度 高
│
┌─────────┼─────────┐
│ 満足を │ 密に │
│ 維持 │ 管理 │
影 │ │ │
響 │ セキュリティ│ PO │
力 │ チーム │ CTO │
高──┼─────────┼─────────┤
│ 監視 │ 情報 │
│ のみ │ 提供 │
│ │ │
│ エンド │ 営業チーム │
│ ユーザー │ CS チーム │
└─────────┼─────────┘
関心度 低
各象限への対応方針
| 象限 | 対応方針 | コミュニケーション頻度 |
|---|---|---|
| 密に管理（高影響×高関心） | 定期的に詳細な報告、意思決定に参加してもらう | 週次以上 |
| 満 足を維持（高影響×低関心） | 大きな決定時に報告、変更時に確認 | マイルストーン時 |
| 情報提供（低影響×高関心） | 定期的に進捗を共有 | 隔週 |
| 監視のみ（低影響×低関心） | 必要時のみ連絡 | リリース時 |
期待のマネジメント
期待値を合わせる
プロジェクト開始時にステークホルダーの期待を把握し、現実と合わせることが重要です。
期待値のずれが起きるパターン:
PO の期待: 「全コンビニ10社対応 + モバイルアプリ対応」
実際のスコープ: 「主要3社 + Web版のみ」
→ 開始時に期待値を合わせないと、
リリース時に「思ってたのと違う」と言われる
期待値を合わせるフレームワーク
| ステップ | 内容 | 具体例 |
|---|---|---|
| 1. ヒアリング | 相手の期待を聴く | 「この機能に何を期待していますか？」 |
| 2. 現実の提示 | 制約条件を伝える | 「2ヶ月では主要3社対応が現実的です」 |
| 3. 合意形成 | 優先順位を決める | 「まず3社対応、残りはフェーズ2で」 |
| 4. 文書化 | 合意内容を記録 | スコープドキュメントに明記 |
| 5. 定期確認 | 期待値がずれていないか確認 | 隔週のミーティングで確認 |
ステークホルダーへの報告の使い分け
報告レベルの設計
経営層（CTO）:
頻度: 月次 or マイルストーン時
内容: エグゼクティブサマリー（3行）
形式: メール or 1スライド
例: 「コンビニ決済PJは予定通り進行中。
4/30リリースに変更なし。
リスク: 外部API連携のテスト遅延の可能性（対策済み）」
PO:
頻度: 週次
内容: 機能の進捗、デモ、判断が必要な事項
形式: ミーティング + 進捗報告書
例: バーンダウンチャート、完了機能のデモ、優先順位の相談
開発チーム:
頻度: 毎日
内容: 技術的な詳細、ブロッカー、依存関係
形式: デイリースタンドアップ + Slack
変更管理
スコープ変更の依頼が来た時
PO: 「やっぱりQRコード決済も追加してほしい」
NG対応:
「わかりました」（安請け合い）
「無理です」（拒否）
OK対応:
1. 要望を正確に理解する
「QRコード決済とは具体的にどの方式ですか？」
2. 影響を分析する
「追加に2週間の工数が必要です。
現在のスコープを維持する場合、リリースが2週間遅れます」
3. 選択肢を提示する
「A案: リリースを5/14に延期してQRコードを含める
B案: 4/30にコンビニ決済をリリースし、QRコードはフェーズ2
C案: モバイルアプリ対応を削除してQRコードを追加」
4. 判断を仰ぐ
「どの案で進めるか決めていただけますか？」
変更管理のルール
| ルール | 内容 |
|---|---|
| 変更は文書化する | 口頭の依頼は記録に残す |
| 影響を分析する | スケジュール、コスト、品質への影響 |
| トレードオフを明示する | 追加するなら何を削るか |
| 承認プロセスを経る | 誰が承認するかを決めておく |
信頼関係の構築
ステークホルダーとの信頼を築く行動
| 行動 | 効果 |
|---|---|
| 約束を守る | 「あの人に任せれば大丈夫」 |
| 悪いニュースを早く伝える | 「正直な人だ。信頼できる」 |
| 定期的に報告する | 「状況が把握できて安心」 |
| 相手の立場で考える | 「自分たちのことを理解してくれている」 |
| 選択肢を提示する | 「問題だけでなく解決策も考えてくれる」 |
信頼を失う行動
| 行動 | 結果 |
|---|---|
| 問題を隠す | 発覚時に信頼崩壊 |
| 安請け合いする | 結局守れずに信頼低下 |
| 報告しない | 「何をしているかわからない」 |
| 一方的に決める | 「こちらの意見を聞いてくれない」 |
まとめ
| ポイント | 内容 |
|---|---|
| ステークホルダー特定 | プロジェクトに関わる全ての関係者を洗い出す |
| マッピング | 影響力と関心度で分類し、対応方針を決める |
| 期待のマネジメント | 開始時に期待値を合わせ、定期的に確認 |
| 報告の使い分け | 相手に応じた頻度・内容・形式で報告 |
| 変更管理 | 影響分析、トレードオフの明示、承認プロセス |
チェックリスト
- ステークホルダーマッピングを作成できる
- 期待値を合わせるフレームワークを使える
- 報告レベルを相手に応じて使い分けられる
- スコープ変更依頼への対応手順を知っている
次のステップへ
次のセクションでは、「振り返りとKPT」を学びます。プロジェクトやスプリントの振り返りを通じて、チームの継続的な改善を推進する方法を身につけましょう。
推定読了時間: 30分