PoC開発を成功に導くには？

自社のPoCは「判断」まで設計できているか

まず、現在のPoC計画を確認してみてください。次の質問に答えられない場合は、試作を始める前に決めておくことがあります。

• PoCの結果を見て、誰が何を決めるのか
• 外れた場合に事業や設計への影響が最も大きい仮説は何か
• どの数値・状態なら次工程へ進めるのか
• 合格と不合格の間に入った場合、何を追加確認するのか
• 今回のPoCでは確認しない項目は何か
• 試験条件は実際の使用環境をどこまで再現しているか
• 試作品側のばらつきと、測定方法のばらつきを区別できるか
• 量産前に残る課題を、製造・調達・品質保証へ渡せるか

答えられない項目があっても、PoCが失敗しているわけではありません。むしろ、今の段階で見つけられたなら修正できます。

最初に手を付けるのは試作品ではなく、「PoC後に何を判断するか」の定義です。

PoC開発とは、次の意思決定に必要な証拠を作る工程

PoCは、新しい技術や仕組みが成立するかを、小さな検証で確かめる取り組みです。ただし、「成立するか」だけでは問いが粗すぎます。

製品開発では、要求仕様を満たすことと、想定する環境で目的を果たすことは別の確認です。NASAのシステム工学でも、要求への適合を示すVerificationと、意図した環境・用途で目的を満たすことを示すValidationは分けて扱われています。^※1

PoCも同じように、何を証明するかを先に絞ります。たとえば「センサー精度が許容範囲に入るか」と「屋外で長期間使ったときの保守負荷を許容できるか」は、必要な試作品も環境も評価者も違います。一つのPoCですべてを証明しようとすると、検証範囲だけが膨らみます。

PoCの主成果は試作品そのものではなく、「この条件なら、この仮説は成立する」と判断できる証拠です。

PoC・プロトタイプ・実証実験・MVPの違い

これらの言葉に、業界をまたいだ厳密な境界があるわけではありません。名称から工程順を決めるより、「何を判断したいか」「何を作るか」「どこで試すか」で使い分けるほうが実務的です。

プロトタイプをPoCの検証器具として使うこともあれば、実証実験の中で技術仮説を確かめることもあります。「PoCの次は必ずプロトタイプ」という固定順序ではなく、未解決の問いに合わせて手段を選ぶと考えてください。

PoCで検証する不確実性を4つに分ける

PoCが長引く一因は、種類の違う問いを一つの実験に詰め込むことです。ハードウェアPoCでは、実務上、不確実性を次の4領域に分けると整理しやすくなります。

技術

原理、性能、耐久性、安全性、他要素との干渉が成立するか

使用・運用

想定ユーザーが使え、使用環境や保守条件に耐えられるか

製造・品質・供給

材料、工法、公差、検査、調達、歩留まりが予定数量で成立するか

事業

顧客が価値を認め、価格・原価・販売数量の前提が成立するか

次に、「外れたときの影響が大きい」「現時点の確信度が低い」「後工程で判明すると修正が高くつく」の3条件が重なる仮説を先に検証します。

たとえば屋外センサーなら、通信機能を増やす前に、温度変化で測定精度が崩れないかを見ます。精度が製品価値の前提であり、筐体や補正方法にも影響するからです。反対に、後から容易に変更できる表示色まで同じPoCに含める必要はありません。

範囲を絞ることと、課題を見落とすことは違う

検証範囲を狭めると、「ほかの問題を見落とすのではないか」と不安になるかもしれません。しかし、PoCで確認しないことは、不要なことではありません。

今回は検証しない項目として記録し、次の試作や実証実験へ送ります。未確認事項が残ることより、何が未確認なのか分からないまま進むことのほうが危険です。

検証項目を増やすより、事業を止める可能性がある仮説を先に見つけるほうが、PoCの範囲を絞りやすくなります。

PoC開発の進め方【6ステップ】

1. 最初に、PoC後の意思決定を定める

「技術を試す」ではなく、「結果を見て何を決めるか」から始めます。本設計へ進むのか、方式を一本化するのか、投資を止めるのか。決定事項が明確なら、必要な証拠を逆算できます。

2. 仮説と前提条件を分ける

検証したい仮説に加え、結果へ影響する前提を記録します。使用温度、電源、材料ロット、荷重、通信環境、作業者などです。前提を書かずに成功値だけ残すと、次工程で同じ結果を再現できません。

3. 合格・条件付き・不合格の基準を決める

