レッスン3：PoC 設計と実施

このレッスンで学ぶこと

PoC のゴール設計を「技術検証」と「業務適合検証」の 2 軸で持てる
PoC 環境の分離と業務側テスターの巻き込みを組み立てられる
評価シートの作り方（機能・使いやすさ・パフォーマンス・運用性）を扱える
PoC 結果を意思決定に繋げる型を持ち帰れる

前レッスンでは企画・RFI/RFP 発行と複数ベンダーコンペの運営を扱いました。本レッスンでは、RFP 選考の中で最も重要な PoC（Proof of Concept：概念実証）の設計と実施を扱います。PoC の目的は「動くか」ではなく「使えるか」であり、この目線を持てるかどうかが SaaS 選定の成否を分けます。

PoC の目的——「動くか」ではなく「使えるか」

多くの企業で PoC が失敗する原因は、目的の設定にあります。

よくある失敗パターン

失敗 1：ベンダーのデモを見て「動く」ことを確認しただけで PoC 完了
失敗 2：IT 側のテスターだけで実施し、業務側の要件が反映されない
失敗 3：短期間（1〜 2 週間）で終わらせ、実業務データでの検証を省略
失敗 4：評価基準が定性的で「なんとなく良さそう」で決めてしまう

あるべき PoC の目的

PoC は「本番導入前の最終検証」であり、次の 2 軸で目的を持ちます。

技術検証：機能が想定通り動くか、既存システムと連携できるか、パフォーマンスが十分か
業務適合検証：業務側の担当者が実際の業務データで使い、業務プロセスに馴染むか

「使えるか」の視点は、業務側テスターにしか判断できません。IT 側だけで PoC を回すと、機能テストで満点でも業務では使われない SaaS を選んでしまいます。

PoC 設計の 5 要素

PoC を設計する時、次の 5 要素を明確にします。

要素 1：期間

標準：2〜 6 週間
ベンダーが用意する PoC 環境の期間内で完結させる
業務側テスターの稼働確保を事前に人事・上長と調整

要素 2：参加者

IT 側：SaaS 設定・連携テスト担当（1〜 2 名）
業務側：実業務データでテストする担当者（3〜 5 名）
業務側マネジャー：業務プロセス変更の判断者（1 名）

要素 3：検証範囲

対象機能：RFP で Must と定めた機能に限定
対象データ：実業務データのサンプル（個人情報などはマスク処理）
対象業務プロセス：現行業務の代表的な 3〜 5 パターン

要素 4：評価軸

機能適合度（RFP で定めた機能要件への実現度）
使いやすさ（業務側テスターの主観評価）
パフォーマンス（レスポンス時間・エラー発生率）
運用性（管理画面の操作性・障害対応のわかりやすさ）
既存システムとの連携性（API・SSO・データ連携）

要素 5：判定基準

各評価軸の閾値（例：機能適合度 80 % 以上、パフォーマンス 3 秒以内）
総合評価の判定方法（合格/条件付き合格/不合格）
PoC 結果を上位承認者に説明する形式

PoC 環境の分離

PoC は本番環境から分離して行います。

graph LR
    A[PoC 環境] --> B[本番データのマスク処理]
    A --> C[既存システムからの独立]
    A --> D[SaaS 側のトライアル環境]
    B --> E[個人情報マスク]
    B --> F[売上データマスク]
    C --> G[本番 IdP から分離]
    C --> H[本番 API から分離]

PoC 環境の設計原則

本番の IdP・SSO 環境と分離（PoC 用のテストユーザーを作成）
本番データを直接使用せず、マスク処理したサンプルデータを使用
個人情報保護法・GDPR などのコンプライアンス確認を事前に済ませる
PoC 期間終了後、データを完全削除する契約条項を確認

業務側テスターの巻き込み

PoC の成否は、業務側テスターの参加度で決まります。

業務側テスター選定の 3 基準

業務理解度：現行業務のプロセスと課題を熟知している
発信力：テスト結果を的確に言語化できる
社内影響力：導入後に周囲を巻き込めるキーパーソン

「暇な人」「新人」を選ぶと、テスト品質が上がらず、導入後の推進役にもなりません。あえて「多忙な中核メンバー」を口説くことが重要です。

テスター向けキックオフの型

PoC の目的と役割の説明（30 分）
SaaS ベンダーによる操作トレーニング（60 分）
評価シートの記入方法説明（30 分）
質問対応（30 分）

キックオフ後、テスターには「毎日 30 分の PoC 時間を確保」してもらい、実業務のシナリオでテストを進めてもらいます。

評価シートの作り方

評価シートは、複数のテスターが一貫した基準で評価できるように設計します。

評価シートの構造

評価項目	説明	配点	テスターの評価	コメント
機能 1：受注入力	1 件 3 分以内で入力完了	20	15	画面遷移が多い
機能 2：一括更新	100 件を 5 分以内で更新	15	15	十分速い
使いやすさ	新規ユーザーが 1 週間で慣れるか	20	12	メニュー階層が深い
パフォーマンス	ページ表示 3 秒以内	15	15	問題なし
運用性	管理画面の操作性	10	8	良好
既存連携	会計システムへの API 連携	20	18	ほぼ完璧
合計		100	83

複数テスターの点数を平均化し、ベンダー間で比較します。

コメント欄の重要性

点数だけでは伝わらない「使い勝手」「学習コスト」「潜在的な問題」がコメント欄に集約されます。上位承認者への PoC 結果報告では、点数以上にコメントの内容が判断材料になります。

PoC 結果の意思決定への繋げ方

PoC 完了後、次の 3 ステップで意思決定に繋げます。

Step 1：PoC 結果レポートの作成

ベンダー別評価点数の集計
テスターコメントの要約
各ベンダーの長所・短所
買い手 PM としての推奨と理由

Step 2：ステークホルダーへの報告

プロジェクトオーナー（役員）
業務側部門長
情シス部門長
予算承認者

Step 3：最終選定と契約交渉

選定候補 1 社に絞る（または 2 社並行で交渉）
契約条件の詳細交渉（既刊譲り）
契約締結

💡 ポイント PoC は「ベンダーを選ぶ」プロセスであると同時に、「業務側の期待値を作る」プロセスでもあります。PoC に参加したテスターは、導入後の主要ユーザー・アンバサダーになります。PoC を丁寧に運営することは、社内浸透の第一歩になります。

次のステップ

本レッスンでは PoC 設計と実施を扱いました。次のレッスンでは、選定完了後の導入プロジェクトのキックオフと WBS を扱い、プロジェクトを実際に回すための骨格を組み立てます。

確認クイズ

このレッスンで学んだ内容を確認しましょう。