---
title: poc_hokensou
tags:  #poc  
author: [Yukiko](https://image.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/DEY49P46JM.jpg?width=480
description: poc_hokensou by Yukiko
published: June 21, 26
canonical: https://image.docswell.com/s/yukiko_it/ZMQ6JN-2026-06-21-223128
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/DEY49P46JM.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/VJNYL56178.jpg)

PoCの3状態：「成功・失敗・不明」の正しい定義
PoCの失敗は「プロジェクトの失敗」ではない。３状態すべてが「判断材料」として価値を持つ。
成功
失敗
不明
検証仮説が実証された状態
仮説が否定された、または目標未達
結論を出すにはデータが不十分
判断基準
判断基準
判断基準
成功基準（事前合意）を達成
成功基準を明確に下回った
検証期間・データ量が不足
本開発への移行判断ができる
技術的・コスト的に実現不可と判明
外部依存により検証不能
再現性・スケーラビリティが見えた
前提条件が崩れた
仮説が途中で変化した
過信による本開発スコープ膨張
「失敗を隠す」ことで二次被害拡大
「不明」を放置し判断が宙に浮く
→ 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.


# Page. 3

![Page Image](https://bcdn.docswell.com/page/YE9P4YLYJ3.jpg)

成功報告の報・連・相
報告の型（成功版）
① 結果サマリ
「成功基準〇〇を達成。応答速度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後のスコープ・体制を一緒に検討に誘う


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GE8DQ6XKED.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/LELMX98P7R.jpg)

不明報告の報・連・相 〈最難関〉
不明を長引かせない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.


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4JMYLZ62JW.jpg)

まとめ
成功
失敗
不明
数値で先に結論を出す
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