Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロジェクトマネジメントは不確実性との対話だ
Search
HisashiWatanabe
August 19, 2025
Technology
0
230
プロジェクトマネジメントは不確実性との対話だ
【資料公開】第7回 クラメソおおさか IT 勉強会「Midosuji Tech」
HisashiWatanabe
August 19, 2025
Tweet
Share
More Decks by HisashiWatanabe
See All by HisashiWatanabe
AWS移行のWHY,WHAT,HOW
hisashiwatanabe
0
1.1k
Other Decks in Technology
See All in Technology
カミナシ社の『ID管理基盤』製品内製 - その意思決定背景と2年間の進化 #AWSUnicornDay / Kaminashi ID - The Big Whys
kaminashi
3
810
Nstockの一人目エンジニアが 3年間かけて向き合ってきた セキュリティのこととこれから〜あれから半年〜
yo41sawada
0
210
実践!カスタムインストラクション&スラッシュコマンド
puku0x
0
150
バッチ処理で悩むバックエンドエンジニアに捧げるAWS Glue入門
diggymo
3
130
なぜSaaSがMCPサーバーをサービス提供するのか?
sansantech
PRO
8
2.5k
AI エージェントとはそもそも何か? - 技術背景から Amazon Bedrock AgentCore での実装まで- / AI Agent Unicorn Day 2025
hariby
4
1.2k
Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp
oracle4engineer
PRO
4
9.9k
Kubernetes における cgroup driver のしくみ: runwasi の bugfix より
z63d
2
230
自作JSエンジンに推しプロポーザルを実装したい!
sajikix
1
160
「魔法少女まどか☆マギカ Magia Exedra」の必殺技演出を徹底解剖! -キャラクターの魅力を最大限にファンに届けるためのこだわり-
gree_tech
PRO
0
590
【初心者向け】ローカルLLMの色々な動かし方まとめ
aratako
7
3.2k
[RSJ25] Feasible RAG: Hierarchical Multimodal Retrieval with Feasibility-Aware Embodied Memory for Mobile Manipulation
keio_smilab
PRO
0
110
Featured
See All Featured
Building Adaptive Systems
keathley
43
2.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Balancing Empowerment & Direction
lara
3
610
Speed Design
sergeychernyshev
32
1.1k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.6k
Become a Pro
speakerdeck
PRO
29
5.5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
How GitHub (no longer) Works
holman
315
140k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
We Have a Design System, Now What?
morganepeng
53
7.8k
Designing Experiences People Love
moore
142
24k
Transcript
2025/08/19 クラウド事業本部コンサルティング部 渡部⽐佐志 プロジェクトマネジメントは不確実性との対話だ 〜あなたの「確実」は相⼿の「不確実」かもしれない〜
⾃⼰紹介 渡部 ⽐佐志(Watanabe Hisashi) l 所属 l クラスメソッド株式会社 クラウド事業本部コンサルティング部 プロジェクトマネージャー
l 業務 l AWS移⾏、AWS運⽤⽀援、DWH構築などのプロジェクト l 資格 l All AWS Certifications Engineers 2024 - 2025 l IPA:プロジェクトマネージャー、情報処理安全確保⽀援⼠試験合格 l 趣味 l 猫と⼦どものお世話 2
皆さんに質問です 「なぜプロジェクトは予定通りに終わらないのか?」 🤔 こんな経験ありませんか? l 「簡単だと思ってた」 → 実装したら複雑な依存関係が発覚 l 「合意したはず」
→ 本番直前に「そんな話じゃなかった」 l 「伝えたつもり」 → 相⼿は全く違う理解をしていた これ、誰が悪いんでしょうか? 実は...誰も悪くないんです 3
⽴場によって⾒えている世界が全く違う 同じ「AWS移⾏プロジェクト」でも... 🏢 発注側が「確実」だと思っていること ✅ AWSに移せばコストは下がる(クラウド=安い) ✅ サーバーをEC2に載せ替えるだけの簡単な作業 ✅ 移⾏ツールを使えば数週間で完了する
💼 受注側が「⾒えている」現実 ⚠ 現⾏システムの設計書が存在しない/古い ⚠ オンプレ特有の設定(IPアドレス固定、特殊ミドルウェア) ⚠ 本番環境でしか検証できないシステムが複数存在 🔥 この認識ギャップが炎上の⽕種になる 4
認識ギャップが引き起こす負の連鎖 Day 1(キックオフ): 😊 発注「20台のサーバー移⾏、3ヶ⽉でお願いできますか?」 😊 受注「検討します。現状調査させていただいてから...」 → 発注側は「できる」と解釈、受注側は「要調査」の認識 Week
4(定例会): 😟 発注「調査結果はどうでした?予定通り進められますよね?」 😐 受注「想定より複雑で...依存システムが20個ありまして...」 → 「想定」が全く違っていたことが判明 緊急会議: 😱 発注「なぜ今頃そんな話が!?スケジュール遅延?」 😰 受注「最初から懸念はお伝えしていたのですが...」 → 「伝えた」「聞いてない」の⽔掛け論 🔥 お互い「ちゃんと伝えたはず」なのに... 5
⾒積もりの「誤差」は避けられない 不確実性には科学的な根拠がある 「3ヶ⽉で移⾏」の体感精度 🏢 発注側の感覚:3ヶ⽉ = ほぼ3ヶ⽉(±2週間) 💼 受注側の感覚:3ヶ⽉ =
1〜12ヶ⽉もありえる 「不確実性のコーン」が⽰す事実 • プロジェクト初期:0.25倍〜4倍の誤差 • 要件定義後:0.5倍〜2倍に改善 • 設計完了後:0.8倍〜1.25倍に収束 📊 つまり ✅ プロジェクト初期の不確実性は「構造的」なもの ✅ どちらも間違っていない、⾒えている範囲が違うだけ ✅ 対話を重ねることで精度を上げていく 6 Steve McConnell.『ソフトウェア⾒積り ⼈⽉の暗黙知を解き明かす』.⽇経BP.2006年,485p
なぜ⾒えている世界が違うのか? それぞれの「当たり前」が違う ⾒ている視点も違う • 発注側:ゴール(What/Why)を⾒ている • 受注側:プロセス(How)を⾒ている 💡 PMが全体を⾒るためには「翻訳」と「対話」が必要 7
🏢 発注側の常識 l 「クラウド = コスト削減」 l 「移⾏ = サーバーの引っ越し」 l 「3ヶ⽉あれば⼗分」 💼 受注側の常識 l 「クラウド = 改修なしだと逆に⾼い」 l 「移⾏ = 現状調査から始まる⻑い道のり」 l 「3ヶ⽉ = 調査だけで終わる」
では、どうすればいいか? 🤝 ⽴場の違いを「強み」に変える ここまでの問題 ❌ ⽴場の違いで認識がズレる ❌ 同じ⾔葉でも意味が違う ❌ 優先順位がバラバラ
発想の転換 違いを排除するのではなく、違いを前提に共通認識を作る 🎯 共通認識を作る「3つの対話」 WHY(なぜ) → WHAT(なにを) → HOW(どうやって) この順番で対話することで、⽴場の違いを乗り越えられる 8
1⃣ WHY - なぜやるのか?の対話 ❌ 曖昧な例:「DXを推進する」 ✅ 明確な例:「インフラコストを3年で30%削減し、保守⼈員を新規事業に配置転換する」 → 全員がより具体的な成功イメージを持つ
2⃣ WHAT - 何をやって、何をやらないか?の対話 ❌ 曖昧な例:「できるだけ多くのシステムを移⾏」 ✅ 明確な例:「売上直結の20システムは移⾏、3年後廃⽌予定の5システムは対象外」 → スコープの認識を⼀致させる 3⃣ HOW - どうやって進めるか?の対話 ❌ 曖昧な例:「ベンダーと相談しながら」 ✅ 明確な例:「3ヶ⽉で技術検証→6ヶ⽉で段階移⾏→各フェーズで経営判断」 → 進め⽅の共通理解ができる ⚠ 重要:必ずWHY→WHAT→HOWの順番で対話する 9 不確実性を確実性に変える「3つの対話」
継続的な不確実性の管理 🔄 共通認識を作った後も、PMがやり続けること WHY/WHAT/HOWを決めても、新たな不確実性は⽣まれ続ける 💡 発⾒:不確実性を「⾒える化」する l 「分からない」を歓迎する雰囲気作り l 会議で「確定事項/未確定事項」を確認する
⚡ 対策:不確実性に「備える」 l 影響の⼤きい不確実性から優先的に対処 l ⼩さく試して(PoC、リハーサル)早めに確実にする 📊 管理:不確実性を「追跡する」 l 不確実性を洗い出して継続的に状態管理 l 新たな課題を探し続ける 10
よくある誤解 ❌ PM = 全てを把握している⼈ ❌ PM = リスクを排除する⼈ ❌
PM = 計画通りに進める⼈ あるべきPM像 ✅ PM = 不確実性を可視化する⼈ ✅ PM = ⽴場の違いを橋渡しする⼈ ✅ PM = 対話を通じて確実性を増やす⼈ 不確実性は悪ではない、前提条件。早く「分からない」と⾔えるチームが強い。 💡 PMは「知っている⼈」ではなく「⼀緒に考える⼈」 11 PMの本当の役割は「翻訳者」であり「対話の促進者」
💬 会議やメールで「現時点で分からないこと」を先に共有する 「スケジュールの件ですが、〇〇の部分がまだ不明なので、△△を確認してから回答します」 → 不確実性を隠さず、対話の起点にする 🤝 ⾃分の意⾒を⾔った後に、相⼿の認識を確認する習慣 「私は〇〇だという認識ですが、イメージあっていますか?」 → ⽴場の違いを前提に、対話で認識を合わせる
✅ 会議の最後に「今⽇決まったこと」を必ず⼝に出して確認 「今⽇は〇〇と△△が決まりましたが、認識合ってますか?」 → 少しずつ確実性を積み上げる 12 明⽇から実践できる3つのこと
🌟 まとめ よくある考え⽅ ❌ 不確実性 = リスク = 排除すべきもの →
完璧な計画を作ろうとし、想定外を恐れ、失敗を隠す 転換後の発想 ✅ 不確実性 = 前提 = 対話の起点 → 段階的に明確にし、想定外を早期共有し、学習機会として活⽤する 📢 今⽇のコアメッセージ プロジェクトマネジメントは不確実性との対話 不確実性を受容し、対話で確実性を⾼めよう 13 最後に
14