プロジェクトマネジメントは不確実性との対話だ

【資料公開】第7回 クラメソおおさか IT 勉強会「Midosuji Tech」

Transcript

1. 2025/08/19 クラウド事業本部コンサルティング部 渡部⽐佐志 プロジェクトマネジメントは不確実性との対話だ 〜あなたの「確実」は相⼿の「不確実」かもしれない〜
2. ⾃⼰紹介 渡部 ⽐佐志（Watanabe Hisashi） l 所属 l クラスメソッド株式会社 クラウド事業本部コンサルティング部 プロジェクトマネージャー l 業務 l AWS移⾏、AWS運⽤⽀援、DWH構築などのプロジェクト l 資格 l All AWS Certifications Engineers 2024 - 2025 l IPA：プロジェクトマネージャー、情報処理安全確保⽀援⼠試験合格 l 趣味 l 猫と⼦どものお世話 2
3. 皆さんに質問です 「なぜプロジェクトは予定通りに終わらないのか？」 🤔 こんな経験ありませんか？ l 「簡単だと思ってた」 → 実装したら複雑な依存関係が発覚 l 「合意したはず」 → 本番直前に「そんな話じゃなかった」 l 「伝えたつもり」 → 相⼿は全く違う理解をしていた これ、誰が悪いんでしょうか？ 実は...誰も悪くないんです 3
4. ⽴場によって⾒えている世界が全く違う 同じ「AWS移⾏プロジェクト」でも... 🏢 発注側が「確実」だと思っていること ✅ AWSに移せばコストは下がる（クラウド＝安い） ✅ サーバーをEC2に載せ替えるだけの簡単な作業 ✅ 移⾏ツールを使えば数週間で完了する 💼 受注側が「⾒えている」現実 ⚠ 現⾏システムの設計書が存在しない/古い ⚠ オンプレ特有の設定（IPアドレス固定、特殊ミドルウェア） ⚠ 本番環境でしか検証できないシステムが複数存在 🔥 この認識ギャップが炎上の⽕種になる 4
5. 認識ギャップが引き起こす負の連鎖 Day 1（キックオフ）: 😊 発注「20台のサーバー移⾏、3ヶ⽉でお願いできますか？」 😊 受注「検討します。現状調査させていただいてから...」 → 発注側は「できる」と解釈、受注側は「要調査」の認識 Week 4（定例会）: 😟 発注「調査結果はどうでした？予定通り進められますよね？」 😐 受注「想定より複雑で...依存システムが20個ありまして...」 → 「想定」が全く違っていたことが判明 緊急会議: 😱 発注「なぜ今頃そんな話が！？スケジュール遅延？」 😰 受注「最初から懸念はお伝えしていたのですが...」 → 「伝えた」「聞いてない」の⽔掛け論 🔥 お互い「ちゃんと伝えたはず」なのに... 5
6. ⾒積もりの「誤差」は避けられない 不確実性には科学的な根拠がある 「3ヶ⽉で移⾏」の体感精度 🏢 発注側の感覚：3ヶ⽉ = ほぼ3ヶ⽉（±2週間） 💼 受注側の感覚：3ヶ⽉ = 1〜12ヶ⽉もありえる 「不確実性のコーン」が⽰す事実 • プロジェクト初期：0.25倍〜4倍の誤差 • 要件定義後：0.5倍〜2倍に改善 • 設計完了後：0.8倍〜1.25倍に収束 📊 つまり ✅ プロジェクト初期の不確実性は「構造的」なもの ✅ どちらも間違っていない、⾒えている範囲が違うだけ ✅ 対話を重ねることで精度を上げていく 6 Steve McConnell.『ソフトウェア⾒積り ⼈⽉の暗黙知を解き明かす』.⽇経BP.2006年,485p
7. なぜ⾒えている世界が違うのか？ それぞれの「当たり前」が違う ⾒ている視点も違う • 発注側：ゴール（What/Why）を⾒ている • 受注側：プロセス（How）を⾒ている 💡 PMが全体を⾒るためには「翻訳」と「対話」が必要 7 🏢 発注側の常識 l 「クラウド = コスト削減」 l 「移⾏ = サーバーの引っ越し」 l 「3ヶ⽉あれば⼗分」 💼 受注側の常識 l 「クラウド = 改修なしだと逆に⾼い」 l 「移⾏ = 現状調査から始まる⻑い道のり」 l 「3ヶ⽉ = 調査だけで終わる」
8. では、どうすればいいか？ 🤝 ⽴場の違いを「強み」に変える ここまでの問題 ❌ ⽴場の違いで認識がズレる ❌ 同じ⾔葉でも意味が違う ❌ 優先順位がバラバラ 発想の転換 違いを排除するのではなく、違いを前提に共通認識を作る 🎯 共通認識を作る「3つの対話」 WHY（なぜ） → WHAT（なにを） → HOW（どうやって） この順番で対話することで、⽴場の違いを乗り越えられる 8
9. 1⃣ WHY - なぜやるのか？の対話 ❌ 曖昧な例：「DXを推進する」 ✅ 明確な例：「インフラコストを3年で30％削減し、保守⼈員を新規事業に配置転換する」 → 全員がより具体的な成功イメージを持つ 2⃣ WHAT - 何をやって、何をやらないか？の対話 ❌ 曖昧な例：「できるだけ多くのシステムを移⾏」 ✅ 明確な例：「売上直結の20システムは移⾏、3年後廃⽌予定の5システムは対象外」 → スコープの認識を⼀致させる 3⃣ HOW - どうやって進めるか？の対話 ❌ 曖昧な例：「ベンダーと相談しながら」 ✅ 明確な例：「3ヶ⽉で技術検証→6ヶ⽉で段階移⾏→各フェーズで経営判断」 → 進め⽅の共通理解ができる ⚠ 重要：必ずWHY→WHAT→HOWの順番で対話する 9 不確実性を確実性に変える「3つの対話」
10. 継続的な不確実性の管理 🔄 共通認識を作った後も、PMがやり続けること WHY/WHAT/HOWを決めても、新たな不確実性は⽣まれ続ける 💡 発⾒：不確実性を「⾒える化」する l 「分からない」を歓迎する雰囲気作り l 会議で「確定事項/未確定事項」を確認する ⚡ 対策：不確実性に「備える」 l 影響の⼤きい不確実性から優先的に対処 l ⼩さく試して（PoC、リハーサル）早めに確実にする 📊 管理：不確実性を「追跡する」 l 不確実性を洗い出して継続的に状態管理 l 新たな課題を探し続ける 10
11. よくある誤解 ❌ PM = 全てを把握している⼈ ❌ PM = リスクを排除する⼈ ❌ PM = 計画通りに進める⼈ あるべきPM像 ✅ PM = 不確実性を可視化する⼈ ✅ PM = ⽴場の違いを橋渡しする⼈ ✅ PM = 対話を通じて確実性を増やす⼈ 不確実性は悪ではない、前提条件。早く「分からない」と⾔えるチームが強い。 💡 PMは「知っている⼈」ではなく「⼀緒に考える⼈」 11 PMの本当の役割は「翻訳者」であり「対話の促進者」
12. 💬 会議やメールで「現時点で分からないこと」を先に共有する 「スケジュールの件ですが、〇〇の部分がまだ不明なので、△△を確認してから回答します」 → 不確実性を隠さず、対話の起点にする 🤝 ⾃分の意⾒を⾔った後に、相⼿の認識を確認する習慣 「私は〇〇だという認識ですが、イメージあっていますか？」 → ⽴場の違いを前提に、対話で認識を合わせる ✅ 会議の最後に「今⽇決まったこと」を必ず⼝に出して確認 「今⽇は〇〇と△△が決まりましたが、認識合ってますか？」 → 少しずつ確実性を積み上げる 12 明⽇から実践できる3つのこと
13. 🌟 まとめ よくある考え⽅ ❌ 不確実性 = リスク = 排除すべきもの → 完璧な計画を作ろうとし、想定外を恐れ、失敗を隠す 転換後の発想 ✅ 不確実性 = 前提 = 対話の起点 → 段階的に明確にし、想定外を早期共有し、学習機会として活⽤する 📢 今⽇のコアメッセージ プロジェクトマネジメントは不確実性との対話 不確実性を受容し、対話で確実性を⾼めよう 13 最後に