はじめに
「新しいパッケージを入れる前に、PoC（Proof of Concept：概念実証）をやりましょう」という提案を受けたことがある発注側担当者は多いはずです。しかし、PoCの目的や進め方を発注側が正しく理解していないと、「ただのデモを見せられて終わった」「何を検証したのか曖昧なまま次の工程に進んでしまった」という結果になりがちです。
パッケージ導入かフルスクラッチか？AI時代に判断すべき3つの視点でも触れたように、基幹刷新の初期段階では技術選定の判断材料が不足していることが多く、PoCはその不足を補う手段として位置づけられます。今回は、基幹刷新プロジェクトにおけるPoCの正しい位置づけと、発注側が主導すべき進め方を解説します。
PoCの目的を明確にする
PoCでよくある失敗は、「何を検証するか」が曖昧なまま始めてしまうことです。PoCの目的は、大きく以下の3種類に分けられます。
- 技術的な実現可能性の検証：想定している機能が、そのパッケージ・技術で本当に実現できるか
- 性能・スケーラビリティの検証：想定しているデータ量・ユーザー数で、実用に耐える性能が出るか
- 業務適合性の検証：現場の業務フローに、そのツールが実際にフィットするか
これらを混ぜて「とりあえずPoCをやってみる」と進めると、検証結果の評価基準が定まらず、「結局、導入すべきかどうか分からない」という結論になります。PoCを依頼する前に、発注側として「このPoCで何が分かれば導入を決断できるのか」を明文化しておくことが重要です。
PoCの範囲を絞る
基幹刷新のPoCは、対象業務のごく一部に絞るのが基本です。すべての機能を検証しようとすると、PoCがそのまま本格開発になってしまい、「概念実証」という位置づけが崩れます。
実務上は、以下の基準で範囲を絞ります。
1. リスクが最も高い機能を優先する（例：既存システムで実現が難しかった処理、データ量が多い処理）
2. 要件定義ワークショップ（要件定義ワークショップを成功させる進め方｜テーマ別に関係者を集める参照）で挙がった「本当に実現できるか不安な要件」を中心に選ぶ
3. 検証期間は2〜4週間程度を目安にし、長期化させない
評価基準を事前に決める
PoCの結果を評価する基準は、PoC開始前に発注側とベンダーの双方で合意しておく必要があります。評価基準が事後的に決まると、「ベンダーに有利な解釈」で結論づけられるリスクがあります。
評価基準の例としては、以下のようなものが挙げられます。
- 処理時間が◯秒以内であること
- 現場の主要なユーザーが、追加の研修なしで基本操作を行えること
- 既存システムで発生していた特定の課題（例：二重入力、手作業の集計）が解消されること
これらを数値や具体的な行動レベルで定義しておくことで、PoC結果の評価を「感覚」ではなく「事実」に基づいて行えます。
PoCの結果をどう次工程に活かすか
PoCで「実現できる」と確認できた部分は、そのまま要件定義・基本設計に引き継げます。一方で、PoCで課題が見つかった部分については、以下のいずれかの対応が必要になります。
- 要件自体を見直す（システムに合わせて業務を変える）
- 別の技術的アプローチを検討する
- 追加のカスタマイズ・アドオン開発を前提に進める
ここで重要なのは、PoCで見つかった課題を「なんとなく解決できるだろう」で先送りしないことです。基幹システム刷新の進め方｜要件定義でつまずかないための3つのポイントでも触れた通り、基幹刷新の初期段階でのつまずきは、後工程に行くほど修正コストが跳ね上がります。PoCは、そのつまずきを早期に発見するための投資だと捉えるべきです。
まとめ
PoCは「やってみて感触を確かめる」ための曖昧な作業ではなく、目的・範囲・評価基準を事前に定義したうえで実施する、検証プロセスです。発注側がベンダー任せにせず、「何を確かめたいのか」「どうなれば導入を決断できるのか」を主導して定義することで、PoCは基幹刷新プロジェクトの初期リスクを大きく下げる工程になります。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント