DX活動の流れには5つのステージがある【第2回】

（3）技術PoCステージ

　今のコンセプトが技術的に実現可能かを検証します。世間では、このステージを「PoC」と呼ぶなど、最もスポットライトが当たっています。ビジネスアナリストが問題を定義し、データサイエンティストが高度なモデリングを実施し、エンジニアがアジャイルで機動的に開発するという、まさに“花形”というイメージです。逆に他のステージが見えていないとも言えます。

　技術PoCステージの「コンセプト構築・要求定義」では、「何をどう検証すれば本格開発に進めるか」という判断基準を設定します。次のステージで、しばしば投資額が跳ね上がるため、ビジネスリーダーはパトロンと自分自身を納得させるための材料を集めねばなりません。もちろん完璧を期していては自縄自縛になってしまいますので、重要度に優先順を付ける必要があります。

　「技術面PoC」は、通常のITプロジェクトに近いものです。ここではビジネスリーダーはプロジェクトオーナーのような役割を果たし、「プロジェクトマネジャー」または「スクラムマスター」がPoCの「どうやって」の部分を担います。

　データサイエンティストやエンジニアにとっては、思う存分クリエイティビティを発揮できる自由度の高いステージです。この時点で「システムアーキテクト」が参加し、将来的なシステム整合性・発展性を見据えるのも重要です。

　技術PoCステージで検証がうまくいかなかった場合は、構想ステージに戻って技術を選び直すか、あるいは解くべき問題を変える必要があります。技術PoCステージが結論ありきの“出来レース”になってしまわないよう、ビジネスリーダーは細心の注意を払う必要があります。

図2：DX活動の流れの前半を構成する3つのステージ。図はデータ系DX活動の例

（4）開発ステージ

　実運用のためのアプリやシステムを作ると同時に、新しいビジネスプロセスも実装します。このステージはケースによって様々で、既存プラットフォームに載せるアプリケーション開発のようなものから、堅牢なシステム開発のようなものまで存在します。

　「要求定義」では、前ステージまでに検証されたコンセプトに基づき必要な項目を洗い出します。ここで重要なのは、DXは単なるシステム開発でもなければ、ただの業務変革でもないということです。従って、ITの部分を「デジタルプロダクトマネジャー」が管轄し、ビジネスの部分を「ビジネスプロセスマネジャー」が見る。その全体を整合させ“ありたい姿”が実現できるかを統括するのがビジネスリーダーになります。

　「開発・試用・評価」は、通常のシステム開発より難易度が高くなります。IT部分は通常のプロダクト開発に近いものですが、ビジネスモデルやプロセスに大きな変革を伴う場合にはビジネスプロセスマネジャーの役割が大きくなります。

　ビジネスリーダーの元でITと業務が一体となったコミュニケーションができないと、開発ステージは容易に長期化します。データは時々刻々と変化しますので、DevOps（開発と運用の融合）／MLOps（機械学習と運用の融合）の考え方で次のステージを見据えることが不可欠です。

（5）運用ステージ

　新しいビジネスモデルやプロセスで価値を生み出します。当たり前ですが、業務変革もシステム開発も運用するためにあります。前ステージで大量に投入され“お祭り騒ぎ”だった人々の多くは次のDX活動に移り、業務中心の人員構成になります。しかし、環境変化の速い時代において、一度開発したシステム、一度設計したビジネスモデルやプロセスが、そのままずっと使えることは稀です。絶えずパフォーマンスを評価し改良し続けることが重要です。

　「運用」ではビジネスリーダーが価値を出すために牽引し、マネジャーとユーザーがオペレーションを回します。同時に、正しくデータを蓄積するために「データスチュワード」が、蓄積されたデータを用いてデータ駆動型での意思決定を支援するためにデータアナリストが、それぞれ必要になります。

　「ギャップ分析・パフォーマンス評価」では、ビジネス価値が想定通り出せているかを定期的にチェックします。ここで初期のコンセプト構築に関わったビジネスアナリストが再登場するのも見逃せません。

　「保守・改良」は、単なるシステム保守・改良に加えて、データ特有のMLOps的な側面にも注意する必要があります。

図3：DX活動の流れの後半を構成する2つのステージ。図はデータ系DX活動の例

　いかがでしたでしょうか。この流れをおさえたうえで次回は、各ステージに必要な人材像について説明します。