DataOpsチームを作る
DataOpsというキーワードが注目されています。DataOpsとはなにかについては、別の記事でご紹介していますが、DataOpsをはじめるうえで、どのようなメンバーを構成すればよいでしょうか。本記事では、人に焦点を当てて、DataOpsのチーム作りに関して重要なポイントを紹介していきます。
本記事では、以下を参考に執筆を行っております。
(参考元：Nik Bates-Haus “Chapter 7. Embracing DataOps: How to Build a Team and Prepare for Future Trends.” In Getting DataOps Right, edited by Palmer, Andy, et al., 13-27. Sebastopol, CA: O’Reilly Media, Inc., 2019)
目次
DataOpsチームを作る前に理解すべきこと
DataOpsチームは、これまで断片的だった多様なデータソースからのデータを統合し、価値を創造したりユーザーが実行可能な洞察を得られるようにするような高品質なリソースに変換します。
DataOpsの実践において重要な視点は、データエンジニアリングチームを「データをソースAからレポートBに移行させる技術チーム」と捉えず、「アジャイル開発手法を採用してデータアプリケーションを迅速に構築するソフトウェア開発チーム」と捉えることです。
そのためには、組織内に存在する、あるいは存在しないスキルの組み合わせが必要です。また、新しい機能を体系化し、それに応じたリソースを提供する組織構造も必要です。
まず、DataOpsチームにおける主要な機能を特定することから始めます。ソフトウェア開発に対するDevOpsアプローチが既存の開発チームやツールを再構築したように、DataOpsの手法でも従来とは異なるスキルセットや作業プロセスが要求されます。
機敏性と継続的な反復に重点を置き、データソースや需要が絶えず変化する中で強固なデータ基盤を構築・維持するためには、多くのコラボレーションが必要になります。
今回は例として、仕入先データを例にして、これらの機能のうち、データの提供、データの準備、データの利用の3点について見てみましょう。
DataOpsチームと人材
データの提供
- 社内の仕入管理システムは誰のものですか？
- 外部の仕入先や仕入データとの関係を所有しているのは誰でしょうか？
仕入れ管理システムを管理し、データを所有（管理に対して責任がある）のは、情報システム部門の担当者です。
さて、データの活用における変化が進んでいます。具体的には以下があげられます。
- データベースのビューやSQLクエリから、データの仮想化とAPIへの移行
- ER図やデータディクショナリーから、NoSQLのようなデータベースの構造を定義しないスキーマレスストアやリッチなデータカタログへの移行
これらを考える上では、データソースへの見つけやすさや管理性といった要素に加えて、機密データへのアクセス制御に対する要件も考慮が必要です。
DataOpsの世界では、データソース所有者は、部門やデータエンジニアと協力して、ビジネスユーザーがすべてのデータを活用できるように、必要なインフラを構築する必要があります。
データの準備
データを利用するビジネスユーザーにとっては、データベースの実装やデータソースの場所ではなく、論理的なエンティティ（今回の場合、仕入先データ）が重要です。
そのため、利用可能なすべてのデータソースから生のデータを組み合わせ、重複を排除し、価値ある情報で充実させ、簡単にアクセスできるデータを準備してくれる人が必要となります。
効果的なデータ準備には、生のデータを扱う技術的なスキルと、データの活用方法に関するビジネスレベルの理解の組み合わせが必要です。
DataOpsは、従来のデータ準備を、データソースからデータマートやデータレイクにデータを移動して変換するデータエンジニアは言うまでもなく、分析やデータソースの品質とガバナンスを担当するデータスチュワード(データ資産の管理人)やキュレーター(大量の情報を収集・整理し他のユーザーに共有する者)にまで拡大します。
最高データ責任者(CDO)は、データ利用者が高品質で精緻なデータにアクセスできるようにする責任を負います。
データの利用
データ・サプライ・チェーンの「ラスト・マイル」では、分析部門と業務部門にまたがるさまざまな成果を得るために、統一されたデータを利用する担当者が存在します。
「ラスト・マイル」とは、あるプロセス、特に顧客が商品を購入する際の最後のルートおよび段階を指します。DataOpsにおける「ラスト・マイル」とは、データの提供者とデータの利用者との間の区間であると言えます。
仕入先データの例では、データアナリストが各仕入先の支出総額をグラフ化したダッシュボードを作成し、データ サイエンティストが在庫最適化モデルを作成し、データ開発者はあらゆる人がアクセス可能な仕入先ポータルサイトを構築します。
最新の可視化・分析・開発ツールにより、データ利用者は、従来のビジネスインテリジェンスツールやデータマートの製品特有の制約から解放されます。しかし、データ利用者は、データセット提供チームと今後も、密接に連携する必要があります。
DataOpsの世界では、これはフィードバック循環の実現を意味します。データの問題が発生したときに、単純に単一のダッシュボードで修正するのではなく、チームでの協業により実際の根本原因を明らかにし、データコミュニティ全体で最適な修正を実施します。
DataOpsのチームメンバーはどこにいるのか
DataOpsチームを作り上げる人材は、多くの場合、社内外の人材の組み合わせが必要になります。また、これらの役割の中にはまだ発展段階のものもあり、業務内容を定義する「ジョブ・ディスクリプション」がないことに注意を払う必要があります。
データ提供者ですが、社内のデータソースの所有者を指名し、彼らが誰であるかを組織の他のメンバーに伝える必要があります。
データカタログには、各ソースへのアクセスに責任を持ち、各データソースの品質に関する問題の主要な連絡先となるべきユーザーを1名登録すればよいでしょう。
技術的なスキルとデータ管理、そしてデータのビジネス要件への理解について、1人ですべてを理解していることは稀なので、データ準備には多くの工数がかかってしまいます。
そこで、データエンジニアリング/ETLチームの中で、最もビジネスに精通したメンバーと、ビジネスチームの中で最も技術に精通したメンバーを探し出し、ペアを組ませることが必要です。そして、データの利用者と協力して、必要なデータパイプラインを構築することに着手してもらいます。
- データパイプラインとは、API、SQL・NoSQLデータベース、ファイルなどのさまざまなデータソースから生データを取り込み、データレイクやデータウェアハウスなどのデータストアに移行して分析する手法を指します。
このパイプラインを構築できるチームを特定したら、今度パイプラインから出力されたデータのオーナーを決めます。
次はこの質問に対する回答が必要です。
- この新しいデータソースの品質とガバナンスの主要な利害関係者は誰か？
- データの使用方法について十分に知っているのは誰か？（データ品質向上とガバナンス強化のために把握しておく必要がある）
この答えとなる人物はすなわち、データ資産の管理人であるデータスチュワードです。
次に、データカタログをメンテナンスする責任者がいれば、それをすなわちチームに参加すべきデータキュレーターとなります。
DataOpsの目標は、データ利用者が、必要な有用なデータを入手するための困難な作業に邪魔されることなく、解決したい分析や運用上の問題に集中できるようにすることです。
優秀かつ高額の人件費が必要なデータサイエンティストを何人か既に雇っており、さらにこれから雇いたいと考えていたとしても、彼らが本来行うべき高度な作業（分析モデルの構築など）ではなく、データの基本的な操作に大半の時間を費やしているとしたら、誰もが不幸となります。
DataOpsの堅牢なデータ・サプライ・チェーンがあれば、熟練したユーザーを本来の業務に専念させることが可能です。データアナリストやその他のユーザーの生産性が向上するだけでなく、データを実際に使用して変革的な成果を上げることができるユーザーも拡大します。
まとめ
DataOpsのチームを作り上げる上で、適切な人材を見つけ適切な領域に配置することはもちろん重要なことですが、それらの人材が力を発揮するための土台となるツールも重要となります。
DataOps/クラウド型ETLサービスであるReckoner は、ユーザーにとって利用しやすいインターフェースおよび信頼度の高いインフラ環境において、データエンジニアリング/ETLチームメンバーからエンドユーザーまで活用が可能なETLツールを提供しており、DataOpsのチームの力を発揮するためのツールです。
また、ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。
