「DataOpsとは、ソリューションの実現、データ製品の開発、データのアクティブ化によって、インフラストラクチャからエクスペリエンスに至るすべてのテクノロジー階層でビジネスの価値を実現する機能です」
産業向けDataOpsの原則
目次
ここからは、産業向けDataOpsの斬新なアプローチの核となる原則です。この章では、データから最大限の価値を引き出す途上で指針となる必須の概念を分かりやすくご説明します。この記事をお読みの方の中には、DataOpsの一般原則(非常に優れた DataOps Cookbook に示されている原則など)の長いリスト(図10)に精通している方もいるかもしれません。また、進歩的なテクノロジーコンサルタント会社が提供するDataOpsの詳細な評価基準(図11)もご覧になっているかもしれません。
DataOps関連の一般的な資料のほとんどが有用な背景情報を提供しているのに対し、本書は重厚長大産業の組織がデータを運用化して価値を引き出せるよう支援するために、具体的かつ実践的な指針を提供することを目的としています。
弊社が注力しているのは産業向けDataOpsであるため、ここでは、まさに産業オペレーションに注力しているデジタル化のリーダーの観点から原則を説明します。
産業向けDataOpsの7つの原則
1.PoCを実施しない
CFOにとって、PoCは価値がありません。開始するデジタル化のユースケースはすべて、コードの記述を開始する前に、本番環境で大規模にライブ実行されるよう設計しておく必要があります。
PoC地獄は、ほとんどの人が経験したことがあります。人によっては今まさにその状態にあります。その理由は容易に理解できます。近年、産業企業の利害関係者全員(特に公開市場、同業他社、業界誌)にデジタル化のユースケースを示すという、善意からの(ただし、場合によっては強迫的な)ボトムアップ型兼トップダウン型の取り組みが見られます。
残念ながら多くの場合、本当に重要な価値である本番環境での運用デジタル化ソリューションが提供される代わりに、分かりやすいデジタル化の紹介が優先されるという結果になっています。短期間でのデジタル化の成功という錯覚が、正真正銘の本番環境での成功を妨げているのです。
この状況で留意すべきことは、PoC自体が悪いものではないということです。運用のスケーリングの前にユースケースを検証することは、理に適っています。運用のスケーリングが全体的なデジタル化の枠組み、テクノロジーアーキテクチャ、および実行されるプロセスに組み込まれていない場合に、課題(およびその結果として起こる実際の価値獲得の失敗)が生じます。つまり、PoCを終える前に、実行アーキテクチャで、理論上のROIの可能性だけでなく、運用上の本番環境のスケーリングを考慮する必要があるのです。
産業向けDataOpsのベストプラクティスに根ざした体系的なプラットフォームアプローチに従い、デジタル化のユースケースを実施します。これにより、企業はPoC地獄のサイクルから脱却し、本番環境に大規模にもたらされるユースケースのイノベーションに注力できます。
「DataOpsとは、ソリューションの実現、データ製品の開発、データのアクティブ化によって、インフラストラクチャからエクスペリエンスに至るすべてのテクノロジー階層でビジネスの価値を実現する機能です」
2.データ製品で考え、データドメインで実行する
大規模に、そして重要な運用の場合に、データを運用上有用なものにするには、そのデータを製品化する必要があります。データを製品化するには、いきなり企業規模のマスターデータ環境を相手にするのではなく、最初は最も価値のある運用・制御データのドメインに注力します。
クラウドデータストレージの進歩と柔軟性のある処理によって、我々は、企業内および企業周辺のすべてのデータ利用者が常に安全なデータにアクセスできる初期の時代へと押し出されています。それでもやはり、同様の大きな変化に対するニーズが依然として急激に高まっているのが、対象のデータドメインに関するビジネスの専門知識を踏まえた、データエンジニアリングとデータ管理の部分です。
データ可用性から、このようなサービスとしてのデータ製品(図13)に移行してこそ、データスワンプを実際のビジネス価値を生み出す運用・制御データアーキテクチャへと変換できるようになります。
サービスとしてのデータ製品の提供にうまく移行したいと考えている組織は、データ製品の所有権の変化を受け入れる必要があります。必要な移行とは、一元化されたデータチーム(デジタルまたはデータのセンターオブエクセレンス(CoE)など)から協力的な組織への移行です。この組織では、主要なビジネスツールでデータを生み出している各事業部門が各データドメインを共同で所有します。
結局のところ、コンテキストにおけるデータを最もよく理解しているのは業務運用チームです。したがって、業務運用チームは、他のデータ利用者にサービスとしてのデータ製品を伝え、提供する、最適な立場にあります。
データ製品とは何か、そしてサービスとしてのデータ製品のモデルを定義づけるものとは
1. データ製品はチームスポーツ
データチームはデータを使用して特定の問題に取り組むために、業務運用チームと連携します。
2. 所有権とサポート
データ製品には、所有者、サポート、サービス品質保証(SLA)、および明確な定義があります。
3. 責任共有モデル
データ製品には、データエンジニアだけでなく、データドメインのチーム全体に基づいたSLAがあります。
4. 双方向性
サービスとしてのデータ製品の流れは双方向であり、データドメインのチームから会社、会社からデータドメインのチームへと流れます。
5. 特定分野の専門知識の融合
特定分野の専門知識がデータ製品自体に直接統合されます。
6. 未処理データだけでなく、データの洞察を提供
データ製品チームのメンバーは、データ製品について他者よりも多くのビジネス機能の経験を持っており、行および列とは別の洞察を提供する責任があります。
7. 信頼性ある高品質のデータを重視
サービスとしてのデータ製品によって、価値を重視するサービス指向のビジネスパートナーシップと、信頼性とデータ品質を重視する製品指向のSLAとが融合します。
産業向けDataOpsの実装を成功させるには、従来の一元化されたデータアーキテクチャからドメインデータアーキテクチャ(データメッシュ)に移行することが不可欠です。これにより、一元化されたモノリシックなデータレイクおよびデータウェアハウスに関連する課題の多くが解決されます。目標は、データの行と列を提供することではなく、ドメインベースのサービスとしてのデータです。
ドメインデータのアーキテクチャが機能するために、データ製品の所有者チームは、データが発見可能で、信頼でき、自己記述型であり、相互運用可能であることを確認する必要があります。また、安全で、グローバルなアクセス制御によって管理されていなければなりません。つまり、データ製品をデータとしてではなく、サービスとして管理する必要があります。
3.データが人間の言葉を話す必要がある
データから価値を生み出せるかどうかは、より多くのデータを収集することではなく、データコンテキスト、そして業務運用におけるデータ利用者の解釈可能性によって決まります。
データ量、速度、多様性、価値創造への期待の急激な増加に直面し、企業は大小を問わず、さらに良いデータ利用者となる(あるいはもっとデータに詳しくなる)ために従業員のスキル向上を急いでいます。Gartnerはデータリテラシーを公式には「置かれた環境や状況の中で、データを読み、書き、伝える能力」と定義し、もっと砕けた場面では「データを話せますか」と表現しています。データリテラシーには、データソースおよびデータ構造の理解、データに適用される分析方法および手法、ユースケースの適用とその結果として生成される価値を説明できる能力が含まれます。
産業においては、生産とメンテナンスのデータ利用者(産業用AI革命の最前線にいるデータ利用者)の大半が、ドメインおよびドメインデータに関する詳細な専門知識を持つ特定分野の専門家（SME）です。ただし、この専門家はデータエンジニア、データベーススペシャリスト、ソリューションアーキテクトではありませんし、無理にそうなる必要もありません。
データリテラシーを大規模に、そして全データドメインにもたらすには、我々のデータ管理インフラストラクチャが難局に対処し、新しいデータ利用者の高まる需要に対応する必要があります。産業向けDataOpsの核心にあるのは、この事実に対する承認です。
この根本的な真理の認識が深まっています。調査によると、ITおよび運用を担当する産業界のリーダーの79%が、データは特定分野の専門家（SME）のサポートがなくてもデータ利用者が理解できるほど、分かりやすいものでなければならないという点で意見が一致しています。つまり、データが人間の言葉を話す必要があるのであって、その逆ではありません。
「データに価値があるのは、事業部門がそれを信頼し、使用するからです。成功要因と、これらの期待を満たす能力の測定方法を定義するために、CDOおよびデータスチュワードには事業部門と連携する責任があります」
Forrester
このレベルの真のデータリテラシーを実現するには、データ製品で考え、データドメインで実行することが極めて重要です(前述の原則2を参照)。
AIで強化されるアクティブなメタデータキュレーションを全面的に利用することも同じく重要です。神経言語プログラミング(NLP)、光学式文字認識(OCR)、コンピュータービジョン、訓練されたオントロジー、グラフデータモデルを活用することで、IT/OT/ET/Xデータの自動的なコンテキスト化がますます促進され、人間による直感的な、またはプログラムによるデータの発見と使用が可能になります。
産業がメタデータへの投資から獲得するリターンは、データ自体への投資よりも10倍高くなります。
メタデータは「他のすべてのデータポイントの使いやすさ、分かりやすさ、実用性、機能性の強化に使用されるデータ」と定義できます。Gartner (2021).The State of Metadata Management:Data Management Solutions Must Become Augmented Metadata Platforms.[2021年3月26日]
4.ビジネス技術者がデータヒーロー
データ顧客ターゲットのペルソナを持つデータプロダクトマネージャーはビジネス技術者であり、データエンジニアではありません。真のデジタル化が起こるのはデジタルCoEの外であり、ビジネスとテクノロジーの新しいタイプのハイブリッド(ビジネス技術者と呼ばれます)のアクションによる、中核的な業務運用の中で起こります。これらの業務分野の担当者はすでに、セルフサービスの発見と複数ソースのデータオーケストレーションをサポートする産業向けDataOpsの機能が欠如していることに、しびれを切らしつつあります。
このような機能によって、優れた意思決定を行い、競争力を高めることができます。同時に、産業向けアプリケーションの開発者はAPIを使用して現代のクラウド-エッジ間のマイクロサービスアプリケーションを構築するために、信頼性ある、一貫したリアルタイムのデータを切望していますが、これらのデータは業務運用内に存在することがあまりにも多くなっています。
ビジネス技術者などの新しいデータ利用者ロールの数が増えるにつれて、企業のIT部門では直感的なサービスとしてのデータ製品に対する、さらに高速で自律的なアクセスを実現する必要性が高まっています。
事業ドメインへのセルフサービスの権限付与は、当然ながらITのビジネスにとって朗報であり、ドメインデータ製品のコラボレーターに魅力的な新規採用ルートをもたらします(前述の原則2を参照)。
当然ながら、産業向けDataOpsプラットフォームだけでは十分な答えになりません。ビジネス技術者が産業データ利用者の次のセグメントへの道を開いている場合でも同様です。エンタープライズデータダッシュボードとローコードアプリケーション開発の機能で補完する必要があります。幸い、現在はどちらも産業全体ではるかに容易に入手できるようになっています。
最後に、IT部門と事業部門全体で信頼と協力関係を構築するには、運用の専門家を「シチズンデータサイエンティスト」と呼んではなりません。彼らは特定分野の専門家（SME）です。また、ドメインデータ製品の配布およびビジネス技術者の擁護のための最良のビジネスパートナーである可能性もあります。「シチズン」ではありません。
出典: Gartner 2020 Digital Friction Survey (2,015名のビジネス技術者)
5.指標としての自律型産業
産業向けDataOpsの目指すところは自律型産業であり、ユニバーサルデータの可用性でもなければ、さらに優れたデータエンジニアリングでもありません。
産業向けDataOpsは適時で現在価値があるだけではありません。将来の基盤となるデータインフラストラクチャなのです。その理由は、提供されるデータドリブンの運用機能が、自律型産業の目標であるインダストリー4.0の約束の達成にも同様に必要だからです。
これが常に、指針となる目標、つまり真の指標になります。
図16は、産業向けDataOpsの機能が自律型産業に向けた産業変革の行程にどのようにつながっているのかを示しています。
産業向けDataOpsの強固な基盤がなければ、データ、データモデル、およびデータドリブンの推奨事項の信頼性は低いままであり、第1または第2レベルのデータドリブンの運用改善を超えて進歩することができなくなります。
クローズドループのインテリジェントな生産システムを指標として用いた完全自律の意思決定の場合は、すでにかなり進行した状況で我々に道を切り拓いていますが、ほとんど同じ核となるテクノロジー機能が必要です。
産業向けDataOpsは、単なるレポートデータからデータドリブンの運用までのキャズムを乗り越える鍵となります。
- 既存のデータを視覚化し、コンテキストの中で正しく理解できるようにします。
- ユーザーはグラフ、ダッシュボードを利用して情報を解釈し、利用可能なデータに基づいて適切な意思決定ができます。
- 既存のデータの価値を高め、実行可能なアドバイスが付属する推奨モデルを作成します。
- 既知の式のシンプルな実装から、異常検出および機械学習まで。
- 人間が出力を評価し、推奨事項に基づいて条件を満たした意思決定を行います。
- アドバイスは、定義されたプロセスを介して適切なペルソナに届けられます。
- 差し迫った問題および続行する方法に関するアドバイスが、ユーザーに表示されます。ペルソナベースのコンテンツは仮想アシスタントを介して伝えられ、ステータスと実行可能な次のステップを提供します。
- 選択したシステムとモデルを直接統合して、自動のアクションをトリガーします。
- 人間による介入のないクローズドループの統合を有効にします。
6.古いテクノロジースタックが機能しない
エグゼクティブサポート、変革の思考様式、従業員のスキル向上すべてが必要です。ただし、適切な新しいツールがなければ、効果は発揮されません。
企業環境全体に影響がありますが、AIやクラウドコンピューティング、安価なデータ収集などのテクノロジーの破壊的な潜在力は、現在多くの産業分野に非常に大きな影響を与えています。これらのテクノロジーは伝統的に、厳しい規制、新たな競合の脅威が低いこと、および極端な資本集約度による破壊の影響から切り離されていました。今後はそうではなくなります。電力・ユーティリティはおそらく最大の破壊を経験している分野です。組織は、ESGおよび活動家の資本配分、社会でのサステナビリティの圧力、再生可能エネルギー、分散型エネルギー資源(DER)、電気プロシューマーの増加といった破滅的な事態に直面します。
さらに悪いことに、電力・ユーティリティ分野は非常に時代遅れのソフトウェアテクノロジーアーキテクチャに大きく依存しています。このアーキテクチャは、主として静的環境でのクローズドな現場レベルの制御用に設計されたものです。調整するだけでなく、目標を達成するために、エネルギー企業は次世代のデータおよび分析のアーキテクチャを積極的に再検討しています。絶え間ない変化、コラボレーション、リアルタイムのデータ、およびイノベーションによって定義されるように設定されたアーキテクチャです。
このような重大なビジネス環境とテクノロジーの変化にもかかわらず、新しいソフトウェアテクノロジーが果たすべき役割が軽視され、次のような一般的な経営陣のフレーズが使用される傾向にあります。
「テクノロジーは容易に入手できますが、課題が残るのは変更管理と人々の組織です」
「テクノロジー面への対処を開始する前に、文化的変化の影響に対する徹底した評価と計画が必要です」
文化的変化および思考様式がテクノロジーよりも優先されるべきという考えは単純に当てはまりません。我々の産業を混乱に陥れている変革のイネーブラーはすべて著しくテクノロジー主導であるため、テクノロジーから開始する(または、最低でも同時に対処する)必要があります。エグゼクティブサポート、変革の思考様式、従業員のスキル向上すべてが必要です。ただし、適切な新しいツールがなければ、効果は発揮されません。実行するためのツール(変革の具体的な原動力)なしでプロセスまたは行動を変えることは、単純にあまりにも抽象的で、特にエンジニアリングの思考様式から乖離しています。実際、テクノロジーの破壊はテクノロジーから開始します。
では、産業向けDataOpsに力を与える適切なテクノロジースタックをどうやって見つければ良いのでしょうか。ドメインデータの利用者向けのデジタルプラットフォームで提供されるべき主要機能を図15にまとめます。
産業向けDataOpsソフトウェアの正式な評価と選定に役立つ質問を付録(産業向けDataOps RFPガイドライン)に一覧でまとめてあります。この付録は、ユースケースおよび過去の成功事例から、ソリューションアーキテクチャ、セキュリティ、ソフトウェアのメンテナンスに至るまで、考慮事項全般を詳細に網羅しています。提案依頼書(RFP)および類似の調達プロセスをサポートする完全なガイドおよびツールキットとしてご利用ください。ここでは、5つの重要な質問を抜き出して解説します。
産業向けDataOpsのソフトウェアを購入する前に産業企業が質問すべき5つの質問
産業向けソフトウェアでは、ITと運用の領域の分かれ道にホームがあります。ソフトウェアを購入すると、両方に影響があります。つまり、双方のニーズと要件を明らかにすることが不可欠であり、ソフトウェア調達プロセスの間中、双方に対して常に情報を提供し、関与させ、調整する必要があります。
現在抱えている特定の問題を解決するためにソフトウェアを購入しようとしているのかもしれませんが、重要なのはもっと大きなことを考えることです。ガスタービンの予測分析であれ、現場の特定の油井に対する生産の最適化であれ、単一のユースケースを解決するソフトウェアは、修正が容易です。
しかし、複数のタービンや、複数の現場での数百という油井を含めるようスケーリングするソフトウェアは、完全に別物です。購買プロセスにおいては、新たに出現しつつあるニーズ、さらには1、2年先のことまで見据え、このソフトウェアが自社の要件を満たすものであるのかをよく考えることが重要です。
ソフトウェアの場合、まさに「百聞は一見にしかず」です。PowerPointのスライドと才能ある営業部員によって、非常に多くのことが分かります。デモを見れば、この種の現実の証拠をリクエストするのは出過ぎたことではなく、テクノロジーの利点を体験してみるために必要だということが分かります。
厳しい現実ですが、現在入手可能なソフトウェアでニーズを完全に満たせるものはありません。すぐに使えるソフトウェア製品で満たせるニーズは約80%です。
これではすべての要件がカバーされない可能性がありますが、忘れてならないのは、適切なソフトウェアパートナーを持つことで、5つの要件のうち4つが6か月以内に満たされるということです。
これは「完全な」解決策(おそらく存在しません)を求めて待つより、あるいは、いつまでもメンテナンスが必要となる社内での完全オーダーメードの何かを構築するよりも、断然良い選択肢です。これには、要領よく適応する力と、ソフトウェアに関して「十分に良い」を目指す意欲が必要です。時間の経過とともに、また想定よりもおそらく早く、「十分に良い」から「形成を一変させる」へと進展します。
ソフトウェアの価格設定はポンプと同じではありません。まったく異なるアプローチが必要です。ソフトウェアは製品であり、そのようなものとして価格設定されます。経験のレベルに基づいて時間で請求されるのではありません。製品の価格を把握した後は、将来のニーズが確実に生じるはずなので、スケーラビリティについて尋ねます。組織の残り全体にわたってソリューションを拡大する準備ができたら、後段階での摩擦をなくす価格モデルについてベンダーと話し合います。必須の質問および条件の完全なリストについては、付録(産業向けDataOps RFPガイドライン:評価に役立つ質問)を参照してください。
7.品質が命
スピードは重要です。しかし、脆弱なソリューションを実行した結果、生産に失敗するようであれば、単純に産業では使いものになりません。
2014年、Facebookでさえも開発者向けのモットーを「Move Fast and Break Things (すばやく動いて破壊せよ)」から「Move Fast With Stable Infra (安定したインフラですばやく動け)」に変えました。Facebookは、急ぎすぎるあまり、どこへ向かっているのかはっきりと分からなくなることを危惧したのです。Mark Zuckerberg氏は 「我々が時間をかけて悟ったのは、他者よりもすばやい行動が役に立たないということです。なぜなら、バグの修正のためにスピードダウンしなければならないので、スピードが改善されなかったのです」と語っています。
こうした慎重さは、デジタルテクノロジーの巨大企業の世界では斬新なものだったかもしれませんが、産業界においては十分に確立された必須事項です。重厚長大産業全体において、あらゆる重要な要因が意味しているのは「早い段階で失敗する」というモットーが適切なことはめったにないということです。
これらの要因には、世間への深刻な影響と長期化するイメージ悪化をもたらす目につきやすい失敗およびサービス停止のリスク、機械類および装置のコスト、従業員の健康と安全、環境への潜在的な影響などがあります。
「データを信用しない限り運用化はできません。何かが失敗した場合に監査能力を提供できなければ、産業としてはおしまいです」
Aker BP社、デジタルオペレーションマネージャー
ソフトウェア開発とデータエンジニアリングの時代のほぼ全期間(産業組織がサービスを受けている期間と比較して短い方)にわたって、スピードと品質は対立する概念でした。これが特に当てはまるのは、リアルタイム環境で複雑なデータ依存関係を扱うときです。バッチおよびストリーミングデータのソース全体にわたって信頼できる/安全/観察可能なデータパイプライン、および開発中のユースケースに適合する実用的データ品質は、長い間熱望されてきましたが実現できていません。いずれにせよ、スピードが著しく犠牲になります。
産業向けDataOpsを使用する組織は、品質とスピードを両立するために、ソリューションのコンテキストを最もよく理解している開発チームに、リスクとデータ品質の直接的な責任を移します。このアプローチによって、遅く、融通の利かない、高価で一元化されたマスターデータ管理の代わりに、アンビエントなデータガバナンスが有効になります。
産業向けDataOpsを使用する組織は、データ品質スペシャリストではなくビジネス技術者で構成される開発者チームにとって、ユースケース関連のデータ品質制御が容易になるようにする必要があります。つまり、産業向けDataOpsのツールの中でも、事前に構築され、自然なアプリケーションデータテンプレート定義フェーズに直接適用しやすい、最も一般的なデータ品質モデルを提供するツールを探すことです。
「IoTソリューションの多様かつ分散型の性質は、ガバナンスに対する従来の画一的で制御指向のアプローチだけでは不十分であることを意味しています。各組織には、さまざまなタイプのデータおよび分析に対応するさまざまなスタイルのガバナンスを適用する能力が必要です」