プロジェクト炎上を予防するためにメンバーひとりひとりができること

2024/02/16 Developers Summit 2024にて登壇したスライドです。

Transcript

1. プロジェクト炎上を予防するために メンバーひとりひとりができること Developers Summit 2024 NCDC株式会社 武⽅順平 2024/02/16
2. 2 みなさん、炎上してますか？
3. 3 炎上したことある？
4. 4 炎上したい⽅はいますか？
5. 5 炎上、したくないですよね
6. ⾃⼰紹介：武⽅順平 l 所属：NCDC株式会社 l エンジニア：B2B・B2Cのウェブアプリ開発 l PdM： PJ Insightの⽴ち上げ l 登壇：ProductZine Day Winter 2024 l 炎上経験：⽕付け・⽕消し 6
7. 本⽇伝えたいこと l 不安は炎上のサイン l 不安を伝えることで炎上を減らせる l 不安を伝えやすくするには l 弊社での事例 7
8. 炎上と周辺概念 プロジェクトの l 失敗：期間・予算・品質が⽬標未達 l 炎上：上記の回避が困難な状況 l デスマーチ：上記の中での過剰労働 8
9. リスクと問題 l リスク：計画を阻害する起こりうる事柄 l 問題：計画を阻害するすでに発⽣した事柄 9 リスク 問題 顕在化 失敗 炎上
10. リスクと問題 l リスク：計画を阻害する起こりうる事柄 l 問題：計画を阻害するすでに発⽣した事柄 10 リスク 問題 顕在化 失敗 炎上 コントロールしたい
11. リスクマネジメントに必要なこと l 起こり得るリスクを洗い出す l リスクを評価する l リスクへの対応を考える 11
12. システム開発の主なリスク l スケジュールの⽋陥 l 要求の増⼤ l ⼈員の離脱 l 仕様の崩壊 l ⽣産性の低迷 12
13. システム開発の主なリスク l スケジュールの⽋陥 l 要求の増⼤ l ⼈員の離脱 l 仕様の崩壊 l ⽣産性の低迷 13 → ほぼマネージャーの仕事
14. 14 メンバーができることはないの？
15. 15 あります
16. メンバーにできること 不安を共有する → プロジェクトがうまくいく → チームが育つ 16 こともある
17. 17 どういうこと？
18. システム開発の主なリスク l スケジュールの⽋陥 l 要求の増⼤ l ⼈員の離脱 l 仕様の崩壊 l ⽣産性の低迷 → 全てに備えるのは難しい → 顕在化しないリスクは優先度が低い 18
19. システム開発の主なリスク l スケジュールの⽋陥 l 要求の増⼤ l ⼈員の離脱 l 仕様の崩壊 l ⽣産性の低迷 → 全てに備えるのは難しい → 顕在化しそうなリスクを知りたい 19
20. 理想のマネージャー l プロジェクトの内部事情 → 把握している l プロジェクトの外部事情 → 把握している l 判断 → 適切である 20
21. 実際のマネージャー l プロジェクト内部事情 → 把握できていないことがある l プロジェクト外部事情 → 把握できていないことがある l 判断 → 適切ではないことがある 21
22. PMはスーパーマンじゃない 22 わからないことだってある → 顕在化リスクを⾒逃す 『MMR マガジンミステリー調査班』 ⽯垣ゆうき 13巻86ページ
23. PMがわからないときに l メンバーが不⾜知識を補うことができればよい 23
24. メンバーの⽅が詳しいこと l 専⾨性の⾼い知識 → プログラマなら特定の⾔語知識など l 作業の中で得られた知識 → 計画段階では⾒えなかった課題や解法 l 過去の経験から得た知⾒ → バックボーンの違い l リアルタイムの進捗状況 24
25. 25 想像してください
26. 26 あなたは開発チームのメンバーです
27. 27 「このロジックはデータ量が増えるとパフォーマンス 問題になりそうだけど⼤丈夫だろうか」 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは？」
28. 28 「このロジックはデータ量が増えるとパフォーマンス 問題になりそうだけど⼤丈夫だろうか」 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは？」 → プロジェクトへの不安を経験から察知
29. 不安は炎上リスクのサイン l 業務の中での些細な違和感・不安 → 顕在化が近い・部分的に顕在化している プロジェクトリスク 29
30. 不安は炎上リスクのサイン l 業務の中での些細な違和感・不安 → 顕在化が近い・部分的に顕在化している プロジェクトリスク l 顕在化が近いリスクを⾒つける⽅法 → メンバーの不安を共有する 30
31. 反論：この不安は杞憂ではないか？ l 「⼀般によくあるリスク」というのが存在する → 過去の問題は今回もリスクになる l ⼀般でないリスク → 組織内での課題は変わらない 経験からの不安は根拠としてよい 31
32. 反論：⾔わなくてもわかっているのでは？ l ⼆⼈が指摘すると確実性が⾼まる → 既知であることは⾔わない理由にならない 32
33. ここまでのまとめ l プロジェクトのリスクを管理したい l マネージャーの不⾜知識をメンバーがサポート l 不安を伝えることでリスクを検知できる 33
34. 34 不安を伝えるとよいのでどんどん伝えましょう
35. 35 不安を伝えるとよいのでどんどん伝えましょう でも実際は…
36. 36 「このロジックはデータ量が増えるとパフォーマンス 問題になりそうだけど⼤丈夫だろうか」 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは？」
37. 37 どうしたのか
38. 38 「このロジックはデータ量が増えるとパフォーマンス 問題になりそうだけど⼤丈夫だろうか」 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは？」 → 「そうなったら早めに対応すればいい」 → 「今から⼿戻りするのは許されないし」 → 「うまく⾏けばなんとかなるだろう」
39. 39 ⾔わなかった
40. なぜ伝えられなかったのか？ l 「⾯倒なことになる」 l 「仕事が増える」 l 「⾃分の責務ではない」 40
41. 不安を伝えるハードル 41
42. マイナス意⾒を表明するハードル l プロジェクトへの不安 < 対⼈リスクへの不安 → 伝えられない → ⼼理的安全性が保たれていない 42
43. ⼼理的安全性を妨げる4つの要素 l 無知だと思われる（チームメンバーや上司に） l 無能だと思われる l 邪魔をしていると思われる l ネガティブだと思われる 43 エイミー・C・エドモンドソン「チームが機能するとはどういうことか」英治出版
44. ⼼理的安全性を妨げる4つの要素 l 無知だと思われる不安 l 無能だと思われる不安 l 邪魔をしていると思われる不安 l ネガティブだと思われる不安 44 →「仕様の理解が曖昧になっている」 →「⾒積もりが間違っていたかも」 →「この機能優先度低いのでは」 →「他の⼈は⼤変そうだし⾃分がやらなきゃ」
45. 不安を伝えるハードル 45
46. ハードルを乗り越えてもらう① l 乗り越えるエネルギーを与える → 動機づけ 46
47. 不安共有による改善サイクル 47 プロジェクト メンバー チーム ①不安を共有 ②リスクに対応 ③不安が減る
48. ハードルを乗り越えてもらう② ハードルを下げる 48
49. ハードルを乗り越えてもらう② ハードルを下げる → ⾔いにくい → 意思に頼ると再現性がない 49 「今のプロジェクトについての不安が3点ありまして いえ、まだ問題になってはいないのですが」
50. ハードルを乗り越えてもらう② ハードルを下げる → 習慣化・ルーチンの形成 → 意思に頼らない 50
51. まとめ：不安を伝えるには l ⼼理的安全性を育む l 不安を共有しやすい仕組みを作る → これでOK 51
52. 52 ここまで理想論
53. こんなにうまくいくの？ l 不安を共有してもらえない →「⼼理的安全性は1⽇で⽣えてくるものではない」 l リスクへの対応が失敗する → 不安を共有しても成功体験に繋がらない → ⾔わないほうが良かった？ 53
54. 希望もある l 不安にチームで向き合う経験 → 不安の共有は批判されるものではない、という認知 → この積み重ねが⼼理的安全性を育てる l 失敗⾃体が学びになる → リスク対応の失敗経験を積む → チームの成⻑ 54
55. 不安共有による改善サイクル 55 プロジェクト メンバー チーム ①不安を共有 ②リスクに対応 ③不安が減る
56. 不安共有による改善サイクル 56 プロジェクト メンバー チーム ①不安を共有 ②不安を受容 ③⼼理的安全性 を⾼める
57. 弊社での事例 前提 l メンバー：30⼈程度(当時) l 5~10プロジェクト l 週次で全体MTG 57
58. 朝礼の場で週次のアンケートを⾏った 1. プロジェクトの不安を5段階評価 → 会議中にリアルタイムで⼊⼒ 2. 結果を確認 → 詳細を直接尋ねる 3. その場でアクションを設定 58
59. なぜそうしたのか アンケートを投げるだけだと l 記⼊率を⾼めるのが難しい l 結果からさらなるヒヤリングが必要 → その場で記⼊してもらう l 各プロジェクトに閉じている情報 → 全体で取りこぼしがないように確認する 59
60. 気をつけたこと l ⼈事⽬的ではないことを周知 → プロジェクト改善が⽬的 l 回答結果でメンバーを評価しない → ネガディブな内容も書けるように 60
61. 結果どうなった？ l 気が付かなかったリスクの発⾒ l スケジュールへの不安を発⾒し、調整 l 負担が⼤きいメンバーにフォロー l 不安の共有経験 l 同じ不安を別のメンバーも感じている 61
62. アンケートの問題点 l 全体の前では話しにくい → 関与する⼈数が増えると、対⼈リスクも増える l 「どうして不安に感じているの？」という質問が⼒ → 漠然とした不安のWhyを答えるのは難しい l 規模が⼤きくなると実施に時間がかかってしまう → スケールしない 62
63. 63 改善する
64. 全体の前では話しにくい → 全体の前で話すことをやめた 1. 回答結果を全体で確認せず、マネージャーが⼀次チェック 2. マネージャーは不明点をメンバーに確認 3. リスクを評価・状況をまとめる 64
65. 対⼈リスクへの不安軽減 → ⽬的を再度共有 l プロジェクトのリスクを知ることが⽬的 l 個⼈の批判や⼈事評価を⽬的としているわけではない → 問いかけの仕⽅ l なぜ？（理由）ではなく何があったのか？（事実）を聞く 65
66. 規模が⼤きくなると実施に時間がかかる → プロジェクトごとに実施する 回答率がさがるのでは？ → アンケート⽂化が定着していた 66
67. 67 これらを踏まえてシステム化した
68. プロジェクトごとにアンケートをとる メンバーは5段階評価・コメント → 開発中の些細な不安を共有 68
69. 回答を元にコミュニケーションを取る マネージャーは回答をもとにメンバーと会話 → リスクを把握する 69
70. レポートを作成する PMはリスクを評価 → ステークホルダーへ共有 70
71. プロジェクト間で不安を共有する 情報をオープンにする⾵⼟ 不安を共有するのは悪いことではない 71
72. やってみて l プロセスの導⼊は効果的 l まずやってみること l 組織に合わせていく必要がある l 導⼊して終わらない l 課題や要望 l 継続的な改善 72
73. まとめ l 炎上と不安 → 不安が炎上のサイン l 不安を伝えることで炎上を減らせる → メンバーが不安を伝える l 不安を伝えやすくするには l ⼼理的安全性を育てる l 話しやすい仕組みを取り⼊れる l 組織に合わせたフィードバック・継続的な改善 73
75. 75 PJ Insight でプロジェクトを継続的に改善 PJ Insight はプロジェクトが抱える潜在リスクをメンバーからのアンケートで 早期発見し、プロジェクトの本質を見抜き改善していくサービスです。 課題 不安 1on1 ⼯数調整 潜在リスクを可視化 リスクの解決行動 アンケートを送信 プロジェクトの改善 炎上防⽌ 品質 全体共有 コスト 納期
76. 76 PJ Insight で解決！ で解決！ 組織マネージャー プロジェクトマネジメントオフィス （PMO） 管理プロジェクトの状況を ⼀覧したい 適切なPMを アサインしたい 炎上前に事態を把握したい メンバーの本⾳を知りたい プロジェクトマネージャー（PM） 進捗管理だけでは不⼗分と 感じる ⼀⼈でプロジェクトを進め ることに不安 炎上リスクを 事前に察知したい メンバーの本⾳や不安を 知りたい プロジェクト進⾏中に出るこんなお悩みを・・・
77. 77 https://pj-insight.net/