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
NCDC
April 18, 2024
Business
1
240
プロジェクト炎上を予防するために メンバーひとりひとりができること
NCDC
April 18, 2024
Tweet
Share
More Decks by NCDC
See All by NCDC
DX実現への鍵。デジタル技術で拓く新規事業の可能性
ncdc
0
29
利用者が離れないUX/UIデザイン 長く使われる業務アプリデザインのポイント
ncdc
3
130
デザインシステム構築の進め方 基本から実践まで、具体的な手順を徹底解説
ncdc
1
190
すぐに始めるAWSコスト削減。短期でできる改善策と長期的な運用負荷軽減への取り組み方を解説
ncdc
1
760
なぜ多くの企業がクラウドの導入・活用推進に苦戦するのか? 注意点と対策を解説。
ncdc
1
230
ノンデザイナーでもできる。直感的で使いやすいUIの設計方法
ncdc
9
7.9k
クラウド活用で生成AIを業務に取り入れる方法
ncdc
5
1.4k
新規サービスのアイデア創出・具体化方法
ncdc
1
590
業務システムのUX/UI設計ノウハウを解説。デザイナー不在で失敗しないために身につけるべき基本とは?
ncdc
3
1.4k
Other Decks in Business
See All in Business
エンジニアの「センス」とは何か / What is the sense of engineers
hiro_y
19
8.3k
エムスリーキャリア エンジニア採用資料 / M3C Engineer Guide
m3c
1
85k
受託開発のアジャイル奮闘記
mifujita
0
170
Sales Marker Culture Book(English)
salesmarker
PRO
1
2.6k
merpay-overview_en
mercari_inc
1
17k
M&A Cloud Advisory Partners 採用ピッチブック
macloud
1
13k
IT 未経験者をVue.js で開発できる IT コンサルタントに育てあげる秘訣/ Future's New Employee Training
yut0naga1_fa
0
220
Theoria technologies:About Us
theoriatec2024
1
1.6k
SmartBank - Recruiting Deck
smartbank
10
190k
【DearOne】Dear Newest Member
hrm
2
5.9k
エンジニア向け会社紹介資料/株式会社PLAY
play_inc
0
5.2k
サスメド株式会社 Culture Deck
susmed
0
36k
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Visualization
eitanlees
145
15k
Bash Introduction
62gerente
608
210k
Building Your Own Lightsaber
phodgson
102
6.1k
A designer walks into a library…
pauljervisheath
202
24k
Happy Clients
brianwarren
97
6.7k
Typedesign – Prime Four
hannesfritz
40
2.4k
Automating Front-end Workflow
addyosmani
1366
200k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
32
1.8k
Adopting Sorbet at Scale
ufuk
73
9.1k
Transcript
プロジェクト炎上を予防するために メンバーひとりひとりができること NCDC Online Seminar NCDC株式会社 武⽅順平 2024/04/18
NCDCのご紹介
NCDCのサービス体系 Business 事業領域の推進 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • コンサルティング
• 新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI / AR • クラウドインテグレーション
はじめに
5 みなさん、炎上したことはありますか?
6 炎上、したくないですよね
⾃⼰紹介:武⽅順平 l 所属:NCDC株式会社 l エンジニア:BtoB・BtoCのウェブアプリ開発 l PdM: PJ Insightの⽴ち上げ l
炎上経験:複数 7
本⽇伝えたいこと l 不安は炎上のサイン l 不安を伝えることで炎上を減らせる l 不安を伝えやすくするには l 弊社での事例 8
炎上と周辺概念の定義 プロジェクトの l 失敗:期間・予算・品質が⽬標未達 l 炎上:上記の回避が困難な状況 l デスマーチ:上記の中での過剰労働 9
リスクと問題 l リスク:計画を阻害する起こりうる事柄 l 問題:計画を阻害するすでに発⽣した事柄 10 リスク 問題 顕在化 失敗
炎上
リスクと問題 l リスク:計画を阻害する起こりうる事柄 l 問題:計画を阻害するすでに発⽣した事柄 11 リスク 問題 顕在化 失敗
炎上 コントロールしたい
リスクマネジメントに必要なこと l 起こり得るリスクを洗い出す l リスクを評価する l リスクへの対応を考える 12
システム開発の主なリスク l スケジュールの⽋陥 l ⾒積もりの失敗を含む l 要求の増⼤ l 開発中に要求が増える。市場が変化する l
⼈員の離脱 l 仕様の崩壊 l ⽣産性の低迷 13
システム開発の主なリスク l スケジュールの⽋陥 l 要求の増⼤ l ⼈員の離脱 l 仕様の崩壊 l
⽣産性の低迷 14 → ほぼマネージャーの仕事
15 メンバーができることはないの?
16 あります
メンバーにできること 不安を共有する → プロジェクトがうまくいく → チームが育つ 17 こともある
18 どういうこと?
システム開発の主なリスク l スケジュールの⽋陥 l 要求の増⼤ l ⼈員の離脱 l 仕様の崩壊 l
⽣産性の低迷 → 全てに備えるのは難しい →リスクに優先度が必要 19
20 どのリスクの優先度が⾼いのか?
リスクと問題 l リスク:計画を阻害する起こりうる事柄 l 問題:計画を阻害するすでに発⽣した事柄 21 リスク 問題 顕在化 失敗
炎上 コントロールしたい
リスクの優先度 顕在化するリスクは対応が必要となる → 優先度が⾼い 顕在化しそうなリスクを知りたい 22
理想のマネージャー l プロジェクトの内部事情(進捗・課題) → 把握している l プロジェクトの外部事情(市場・ステークホルダー) → 把握している l
リスクの判断 → 適切である 23
実際のマネージャー l プロジェクト内部事情 → 把握できていないことがある l プロジェクト外部事情 → 把握できていないことがある l
リスクの判断 → 適切ではないことがある 24
メンバーの⽅が詳しいこと l 専⾨性の⾼い知識 → プログラマなら特定の⾔語知識など l 作業の中で得られた知識 → 計画段階では⾒えなかった課題や解法 l
過去の経験から得た知⾒ → バックボーンの違い l リアルタイムの進捗状況 →報告を挟まない 25
26 想像してください
27 あなたは開発チームのメンバーです
28 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは?」 「このロジックだと本⼈に成り代われるのでは?」
29 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは?」 「このロジックだと本⼈に成り代われるのでは?」 → 業務の中での些細な違和感・不安
不安は炎上リスクのサイン l 業務の中での些細な違和感・不安 → 顕在化が近い・部分的に顕在化している プロジェクトリスク 30
不安は炎上リスクのサイン l 業務の中での些細な違和感・不安 → 顕在化が近い・部分的に顕在化している プロジェクトリスク l 顕在化が近いリスクを⾒つける⽅法 → メンバーの不安を共有する
31
反論①:杞憂では? l 「⼀般によくあるリスク」というのが存在する → 過去の問題は今回もリスクになる l ⼀般でないリスク → 組織内での課題は変わらない 経験からの不安は根拠としてよい
32
反論②:⾔わなくてもわかっているのでは? l 複数⼈が指摘すると確実性が⾼まる → 既知であることは⾔わない理由にならない 33
ここまでのまとめ l プロジェクトのリスクを管理したい l マネージャーの不⾜知識をメンバーがサポート l 不安を伝えることでリスクを検知できる 34
35 不安を伝えるとよいのでどんどん伝えましょう
36 不安を伝えるとよいのでどんどん伝えましょう でも実際は…
37 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは?」 「このロジックだと本⼈に成り代われるのでは? 」
38 どうしたのか
39 「ユーザー解約時の仕様が曖昧になっている」 「テスト⼯数が⾜りていないのでは?」 「このロジックだと本⼈に成り代われるのでは? 」 → 「まさか24億円送ることはないだろう⚾」 → 「今から⼿戻りするのは許されないし」 →
「うまく⾏けばなんとかなるだろう」
40 ⾔わなかった
なぜ不安を伝えられなかったのか? 不安を伝えることで想定されるデメリット l 「⾯倒なことになる」 l 「仕事が増える」 l 「⾃分の責務ではない」 41
不安を伝えるハードル 42
マイナス意⾒を表明するハードル l プロジェクトへの不安 < 対⼈リスクへの不安 → 伝えられない → ⼼理的安全性が保たれていない 43
⼼理的安全性を妨げる4つの要素 l 無知だと思われる(チームメンバーや上司に) l 無能だと思われる l 邪魔をしていると思われる l ネガティブだと思われる 44
エイミー・C・エドモンドソン「チームが機能するとはどういうことか」英治出版
⼼理的安全性を妨げる4つの要素 l 無知だと思われる不安 l 無能だと思われる不安 l 邪魔をしていると思われる不安 l ネガティブだと思われる不安 45
→「仕様の理解が曖昧になっている」 →「⾒積もりが間違っていたかも」 →「ヘルプもらいたいけど他の⼈も忙しそう」 →「この機能の優先度は低いのでは?」
不安を伝えるハードル 46
ハードルを乗り越えてもらう① l 乗り越えるエネルギーを与える → 動機づけ 47
不安共有による改善サイクル 48 プロジェクト メンバー チーム ①不安を共有 ②リスクに対応 ③不安が減る
l 乗り越えるエネルギーを与える → 動機づけ → 不安を伝えたあとの⽅がストレスレベルが下がる認識 ハードルを乗り越えてもらう① 49
ハードルを乗り越えてもらう② ハードルを下げる 50
ハードルを乗り越えてもらう② ハードルを下げる → ⾔いにくい → ⾔いやすい仕組みを作ろう 51 「今のプロジェクトについての不安が3点ありまして いえ、まだ問題になってはいないのですが」
ハードルを乗り越えてもらう② ハードルを下げる → 意志の⼒に依存しない → 習慣化・ルーチンの形成 52
ハードルを乗り越えてもらう② ハードルを下げる → 習慣化・ルーチンの形成 🙅 むずかしいけど、がんばってね 🙆 ⾔いやすい仕組み作り 53
まとめ:不安を伝えるには l ⼼理的安全性を育む l 不安を共有しやすい仕組みを作る → これでOK 54
55 ここまで理想論
こんなにうまくいくの? l 不安を共有してもらえない →「⼼理的安全性は1⽇で⽣えてくるものではない」 l リスクへの対応が失敗する 56
不安共有による改善サイクル 57 プロジェクト メンバー チーム ①不安を共有 ②リスクに対応 ③不安が解消 されない ❌
こんなにうまくいくの? l 不安を共有してもらえない →「⼼理的安全性は1⽇で⽣えてくるものではない」 l リスクへの対応が失敗する → 不安を共有しても成功体験に繋がらない → ⾔わないほうが良かった?
58
希望もある l 不安にチームで向き合う経験 → 不安の共有は批判されるものではない、という認知 → この積み重ねが⼼理的安全性を育てる 59
不安共有による改善サイクル 60 プロジェクト メンバー チーム ①不安を共有 ②リスクに対応 ③ 不安が解消 されない
❌
不安共有による改善サイクル 61 プロジェクト メンバー チーム ① 不安を共有 ②リスクに対応 ③ 不安が解消
されない ②ʼ 不安を受容 ③ʼ ⼼理的安全 性を⾼める ❌
希望もある l 失敗⾃体が学びになる → リスク対応の失敗経験を積む → チームの成⻑ 62
弊社での事例 63
弊社での事例 前提 l メンバー:30⼈程度(当時) l 5~10プロジェクト l 週次で全体MTG 64
朝礼の場で週次のアンケートを⾏った 1. プロジェクトの不安を5段階評価 → 会議中にリアルタイムで⼊⼒ 2. 結果を確認 → 詳細を直接尋ねる 3.
その場でアクションを設定 65
なぜそうしたのか アンケートを投げるだけだと l 記⼊率を⾼めるのが難しい l 結果からさらなるヒヤリングが必要 → その場で記⼊してもらう l 各プロジェクトに閉じている情報
→ 全体で取りこぼしがないように確認する 66
気をつけたこと l ⼈事⽬的ではないことを周知 → プロジェクト改善が⽬的 l 回答結果でメンバーを評価しない → ネガティブな内容も書けるように 67
結果どうなった? l 気が付かなかったリスクの発⾒ l スケジュールへの不安を発⾒し、調整 l 負担が⼤きいメンバーをフォロー l 不安の共有経験 l
同じ不安を別のメンバーも感じている 68
アンケートの課題 l 全体の前では話しにくい → 関与する⼈数が増えると、対⼈リスクも増える l 「どうして不安に感じているの?」という質問が圧⼒ l Whyをその場で回答するのは難しい l
漠然とした不安のこともある l 規模が⼤きくなると実施に時間がかかってしまう → 仕組みの問題 69
70 反省を活かして改善する
全体の前では話しにくい → 全体の前で話すことをやめた 1. 回答結果を全体で確認せず、マネージャーが⼀次チェック 2. マネージャーは不明点をメンバーに確認しつつ、状況をま とめる 71
対⼈リスクへの不安軽減 → ⽬的を再度共有 l プロジェクトのリスクを知ることが⽬的 l 個⼈の批判や⼈事評価を⽬的としているわけではない → 問いかけの仕⽅ l
なぜ?(理由)ではなく l 何が起きているのか?(事実)を聞く 72
規模が⼤きくなると実施に時間がかかる → プロジェクトごとの実施 73
74 これらを踏まえてシステム化した
プロジェクトごとにアンケートをとる メンバーは5段階評価・コメント → 開発中の些細な不安を共有 75
回答を元にコミュニケーションを取る マネージャーは回答をもとにメンバーと会話 → リスクを把握する 76
レポートを作成する PMは状況を報告する → ステークホルダーへ共有 77
複数プロジェクトを⼀覧 情報をオープンにする → ⾵⼟の醸成 78
まとめ l 炎上と不安 → 不安が炎上のサイン l 不安を伝えることで炎上を減らせる → メンバーが不安を伝える l
不安を伝えやすくするには l ⼼理的安全性を育てる l 話しやすい仕組みを取り⼊れる l 継続的な改善が必要 79
80
81 PJ Insight でプロジェクトを継続的に改善 PJ Insight はプロジェクトが抱える潜在リスクをメンバーからのアンケートで 早期発見し、プロジェクトの本質を見抜き改善していくサービスです。 課題 不安
1on1 ⼯数調整 潜在リスクを可視化 リスクの解決行動 アンケートを送信 プロジェクトの改善 炎上防⽌ 品質 全体共有 コスト 納期
82 PJ Insight で解決! で解決! 組織部⾨⻑・PMO 管理プロジェクトの状況を ⼀覧したい 適切なPMを アサインしたい
炎上前に事態を把握したい メンバーの本⾳を知りたい プロジェクトマネージャー(PM) 進捗管理だけでは不⼗分と 感じる ⼀⼈でプロジェクトを進め ることに不安 炎上リスクを 事前に察知したい メンバーの本⾳や不安を 知りたい プロジェクト進⾏中に出るこんなお悩みを・・・
None