データ分析基盤が求められる背景
昨今、デジタルトランスフォーメーションの推進や、データドリブンの経営が必要と言われています。それは、IoT、機械学習、AI等を、業務に活用していこうという流れからきています。
こういったビッグデータの処理は、Googleの論文をきっかけに、オープンソースソフトウェア（OSS）であるHadoop/Sparkが牽引をしてきたことは間違いありません。Hadoopが出た当時は革新的な技術であり、現在のDBではできない処理を実施でき、ビジネスに本当に貢献できると思われてました。しかしながらHadoopは、PoCで終了をしてしまうケースが多く、本格的に、データ分析基盤として、システム導入、ビジネス貢献できた例は多くありませんでした。クラウドへの移行も進んでいますが、データ分析基盤を構築できている例は少ないと思っています。各社個別の状況、事情が違うので原因は様々ありますが、主には以下の理由だったと思います。
データ分析基盤を構築するときの課題
目的・目標が不明確
データ分析基盤を構築するときに、真っ先にぶつかる課題は、データ分析の目的・目標が不明確という点です。
取りあえずデータを溜めてから考えるというプロジェクトが非常に多いです。DXや、データドリブン経営とか、IoTとかAIとかのキーワードだけが先行し、弊社も何かできないかを検討して！というような他人事で始まるプロジェクトは上手くいくはずがありません。
なぜ、その分析を実施するのかというプロジェクトの目的が不明確であったり、分析した結果、どこを目標値とするのかが上手く設定できないと、効果が出るかどうかわからず、その後思い切ってプロジェクトが進められないのです。
そのデータ分析は、本当に業務の役に立つのかを証明していかないといけないですし、経営側から、目的のためには実施していくという強い意思がないと、データ分析基盤は構築できません。
最新技術の習得に関する課題
２番目の課題は、新しい技術を覚えるのが困難という点です。データ分析基盤を構成する技術要素としてはたくさんあります。ETLツール、DB、DWH、BIツール等、全ての製品やソリューションを経験して、ノウハウを積んでいくことは不可能に近いです。
外部協力会社で実施できたとしても、社内開発メンバーが習得できる技術でなければ、運用できない。みんなが取り組んで枯れた技術を採用しないと後で苦労をするという懸念が残り、なかなか新しい技術に自ら取り組もうとしていないのです。
Hadoop/Sparkのエコシステム、Kafka、各種クラウドサービスも、リリースしてから数年以上経っても、まだ取り組まれてない企業もまだたくさんいると思います。既存技術に縛られてしまうと、最新の技術であれば、どこまで実現可能なのかも分からなくなってしまいます。技術はどんどん新しく進歩しているので追従をして理解をしていかないと、活用をしている他社に追いつけなくなることが必至です。
業務システムへの影響
3番目の課題は、分析可能なデータが簡単に集まらないということです。データを上手く収集するためには、現行システムに変更を加えないと不可能な場合も多々あります。急に業務システムを変更するのは、運用メンバーの業務負担が大きい場合もあります。現行システムを知ってないと変更容易性も判断できません。現状業務を実施する上で使用しているデータを、他の部署が活用をしようとすると、現状業務にもシステムにも、両方の部門にも負荷がかかります。
業務システム自体が、最初から、その大量データ、複数年のデータを分析しようと思っていなかったため、どういうデータを持つべきだったのか、どうやってデータの移動、型変換、クレンジング等をして使えるようにするかの検討が難しいのです。
企業にとっては、システムを構築する上で、データモデルが最も重要と言っても過言ではありません。
データアーキテクトの必要性
弊社では、基幹業務を支えるシステムをスクラッチで開発するプロジェクトに対して、どうやってシステム開発を効率化し、どうやってビジネスに貢献をするかを考えて常に取り組んでいます。
前段の課題を踏まえて、現在のDXによるイノベーションの実現や、データドリブン経営を実施していくためには、論理的な思考で経営を理解し、全体構造や本質を捉える『モデリング』と、最適な構造に変換する『アーキテクチャー設計』を実行する技術力をもつ、データアーキテクトを育成していくことが、データ分析基盤の構築には必要だと思っています。
論理的な思考と説明能力
ビジネス課題認識と、課題に対するデータ分析による効果の仮説設定を明確にしていく論理的な思考と説明能力が求められます。
データ分析をする目的をしっかりと理解をすること。その目的に対してデータ分析で何を実行しようとするのか？その結果をどう役に立てようとしているのか？そしてデータ分析した結果をどう説明して、関係者に理解を得るのかという活動を継続していくことが必要とされます。後述しますが、データをプロダクトシンキングで推進していくということだと思っています。
技術探求の姿勢
現在のDXによるイノベーションの実現や、データドリブン経営を実施していくためには、 新しい技術や、OSS、更には、クラウドから提供するサービスを、素早く評価・検証をし、利用価値があるか、継続利用が可能かを見極めることが求められます。
現在のクラウドサービスは、特に、H/W側の設定や、バックアップ、2重化等のインフラ面の懸念点を上手くカバーをしています。そのカバー範囲を、ジョブ管理や、ETL、DB、DWHなどのアプリケーション開発の分野にも浸透してきており、現在のシステム開発、運用に、クラウドは欠かせないサービスになっています。
クラウド上で様々な技術を試して評価をして利用する。失敗したら何度もやり直す。また別ソリューションを試す等の試行錯誤をしながら、技術探求をしていく。そういった技術探求の姿勢を持ったエンジニアが求められます。
最低限はユーザ企業の内製化で実施していくこととし、外部のパートナーの技術支援を得て、常に技術ノウハウを蓄積をしていくことが必要です。
業務(ドメイン)のデータモデリング
実際の業務で活用をしているデータを分析しようとすると実業務を知っている人でないとデータの特性がわかりません。業務システムは、そもそも、データ分析をする目的で構築をしていないので、データ形式や型、ネーミング等に不都合があり、すぐに使えるデータにはならないことが多いです。
特性とは、例えば商品コードは一緒でも商品が違うとか、マスターの持ち方をこの時期に変更したとかの事実であり、そういった特性がわからないと正しくデータを扱えないからです。間違ったデータで分析をすると間違った結果になってしまいます。
データ整備は、データを活用するためには最も重要です。しかも、一度整備をしたら終わりでなく、常に変化をし続けるデータモデルを維持していく必要があります。そこで、DDDの考え方を駆使してデータモデリングを実施していくことが必要になります。
データ分析基盤を本格的に構築運用をするためには、業務システム側から、データモデリングをしっかりしないといけないと思っています。
つまり、データ分析の目的・目標を設定し、最新技術を素早く理解をしクラウド等を利用してどうやって実現をするか、また業務を理解してデータモデルがどうあるべきかモデリングをしていく、３つのスキルを持つ**『データアーキテクト』**が求められているのです。
データ分析基盤の構築は、DDDからマイクロサービス開発に繋がる
オンプレミスからクラウドへの移行は、単に、ハードウェアを買うから借りるにチェンジをすることではなく、データ分析の名のもとに、業務ドメインに対して、どういったデータを、システムを持つべきかを考えさせる第一歩になると思っています。
では、クラウドを利用した上でも、具体的には、どんなデータ分析基盤を構築していくべきなのか？ユーザ企業別に、個別事情もあり、様々なシステムも既に導入されていますので、このデータ基盤を導入すべきとは言い切ることはできません。しかし、考え方としては、何か全体的な方向性があるのではないかと模索しておりました。
そこで目に止まったThought works社のプリンシパルコンサルタント Zhamak Dehghani氏の下記の記事は、私のイメージに一番近いと共感しましたので、ご紹介します。
『How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh』
https://martinfowler.com/articles/data-monolith-to-mesh.html
DWHの集中型のアーキテクチャーから、分散型データメッシュのアーキテクチャーにパラダイムをシフトする。その時のデータモデルはDDDでモデリングして、マイクロサービスをクラウド中心に構築をしていく。更に、セルフサービスのプラットフォームが必要で、データ自身をプロダクトシンキングで考えるというマインドシフトが大事なのだと理解しました。
オンプレからクラウドへの移行しながらデータ分析基盤を構築していくこと自体が、モノシリックな業務システムからDDDによるドメイン分析を実施してマイクロサービスアーキテクチャー化をしていく流れに繋がるのではないかと思っています。
株式会社メソドロジック
白石 章 @Akira_Shiraishi