どのようにデータ基盤を作ったのか？「俺の考えた最強のデータ基盤」は使われない：開発現場に“データ文化”を浸透させる「データ基盤」大解剖（3）（1/2 ページ）

「ゼクシィ縁結び・恋結び」の開発現場において、筆者が実際に行ったことを題材として、「データ基盤」の構築事例を紹介する連載。今回は、「データ基盤」の開発プロセスについてお伝えします。

[横山翔，リクルートテクノロジーズ]

　「使われるデータ基盤」を構築するために筆者が取り組んだ試行錯誤を紹介する本連載『開発現場に“データ文化”を浸透させる「データ基盤」大解剖』。前回はデータパイプラインを支える基盤システム設計について解説しました。第3回となる今回は開発プロセスについてお伝えします。

　なお、技術要素としてはPythonやBigQuery、ツールとしてGitHubやJIRAを扱いますが、他の手段でも代替可能な内容です。細部にとらわれずにご自身の担当する業務や組織に当てはめながら読んでいただければと思います。

「俺の考えた最強のデータ基盤」は使われない

　データ基盤の構築は苦い失敗の経験から始まりました。

　最初の取り組みとしては、オフィスの大型モニターにダッシュボードを投影するところから着手しました。メンバーが毎日のKPIをすらすら言えるようになるかもしれません。メンバーが異常値に気付いて迅速に動けるようになるかもしれません。全員が同じデータを見て、データを基に行動する。そんなデータ駆動組織への進化に期待は高まりました。

　しかし残念ながら、現実はそう甘くありません。たったの1週間で、誰もダッシュボードを見なくなりました。

　必要なのは何だったのでしょうか。基盤構築の長期ロードマップでしょうか。細部まで検討を詰めた企画書でしょうか。圧倒的な予算でしょうか。大規模な開発チームでしょうか。1年間の開発プロジェクトでしょうか。

　仮に、これら全てを用意しても結果は同じだったでしょう。「思っていたのと違った」「良さそうだけど結局使わなかった」――1年後には、そういった声が挙がるはずです。

　結局のところ「俺の考えた最強のデータ基盤」は誰にも使われないのです。

「現場が使う最小のデータ基盤」を積み重ねた

　そこで筆者は「現場が使う最小のデータ基盤」を積み重ねることにしました。ヒアリングを重ねると、業務イメージが見えてきました。

　例えばある部署では、毎朝SlackにKPIのグラフを手動で流しているとのことでした。事務スタッフがデータを出力し、複数のExcelシートに貼り付け、グラフをファイルに出力し、Slackにアップロードする。ビジネス成長に伴って業務が次々と増えていく環境において、工数面の負担は軽視できません。そのレポートを基に広告配信の意思決定を行うため、手動作業のミスで数字に誤りがあるとビジネスへの影響が生じます。

　そういった事情を知って、簡単なスクリプトを組むことで、デーリーレポートを自動化しました。たったそれだけでビジネス的には大きな改善の一歩となりました。すでに使っているのだから、これまでと同様に確実にデータを活用してもらうことができます。

　現場が必要とするデータを軸にして、集計や描画の処理を構築して、パイプラインに取り込みました。このようにして、少しずつ既存業務を置き換えながらデータ基盤を構築しました。

　データ活用の種は現場にあります。業務フローを改善したり、顧客体験を向上させたりするためにデータを活用するのです。何となくデータを集めたり出力したりすればいいわけではありません。業務を実際に担っているのも、顧客と実際に向き合っているのも、現場です。普通のシステム開発と同じで、現場の業務分析から始めることが必要になります。

イテレーションによって要求を段階的に学習する

　特にイテレーションを回すことが大事です。最初に要件を全部洗い出したとしても、現場でのやりたいことは日々変わっていくからです。

• 他社ブログで紹介されている事例を見て、自社でもまねしたいという声が上がる
• 日進月歩の分野なので、新しいBIツールの営業提案が日々寄せられる
• 実際に画面を作ってみたら、「欲しいものとは違った」と気付く
• データを使っているうちに、業務フローが改善されて、別のデータも追加で見たくなる

　これらの例は全て、実際に筆者が現場で体験したことです。自分が本当に見たいデータというのは実際に試してみないと自分自身でさえ分からないものです。

　組織として、システムとして、段階的にデータを活用していく。試してみてダメだったら切り戻す。WebサービスでABテストをするのと同じように、データ基盤もまた小さく試しながら勝ちパターンを磨き込む。「使われるデータ基盤」実現のためには、イテレーションに基づく開発プロセスが必要でした。

優先順位を調整するチケット駆動開発

　イテレーションを高速で回すに当たって、案件は「JIRA」というプロジェクト管理ツールで管理しました。案件チケットの上下を入れ替えることで、状況の変化に柔軟に対応するためです。

　早期の過剰実装を避け、案件規模を小さく保つことによって、管理が複雑にならないように制御しました。過剰要求が積み重なって案件一つ一つが肥大化すると、優先順位の入れ替えができなくなってしまうからです。

　主な案件分類と優先順位は以下の通りです。

【1】信頼性の維持

　「このデータは間違っているのではないか」といった疑惑が上がったときの調査、ならびにクレンジング対応となります。自発的に検知することもあれば、データ利用者からの問い合わせもあります。データを使う人間の心情としては、データが一つでも間違っていると、他のデータも含めて全てが信用できなくなります。そのため案件としては最優先で対応します。すぐ調査、報告することによって、むしろ、関係者の“信頼残高”を増やすことができます。

【2】Modelの追加、改修

　次に優先となるのは、データの項目追加といったModel改修案件です。多少見にくくてもデータを使える状態にすることが優先となります。データが利用可能な状態でさえあれば、どうにか利用者側で見栄えや使い方は工夫できるからです。

【3】Viewの追加、改修

　その次に優先されたのが、グラフの見栄えを調整するといったView改修案件です。現場実務の遂行という観点では、どうしても優先順位が下がりがちになってしまいます。

　ただ、データの利用者にとっては重要な要素で、最もインパクトを与える案件でもあります。また、新しくグラフが表示されるだけでも「変化している」という印象を与えるので、各所との関係構築には寄与します。可能な範囲でサポートするようには心掛けました。

【4】システムのチューニング

　基盤システムの保守性やパフォーマンス向上は最も優先度の低い案件として扱いました。他の案件を推進する上でボトルネックになるようだったら対処します。

　というのも、この手のシステムはいくらでも凝ることができるので、ついつい「速過ぎる最適化」に陥りがちだからです。むしろソフトウェアエンジニアとしては、システムのチューニングで気になるところは、他案件のついでに直すくらいの習慣を付けておきたいと思っています。