poc_guide_usausa

一流エンジニアの PoC 完全ガイド クライアントワークの振る舞い・タスク受けの要点 Proof of Concept | 概念実証 振る舞い うさうさ先生 ／ SESエンジニア×教育心理 タスク管理 クライアント対応

PoCとは何か ／ よくある落とし穴 PoC の目的 よくある落とし穴 本開発化バイアス 「せっかく作ったから」で本番採用 • 技術的実現可能性の検証（Feasibility） • リスクを最小コストで早期発見 • ステークホルダーへの可視化・説得 • • 本開発のスコープ・見積もり根拠づくり 「作らない意思決定」も立派なPoC成果 スコープ膨張 PoCがいつの間にかMVPに 成功基準未定義 何をもって「成功」か曖昧なまま開始 期間・予算の無限延長 ゴールが動き続けるPoC地獄 参照: Blank & Dorf (2012). The Startup Owner's Manual. K&S Ranch. | IEEE Std 1028-2008

クライアントワークの振る舞い 信頼は技術力ではなく「予測可能性」で作られる 透明性を先に出す 不確実なことは「不確実です」と言う 。 PoC段階の限界を最初に合意する。 クライアントを巻き込む デモは週次で見せる。 「見てもらう」ではなく「一緒に作る 」。 期待値を先に設定 「2週間でお出しします」より 「2週間で判断軸をご提示」と言う。 議事録・決定ログ 口頭決定は即テキスト化。 「言った言わない」をゼロにする。 参照: Maister, Green & Galford (2000). The Trusted Advisor. Free Press. | PMI PMBOK® Guide 7th Ed. 悪いニュースを早く 詰まったら24時間以内に報告。 黙って抱えるのが最大のリスク。 成果物より意思決定支援 PoCの納品物は「コード」ではなく 「判断できるデータ」。

タスクを受ける前のチェックリスト ✓ 目的・ゴールは明確か？ ✓ PoC初日に最大リスクを攻める 「何を判断するためのPoC」を言語化 ✓ 成功基準を定義したか？ ✓ 定量／定性どちらでも事前合意が必須 ✓ 期間・予算の上限は？ スコープ外を明示したか？ クライアント窓口は一本化？ 意思決定者と確認者を明確に ✓ PoC単体の工数と本開発は別計上 ✓ 技術的リスクを洗い出したか？ 中間報告ポイントは合意済か？ 週次デモ or マイルストーン設定 ✓ 「やらないこと」リストを先に作る 参照: Ries, E. (2011). The Lean Startup. Crown Business. | Gothelf & Seiden (2013). Lean UX. O'Reilly. PoC後の意思決定フローは？ 「Go/NoGoの基準と判断者」を確認

まとめ 01 PoCは「作ること」でなく「判断材料を得ること」が目的 02 クライアントとは信頼を「透明性＋予測可能性」で構築する 03 タスクを受ける前に成功基準・スコープ・Go基準を合意する 04 悪いニュースほど早く共有。黙ることが最大リスク 参照文献： Blank & Dorf (2012) The Startup Owner's Manual ／ Maister et al. (2000) The Trusted Advisor ／ Ries (2011) The Lean Startup ／ Gothelf & Seiden (2013) Lean UX ／ PMI PMBOK® Guide 7th Ed. ／ IEEE Std 1028-2008