理想的なDataOps組織構造

組織の社外へのコミュニケーションは、社内のコミュニケーションを反映する傾向があります。これはMelvin Conwayが私たちに教えてくれたことであり、データエンジニアリングにも当てはまります。明確に定義されたデータ運用チーム（「DataOps」チーム）がいない場合、会社のデータ出力は入力と同じくらい煩雑になります。

データオペレーションは、データを生成、処理し、維持するためのインフラストラクチャーを組み立てるプロセスです。この作業を行う（または行うべき）チームの名前もデータオペレーション（DataOps）です。DataOpsは何をするのでしょうか?会社がデータ パイプラインを維持している場合、この名前で 1 つのチームを立ち上げてそれらのパイプラインを管理すると、他の方法では欠けている組織化と制御の要素がもたらされます。

DataOpsは、データを販売する企業だけのものではありません。最近の歴史は、データの出所や用途に関係なく、データオペレーションチームが必要であることを証明しています。内部顧客でも外部顧客でも、すべて同じです。パイプラインを構築するには 1つのチームが必要です（実際には継承して再構築します）。このチームは、観測可能性ツールと追跡ツールを実装し、4つの属性にわたってデータ品質を監視するのと同じチーム（あるいは、多くの組織にとっては個人）である必要があります。

そしてもちろん、パイプラインを構築した人々は、ダッシュボードがダウンしたときに悲惨なPagerDutyアラートを受け取るのと同じ人々である必要があります。それは懲罰ではなく、教育のためです。積極的な参加があれば、仕事の進み方は違ってきます。これは優れたインセンティブであり、より適切な問題解決とより迅速な解決を可能にします。

最後に重要なことですが、データオペレーションチームには、単に「データをA地点からB地点に移動する」だけではないミッションが必要です。だからこそ、チーム名の「オペレーション」の部分が非常に重要なのです。

データオペレーションは、データを本来の目的のために動かすための、回復力のあるプロセスを構築することです。すべてのデータは理由があって動かすべきです。多くの場合、その理由は収益です。データオペレーションチームが、営業チームの予測が正確で収益が増えるといった最終目標から、パイプライン管理活動までを明確に追跡できない場合は、問題が発生します。

オペレーションがなければ、規模が拡大するにつれて、次のような問題が発生します。

• データの複製
• 問題のあるコラボレーション
• データ待ち
• 事態を悪化させる応急処置
• 発見の問題
• 分断されたツール
• ロギングの不一致
• プロセスの欠如
• オーナーシップとSLAの欠如

分断が生じている場合は、従来のデータ管理を行っているということです。データ管理は、データオペレーションの定期保守作業です。これは非常に重要なことですが、戦略的ではありません。保守モードでは、欠落した列やパイプラインの障害の原因を探してパッチを適用していますが、計画や改善に費やす時間がありません。

トラブル・チケットを反復可能な修正プログラムに変換することで、あなたの作業は真の「オペレーション」になります。たとえば、パートナーからの変換エラーを見つけた場合、パイプラインに到達する前に修正するようにパートナーにEメールを送信します。あるいは、経営幹部のダッシュボードに「アラート」バナーを設置して、何か問題が発生したときに経営陣に知らせ、更新を待たせるようにします。データオペレーションは、開発者オペレーションと同様に、反復可能でテスト可能で説明可能で直感的なシステムを導入することを目的としており、最終的にはすべての人の労力を軽減します。

これがデータ運用とデータ管理の違いです。そこで問題は、データ運用チームをどのように編成すべきかという点です。

では最初に戻って、システムの出力が組織構造をどのように反映しているかについて見てみましょう。データオペレーションチームが名前だけの「オペレーション」チームであり、ほとんどが保守のみである場合、おそらく、リクエストのバックログは際限なく膨れ上がることでしょう。システムの切り替えやプロセスの調整など、長期的なメンテナンスの変更を行うために一息つく時間はほとんどありません。JiraやServiceNowの応答地獄に陥っているのです。

一方、強力な原則と構造を備えたデータオペレーションチームを設立（または再立ち上げ）した場合は、質の高い内部構造を反映したデータを作成します。優れたデータオペレーションチーム構造は、優れたデータを生み出します。

データ・エンジニア、データサイエンティスト、アナリストをグループまたは「ポッド」に集め、これまでは個別に対応していたであろうことに、一緒に対応してもらいます。必ず、これら3つの視点が、より良い意思決定、偏見を減らし、先見性を高めることにつながります。例えば、データサイエンティストが意味を成さないノートブックを書いて、それをエンジニアに渡してやり取りするよりも、データサイエンティストとアナリストが必要なものについて話し合い、エンジニアがその方法を説明することができます。
多くのデータオペレーションチームは、すでにこのような方法で取り組んでいます。「チームは『フルスタック』として人員配置を目指すべきです。そうすることで、必要なデータ・エンジニアリングの人材がデータのライフサイクル全体を長期にわたって把握できるようになります」と、UberのKrishna Puttaswamy氏とSuresh Srinivas氏は述べています。また、旅行サイトAgodaでも、エンジニアリング・チームは同じ理由でPodを使用しています。

