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