DevOpsの3つの道になぞらえてDataOpsの3つの道について語ってみる

##はじめに
私はデータマネジメントのエバンジェリストとして活動する前、前職でDevOpsのソリューションアーキテクトとして活動していました。
そこで本日は、前職のDevOpsの知見を踏まえ、DataOpsについて独自の見解で語ってみようと思います。

##アプリケーション開発のトレンド
まず始めに、皆さんと一緒に、アプリケーション開発のトレンドを少しふりかえってみたいと思います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/7015963d-fc2a-b435-172f-80dc1ae357c3.png)
開発のトレンドは、時代と共に変化してきました。

1990年以前、**最初に決めた計画にいかに従って開発する**かを重視したウォーターフォール開発が提唱され、ソフトウェアエンジニアリングの世界が幕を開けます。
特に日本では、日本IBMが策定したADSG (Application Development Standardization Guide)というアプリケーション開発ガイドを参考とし、多くの大型プロジェクトでウォーターフォール開発が成功を収めることになります。

しかし、2001年以降、アプリケーション開発の世界に新しい風が吹き始めます。
テクノロジーの進歩によってビジネスの変化が早くなってくると、計画に従うことよりも**計画の変化を喜んで受け入れる**アジャイル開発に注目が集まります。
それに加えて、モノ作りよりもコト作り、**継続的な顧客体験の追求が価値に繋がる**ことがわかってくると、顧客に寄り添った開発と運用を実現するDevOpsが多くの現場で実践されるようになります。

そして、HW、コンピューティングリソースの大幅な進歩を遂げた2012年頃から、Deep Learningを基礎としたAIが注目されるようになります。
AIのインプットとなる**データの価値にも注目が集まる**ようになり、DataOps、MLOps、AIOpsというなんとかOpsの言葉も多数登場します。

今、現代のアプリケーション開発は、**データ活用がその中心にある**といっても過言ではないと思います。


## DevOpsの3つの道
DevOpsが提唱される以前、データ利活用を前提としないアプリケーション開発においては、開発チームと運用チーム、運用と隣合わせにいるLOBとの間で、大きく3つの壁がありました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/347e5e6a-a2d9-9664-63d6-b8214661cd7f.png)

* 開発を依頼したけど、納期が遅い
* 最後に出てきたアプリがイメージしていたものと違う
* 待ち時間の長いムダな承認プロセスが多い

そしてDevOpsではこの開発と運用の間の3つの壁を破壊するために、3つの道を実践することが必要とされています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/28a8936b-0ffe-9b16-1565-5f06cb6101ba.png)

* リードタイムの短縮：　CI/CDによって開発スピード向上を目指す第一の道
* フィードバック　　：　運用によって得られた反応を開発に伝達し、開発と運用の乖離を防ぐ第二の道
* 継続的な実験＆検証：　徹底的なムダの排除、組織横断での改善を継続し続ける第三の道

開発チームは、これらの活動を行うことで、この壁を乗り越えていきます。


## DataOpsを阻む3つの壁
一方、データドリブンなアプリケーション開発においても、DevOps同様に開発チームとLOB（運用）を隔てる3つの壁が存在すると言われています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/95a49982-4983-3f30-dedf-57677535e2d3.png)

* データの透明性の壁　　：どこにどんなデータがあり、どのデータがどのビジネスに使われているのかわからない
* データのアジリティの壁：データ利活用のアイディアが思い浮かんでもデータ入手に時間がかかる
* データのサイロ化の壁　：各部門で個別バラバラに管理されてきたデータは部門横断での利活用に使えない

これらの壁を破壊するためにどのような道を歩むべきなのか、対応するお客様事例を紹介しながら一つずつ解説していきたいと思います。


## 第一の道：データの透明性を阻む壁を破壊する
ある国内の通信ソフトウェアサービス業を営む企業様のお話です。
彼らは現在行っているビジネスを更に拡大するため、”全社的な”データ利活用の促進を考えていました。

このイニシアチブの成功には、開発チームが持つデータサイエンスのスキルと、LOBが持つビジネスのスキルの融合が必要不可欠でした。
しかし、相互の理解には大きな壁がありました。
というのも、普段自分が担当してない部門のデータを取り扱おうとした時、開発寄りのデータエンジニアからLOBリーダーまで、あらゆる人がデータにまつわる疑問を抱いてしまい、その解決に多大な時間がかかってしまっていたからです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/702d04a6-bae8-cc32-04ee-7fc6bc0fa0df.png)

そこで彼らは、誰でもすぐに、データにまつわる疑問をセルフサービスで解決できるように、データと関連ビジネスの情報共有に着手します。
データと関連ビジネス、その相互関係を調べられるメタデータのカタログを整備することで、この課題を解決します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/c8a2a716-1faf-5e26-0626-f3485d6c67f7.png)

例えば、DWHへデータの格納を依頼された場合、そのデータのビジネスにおける活用目的は何か、そのデータを集めた時に結んだデータのプライバシー契約は何か、その2つの相互関係を調べることができれば、DWHへの格納有無の判断ができる、というわけです。

