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