合否を検証後に決めると、都合のよい解釈が入り込みます。目標値だけでなく、条件付きで進められる範囲と、方式変更や中止が必要な範囲も先に決めます。判定者と判定日も、この時点で決めます。

4. 問いに答えられる最小の実験を設計する

完成品に近づけることより、問いに対する識別力を優先します。候補方式の比較なら同じ条件で差を測れる構成にし、耐環境性を見るなら温度や振動などの因子を変えられる構成にします。今回あえて確認しない項目も明記します。

5. 実施条件と逸脱を記録する

実測値だけでなく、試料、設備、設定、測定器、作業者、日時、異常、計画からの変更を残します。想定外の結果が出たときは、失敗として隠さず、製品側の問題か、測定側の問題か、前提条件の違いかを切り分けます。

6. 証拠をそろえて次の判断を行う

最後に、結果、成立条件、限界、未確認事項を一式にします。そのうえで、次へ進む、条件を付けて進む、再設計する、中止・保留にする、のいずれかを決めます。ここが、次へ進むかを決める判定の場、いわゆるゲートです。

屋外センサーのPoCを一枚にすると

6ステップを実務へ落とすと、次のようになります。数値や条件は製品ごとに異なりますが、計画書の粒度を確認する参考にしてください。

この形まで整理できれば、PoCの担当者が変わっても、何を確かめ、どの結果なら次へ進むのかを追えます。

PoCの結果を「判断に使える証拠」にする

試作品の見た目が整うと、製品開発そのものが前進したように見えます。しかし、完成品に近く見えることと、判断材料としての信頼性は別です。

証拠の強さは、検証した範囲、環境の現実性、条件幅、反復、測定方法で決まります。

実験室で動いた範囲と、現場で使える範囲を分ける

NASAの技術成熟度では、重要機能の概念実証、実験室環境での確認、関連環境での確認、運用環境での実証を段階的に区別しています。^※2 民生品にこの尺度をそのまま導入する必要はありませんが、「どの環境で得た証拠か」を明示する考え方は有効です。

以下はNASAのTRLをそのまま転記したものではなく、検証環境を段階的に現実へ近づける考え方を、ハードウェア開発向けに整理したものです。

中央の一条件だけでなく、境界条件を見る

室温・定格電圧・新品部品だけで成立しても、使用範囲の端で崩れるかもしれません。温度、電圧、荷重、材料ロット、経時変化など、結果を動かしそうな因子を挙げ、どの範囲まで見るかを決めます。

複数因子が絡む場合、一条件ずつ場当たり的に変えると原因を読み違えることがあります。NISTは実験計画について、目的を先に定め、変化させる因子と測定する応答を選び、実施前に詳細な計画を組む考え方を示しています。^※3

すべてのPoCに本格的な統計手法が必要なわけではありません。ただし、少なくとも「何を変え、何を固定し、何を測るか」はそろえます。

製品のばらつきと、測定のばらつきを分ける

目標値ぎりぎりの結果ほど、測定方法の影響を無視できません。同じ試料でも、測定器、作業者、設定、環境、時間が変われば値は揺れます。NISTの測定プロセス評価でも、反復性、条件や実施者が変わったときの再現性、安定性、バイアス、測定不確かさを分けて扱っています。^※4

試行回数に一律の正解はありません。対象と許容誤差に応じて決めます。ただし、測定器、手順、実施者、校正状態、反復回数を記録し、判定値と測定の不確かさが近すぎないかは確認してください。

PoCを終わらせるために残す判断材料

PoCが終わらないのは、データ不足だけが原因ではありません。誰が、どの資料を見て、何を決めるかが曖昧なまま検証を始めると、「もう少し試す」が続きます。

終了判定に必要な資料一式を、意思決定パッケージとして整理します。

Stage-Gateの考え方では、次段階への投資を決める場に、提出物、評価基準、決定と次の計画をそろえ、Go、Kill、Hold、Recycleなどを判断します。^※5 PoCへ制度全体を導入する必要はありませんが、終了判定の設計には使えます。

結果が合格基準ぎりぎりだったらどうするか

実際のPoCでは、きれいな合格・不合格に分かれないことがあります。平均値は基準を満たしたものの一部の試料が外れた、測定誤差を考えると合否を断定できない、特定の環境だけで性能が落ちた、といった状態です。

この場合、平均値だけを見てGoにするのではなく、次の点を確認します。

• 基準から外れた結果に、説明できる原因があるか
• 製品のばらつきなのか、測定方法のばらつきなのか
• 実際の使用範囲でも発生する条件なのか
• 設計変更や補正によって解消できるか
• 追加検証で結論が変わる可能性があるか
• 追加検証に必要な期間と費用を許容できるか

