データ活用基盤の投資判断は難しい
坪内進史氏：まず事例①で、データ活用基盤の投資判断が難しいみたいなところ。「！」で強調していますが（笑）。我々SIerがぶつかるシーンがかなり多いところになっています。内容に入っていきたいと思います。
データ活用基盤の構築に至るまでの流れ。通常のシステム投資でも近いところはあるかなと思います。データ活用の文脈でいうと、データ活用のユースケースを策定していく取り組みが最初に来て、そこからプロセスを踏んで、最終的にはデータ活用基盤の構築・整備にいくことが多いかなと思います。
ここでいう「データ活用のユースケース」は、ちょっとイメージが湧かない方がいると思うので、弊社社内にあった適当なユースケースを持ってきました（笑）。
（スライドを示して）データを活用して会社としてのメリットを得ていく例として、ここに書いて挙げられているようなものがあるかなと思います。これはおそらく各社さまのビジネス形態によって大きく変わっていくところかなと思います。
BtoBのお客さま、BtoCのお客さまでかなり変わっていくものであるかと思いますが、総じて言えることは、データを使ってビジネスの利益を得る一連の流れ。そういったものを本日は「データ活用ユースケース」と呼びたいと思います。
話を戻して、データ活用のユースケースを策定して、それを基に、おそらくそれで得られる期待効果を算出する。その上で必要な投資判断を行って回収ができるものなのか、ビジネス上のメリットがあるものなのかを判断した上で、データ活用基盤の構築だったり整備に入っていけるかというのが、組織としての意思決定の健全な流れかなと思っています。
一方で、私もたまに見るんですが、ものすごくトップダウンで、CIOの方が費用対効果みたいなところをある程度度外視して、データ活用基盤の構築・整備に動き出すケースも見られます。これはちょっと例外的な話で、そういった会社さまは当てはまらないかもしれないですが、8割、9割の会社さまがこういった段取りを踏まないと、例えば役員会だったりで稟議がおそらく通らないようなことになるかなと思います。
こういった領域に関わっている方はおそらく実感しているかと思いますが、起点になるデータ活用のユースケースの策定というのは、非常に難易度が高くて時間がかかります。
例えばERP（Enterprise Resources Planning）の導入のような、今ある業務に対しての改善、コスト削減が見えて費用対効果を算出しやすい……。ERPがしやすいと言っているわけではないんですが、比較的しやすいものと比べて、こういった領域は本当に難しい。起点となる、効果を生み出すユースケースを考えるのが難しい特性があります。
このせいで初期の投資判断がなかなか難しくなりがちです。なので、段階的な投資判断、ないしデータ活用基盤の整備を回せていけないと、前に進めないというような問題に陥ってしまいます。
データ活用基盤整備における失敗事例
（スライドを示して）「非推奨パターン」と書いているんですが、まさに我々が陥った、実際に投資判断が得られなかったケースについて、みなさまに失敗事例として共有したいと思います。
我々のデータ活用基盤というところで、先ほどのIPAの資料とかをもうちょっと見てもらえれば、論理的なもの……。AWSのサービスがごちゃごちゃしているものではなくて、論理的なものが見て取れるかなと思います。
データの収集元があって、その現身であるデータレイクがあって、そこから分析に必要な整形・加工を行ってビジネス的な意味のあるかたち。再利用性の高いデータのマートとして保管してデータを分析していくみたいな。そういった一連の流れがある中で、データを収集していくところに関しては組織や企業が持っている、ないし企業外も含めて多種多様なデータを集めていく必要があります。
アンチパターンは、データをまず先にすべて集めてしまおうというパターンになります。この方法をやった方はけっこう納得してもらえるかなと思うんですが、我々もこのプロジェクトのかなり初期に、データ活用基盤の導入を特定のお客さまとデータレイクの構築プロジェクトとして（このパターンを）実際に対応したことがあります。名前の時点でもうゴール感が透けて見えるかなと思うんですが、まずはデータを集めて使える状態にしていこうとするようなプロジェクトでした。
やった方は本当にわかると思うんですが、データ収集って実はかなり泥臭くて。1つのツールを使って企業内のデータを全部収集できることはないです。集めたいデータによって収集するツールを変えたり、同じツールの中でも、データ収集元のデータのパターンだったり更新頻度によっては、やり方をカスタマイズしていかないといけない。一つひとつの個別特性を考慮して作っていかないといけないので、全部やろうとすると、それなりの構築期間とリードタイム、あとは人的投資が発生します。
これを集めることに注力していたら何が起きたかと言うと、途中経過を一緒に進めていたDX推進部の担当の方が経営層に報告した時に、プロジェクトの停止、ストップを言い渡されて、我々にもいったん契約解除が発生したことがあります。
役員の方のコメントでどういったものがあったかというと、「この進め方をしても、いつまで経ってもビジネスのメリットを得られる状態にならないし、その投資が本当に有効なものなのかを判断することができません」というフィードバックでした。
「そもそもプロジェクトのタイトルから間違っていたんじゃないか」というツッコミはあるんですが、確かに適切なご指摘なのかなと思っています。「期待効果を得られない進め方」というところですね。
データ活用基盤整備の推奨パターンを踏まえた事例
それらを踏まえた我々の推奨パターンとしては、必要最低限の基盤をユースケースを通しながら整備していくというのが、関係者の理解、合意形成を得やすいし、実際に健全な進め方かなと認識しています。
本日はこの進め方に関しての、より具体的な事例をちょっと紹介したいと思います。基盤というとやはりどうしても上物に載せていくためのベースになるので、最初に構築しきらないとという意識があると思うんですが、それをどのようにこの進め方にアジャストしていったかというところを伝えたいと思います。
（スライドを示して）これは実際に他のお客さまにご提案した際の資料になります。費用対効果について、この会社さまの意思決定者の方は、かなりうるさいと言うとアレですが、シビアな方でした。その中で、我々がそういった方の期待に応えるためにこういったフェーズ分けをしています。
Step1、Step2、Step3というところで、Step1でなんにせよユースケースを構築しきる。優先度の高いユースケースを1パターンでも2パターンでもいいから構築する。そのあとに基盤の整備・拡張みたいなところを追加のユースケースを追加するために必要なパターンの拡張と合わせて、例えばですがStep1で構築したユースケースの自動化を行ったり、CI/CDを整備していくような動き。そこからさらにそれを発展させていくというような3段階で実施しました。
これをもうちょっと具体的に見ていきます。もしかしたら「何のこっちゃ？」と置いけきぼりになる方もいるかと思いますが、すみません。
先ほどのStep1、Step2というところで、色分けをしています。Step1で何を構築してStep2で何を構築したかを図示しています。これだけだと少しわかりづらいので、ちょっと説明を入れます。
まずStep1で最初に優先度が高いと判断したユースケースの収集データを優先的に追加していきます。また、データのレイクを集めたその生データからデータマートを作っていくところの加工処理も、いきなり開発しないで、序盤はデータサイエンティストの方などが自分の環境で作成したデータをデータマートにアップロードして、それを実際の分析に回していくような取り組み。運用もかなり挟みましたが、そういったところでそのユースケースを通すことをまず優先的に行いました。
そこである程度の効果実感を得られた上で次のステップに進んでいき、例えば先ほどお話ししたマートの処理をシステム開発していくであったり、あとはデータパイプラインの加工も含めて自動化していくような動き。あとは適正な構成管理をしていくような動きを、ユースケースの効果確認後に段階的に実施していく。
当時はもともとの販売データからのデータの収集と合わせてやったんですが、ECサイトなどのアクセスログと合わせて、顧客の動向を横断的に分析したいという要望が出てきていたので、そういったデータの収集を実施してユースケースを拡張していく。こういう段階を踏んだ動きを実施いたしました。
一応こういった流れで、関係者、特に経営層だったりの合意形成をしながら、システムもその意思決定がしやすいように合わせて進めていくというような対応をした事例となります。
（次回につづく）
