〈開発者ブログ 連載〉Vol.9
～ データの可視化・分析について ～

データ分析・可視化に関する記事の第9回目です。

DXを実現するために、なぜデータ○○基盤が必要なのかについて正確に説明できる人は少ないと思います。この説明のために、IPAの「DX実践手引書 ITシステム構築編」から、スサノオ・フレームワークを引用します。

スサノオ・フレームワークは企業で IT システムを実現する技術要素群を表現したもので、先行事例の調査において有効性が明らかになった技術要素についてまとめられています。

あるべき IT システムを実現する技術要素群「スサノオ・フレームワーク」

出典: 情報処理推進機構「DX実践手引書 ITシステム構築編 完成第1.0版」

絵の中で、技術要素群に対してAからJまでアルファベットが割り振られています。
この中で最も想像がしやすい要素は、(A),(B),(H),(I)あたりではないかなと思います。

企業内のアプリケーション群を以下の2軸のマトリクスで切った場合、下表のようなマッピングになります。

• 競争力の源泉となる領域/効率性・標準化を進める領域
• 顧客接点となる領域/社内の業務プロセスに関わる領域

また、データ活用基盤(D)・データ分析基盤(E)なども想像しやすいですね。
企業内外からデータを集めて利活用できるようにする環境を表しており、当社におけるデータ・ドリブン・プラットフォーム（以下DDP）にあたります。

データの分析する際に、天候の情報、地図情報などの外部情報があると分析の幅が広がりそうだなというのも納得なのではないでしょうか。（社外データソース(J)）

残った(C)と(F)について考えてみようと思います。

媒介層(C)/API(F)は何を指すのか

このスサノオ・フレームワークの元にある「スピード・アジリティ」を実現するための IT システム要件として以下が挙げられています。

DX の実践に適しているシステムは、ビジネスモデルやサービスの個々の変化に応じ独立に俊敏かつ安全にアプリケーション/プログラムを更新できるシステムである。
(中略)
機能単位で疎結合に分離・独立しているアプリケーション群をそれぞれ連携させるにあたっては、新規に構築した DX 基盤/アプリケーション、基幹システムそれぞれの負荷にならないよう、密結合させずに 「緩く」連携させる工夫が必要である。

どういうことかというと、

• 先に挙げた(A),(B),(H),(I)の仕組みは独立性を持つ必要がある
• しかし情報の受け渡しの必要があるので、疎結合で連携させよう

ということを言っています。

この役割を担うのが、媒介層(C)/API(F)になります。
疎結合な連携になることで、(C).(F)以外のそれぞれの要素が個別にスピードを落とさず開発・運用できる環境となっていきます。

これを私たちの言葉で表現すると、媒介層(C)がデータ連携基盤であり、API(F)がiPaaSにあたります。

• ※ 伝わりやすさを優先した説明をしているので、全ての局面において正しい説明ではありません。
• ※ APIという言葉はREST APIのことのみを指しているわけではないことに注意。

ここまでの説明を踏まえると、最初に提示した図は以下のようになります。

なぜ"基盤"なのか

たとえばデータ分析基盤がない企業のダッシュボード開発というのは単発のプロジェクトで終わります。
データ連携基盤がないインターフェース開発プロジェクトも同様です。

たとえば誰かが何かの分析をしたいと思い立った時に、稟議書を書いて、決裁もらって、環境を作って、半年のリードタイムがかかります、というのがDXと言えるでしょうか。

何かやりたいときに都度その土台を作っているのでは一向に物事が進みません。
ブログの記事を書こうと思ったときに、記事ごとに最初からHTMLでと考えたらもう書く気なんて起こらないですよね。

ダッシュボードやインターフェースというのはコンテンツです。
コンテンツとそのコンテンツが載る土台を分離して、コンテンツを載せたいと思ったときにすぐ実現できる状態にする、そのためには基盤があることが重要なのです。