条件付きGoは、「懸念はあるが進める」という曖昧な承認ではありません。追加条件、担当者、期限、未達時の扱いまで決めて初めて機能します。保留も同様に、再開条件と見直し日がなければ事実上の放置です。

中止や再設計も、PoCの正当な結論です。見込みの薄い方式への追加投資を止められたなら、PoCは役割を果たしています。

ハードウェアPoCを量産へつなぐ確認事項

技術が成熟しても、製造が成熟しているとは限りません。試作品は、熟練者が選別部品を使い、時間をかければ作れます。量産では、異なるロット、設備、作業者でも、決めた時間と原価で品質を保つ必要があります。

「1台が動いた」から量産性を判断しない

PoC終了時にすべての量産条件を証明する必要はありません。代わりに、PoCで確認できたことと、製造試作以降で確認すべきことを分けます。

米国防総省の調達における製造成熟度を検証したGAO報告では、技術成熟度と製造成熟度を分け、実験室、製造に関連する環境、パイロットライン、量産へと製造証拠を段階的に強める考え方が整理されています。一般企業がMRL制度をそのまま導入する必要はありませんが、技術と製造の証拠を分ける視点は参考になります。^※6

• 候補材料・部品は安定調達できるか
• 予定数量に対して工法と設備は合っているか
• 公差は必要以上に厳しくないか
• 組立・調整を作業者の勘に依存していないか
• 合否を判定できる検査方法と治具があるか
• 歩留まり、生産速度、目標原価の見通しがあるか
• 保守、交換、廃棄まで含めて運用できるか

ここで答えられない項目があること自体は問題ではありません。PoCの段階で答えられない項目を特定し、次の試作で誰が確認するかを決めることが重要です。

製造制約はPoCの後ではなく、設計中に入れる

NISTに掲載されたDFM研究では、製造上の問題を設計段階で見つけて排除し、作りやすさを設計へ反映する考え方が示されています。^※7 PoCの装置をそのまま量産設計にする必要はありませんが、成立した原理をどの工法へ移すかという仮説は早めに置きます。

ここで製造、調達、品質保証を入れると、技術部門だけでは見えにくい供給リスクや検査不能な仕様を拾えます。PoCの結論を「技術OK」で閉じず、次工程で扱う製造条件と未確認事項へ落とし込みます。

PoC計画書に入れる項目と相談先の選び方

計画書は長いほどよいわけではありません。検証担当者と判定者が同じ前提で動ける情報を、1枚目で追えるようにします。

外部へ依頼する場合は、装置を作れるかだけでなく、仮説と評価方法を設計できるかを見ます。ハードウェアでは、材料・工法・公差・検査・調達まで扱え、結果が悪かった場合に原因の切り分けと再設計を提案できる相手が向いています。

• PoCの終了条件を契約前に合意できるか
• 測定方法と生データを引き渡せるか
• 試作後の設計・製造・品質課題を整理できるか
• 量産メーカーへ渡せる仕様と未決事項を残せるか
• 追加検証が必要な場合、理由と費用を説明できるか

自社内で不足する知見が見えたら、検証だけでなく、その後の設計・製造までつなげられる相談先を比較します。

PoC開発でよくある質問

PoCの期間と費用はどのくらいですか？

製品分野や検証環境によって変わるため、一律の相場から決めるのは危険です。先に、今回の意思決定に必要な仮説と証拠を絞り、その実験に必要な試作、設備、測定、反復から期間と費用を積み上げます。予算上限が先にある場合は、答えられる問いの範囲を狭めます。

何回試せば再現性を確認できますか？

「最低3回」のような共通基準はありません。期待するばらつき、許容誤差、破壊試験かどうか、ロット差や作業者差まで見るかで必要数は変わります。回数だけを決めず、どの変動要因を含めるかを先に決めてください。

PoCに成功すれば量産へ進めますか？

必ずしも進めません。PoCで技術仮説が成立しても、工法、供給、検査、歩留まり、原価が未確認なら、量産判断には別の証拠が必要です。PoC終了時に、確認済みと未確認を分け、次の製造試作で何を確かめるかを決めます。

狙った結果が出なければPoCは失敗ですか？

事前の基準で仮説を否定でき、追加投資を止めたり方式を変えたりできたなら、PoCは役割を果たしています。問題なのは、結果が出ないことではなく、何も判断できない検証を続けることです。