PoCで大切にしたい2つの勘所
続いてInsight Edgeの日下氏がエンジニア目線で、当時のPoCを振り返っていく。まずは今回構想されていたSaaSの全体像を紹介しておこう。ユーザー企業の工場では、作業員が日報を書いたり、検査結果をレポーティングしたり、設備の稼働状況のデータが出力されていたりする。これらのデータを住友商事が提供するSaaSのデータ基盤に蓄積し、可視化システムを通じてダッシュボードに表示するというものである。
それを実現するために想定したアーキテクチャが以下の図だ。電子帳票やIoTのデータ収集は既存製品を使用。データの可視化には、マルチテナント対応かつWebアプリ埋め込みの機能があるAmazon QuickSightを使用するため、クラウド基盤はAWSを採用した。ユーザー側には、これらの機能をまとめるポータルアプリを用意し、ログインやデータセット定義、マスタデータ管理などを行えるようにする。
次に、日下氏はPoCの目的として強く意識していることについて話を進めた。「PoC（コンセプト検証）という言葉はフワッとしていて、人によって解釈が異なる。そこで、PoCの目的を大きく『Proof of Value（価値検証）』と『Feasibility Study（実現性検証）』の2つに分け、両面から検証することを大切にしている。エンジニア目線だと技術的な実現性は必ず意識することになるが、ビジネス上のニーズや効果も忘れてはいけない重要な観点だ」。
その上でPoCの効果を高めるための勘所として、日下氏は次の2点を挙げた。
- 「何を検証するのか？」を明確にして、目的を絞って素早く開発すること
ビジネス価値を検証したい場合は、プロトタイピングで挙動やアウトプットさえ再現できれば、技術的手段は置き換え可能である。他方、技術的実現性を検証したい場合は、不確定な要素や経験の少ない技術にフォーカスを絞ることで、無駄なものを作らずにスピードを上げられる。
- 検証する観点ごとの重要なステークホルダーを正しく認識し、生の声を聞くこと
よくある「PoC止まり」や「導入したけれど使われない」といった失敗を防ぐために、現場が効果を実感できるプロダクトに育てられるよう、生の声を大切にする。
これらを踏まえ、今回のPoCで検証したい観点とその関連ステークホルダーを整理した例が次の図だ。