たとえ1人であっても、これを行ってください。それぞれの役割は、誰かが身に着けなければならない「帽子」です。高性能なデータオペレーションチームを構築するには、どの帽子がどこにあるか、誰が何をどのデータ所有者であるかを把握することが役立ちます。各個人の管理範囲を管理可能なレベルまで縮小する必要もあります。このようにグラフを描くと、採用の根拠を示すのに役立つかもしれません。

データオペレーションチーム管理とはポッド構造の上にある調整層で、サーバント・リーダーの役割を果たします。プロジェクトの管理、指導、ブロックの解除を行います。チームの中で最も知識豊富な人材が理想的です。

写真に示すように、私たちは独自の理想的な構造を考案しましたが、まだ作業中です。ここで注意すべき重要な点は、データのビジョンを統率している単一の人物（VP）が存在することです。その下に、そのビジョンに向けてさまざまなデータ分野を導く複数のリーダー（ディレクター）が、その下に、データ組織とデータ機能が確実に連携することを保証する分野横断的なチームがあります。(これらのアイデアは、当社のデータ ソリューション アーキテクトであるMichael Harperによるものです)

目標となるメトリクスを選ぶことで、関係者全員が何を最適化すべきかを理解しやすくなります。そのような同意がなければ、紛争が発生します。社内データの「顧客」は、データが遅いという苦情を言っているかもしれません。しかし、それが遅い理由は、同社の暗黙の願望が第一に品質を最適化することであることがわかっているからです

一般的なDataOpsの目標：データ品質、オートメーション（反復可能なプロセス）、プロセスの分散化（エンドユーザーの自立性）。

目標となる指標を設定したら、その目標を示すサブメトリクスやサブ原則を決定することもできます。これはほとんどの場合、遅行指標となります。

チームを編成すると、チーム内のさまざまなグループが頻繁に交流したり、他のグループに物事を求めたりする必要があります。こうしたやり取りは、非常に貴重なものになる可能性があります。「データサイエンティストとエンジニアが互いの仕組みを学ぶことで、チームはより迅速に行動し、より多くの成果を生み出すことができます」とAgoda社のシニア・エンジニアリング・マネージャー、Amir Arad氏は言います。

Amir氏は、部門間の冗長性に対する隠れた価値の1つは、そのチームの誰も、誰も尋ねようと思わなかった質問をすることです。

「エンジニアリングの知識ギャップは、実に良いものです。簡素化するよう求められるようになります」とAmir氏は言います。「しかし、『なぜそれができないのでしょうか？』と言うかもしれません。時にはそのコードやサーバーも必要ないことに気づきます。時には、専門家でない人が新しいものを持ち込むこともあります。」

DevOpsと同様に、最高のデータオペレーションチームは目に見えない存在であり、常に常に冗長化に取り組んでいます。全員を救うために飛び込んできたがるものの、最終的にはシステムを脆弱にするヒーローをプレイするのではなく、サーバント・リーダーをプレイしてください。Lao Tzu氏が言うように、「それは私たち自身で行った」と考えてもらえるような解決策に導くことを目指しています。

データオペレーションチームを製品チームのように扱います。顧客をよく観察しましょう。修正プログラムのバックログを残しておきましょう。データが実際に使用されるのに十分なほど便利なツールにすることを目指してください。

データのモニタリングとオブザーバビリティーに「早すぎる」ということはありません。監視を避ける口実としてよく使われる例えに、「飛行中に飛行機を製造している」というものがあります。そのビジュアルを考察してみてください。それこそが長期的な生存について知っておくべきことのすべてではないでしょうか？より良い例えは、「平易な古いアーキテクチャー」です。基盤の構築に時間がかかればかかるほど、導入コストもかさみ、基盤が不足していることにより多くの問題が生じます。

関連記事:データ・オブザーバビリティーとは

データ・インフラストラクチャーに関して現在行う決定は、General Maximusの言葉を借りれば「永遠に響き渡る」ことになります。今日は成長ハックだとしても、明日には巨大でデータを変革する内部システムの混乱の悪夢になります。不便であっても正しい決断ができるよう、経営幹部のサポートを確実にする必要があります。たとえば、物事の解決には四半期かかるためリクエストを一時停止するよう全員に伝える、などです。

CASEは「すべてをコピーして盗む（copy and steal everything）」の略で、「すべてをゼロから作らない」という意味の冗談めいた表現です。今日、便利なマイクロサービスやオープンソース製品がたくさんあります。巨人の肩に乗って、実際にカスタムである必要があるパイプラインの40%を構築し、それをうまく実行することに集中します。

バックログにあるチケットを見てみましょう。問題を事前に予防するのではなく、起きた問題に対処する頻度はどのくらいですか？これまでに対処した問題で、根本原因が明確に特定できる問題はいくつありますか？完全に修正できた問題はいくつありますか？先取りをすればするほど、真のデータオペレーションチームに近づいてきます。そして、データ・オブザーバビリティーツールがより役立つことがわかります。完全な可視化は、単に維持するだけから、積極的な改善へ移行するのに役立ちます。

構造を積極的に改善するチームは、データを積極的に改善します。社内の調和は社外の調和をもたらし、そのつながりにおいて、Melvin Conwayは誇りに思っています。

IBMのデータ・オブザーバビリティープラットフォームと、それがデータ・インシデントを早期に検知し、より迅速に解決し、より信頼できるデータをビジネスに提供するのにどのように役立つかについて詳しく説明します。もし詳細をもっと知りたいのであれば、今すぐデモを予約してください。