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.4k
プロジェクト炎上を予防するためにメンバーひとりひとりができること
2024/02/16 Developers Summit 2024にて登壇したスライドです。
Takegata
February 16, 2024
Tweet
Share
More Decks by Takegata
See All by Takegata
勤怠入力のためにブラウザを開きたくない!
ratmie
0
190
Other Decks in Business
See All in Business
NOT A HOTEL SOFTWARE DECK
notahotel
6
63k
Nstock 採用資料 / We are hiring
nstock
24
220k
コーポレートストーリー(新規投資家様向け会社説明資料)
gatechnologies
1
8.4k
しるし株式会社_コーポレートデック
shirushi
0
540
株式会社gecogeco 会社紹介資料
gecogeco
1
2.1k
Карта гипотез для ментора
alexanderbyndyu
0
510
レイド株式会社_会社紹介資料
rayd
0
220
Findy - 人生で熱くなれるなにかを探している誰かへ / Letter from Findy
findyinc
7
140k
スクラムに必要な知的生産性を上げるソフトスキル / The Soft Skills Required to Enhance Productivity in Scrum
shinichi9987
4
2.7k
株式会社ユビレジ_採用ピッチ資料 / Ubiregi_CompanyProfile
ubiregi_saiyo
0
5.8k
会社案内
aobabbt
0
580
20240914_CMCKochi_6
hideki_ojima
1
380
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
44
2k
Fashionably flexible responsive web design (full day workshop)
malarkey
403
65k
No one is an island. Learnings from fostering a developers community.
thoeni
19
2.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
663
120k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
105
48k
From Idea to $5000 a Month in 5 Months
shpigford
380
46k
How to name files
jennybc
77
98k
Robots, Beer and Maslow
schacon
PRO
157
8.2k
Designing for Performance
lara
604
68k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Infographics Made Easy
chrislema
239
18k
A Modern Web Designer's Workflow
chriscoyier
692
190k
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