カスタマーオンボーディングチームの溝川 晃央です。
本日はDXにおけるPoC（Proof of Concept）の在り方について問題提起したいと思います。まず、DXの現状についてですが、多くの企業で「DXは必然のものである」という認識ができつつあると思います。また、それに対してPoCを行い、徐々にDXを進めていっている企業も多いと思います。ITプロジェクトにおけるPoCの場合、通常半年〜1年程度のスパンでの検証を行うケースが多いと思いますが、DX PoCにおいてITプロジェクト同様の期間設定は適切なのでしょうか？また、そもそもDXにおいて各企業が適切なPoCのゴール設定をできているのでしょうか？
DXにおいて各企業が適切なPoCのゴール設定をできているか
そもそもDXというのはデータを中心に据えた事業変革であり、これが達成できる見込みがあるか、というのがPoCのゴールとして設定されていなければなりません。しかしながら、筆者が前職を含め過去に携わってきた数多のプロジェクトを見る限り、DX PoCとは名ばかりのゴールが設定されるケースが非常に多く見受けられます。
例えば、「MAを導入してメール配信ができること」や「CDP/DMPでデータを集約して施策チャネルに連携できること」といった具合です。性能試験の要素が強いオンプレ/IaaSの構築プロジェクトではこういったPoCゴールを設定してもいいかもしれません。然しながらSaaSプロジェクトの場合には、こういったPoCゴール設定をしている時点でPoCから先に進むことはないと断言できると思います。
辛辣なことを言うと、SaaSなので、そもそもそのようなことができるソフトウェアなのです。それを今更PoCして何の意味があるのでしょうか？PoCした結果、どのような気づきをを得て、具体的にネクストアクションへどのように活かすことができるのでしょうか？DXのPoCの場合にはやはり「データで事業変革ができるのか」を検証する、というのが非常に重要になり、その最短の検証手段として（自社開発ではなく）既にソフトウェアとして完成されているSaaSを用いるというのが1つの選択肢になります。
なので、DX PoCの場合には、事前に社内で議論された事業変革プラン（仮説）に対して、
- 適切なデータを集約できるか？
- 集約されたデータから（AIや可視化技術を用いて）事業変革に対して有用そうなデータを見つけられるか
- 有用そうなデータに対して施策を行い、事業変革にたりうる質/量の顧客を確保できそうか
という点を見る必要があります。ということで、DX PoCのゴールとしては、開発系プロジェクトのようなツールの性能試験ではなく、データを中心に据え事業変革の芽があるデータがないかを探ることが重要になると考えます。
DX PoCにおける期間の適切さ
前述の通り、PoC期間として旧来の開発系プロジェクトと同様に半年〜1年でDX PoCの期間が設定されることが多いというイメージです。この点に非常に違和感を覚えます。繰り返しになりますが、そもそもDXというのはデータを中心に据えた事業変革であって、それがたかだか半年〜1年で実現できるはずがないと思っています。
そんな短期間で実現できる程度のDXであれば、データを改めて観察する必要やAIに依存することもなく、既に先人たちの3K（経験、勘、根性）で実現できているのではないでしょうか？大事なのは、自社の事業変革プランに対して、データを用いて適切なアプローチができるかを、何度もAIモデルやBIをスクラップ＆ビルドしながら徐々に探りをいれてゆくことです。
ということは、DXに終わりは決してなく、常に仮説立案と検証を繰り返す期間無制限のPoCのような形になるはずです。つまり、DXプロジェクトにおいてPoCに所定の期限を設けることにあまり意味はない、というのが持論です。そもそも論として「ITツール導入=PoC」と思考停止しがちな風潮において、DXプロジェクトの特性を鑑みて「PoCを設定する必要性」という点から議論しないといけないと考えます。
いま一度DXプロジェクトにおけるPoCの在り方、また議論の原点である「DXで何を変革したい/できそうなのか」という事業仮説自体を社内で議論頂けると幸いです。