これがデータの透明性の課題を解決する、**第一の道：データ×ビジネスの共有**になります。
この取り組みは、開発チームとLOBの間で共通認識、共通言語を生み、データドリブンなアプリケーション開発の活動全体を円滑に推進できる大きなメリットがあります。


##　第二の道：データのアジリティを阻む壁を破壊する
続いて、第二の壁に関係する国内製造業を営む企業様のお話です。
彼らはデータを活用するアプリケーション開発プロジェクトのスピードに悩んでました。

LOBがデータ利活用のアイディアを出したとしても、それを開発チームに依頼すると、「では、2カ月後に対応しますね！」という回答が返ってくる状況でした。
理由は、開発チームの人手が少ないのと毎回のデータ収集に手間を要すること、などが主たる原因でした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/1aaddb1f-355c-7173-8eb0-0648da2dee44.png)


そこで彼らは、この状況を改善し、最短3日で対策をうてるようになることを目指します。
特に、簡単な要件は、LOBのみで計画から対策まで行うことを、彼らは理想の姿と定義しました。

この理想の姿を現実のものにするため、彼らはデータパイプラインの統合、高速化、自動化のアーキテクチャを実現する道を歩んでいきます。
データレイク、DWHに予め再利用可能なデータを貯めておき、それをTableauやMS PowerBIなどのセルフサービスBIツールや、ノーコードのアプリ開発ツールで利用することによって、誰もがセルフサービスで、アジリティのあるデータ利活用を可能とするものです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/7b178244-1aa9-6cdf-72b3-dc0942d39637.png)

これがデータのアジリティの課題を解決する、**第二の道：俊敏×柔軟なデータパイプライン**になります。
この取り組みは、先にご紹介した、データとビジネスの共有の取り組みとセットで推進するとより多くのメリットがあります。
なぜならば、誰もがすぐに、自らの要件にあう再利用可能なデータを探索・理解できるようになり、計画立案のスピードが飛躍的に向上するためです。


##　第三の道：データのサイロ化の壁を破壊する
続いて、第三の壁に関係するコングロマリット企業様のお話です。
彼らは多くの事業を行っており、その事業全体で持つ顧客情報を使って、顧客理解や販売の機会予測を行うことを計画してました。

しかし、当初は全く上手くいきませんでした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/86bf4195-eaeb-18bf-29d2-d246a2a5b870.png)
同じ顧客情報といっても、各事業部の各システムで今まで個別に管理してきたため、電話番号の記載形式や住所の分かち書き等のデータ品質がバラバラだったのです。
無理やり一つのリストに合わせてみても、似て非なる顧客情報だらけで、事業横断で同じ顧客を特定することができませんでした。

そこで彼らは、このサイロ化されたデータの統合に着手します。
次の3ステップを踏むことで、事業横断の統合顧客マスタDBを完成させていきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/6e18f47a-586b-27f9-ac3f-b770e5030536.png)

* 全社統一の品質標準を決めて、顧客情報を集める際、その品質を統一するようクレンジングする
* 顧客情報を一か所に集めて、名寄せし、重複データの排除を行う
* 名寄した顧客情報の中から、最も信頼すべき値を選定し、ゴールデンレコードを作成する

ただし、統合顧客マスタDBを完成して完了、というものではありません。
この統合顧客マスタDBを中心として、各事業部のシステムで個別に持っている取引データを横串検索できるようにしていきます。
結果として、同じ顧客に対して事業横断で、Webアクセス、営業活動などの履歴を把握できるようになりました。

彼らはこの取り組みによって初めて、全社のあらゆる事業で共通した顧客理解を入手可能になり、一貫した顧客体験を提供できるようになります。
そして1to1マーケティングや、販売の機会予測、クロスセルなど、ビジネス上の多くの利益を得ることに成功しました。

これがデータのサイロ化の課題を解決する、**第三の道：事業横断的なデータ品質×マスタ統合**になります。

なお、今回ご紹介したのは、全社的な顧客情報、顧客マスタの統合の例ですが、それ以外にも商品や部品等のマスタデータも同様に統合していく価値があります。
例えば、製造や小売業では、商品やサプライヤー情報も同様に取り組むことで、事業横断でのサプライチェーンの高度化を実現することもできます。


## （まとめ）DataOpsの3つの道
以上まとめると、事例を通してご紹介したDataOpsを阻む3つの壁を破壊する道は、以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301774/d23bbeca-44e8-fd80-cd36-cfe7173c6773.png)

* データ×ビジネスの共有　：データのまわりの透明性を確保し、IT部門とLOBのコミュニケーションを円滑にする第一の道
* 俊敏×柔軟なデータパイプライン　：必要なデータをアジャイルに分析・利活用へと繋げるデータパイプラインを入手する第二の道
* 事業横断的なデータ品質×マスタ統合　：サイロ化されたデータと品質を改善し、全社的なデータの組合せと利活用を可能にする第三の道

今後皆さまがデータドリブンなアプリケーション開発を実践し、DataOpsに取り組んでいく際には、この3つの道をぜひ歩んでいっていただければ幸いです。