全1975文字
PR

 DXプロジェクトを進める上で重要な工程が「PoC」です。PoCとは「Proof of Concept」の略称です。開発しようとしているサービスのコンセプトが本当に実現可能かどうかを検証する作業です。

 DXプロジェクトでは多くの場合、枯れた技術ではなく、AIなどの新しい技術を利用します。このため、「思ったように精度が出ない」「データが想定通りに集まらない」などのリスクがつきものです。

 このリスクを考慮せずに全体のスケジュールを組み立てると、技術面の問題を解消できずに、プロジェクト全体がずるずると遅延していく恐れがあります。これを防ぐために、PoCがあるのです。

 PoCで実施する内容は、プロジェクトによって異なります。ここではPoCをどのように進めるべきかについて解説します。

PoCはどのタイミングで実施するのか

 まずは実施のタイミングです。サービスの企画後か、要件定義後かで迷うケースが多いようです。

 答えは、開発するサービスの規模によって異なると筆者は考えます。例えば、AIがサービスのコアとなる機能でそれ以外の機能が少ない場合、つまりAI以外のシステム開発規模が小さい場合は、要件定義をした後にPoCを実行するのでも問題ないでしょう。AIの技術リスクがそれ以外のシステム開発に及ぼす影響が小さいためです(図1)。

図1●PoCの実施タイミングはサービスの規模によって異なる
図1●PoCの実施タイミングはサービスの規模によって異なる
[画像のクリックで拡大表示]

 一方で、今回のJQベーカリーの例のように、フロントエンドの画面や決済の仕組み、管理画面など多くの周辺機能があるような場合では、サービス企画の直後に実施すべきです。要件定義の後にPoCを実施すると、PoCの結果どうしても技術リスクが解消されない場合、企画から練り直さなければならなくなります。つまり、要件定義作業が無駄になってしまう恐れがあるのです。

 ただし、技術リスクが解消されないとしても代替案があるような場合は、要件定義後にPoCを実施する方法で問題ないこともあります。プロジェクトの内容によって適切な方法は異なるため、「技術リスクが要件定義に及ぼす影響の大きさ」を考慮しながら、全体の開発プロセスの中でPoCをどこで実施するかを決めるとよいでしょう。