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
0
64
プロジェクト炎上を予防するために メンバーひとりひとりができること
NCDC
April 18, 2024
Tweet
Share
More Decks by NCDC
See All by NCDC
新規サービスのアイデア創出・具体化方法
ncdc
0
150
業務システムのUX/UI設計ノウハウを解説。デザイナー不在で失敗しないために身につけるべき基本とは?
ncdc
2
370
クラウドネイティブ時代のシステム運用・監視とは? 自動化・効率化のベストプラクティスを紹介
ncdc
0
190
アジャイル開発の落とし穴とは? よくある失敗を回避し成功へ導くポイントを解説
ncdc
0
300
UX/UI改善に貢献するユーザーテストとは? 基礎知識から実施のプロセスまで解説
ncdc
0
350
内製化の成功への道 〜アジャイル開発・DevOpsと人材育成の両立〜
ncdc
0
260
NCDC_NoCode_seminar
ncdc
0
270
NCDC_UXSession_20230830
ncdc
0
370
事例に学ぶ内製化、DevOps戦略 〜DXパートナーとの連携がプロセス変革や人材育成の鍵〜
ncdc
0
470
Other Decks in Business
See All in Business
KAKEHASHI会社説明資料/Company information materials
kakehashi
0
2.7k
enechain company deck
enechain
PRO
3
70k
Pictoria 会社紹介・採用資料
pictoria
3
840
akippa株式会社 - 会社紹介資料
akippa
3
45k
しくじり先生 〜ふりかえり手法はチームのイマとコネクトして〜
electricsatie
0
450
株式会社gecogeco 会社紹介資料
gecogeco
1
1.6k
新卒向けふりかえり研修
viva_tweet_x
10
2.5k
TECH HIRE |「大胆なポジションの開発」によって ハイクラス人材を直接応募で4名採用できた話
trackrecords
PRO
0
430
解説カンバン方式
pokotyamu
1
140
AHV環境で利用できるネットワーク/セキュリティ
kuze_k
0
160
We are Wunderbar, Culture Deck Min
wunderbar
0
18k
2023年度ICT職専門研修(海外派遣研修)報告書_No.1_サービス開発におけるデザイン思考からのアプローチ
tokyo_metropolitan_gov_digital_hr
0
130
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
0
73
A Philosophy of Restraint
colly
197
16k
GraphQLとの向き合い方2022年版
quramy
33
12k
Designing on Purpose - Digital PM Summit 2013
jponch
111
6.5k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
How STYLIGHT went responsive
nonsquared
92
4.8k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
Designing Experiences People Love
moore
136
23k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
188
16k
Typedesign – Prime Four
hannesfritz
36
2.1k
The Pragmatic Product Professional
lauravandoore
26
5.9k
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