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

Transcript

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