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
250
プロジェクトマネジメントは不確実性との対話だ
【資料公開】第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
mypyの10年、pyrightの5年 tyの挑戦 - 型チェッカー進化論 -
byfarsmall
0
130
【新卒研修資料】LLM・生成AI研修 / Large Language Model・Generative AI
brainpadpr
12
5.7k
サプライチェーン攻撃に学ぶModuleの仕組みと セキュリティ対策
kuro_kurorrr
3
590
AWSのProductのLifecycleについて
stknohg
PRO
0
250
Streamlit は社内ツールだけじゃない!PoC の速さで実現する'商用品質'の分析 SaaS アーキテクチャ
kdash
1
710
最近話題のForward Deployed EngineerとPalantirについて調べてみた / Recently popular topics: Forward Deployed Engineer and Palantir
jumtech
0
120
Where does my memory come from?
ennael
PRO
0
110
GA technologiesでのAI-Readyの取り組み@DataOps Night
yuto16
0
140
CTFのためのKubernetes入門
kyohmizu
2
760
RailsのPostgreSQL 18対応
yahonda
0
850
CData MCP ナイト!「CData × Oracleで実現する新しいデータ活用 ― 国産SaaS 連携から MCP Server for Oracle Database まで」
shisyu_gaku
0
160
WebアプリケーションのUI構築で気を付けてるポイント
tomokusaba
0
100
Featured
See All Featured
Scaling GitHub
holman
463
140k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
2.6k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.1k
A better future with KSS
kneath
239
17k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Agile that works and the tools we love
rasmusluckow
330
21k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
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