PR
全2596文字

DXではユーザーの要求が曖昧なことが多い。現場では明確ではないユーザーのニーズを短期間で形にする「造形力」が求められる。

 DXの現場では「たとえ基幹系システム関連の開発であっても、ユーザーのニーズが曖昧だ」。アビームコンサルティングの一岡敦也 P&T DigitalビジネスユニットITMSセクターダイレクターはこう話す。

 「新たな販売方法を確立したい」という場合、刷新対象は既存の販売管理システムだ。これまでの業務効率化を目的としたシステム構築案件と異なるのは、販売管理システムの改修と同時に新しい販売方法というビジネス手法を考えることである。ウォーターフォール型の開発で言えば、要件定義と開発を一体化しながらユーザーの曖昧なニーズを形にする必要がある。

漠然としたニーズを形にする「造形力」
漠然としたニーズを形にする「造形力」
[画像のクリックで拡大表示]

PoCでは間に合わない

 では「要求」とも言えない曖昧なニーズからシステム要件を、それも短期間で導くにはどんなチカラを備えるべきか。そのポイントの1つが、サービスの「価値」を重視するアプローチだ。

 「IoT(インターネット・オブ・シングズ)を使って工場で異常を検知したい」。こうしたニーズがユーザーから寄せられたとき、「取得可能なデータを使ってまずPoC(Proof of Concept、概念実証)を実施しよう」と考えるかもしれない。

 しかしこれからのDXプロジェクトでは「PoCを実施するのはダメだ」とグルーヴノーツの最首英裕社長は断言する。本番向けのサービスを開発する際にPoCで開発したサービスをそのまま利用できるとは限らない。時間のムダになるからだ。

 そこで「異常を検知したい」というニーズが寄せられたら、「検知結果から得られる価値、が検証すべき事項になる」と最首社長は強調する。

 そこで必要になるのがサービスから得られる価値が本当に意味があるものかどうかを検証する「Proof of Value(PoV、価値実証)」だ。

「PoC」と「PoV」の違い
「PoC」と「PoV」の違い
[画像のクリックで拡大表示]

 PoVで着目するのはサービスが実現する価値だ。「IoTを使って異常を検知した結果、どんな価値が得られるのか。その価値は本当に必要なのか」を検証する。

 例えば異常検知の目的が工場の稼働率アップであれば、IoTで異常検知する以外の方法が向くかもしれない。「本当に必要な価値をどのように実現するかを検証することが求められている」と最首社長は説明する。

 NECでは最小限の機能のみを実装する手法「MVP(Minimum Viable Product)」を採用し、短期間で最小限の価値を検証することを目指している。「DXを支援するシステムをサーバーレスで実行したい」といったニーズがあれば、エラーハンドリングといった機能は実装せず、サーバーレス環境で実行するコードのみを用意する、といった考え方だ。

 「サービスを開発する中でも最もコアとなる機能をMVPとして実装することで、価値があるかすぐに検証できる」とNECの長田祐介サービス&プラットフォームSI事業部シニアマネージャーは話す。短いものであればMVPを1週間程度で開発できるという。

この記事は有料会員限定です

「日経コンピュータ」定期購読者もログインしてお読みいただけます。

日経クロステック有料会員になると…

専門雑誌8誌の記事が読み放題
注目テーマのデジタルムックが読める
雑誌PDFを月100pダウンロード

有料会員と登録会員の違い