基盤とコンテンツに分離するということは、SI開発が長い方にとっては今までと少し違う進め方になります。
まず基盤を作る、その後(または並行して)コンテンツの開発が非同期で複数動き始める。
これが通常のSI開発と違う点であり特徴にもなってきますので、前提知識として覚えておくとよいかもしれません。

企業によってDXの進み具合や、力の入れ具合はばらばらです。
今がどうかというのも大事ですが、どうやってDXを軌道に乗せていくかというロードマップの描き方も重要になってきます。

そういったものを考えるときに便利な枠組みがこれもIPAから発表されていますので引用します。
「DX成熟度レベル」です。

出典: 情報処理推進機構「DX 推進指標 自己診断結果 分析レポート2020年版」

こちらに私の経験則から、アプローチと重視されるものを補記したのが下図になります。

DXの初期段階というのは、ボトムアップの取り組みが主になります。
そして小さくても早く成功例を出すことで、次の取り組みが続くようにすることが重要です。
重視されるものはAgilityです。

一方で成熟度が上がってくるとトップダウンで統制を持った取り組みというのが重要になります。
草の根活動だけでは、業績に与える影響力がどうしても限定されてくるためです。
取り組みが全社にスケールしていくということは、小さな成功例の創出よりもROIなどが重視されてくるでしょう。

統制を持った取り組みにするためには、マネジメント/ガバナンス（ルールや枠組み）の重要度があがってきます。

さて、この説明に何か引っかかりを感じた方はいるでしょうか。
何度も読み返すと、DX成熟度をあげていく過程でパラドックスが発生していることに気が付きます。

• DXの初期段階で、マネジメント/ガバナンス(=ルール作り)ばかりに時間をかけるとアジリティを失ってしまう
• スタートの段階でマネジメント/ガバナンスを無視すると成熟度が上がっていく過程で足かせになってしまう

つまり、いったいルール作りはいつやるべきなんだという問題に行き着くわけですね。
この解決策は次の章で述べますので、まずはルール作りは必要ですがアジリティを失ってはいけないということだけ覚えておいてください。

ここまでで説明してきた基盤の構成要素をスタックとしてまとめると以下のようになります。

基盤があり、その上にルールがあり、コンテンツが重なるという構成ですね。
それが具体的に何にあたるか、というのを右に補記してあります。

ここに弊社がサービスとして提供しているラインナップを重ねると下図のようになります。

これが前の章の最後に述べたパラドックス、つまり、いったいルール作りはいつやるべきなんだという問題への解決策へと繋がっていきます。

DX成熟度をあげていく過程でルール作り(もしくはルールがない状態)が足かせにならないよう、私たちのノウハウから最低限のルールを最小労力で作り上げる。

これを実現するサービスが、私たちの提供している「コンセプトデザイン」になります。

• ※正確にはコンセプトデザインのうちの標準化企画フェーズというフェーズになります

ルールを決めておくことは内製化において重要な成功ファクターです。
無茶苦茶な使い方をされた基盤は問題が頻発してすぐに負の遺産となってしまいます。

データレイヤーと内製化という記事で、Curated data layerなどの整備が内製化には重要と書きました。
当社の内製化の支援サービスの一環である『コンセプトデザイン』は、"技術を直接教える"ことの外側にポイントがあることが多いのです。

• ※技術を直接教える"ことも大事です

現場の最前線にいる私が思う「お客様のDXをリードするために必要だと思う能力・知識」は以下です。

• ① アーキテクトとしての能力
• ② エンタープライズアーキテクチャへの理解
• ③ ロードマップを描く力(ステップを考える力)

①②はわかりやすいですし、デジタルスキル標準を見てもデータエンジニアに必要なスキルと位置付けられています。
一方で③というのはなかなかイメージがし辛いものです。

『コンセプトデザイン』のような考え方はとても大事です。

⇒コンセプトデザインとは（データ連携基盤構築サービス）

最後までお読みいただきありがとうございました。

TOPへ