What is PoC

What PoC means

PoCの定義

PoCとは「Proof of Concept」の略で、日本語では「概念実証」と訳されます。新しいシステムやサービスを本格開発する前に、そのアイデアや仕組みが実際に機能するかどうかを小規模・低コストで検証するプロセスです。

IT分野では特に、業務システムを導入する際に「このシステムで自社の業務が本当に回るか」「現場の担当者が実際に使えるか」を確かめる目的で実施されます。PoC段階では完成品を作るのではなく、核心的な仮説だけを検証できる最小限の形で試します。

PoC vs Prototype

PoCとプロトタイプの関係

PoCとプロトタイプはセットで語られることが多く、混同されやすい概念です。厳密には、PoCは「検証の目的」を指し、プロトタイプは「検証に使う成果物」を指します。

つまり、「プロトタイプを作ってPoCを実施する」という関係です。プロトタイプがなければPoCは絵に描いた餅になり、PoCの目的が明確でなければプロトタイプは作りっぱなしで終わります。両者は切り離せない関係にあります。

The cost of skipping

PoCを省略すると何が起きるか

業務システムの開発失敗の多くは、PoCなしで要件定義・設計・開発と進んでしまったことに起因します。「資料上では問題なかった」「打ち合わせでは合意していた」にもかかわらず、完成したシステムを現場に展開したときに初めて問題が発覚する——これが典型的な失敗パターンです。

この時点での手直しは、開発初期の修正に比べて10倍〜100倍のコストがかかるという試算もあります。要件が確定してから設計・開発・テストと進めるウォーターフォール型の開発では特に、この問題が顕在化しやすくなります。

What PoC validates

PoCで検証すべき3つのこと

• システムが実際の業務に適応しているか システムを使って実際の業務手順を一通り試し、手順の抜け・矛盾・非効率がないかを確認します。資料上の業務フローと、実際の現場の動きにずれがあることは珍しくありません。
• 現場がスムーズに使えるか（UX検証） 担当者が実際にシステムを操作し、画面の設計・入力項目・操作の流れが現場の感覚に合っているかを確認します。「使いにくい」という感想は、完成後ではなくPoC段階で出すべきフィードバックです。
• 要件の曖昧さ・抜け漏れを洗い出せるか 動くシステムを試すと、文書では気づかなかった仕様の抜け漏れや、担当者間の認識のずれが自然に表面化します。これをPoC段階で解消することが、本開発での手戻りを防ぐ最大の効果です。

Why PoC fails

PoCが失敗に終わるパターン

PoCを実施しても効果が出ないケースには、共通したパターンがあります。

最も多いのは、検証に使ったプロトタイプが「画面だけのモックアップ」だったケースです。実際のデータが扱えない・業務ロジックが入っていない・画面遷移がハードコードされているような形では、業務フローの検証にはなりません。見た目を確認することはできますが、「動くか」の確認にはなっていないのです。

次に多いのは、検証期間が短すぎる・関係者が揃っていないケースです。発注担当者だけで確認して「問題なし」とすると、現場担当者が使い始めてから問題が噴出します。PoCは現場ユーザーが実際に手を動かして試す時間と機会を確保することが不可欠です。

Keys to success

PoCを成功させる条件

• 実データを扱える完全型プロトタイプを使うこと — 見た目だけのモックアップではPoC本来の効果は得られません
• 現場担当者が実際に操作する機会を設けること — 発注側の判断だけでは現場の実態は見えません
• フィードバックを要件に反映するプロセスを持つこと — PoC後の改善サイクルがなければ、検証は形式だけになります
• 検証スコープを絞り込むこと — 全機能を一度に検証しようとすると焦点がぼやけます。核心的な業務フローに絞って深く検証することが重要です

Why so few can do this

完全型プロトタイプでPoC支援できる企業が少ない理由

PoCに完全型プロトタイプが必要なことは、多くのIT支援者が理解しています。しかし実際に提供できる企業は非常に限られています。その理由はシンプルで、「ビジネス分析」と「システム開発」の両方ができなければ、完全型プロトタイプは作ることが難しいからです。

ITコンサルタントやSIerの上流工程担当者は、要件整理・ヒアリング・ドキュメント作成は得意ですが、実際に動くシステムを自分たちで構築する開発能力を持たないケースが大半です。逆に開発会社は技術力があっても、プロトタイプを通常の開発コスト構造で作るため、「完全型プロトタイプを短期間・低コストで作る」ことが難しくなります。

もちろんSIerや開発会社も、時間やコストを存分にかければ完全型プロトタイプを作ることは可能です。しかし、「素早く作って作り直す」「低コストで実施する」という条件が付けば、実現できる企業は少なくなります。

Alcogy's advantage

Alcogyが低コスト・高精度で提供できる理由

• 専用の技術基盤 完全型プロトタイプの実装に最適化した技術スタックやアーキテクチャを整備しています。業務システムに共通する機能を抽象化することで、完全型プロトタイプを短期間・低コストでの構築を実現しています。
• ビジネス分析と開発の両方を担う ヒアリング・業務整理・要件定義からプロトタイプの設計・実装・PoC支援まで、一貫して対応します。コンサルタントと開発者を別々に用意する必要がなく、認識のずれや引き継ぎコストが発生しません。
• 軽量DDD設計による高い品質と柔軟性 ドメイン駆動設計（DDD）を中小企業向けにカスタマイズした設計手法を採用しています。プロトタイプ段階から保守性の高いコードで構築するため、検証後に発生する仕様変更やスコープ追加にも素早く対応できます。
• 小規模チームによるオーバーヘッドの少なさ 大規模な組織では、プロジェクト管理・社内調整・営業対応などの間接コストが開発費用に乗ります。Alcogyは小規模チームで直接対応するため、費用の大部分が実作業に充てられます。

PoC reduces total cost

PoCは追加費用ではなく、開発コストを下げる投資

「PoCをやると余分なコストがかかる」と思われがちですが、実際には逆です。PoC段階で問題を解消することで、本開発全体のコストが下がる可能性があります。

• 手戻りコストの解消 開発完了後に仕様のずれが発覚した場合、設計・実装・テストをやり直す費用が発生します。PoC段階で問題を見つけて修正するコストは、開発後の手戻りと比べて大幅に小さくなります。開発後のUAT（受け入れテスト）でも、PoC段階で現場検証を済ませておくことで指摘が大幅に減るため、リリース前の調整コストを抑えられます。
• 不要な機能の削減 「あったら良いかも」という理由で盛り込んだ機能が、実際に使ってみると必要なかったというケースは珍しくありません。PoCで現場が実際に触れると「これは使わない」「こっちの方が優先度が高い」という判断が自然に出てきます。必要な機能だけに絞って開発することで、開発費用を削減できます。
• 現場定着コストの削減 リリース後に「使いにくい」「業務フローが合わない」という問題が起きると、再設計・追加開発・操作説明会・定着支援と、予想外の費用が積み上がります。PoC段階で現場が検証に参加したシステムは受け入れられやすく、定着に必要なコストを抑えられます。

PoCのコストと、それによって削減できる本開発・手戻り・定着コストのバランスを考えると、適切なPoC投資は総コストを下げる可能性が高くなります。税理士費用や保険料と同様に、「かけることで後の大きな損失を防ぐ」性格の支出です。