Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロジェクト炎上を予防するためにメンバーひとりひとりができること
Search
Takegata
February 16, 2024
Business
0
1.5k
プロジェクト炎上を予防するためにメンバーひとりひとりができること
2024/02/16 Developers Summit 2024にて登壇したスライドです。
Takegata
February 16, 2024
Tweet
Share
More Decks by Takegata
See All by Takegata
プロダクト開発のトラブルを予防するために どうして「大丈夫です」と報告されるのに スケジュールは遅れるのか
ratmie
0
3
銀の弾丸?AWS App Runnerとは
ratmie
0
1
勤怠入力のためにブラウザを開きたくない!
ratmie
0
190
AWS re/Invent 2023 所感とサービス
ratmie
0
1
Other Decks in Business
See All in Business
Sasuke Financial Lab_会社説明資料
mayuko_nishida
1
5k
ネクストビートコーポレートガイド/corporate-guide
nextbeat
3
77k
Cobe Associe: Who we are? /コンサル・市場調査・人材紹介のCobe Associe
nozomi
6
18k
KRAF Impact Report 2024(English)
kraf
0
180
Go See!で見つけるプロダクト開発の突破口とその実践法
ta0o_o0821
0
140
HireRoo Culture Deck(日本語)
kkosukeee
2
26k
NEXERA inc. | Company Deck
nexera
0
7.7k
SHONAIグループ_コーポレートブック
shonai9107
0
2k
東京都教育委員会 情報共有掲示板
tokyo_metropolitan_gov_digital_hr
0
270
株式会社ispec 会社紹介資料
emikamihara
0
5.9k
知識を超えて実践するためのマインドの作り方
mayforblue
0
1.6k
成功をつなげる プロジェクトマネジメントの探求 / Exploring Project Management to Continuous Success
tunepolo
0
170
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
4 Signs Your Business is Dying
shpigford
181
21k
How GitHub (no longer) Works
holman
311
140k
Being A Developer After 40
akosma
87
590k
Six Lessons from altMBA
skipperchong
27
3.5k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Building Applications with DynamoDB
mza
91
6.1k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
28
900
Building Your Own Lightsaber
phodgson
103
6.1k
Unsuck your backbone
ammeep
669
57k
Transcript
プロジェクト炎上を予防するために メンバーひとりひとりができること Developers Summit 2024 NCDC株式会社 武⽅順平 2024/02/16
2 みなさん、炎上してますか?
3 炎上したことある?
4 炎上したい⽅はいますか?
5 炎上、したくないですよね
⾃⼰紹介:武⽅順平 l 所属:NCDC株式会社 l エンジニア:B2B・B2Cのウェブアプリ開発 l PdM: PJ Insightの⽴ち上げ l
登壇:ProductZine Day Winter 2024 l 炎上経験:⽕付け・⽕消し 6
本⽇伝えたいこと l 不安は炎上のサイン l 不安を伝えることで炎上を減らせる l 不安を伝えやすくするには l 弊社での事例 7
炎上と周辺概念 プロジェクトの l 失敗:期間・予算・品質が⽬標未達 l 炎上:上記の回避が困難な状況 l デスマーチ:上記の中での過剰労働 8
リスクと問題 l リスク:計画を阻害する起こりうる事柄 l 問題:計画を阻害するすでに発⽣した事柄 9 リスク 問題 顕在化 失敗
炎上
リスクと問題 l リスク:計画を阻害する起こりうる事柄 l 問題:計画を阻害するすでに発⽣した事柄 10 リスク 問題 顕在化 失敗
炎上 コントロールしたい
リスクマネジメントに必要なこと l 起こり得るリスクを洗い出す l リスクを評価する l リスクへの対応を考える 11
システム開発の主なリスク l スケジュールの⽋陥 l 要求の増⼤ l ⼈員の離脱 l 仕様の崩壊 l
⽣産性の低迷 12
システム開発の主なリスク l スケジュールの⽋陥 l 要求の増⼤ l ⼈員の離脱 l 仕様の崩壊 l
⽣産性の低迷 13 → ほぼマネージャーの仕事
14 メンバーができることはないの?
15 あります
メンバーにできること 不安を共有する → プロジェクトがうまくいく → チームが育つ 16 こともある
17 どういうこと?
システム開発の主なリスク l スケジュールの⽋陥 l 要求の増⼤ l ⼈員の離脱 l 仕様の崩壊 l
⽣産性の低迷 → 全てに備えるのは難しい → 顕在化しないリスクは優先度が低い 18
システム開発の主なリスク l スケジュールの⽋陥 l 要求の増⼤ l ⼈員の離脱 l 仕様の崩壊 l
⽣産性の低迷 → 全てに備えるのは難しい → 顕在化しそうなリスクを知りたい 19
理想のマネージャー l プロジェクトの内部事情 → 把握している l プロジェクトの外部事情 → 把握している l
判断 → 適切である 20
実際のマネージャー l プロジェクト内部事情 → 把握できていないことがある l プロジェクト外部事情 → 把握できていないことがある l
判断 → 適切ではないことがある 21
PMはスーパーマンじゃない 22 わからないことだってある → 顕在化リスクを⾒逃す 『MMR マガジンミステリー調査班』 ⽯垣ゆうき 13巻86ページ
PMがわからないときに l メンバーが不⾜知識を補うことができればよい 23
メンバーの⽅が詳しいこと l 専⾨性の⾼い知識 → プログラマなら特定の⾔語知識など l 作業の中で得られた知識 → 計画段階では⾒えなかった課題や解法 l
過去の経験から得た知⾒ → バックボーンの違い l リアルタイムの進捗状況 24
25 想像してください
26 あなたは開発チームのメンバーです
27 「このロジックはデータ量が増えるとパフォーマンス 問題になりそうだけど⼤丈夫だろうか」 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは?」
28 「このロジックはデータ量が増えるとパフォーマンス 問題になりそうだけど⼤丈夫だろうか」 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは?」 → プロジェクトへの不安を経験から察知
不安は炎上リスクのサイン l 業務の中での些細な違和感・不安 → 顕在化が近い・部分的に顕在化している プロジェクトリスク 29
不安は炎上リスクのサイン l 業務の中での些細な違和感・不安 → 顕在化が近い・部分的に顕在化している プロジェクトリスク l 顕在化が近いリスクを⾒つける⽅法 → メンバーの不安を共有する
30
反論:この不安は杞憂ではないか? l 「⼀般によくあるリスク」というのが存在する → 過去の問題は今回もリスクになる l ⼀般でないリスク → 組織内での課題は変わらない 経験からの不安は根拠としてよい
31
反論:⾔わなくてもわかっているのでは? l ⼆⼈が指摘すると確実性が⾼まる → 既知であることは⾔わない理由にならない 32
ここまでのまとめ l プロジェクトのリスクを管理したい l マネージャーの不⾜知識をメンバーがサポート l 不安を伝えることでリスクを検知できる 33
34 不安を伝えるとよいのでどんどん伝えましょう
35 不安を伝えるとよいのでどんどん伝えましょう でも実際は…
36 「このロジックはデータ量が増えるとパフォーマンス 問題になりそうだけど⼤丈夫だろうか」 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは?」
37 どうしたのか
38 「このロジックはデータ量が増えるとパフォーマンス 問題になりそうだけど⼤丈夫だろうか」 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは?」 → 「そうなったら早めに対応すればいい」 → 「今から⼿戻りするのは許されないし」 →
「うまく⾏けばなんとかなるだろう」
39 ⾔わなかった
なぜ伝えられなかったのか? l 「⾯倒なことになる」 l 「仕事が増える」 l 「⾃分の責務ではない」 40
不安を伝えるハードル 41
マイナス意⾒を表明するハードル l プロジェクトへの不安 < 対⼈リスクへの不安 → 伝えられない → ⼼理的安全性が保たれていない 42
⼼理的安全性を妨げる4つの要素 l 無知だと思われる(チームメンバーや上司に) l 無能だと思われる l 邪魔をしていると思われる l ネガティブだと思われる 43
エイミー・C・エドモンドソン「チームが機能するとはどういうことか」英治出版
⼼理的安全性を妨げる4つの要素 l 無知だと思われる不安 l 無能だと思われる不安 l 邪魔をしていると思われる不安 l ネガティブだと思われる不安 44
→「仕様の理解が曖昧になっている」 →「⾒積もりが間違っていたかも」 →「この機能優先度低いのでは」 →「他の⼈は⼤変そうだし⾃分がやらなきゃ」
不安を伝えるハードル 45
ハードルを乗り越えてもらう① l 乗り越えるエネルギーを与える → 動機づけ 46
不安共有による改善サイクル 47 プロジェクト メンバー チーム ①不安を共有 ②リスクに対応 ③不安が減る
ハードルを乗り越えてもらう② ハードルを下げる 48
ハードルを乗り越えてもらう② ハードルを下げる → ⾔いにくい → 意思に頼ると再現性がない 49 「今のプロジェクトについての不安が3点ありまして いえ、まだ問題になってはいないのですが」
ハードルを乗り越えてもらう② ハードルを下げる → 習慣化・ルーチンの形成 → 意思に頼らない 50
まとめ:不安を伝えるには l ⼼理的安全性を育む l 不安を共有しやすい仕組みを作る → これでOK 51
52 ここまで理想論
こんなにうまくいくの? l 不安を共有してもらえない →「⼼理的安全性は1⽇で⽣えてくるものではない」 l リスクへの対応が失敗する → 不安を共有しても成功体験に繋がらない → ⾔わないほうが良かった?
53
希望もある l 不安にチームで向き合う経験 → 不安の共有は批判されるものではない、という認知 → この積み重ねが⼼理的安全性を育てる l 失敗⾃体が学びになる →
リスク対応の失敗経験を積む → チームの成⻑ 54
不安共有による改善サイクル 55 プロジェクト メンバー チーム ①不安を共有 ②リスクに対応 ③不安が減る
不安共有による改善サイクル 56 プロジェクト メンバー チーム ①不安を共有 ②不安を受容 ③⼼理的安全性 を⾼める
弊社での事例 前提 l メンバー:30⼈程度(当時) l 5~10プロジェクト l 週次で全体MTG 57
朝礼の場で週次のアンケートを⾏った 1. プロジェクトの不安を5段階評価 → 会議中にリアルタイムで⼊⼒ 2. 結果を確認 → 詳細を直接尋ねる 3.
その場でアクションを設定 58
なぜそうしたのか アンケートを投げるだけだと l 記⼊率を⾼めるのが難しい l 結果からさらなるヒヤリングが必要 → その場で記⼊してもらう l 各プロジェクトに閉じている情報
→ 全体で取りこぼしがないように確認する 59
気をつけたこと l ⼈事⽬的ではないことを周知 → プロジェクト改善が⽬的 l 回答結果でメンバーを評価しない → ネガディブな内容も書けるように 60
結果どうなった? l 気が付かなかったリスクの発⾒ l スケジュールへの不安を発⾒し、調整 l 負担が⼤きいメンバーにフォロー l 不安の共有経験 l
同じ不安を別のメンバーも感じている 61
アンケートの問題点 l 全体の前では話しにくい → 関与する⼈数が増えると、対⼈リスクも増える l 「どうして不安に感じているの?」という質問が⼒ → 漠然とした不安のWhyを答えるのは難しい l
規模が⼤きくなると実施に時間がかかってしまう → スケールしない 62
63 改善する
全体の前では話しにくい → 全体の前で話すことをやめた 1. 回答結果を全体で確認せず、マネージャーが⼀次チェック 2. マネージャーは不明点をメンバーに確認 3. リスクを評価・状況をまとめる 64
対⼈リスクへの不安軽減 → ⽬的を再度共有 l プロジェクトのリスクを知ることが⽬的 l 個⼈の批判や⼈事評価を⽬的としているわけではない → 問いかけの仕⽅ l
なぜ?(理由)ではなく何があったのか?(事実)を聞く 65
規模が⼤きくなると実施に時間がかかる → プロジェクトごとに実施する 回答率がさがるのでは? → アンケート⽂化が定着していた 66
67 これらを踏まえてシステム化した
プロジェクトごとにアンケートをとる メンバーは5段階評価・コメント → 開発中の些細な不安を共有 68
回答を元にコミュニケーションを取る マネージャーは回答をもとにメンバーと会話 → リスクを把握する 69
レポートを作成する PMはリスクを評価 → ステークホルダーへ共有 70
プロジェクト間で不安を共有する 情報をオープンにする⾵⼟ 不安を共有するのは悪いことではない 71
やってみて l プロセスの導⼊は効果的 l まずやってみること l 組織に合わせていく必要がある l 導⼊して終わらない l
課題や要望 l 継続的な改善 72
まとめ l 炎上と不安 → 不安が炎上のサイン l 不安を伝えることで炎上を減らせる → メンバーが不安を伝える l
不安を伝えやすくするには l ⼼理的安全性を育てる l 話しやすい仕組みを取り⼊れる l 組織に合わせたフィードバック・継続的な改善 73
74
75 PJ Insight でプロジェクトを継続的に改善 PJ Insight はプロジェクトが抱える潜在リスクをメンバーからのアンケートで 早期発見し、プロジェクトの本質を見抜き改善していくサービスです。 課題 不安
1on1 ⼯数調整 潜在リスクを可視化 リスクの解決行動 アンケートを送信 プロジェクトの改善 炎上防⽌ 品質 全体共有 コスト 納期
76 PJ Insight で解決! で解決! 組織マネージャー プロジェクトマネジメントオフィス (PMO) 管理プロジェクトの状況を ⼀覧したい
適切なPMを アサインしたい 炎上前に事態を把握したい メンバーの本⾳を知りたい プロジェクトマネージャー(PM) 進捗管理だけでは不⼗分と 感じる ⼀⼈でプロジェクトを進め ることに不安 炎上リスクを 事前に察知したい メンバーの本⾳や不安を 知りたい プロジェクト進⾏中に出るこんなお悩みを・・・
77 https://pj-insight.net/
None