poc_hokensou

-- Views

June 21, 26

スライド概要

profile-image

はじめまして、yukikoと申します。 IT教育支援や、DX推進が可能です。 ◆ スキル LPIC レベル2 AI / Python Splunk BI(データ可視化・分析) ◆ その他 新卒・未経験の学生向けに、エンジニア転職を応援する資料を趣味で作成しています。 もしよろしければご活用ください。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

各ページのテキスト
1.

PART 3 PoC 実務の報・連・相 成功・失敗・不明 編 どの結果でも「信頼を守る」伝え方と進め方 成功 報告 失敗 連絡 相談 うさうさ先生 / SESエンジニア × 教育心理 | PoC完全ガイド 不明

2.

PoCの3状態:「成功・失敗・不明」の正しい定義 PoCの失敗は「プロジェクトの失敗」ではない。3状態すべてが「判断材料」として価値を持つ。 成功 失敗 不明 検証仮説が実証された状態 仮説が否定された、または目標未達 結論を出すにはデータが不十分 判断基準 判断基準 判断基準 成功基準(事前合意)を達成 成功基準を明確に下回った 検証期間・データ量が不足 本開発への移行判断ができる 技術的・コスト的に実現不可と判明 外部依存により検証不能 再現性・スケーラビリティが見えた 前提条件が崩れた 仮説が途中で変化した 過信による本開発スコープ膨張 「失敗を隠す」ことで二次被害拡大 「不明」を放置し判断が宙に浮く → Go判断→本開発スコープ・予算を合意 → NoGo判断→代替案または方針転換を提案 → 継続/中止判断→追加検証計画を提示 参照: Ries, E. (2011). The Lean Startup. | Blank & Dorf (2012). The Startup Owner's Manual. | Christensen, C. (1997). The Inn ovator's Dilemma. HBS Press.

3.

成功報告の報・連・相 報告の型(成功版) ① 結果サマリ 「成功基準〇〇を達成。応答速度500ms→180msを確認」 → 数値で先に結論を示す ② 根拠データ 「計測ログ・スクリーンショットを別添。n=100回の平均値」 → 再現性・信頼性を担保 Go 判断を引き出す 成功時こそ気をつけること 「完璧」は禁句。未検証事項を必ず添える 本開発スコープの膨張を合意なく進めない PoC成功≠本開発成功。条件の違いを明示 ③ 本開発への示唆 「構成をそのままスケールすれば〇万req/日に対応可能」 → 次の意思決定に繋げる ④ 未解決リスク 「負荷テストは未実施。本開発フェーズで要検証」 → 過信を防ぎ信頼を守る ⑤ 要求事項 「Go判断をいただければ来週킥 キックオフを設定可能」 → 明確なCTA で止まらせない 参照: Kotter, J.P. (1996). Leading Change. HBS Press. | Maister et al. (2000). The Trusted Advisor. 報連相タイミング(成功) 報告 成功確認後24h以内に書面報告 連絡 週次デモで事前に「手応え」を共有しておく 相談 Go後のスコープ・体制を一緒に検討に誘う

4.

失敗報告の報・連・相 報告の型(失敗版) 信頼を守るNoGo NG表現 → OK表現 ① 結果を先に ✕ 「失敗しました…すみません」 「成功基準〇〇を達成できませんでした」 → 曖昧にせず冒頭で明示。印象操作はNG → 「〇〇の結果、成功基準未達を確認しました」 ② 原因の構造化 ✕ 「もう少し時間をください」 「技術的要因/前提条件崩れ/工数不足」を分類 → 感情論でなくファクトで語る → 「追加〇週間で△△を確認し判断します」 ③ 学習の成果 ✕ 「難しい状況です」 「〇〇は不可。代わりに△△なら可能と判明」 → PoC失敗は情報を得た成功でもある → 「現時点では実現困難。代替案は〇〇です」 ④ 代替案の提示 「アプローチAで再PoC」「要件を緩めて再挑戦」 → 空白で終わらせない ⑤ 次の意思決定依頼 報連相タイミング(失敗) 報告 判明後12h以内。黙って持つのが最大リスク 連絡 週次で「手応えなし」の予兆を先出しする 相談 「代替案のどれが現実的か」を一緒に考える 「撤退か転換かを〇〇までにご判断ください」 → 判断者に適切なボールを返す 参照: Edmondson, A. (1999). Psychological Safety. ASQ. | Argyris, C. (1990). Overcoming Organizational Defenses. Allyn & Bacon.

5.

不明報告の報・連・相 〈最難関〉 不明を長引かせない3ルール 報告の型(不明版) ① 確認済みを先出し 「〇〇は確認完了。△△は現時点で未確認」 → 何が分かっていて何が分からないかを分離 ② 不明の原因を分類 継続判断を引き出す 1 「確認中」は最大1週間が限度。超えたら相談に切り替え る 2 週次で「不明の解消状況」を進捗として共有する 3 「どうやれば分かるか」を示せない状態を続けない 「データ不足 / 外部依存 / 前提条件変化」 → 「なぜ不明か」を説明できることが重要 ③ 確認計画を提示 「あと〇日・〇の手順で結論が出せます」 → 空白で終わらず次のアクションを示す ④ リスクシナリオ 「A案なら継続、B案なら中止を推奨」 → 不確実でも選択肢を構造化して渡す 報連相タイミング(不明) 報告 不明と判断した瞬間に報告。隠さない 連絡 週次で「不明解消への進捗」を報告し続ける 相談 判断に必要な情報・期限をクライアントと決める ⑤ 判断期限の確認 「〇〇までに継続/中止のご判断をお願いします」 → 「不明のまま漂流」が最悪。期限を作る 参照: Snowden & Boone (2007). A Leader's Framework for Decision Making. HBR. | Knight, F.H. (1921). Risk, Uncertainty and Profit.

6.

まとめ 成功 失敗 不明 数値で先に結論を出す 12h以内に第一報を出す 判明した瞬間に報告する 未解決リスクを必ず添える 原因を構造化して説明する 「なぜ不明か」を説明できる Go後スコープを合意前に動かさな い 代替案とCTAをセットで渡す 継続/中止の期限を自ら作る 黄金律:どの結果でも「事実 → 原因 → 代替案 → CTA」の型で伝えれば信頼は守られる 参照:Ries(2011) Lean Startup / Blank&Dorf(2012) Startup Owner's Manual / Kotter(1996) Leading Change / Maister(2000) Trusted Advisor / Edmondson(1999) Psychological Safety / Argyris(1990) Overcoming Defenses / Snowden&Boone(2007) HBR / Knight(1921) Risk&Uncertainty