プロダクト開発のトラブルを予防するために どうして「大丈夫です」と報告されるのに スケジュールは遅れるのか

ProductZine Day 2024 Winter
https://event.shoeisha.jp/pzday/20240130/timetable

Transcript

1. プロダクト開発のトラブルを予防するために どうして「大丈夫です」と報告されるのに スケジュールは遅れるのか ProductZine Day 2024 Winter NCDC株式会社 武方順平 2024/01/30
2. 自己紹介 ⚫ 武方順平 ⚫ NCDC株式会社 ⚫ プロダクトオーナー・シニアエンジニア ⚫ 2019年フルスタックエンジニアとして入社 ⚫ B2B・B2Cのウェブ・スマホアプリ開発 ⚫ 現在は自社プロダクトの立ち上げを担当 2
3. はじめに こんなことありませんか？ 3 (次の例は実際の人物・プロジェクトには関係ありません）
4. とある日の進捗会議 「進捗どうですか？」 「「「大丈夫です」」」 4
5. とある日の進捗会議 「進捗どうですか？」 「「「大丈夫です」」」 「スケジュールにも問題なさそうだし、メンバーは問 題ないって言ってるし、大丈夫だな。ヨシ！」 5
6. 6 数週間後…
7. 7 数週間後… 「リリース後に不具合報告が多数出ています」 「このままだとリリース予定日に間に合わなそうです」 「スコープ厳しいのでこの機能入りません」
8. 8 数週間後… 「リリース後に不具合報告が多数出ています」 「このままだとリリース予定日に間に合わなそうです」 「スコープ厳しいのでこの機能入りません」 「プロジェクト状況を把握してないって、あなたの仕事は何ですか？」 「リリース日は厳守してください」 「今更言われても困るよ、なんとかしてね」
9. 9 数週間後… 「リリース後に不具合報告が多数出ています」 「このままだとリリース予定日に間に合わなそうです」 「スコープ厳しいのでこの機能入りません」 「プロジェクト状況を把握してないって、あなたの仕事は何ですか？」 「リリース日は厳守してください」 「今更言われても困るよ、なんとかしてね」 「それぞれのタスク消化に追われてチームの空気悪くないですか？」 「やめさせてください」 「いつまでこれ続くんですか？」
10. 10 数週間後… 「リリース後に不具合報告が多数出ています」 「このままだとリリース予定日に間に合わなそうです」 「スコープ厳しいのでこの機能入りません」 「プロジェクト状況を把握してないって、あなたの仕事は何ですか？」 「リリース日は厳守してください」 「今更言われても困るよ、なんとかしてね」 「それぞれのタスク消化に追われてチームの空気悪くないですか？」 「やめさせてください」 「いつまでこれ続くんですか？」
11. 11 こうはなりたくない なにが悪かった？
12. はじめに：本日のゴール ⚫ リスクをマネジメントする ⚫ メンバーはリスクを察知している ⚫ 不安を共有できる環境を作る ⚫ 弊社での事例 12
13. プロダクト開発の難しさ ⚫ 顧客と市場に受け入れられるか → 企画の難しさ 13
14. プロダクト開発の難しさ ⚫ 顧客と市場に受け入れられるか → 企画の難しさ ⚫ 目的の価値を一定以上の品質で届けられるか ⚫ ビジネス上のデッドラインを守れるか → 開発の難しさ 14
15. プロダクト開発の難しさ ⚫ 企画の難しさ ⚫ 開発の難しさ + ⚫ 正しい計画を立てることが難しい ⚫ 計画通りに進まない → 計画の難しさ 15
16. 不確実性が計画を狂わせる ⚫ プロダクト開発では多種の問題が起きる ⚫ 問題は不確実さから生まれるリスクに起因している → 問題への対応が後手になる ⚫ 必要なのは起きる前の対応 → リスクマネジメント 16
17. リスクと問題 ⚫ リスク：計画を阻害する起こりうる事柄 ⚫ 問題：計画を阻害するすでに発生した事柄 17
18. リスクと問題 ⚫ リスク：計画を阻害する起こりうる事柄 ⚫ 問題：すでに発生した計画を阻害する事柄 18 リスク 問題 顕在化
19. リスクマネジメントに必要なこと ⚫ 起こり得るリスクを洗い出す ⚫ リスクを評価し、対応を考える 19
20. システム開発の主なリスク ⚫ スケジュールの欠陥 ⚫ 要求の増大 ⚫ 人員の離脱 ⚫ 仕様の崩壊 ⚫ 生産性の低迷 → 全てに備えるのは難しい 20
21. システム開発の主なリスク ⚫ スケジュールの欠陥 ⚫ 要求の増大 ⚫ 人員の離脱 ⚫ 仕様の崩壊 ⚫ 生産性の低迷 →顕在化しそうなリスクを知りたい 21
22. とある日の進捗会議 「進捗どうですか？」 「「「大丈夫です」」」 「スケジュールにも問題なさそうだし、メンバーは問 題ないって言ってるし、大丈夫だな。ヨシ！」 22
23. 23 数週間後… 「リリース後に不具合報告が多数出ています」 「このままだとリリース予定日に間に合わなそうです」 「スコープ厳しいのでこの機能入りません」 「プロジェクト状況把握してないって。、あなた の仕事は何ですか？」 「リリース日は厳守してください」 「今更言われても困るよ、なんとかしてね」 「それぞれのタスク消化に追われてみんなバラバラじゃないですか？」 「やめさせてください」 「いつまでこれ続くんですか？」
24. 24 なんでこんなことに？
25. 25 数週間後… 「リリース後に不具合報告が多数出ています」 「このままだとリリース予定日に間に合わなそうです」 「スコープ厳しいのでこの機能入りません」 「プロジェクト状況把握してないって。、あなた の仕事は何ですか？」 「リリース日は厳守してください」 「今更言われても困るよ、なんとかしてね」 「それぞれのタスク消化に追われてみんなバラバラじゃないですか？」 「やめさせてください」 「いつまでこれ続くんですか？」
26. 26 「このままだとリリース予定日に間に合わなそうです」 「仕様の確認の手戻りが多いな この感じで進めて大丈夫なんだろうか」
27. 27 数週間後… 「リリース後に不具合報告が多数出ています」 「このままだとリリース予定日に間に合わなそうです」 「スコープ厳しいのでこの機能入りません」 「プロジェクト状況把握してないって。、あなた の仕事は何ですか？」 「リリース日は厳守してください」 「今更言われても困るよ、なんとかしてね」 「それぞれのタスク消化に追われてみんなバラバラじゃないですか？」 「やめさせてください」 「いつまでこれ続くんですか？」
28. 28 「リリース後に不具合報告が多数出ています」 28 「コード品質が下がってる気がする、 今のタスクには影響出てないけど・・」
29. メンバーが考えていたかもしれないこと ⚫ 「会議ばかりで時間がとれない」 ⚫ 「見積もりが間違っていたかも」 ⚫ 「この機能、優先度が低い気がするなあ」 ⚫ 「仕様の理解が曖昧になっている」 ⚫ 「他の人は大変そうだし自分がやらなきゃ」 ⚫ 「ステークホルダーと話すと手戻りがある」 29
30. メンバー視点だと…？ ⚫ 「会議ばかりで時間がとれない」 ⚫ 「見積もりが間違っていたかも」 ⚫ 「この機能、優先度が低い気がするなあ」 ⚫ 「仕様の理解が曖昧になっている」 ⚫ 「他の人は大変そうだし自分がやらなきゃ」 ⚫ 「ステークホルダーと話すと手戻りがある」 → 計画・プロセス・コミュニケーション等の課題 30
31. メンバーはリスクを見つけていた ⚫ 業務の中での些細な違和感 ⚫ 不安 → 顕在化しそうなプロジェクトリスク 31
32. 「わかってたなら先に言ってよ」 「大丈夫です」と報告したのに？ 32
33. 「わかってたなら先に言ってよ」 「大丈夫です」と報告したのに？ → 言えなかった理由があるはず 33
34. なぜ進捗会議で聞けなかったのか ⚫ 影響がまだ出ていないから → 避けられなくなってから共有される ⚫ 正常性バイアスが働く → 不安を伝えるのは心理的に負担 34
35. 不安を伝えるハードル 35
36. 心理的安全性を妨げる4つの要素 無知だと思われる 無能だと思われる 邪魔をしていると思われる ネガティブだと思われる 36 エイミー・C・エドモンドソン「チームが機能するとはどういうことか」英治出版
37. 心理的安全性を妨げる4つの要素 無知だと思われる不安 →「仕様の理解が曖昧になっている」 無能だと思われる不安 →「見積もりが間違っていたかも」 邪魔をしていると思われる不安 →「この機能優先度低いのでは」 ネガティブだと思われる不安 →「他の人は大変そうだし自分がやらなきゃ」 37 エイミー・C・エドモンドソン「チームが機能するとはどういうことか」英治出版
38. 不安を伝えるハードル 38
39. ハードルを乗り越えてもらう① ⚫ 乗り越えるエネルギーを与える → 動機づけ ⚫ プロジェクトが改善すると不安が減る 39
40. 不安共有による改善サイクル 40 プロジェクト メンバー チーム ①不安を共有 ②リスクに対応 ③不安が減る
41. ハードルを乗り越えてもらう② ⚫ ハードルを下げる → 習慣化・ルーチンの形成 41
42. 仕組みを作る 案1. 個別に聞く → 各メンバーと細かく1on1を行う 案2. 全体で聞けるようにする → 心理的安全性を高める 42
43. 弊社での事例 前提 ⚫ メンバー：30人程度(当時) ⚫ 5~10プロジェクト ⚫ 週次での全体MTG 43
44. 朝礼の場で週次のアンケートを行った 44 プロジェクトの不安を5段階評価で質問 会議中にリアルタイムで入力 結果を確認 詳細を直接尋ねる その場でアクションを設定する
45. なぜそうしたのか アンケートを投げるだけだと ⚫ 記入率を高めるのが難しい ⚫ 結果からさらなるヒアリングが必要 → その場で記入してもらい詳細を尋ねる ⚫ 各プロジェクトに閉じている情報 → 組織全体で取りこぼしがないように確認する 45
46. 結果どうなった？ ⚫ リリースへの不安を発見し、調整する場を設けられた ⚫ 不安の可視化ができた ⚫ 不安を共有すると良いことがある 46
47. アンケートの問題点 ⚫ 全体の前では話しにくい ⚫ 心理的安全性へのハードルが高くなる ⚫ 「どうして不安に感じているの？」と質問をすると圧力に なる ⚫ 漠然とした不安 ⚫ 説明の難しさ ⚫ 規模が大きくなると実施に時間がかかる ⚫ 深掘りできない 47
48. 48 反省を活かして改善する
49. 全体の前では話しにくい → 全体の前で話すことをやめた 1. 回答結果を全体で確認せず、マネージャーが1次チェック をする 2. マネージャーは不明点をメンバーに確認しつつ、状況を まとめる 49
50. 記入率の課題は？ ⚫ アンケートの習慣がすでに形成されていた 50
51. 問いかけの圧力 → 目的の共有 ⚫ プロジェクトのリスクを知ることが目的 ⚫ 個人の批判や人事評価を目的としているわけではない → 問いかけの仕方 ⚫ なぜ？（理由）ではなく何があったのか（事実）を聞く 51
52. 規模が大きくなると アンケートの実施に時間がかかってしまう → プロジェクトごとにアンケートを実施 52
53. 53 これらを踏まえて作り直した
54. プロジェクトごとにアンケートをとる メンバーは各項目に5段階で回答 → 開発中の些細な不安を共有 54
55. 回答を元にコミュニケーションを取る マネージャーは回答をもとに メンバーと会話 → リスクを把握 55
56. レポートを作成する PMは状況を報告する → ステークホルダーへ共有 → 状況を整理するきっかけ 56
57. 複数プロジェクトを一覧 情報をオープンにする → 不安共有の文化醸成 57
58. まとめ ⚫ プロダクト開発には多種のリスクが潜んでいる ⚫ メンバーはリスクを早期察知している ⚫ 不安を共有したい ⚫ 文化とシステム両輪で対応している 58
59. 見えない不安を可視化するPJ Insight ⚫ https://pj-insight.net/ ⚫ サービス公開中 ⚫ 基本料金無料 ⚫ 30日間の無料トライアルを実施 59