データ基盤

本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。 様々な企業でデータアナリティクスチームが新しく設立されています。データを活用して大きく成長する企業があれば成果が出せずにチームを解散させる企業もあります。両者の違いはなんでしょうか。その答えの1つは組織の関係性です。本記事では事業を成長へ導くためにデータアナリティクスチームを社内で信頼できるパートナーに育てるべきだという話を紹介します。 失敗するデータアナリティクス部門 データの活用が大きく注目されてから数年が経ち、多くの企業で社内外のデータを分析し自分たちのビジネスに活かすため新たにデータアナリティクスチームが創設されてきました。分析者の採用は活発化し関連する設備への投資は盛り上がりました。一方で、チームを作り人材も設備も用意されたというのに成果が挙げられずデータアナリティクスチームの閉鎖や縮小、企業内での立場が弱くなるという結果になっています。なぜ、このようなことになってしまったのでしょうか。 データの活用に実は価値がなかったのでしょうか？いいえ、そんなことはないはずです。実際にいくつかの企業ではデータを活用し大きな成長を遂げています。では、成功した企業と失敗した企業では何が違ったのでしょうか。この質問に対する答えは無数にあります。すでに多くの例がインターネットや書籍に書かれています。良い人材を採用できなかった、解くべき課題が立てられなかった、現場が協力を拒んだ…など様々です。 この記事で紹介するデータアナリティクスチームを成功させる秘訣は事業部とのパートナーシップを強化し並走することです。事業部からの依頼をこなすだけの下請け組織からの脱却であり、共に事業を成長させるための頼れる専門家集団への進化です。 下請け化がもたらす弊害 まずはデータアナリティクスチームの下請け化という現象について解説します。多くの企業では事業部がビジネスを営んでおり支援組織としてあとからデータアナリティクスチームを設立することが多いです。そのため、組織内の力関係として事業部本体のほうが強くデータアナリティクスチームが弱い立場になりやすいです。 データアナリティクスチームの立ち上がりの初期は事業部に対するドメイン知識が不足しています。一方で事業部側にはデータアナリティクスの知見が不足しているでしょう。そのためデータアナリティクスチームが事業部が知りたいことをヒアリングして具体的な分析方法はチームに一任されるという依頼ベースの仕事の進め方になっていきます。 このようにして事業部が主導権を持っている状態が常態化すると次第にデータアナリティクスチームは事業部の下請け組織となっていきます。事業部に言われるがままにデータ集計や分析を行うだけの状態です。この状態が長く続くといつまで経っても事業部とデータアナリティクスチームの間にシナジーが生まれず生産性は上がらないどころかむしろ下がっていきます。 なぜ下請け状態になると生産性が下がってしまいやすいのでしょうか。ビジネスでデータを活かすには事業部とデータアナリティクスチームの双方が成長していくことが重要だからです。分析結果を行動に移し行動した結果を分析するというサイクルから学ぶ必要があります。その中でデータの知見がない事業部と事業の知見がないデータアナリティクスチームの間でコミュニケーションが難しくなることは大きな問題になるのです。 依頼者と下請けという関係性では前提知識や価値観、優先度の違いから課題感の共有が難しく、お互いの立場の強さや信頼関係から積極的な意見や提案、その実行の柔軟さや迅速性に欠けることになります。本来、意思決定者と分析者は対等な立場であり顧客への還元という共通の目的をもっているはずですが、次第に意思決定者が顧客のように振る舞いはじめます。外部ベンダーを通したITシステムの開発が難しいように、このような状態では柔軟かつ迅速なデータ活用は簡単ではありません。 それでは、どのようにしてこの問題を解決していけばよいのでしょうか？私の考える解決方法は事業部とデータアナリティクスチームがパートナーとして並走することです。事業部とデータアナリティクスチームが普段から課題感を共有し同じ方向を向いて課題解決に取り組んでいる状態です。 分析とアクションのサイクルを通して成長していくためにはアクションを起こしやすい分析を行い、分析のしやすいアクションを計画していく必要があります。このためにはお互い密な連携が必須です。依頼者と下請けという立場では実現が難しいですが、お互いに並走することで強力なシナジーを生み出すことが可能です。 パートナーとして並走する 事業部にデータアナリティクスチームがパートナーとして並走することで上手くいくと述べましたが、実際の問題として「明日からパートナーとしてやっていきましょう」と同じ会議室に詰め込んだところで簡単に成し遂げられるわけではありません。最初はお互いに関係性もなくナレッジの共有もできていませんから、挑戦と実績を積み重ねる必要があります。 重要なことは小さく挑戦し失敗と成功を積み重ねることです。事業部はデータアナリティクスチームと共にやっていくことにメリットを得られるのか不安を抱えています。データ活用に知見がないのでそこに腹落ちするビジョンを描けていません。一方でデータアナリティクスチームは新しく作られたチームですので早く成果を生み出して信頼を勝ち取る必要があります。このような状況で両チームに必要なのは小さくてもよいので実際に手を動かして実績を積み上げていくことです。良い結果が望ましいですが失敗しても構いません。 もちろん、挑戦しただけでは意味がありません。その結果を受けて振り返りを行い改善サイクルを回していきます。分析結果を生かしてアクションを起こす、アクションを起こした結果を分析する。このサイクルを回して効率よく効果的なデータアナリティクスの活用を見出します。これは単純に良い結果を出すという意味ではありません。良いやり方を見つけるということです。人材の配置やデータ連携など設備はもちろん、見るべき指標の精査やデータの処理方法、タスクの決め方や管理方法など、データを活用するということは今まで仕事の進め方を変えるということですので考えなければいけないことは多岐にわたります。 このようにして深いパートナーシップを結び成果を生み出せるようになるためには経営層からの強いバックアップが必要不可欠です。事業部とデータアナリティクスチームの双方に方向性を示し軌道修正していくということです。事業の成長のためにそしてユーザのために長期的に改革していくのだということを説明しそのように実行できるよう協力することが経営層の仕事です。事業部とデータアナリティクスチームに丸投げしてはうまくいきません。データ活用の成功も失敗も最終的には経営層の責任なのです。

前回の記事ではデータ分析基盤開発において小さく動くものから作ることの必要性を解説しました。 では、データ分析基盤におけるMVPとはなんでしょうか？ 一言でいうならば、意思決定者がデータを取得し意思決定に活かせる最小構成です。 ここでは2つの要素を取り上げます。 得られるデータがビジネスの意思決定の役に立つ これは言うまでもないことですがビジネスの意思決定の役に立つことが目的です。 そのため、大なり小なり意思決定へ寄与することが求められます。 なんの役にも立たないデータしか取得できない分析基盤はMVPになりえないという話です。 もちろんMVPですからクリティカルで重要な知見を提供する必要はありません。 イノベーティブな指標を計算しようとすると仕様を決めるのに時間がかかるので数字がある程度わかっているものを選んだほうがよいくらいです。 スプレッドシートで計算しているものを自動化できるくらいでも良いでしょう。 自動化されれば手間や品質の改善が起きるのでこれも重要な成果です。 大事なのは役に立っているということです。 この基準はクイックウィン的な発想も入っています。 なにかしら役に立つことを証明し具体的なイメージをもってもらうことでその後の進行が円滑になりますし課題も見えてきます。 誰も注目しない数字では次のステップへのブーストになりません。 「この数字が見られるならこっちも見てみたいな」 そう思ってもらえるようなものをアウトプットすることで初めて積極的な投資が得られます。 実はデータ分析基盤のMVPとは利用者側の体勢の検証でもあります。 データドリブンな意思決定パイプラインは作れるか？ 自分たちの意思決定に必要なデータはなにか定義できるか？ 現場のデータ入力を掌握できているか？ こういった問いを自分たちに突きつけるシーンです。 データソースからBIまで取得・保存・加工・可視化が一気通貫に動く ビジネスの意思決定に役立つことが重要だと述べましたが、そのためには使う側にデータを届けられるシステムが必要です。 これを満たすにはデータ分析にかかる一連の処理が一気通貫に動いていることが求められます。 重要なのは要件が把握されコントロールできていることです。 データ分析基盤を実装するにあたって最大の壁がデータの取り扱いです。 実際に実装を始めると想定外のデータの仕様にぶつかります。 データソースからデータが取得できない 取得したデータのスキーマがおかしい 入っているデータの仕様がわからない …etcとさまざまな問題が噴出します。 これらの問題について必要な項目は仕様を調査したり対応を実装していきます。 ポイントはやりたい分析に必要な仕様がわかっており、必要なデータの取得 ~ 可視化までの処理が可能な限り自動化されていることです。 仕様を把握する MVPなので入っているデータについてすべて整形し仕様を把握する必要はありません。 はっきりいってデータの仕様はすべてを理解しようとすると莫大な時間がかかります。 仕様書に書いてあることと実態がズレていることなんて当然に起きますし仕様書がないことも頻繁です。 達成したい最低限の問題についてだけ答えられればよいのでそこに絞って調査をおこないます。 指標の集計に必要な仕様の把握は必須です。 データの結合方法や集約キーの仕様、絞り込みに使うパラメータなどがあります。 使えるとおもっていたデータが実は集計に使えなかったということはよくあります。 たとえば、顧客の属性情報がCRMに入力されているが自由記述なので内容がバラバラで簡単に集約できないということはありがちです。 実際のデータを見るまでは油断しないほうがいいでしょう。 また、データ自体の仕様の整理も必要です。 取得するデータがどんな状態なのか実際にやってみるまでわからないことがほとんどです。 言い換えると仕様と実態がズレていたり仕様が明瞭でないことが頻繁に起きます。 スキーマの破損やデータの欠損などのデータ品質は前処理や集計に関わってきますし、場合によっては自動化の可・不可にまで影響します。 人によって入力にばらつきがあるようなデータの不整合は一括で対応できないため自動化ができなくなります。 このようなデータの状態は実際のデータを見ないとわかりません。 実態を見ながら対応を考え、MVPとしてどのように進めるのか？着地をどうするのか考えていきます。 自動化する データ分析基盤をシステムとして実装している以上は当然自動化が期待されています。 最初から完全な自動化が必要というわけではありませんが可能な限り手作業は排除すべきでしょう。 処理をコードとして実装し自動で実行できる環境を構築していきます。 人がやっているからといって自動化できるとは限りません。 それぞれのステップの処理を自動化できるのかどうか、という観点だけでなくステップ同士をスムーズに連携できるかどうかもポイントです。 定期実行の設定も重要です。 データを閲覧したい時間や更新タイミング、処理の時間は重要な課題です。 あるデータは朝に更新され別のデータは夕方に更新されるので統合した結果がわかるのは次の日になってしまう、なんてケースは珍しくありません。 cronなどスケジューラーでもよいので自分たちの用途に合わせて自動化が構築され、あわせて今後の拡張の方向性が見えていることが望ましいでしょう。 とはいえ、自動化が難しいケースは珍しくありません。 前述したようにデータソースの品質の問題で自動化ができないようなデータはよくあります。 無理に自動化を目指してスケジュールが遅れるくらいなら手動でも良いとおもいます。 その場合は手作業を前提に誰がいつどのように行うのか？などを明確に整理し動作を検証する必要があります。 一方で自動化の仕組みはあるがエラーばかりで全然動かない状態は問題があります。 MVPとはいえスコープの範囲ではそれなりに想定されたとおりにシステムが動いている必要があります。 ...

動くものを作らないから失敗する 失敗するデータ分析基盤プロジェクトに共通する重要な特徴の1つは「動くものから作らない」ということです。 何年もかけて巨大な基盤を構築しすべてが完成してから稼働させるようなやり方は経験上うまくいきません。 開発の前にすべての要件を定義し仕様を決めようとする。 データ分析基盤の実装をレイヤーごとに進めようとする。 こういった進め方をしようとする人は少なくありませんが実際のところうまくいきません。 なぜ、このような進め方をするとなぜ失敗するのでしょうか？ 3つの要素にわけて解説します。 時間をかけると作った頃には役に立たない まず根本的な問題として、データ分析基盤を何年もかけて作ったとしても完成した頃には情勢が変わっており使い物にならない可能性が高いという点があげられます。 これはビジネスを取り巻く環境の影響を受けること、そしてデータ分析基盤は社内の様々なシステムの影響を受けることから発生します。 現代の市場は凄まじい速度で変化しておりビジネスの戦略もそれに合わせて日々変わっていきます。 ビジネス戦略が変われば知りたい情報もどんどん変わっていきます。 何年も前に決めた指標や分析方法が役に立つでしょうか？ 少なくない割合で変更が求められることは想像に難くないでしょう。 このようにして作った瞬間から役に立たないダッシュボードができあがります。 また、社内システムが変更されれば取得するデータの性質は変わっていきます。 1つ1つの変更の周期は短くなくとも様々なシステムによってなりたっている現代では毎年のように何らかのシステムが変更されていきます。 変更に限らず新たなシステムを導入することも珍しくないでしょう。 データ分析基盤は様々なシステムの下流に位置するためそれらの影響を強烈に受けます。 また、社内のシステムは変わらずとも法律や規制などによって変更や修正が要求されることもあります。 分析に必要なデータソースが増えたり減ったり変更されることで、データの取得方法や前処理、集計の定義すら変わるのです。 フィードバックループを回せ 次に重要な問題の1つとしてフィードバックループが回らないことが挙げられます。 完成まで誰も触らなければ誰も検証できずフィードバックができません。 途中で誰かが実際に利用しはじめていれば意思決定に使える分析ができるのか確認できますし問題があれば修正ができます。 開発の前に完全な要求や仕様を定義することはできません。 事前の想定が間違っていたという自体は当然のように発生します。 最初にすべてを定義して設計、実装を行うという方法は絶対に過不足が発生します。 分析する側も分析基盤を開発する側も両方でこの問題が発生します。 分析する側は実際に分析して意思決定に活かしてみると最初に想定していた指標では上手くいかない、なんてことはよく起きます。 これは「考える人のスキルが足りず想定不足だった」という話ではありません。 前述したように事業や環境が変わって分析の切り口が変わるケースはその典型例です。 探索的に分析を行うことで初めて見えてくるものもあります。 やってみないとわからないことがたくさんあるのです。 分析基盤を構築する側としては当然上記の分析する側の状況が変化すれば作るものも変わってきます。 見たい指標が変わればデータマートやダッシュボードの実装は変化するでしょう。 場合によっては中間テーブルでのデータの持ち方や前処理の方法を変更する必要があるかもしれません。 想定よりも負荷が高くてうまく運用が回らないというケースもありえます。 これらの問題を使う前にすべて洗い出すのはおおよそ不可能であるといってよいでしょう。 少なくともすべてを洗い出すコストとリスクを考えると作って使ったみたほうが早くて確実です。 地に足のついた議論をする もう1つ重要な問題として進める優先度や方向性を揃えることが難しいという点があります。 データ分析基盤は社内の多くのステークホルダーを巻き込んで開発されるものです。 意思決定に活かすという性質から上位レイヤーの人間への影響をもちます。 その中データ分析基盤ではどれをどの順番で作るのか決めていく必要があります。 これが実際に動くものと検証ができない状態だと物事を進めるのが簡単ではありません。 データ分析基盤の開発に着手するとき、多くのステークホルダーは具体的なイメージを持てていません。 まして自分たちのチーム以外との連携などほぼ不可能といってよいでしょう。 しかし実際に開発を進めるには社内のそれぞれのステークホルダーの要望から優先度を決める必要があります。 具体的なモノがない状態だと各々の認識をぶつけることになり議論が空中戦になりがちです。 結果として社内の力学がそのまま反映されてしまいあるべき姿から歪んでしまいます。 しかし、実際に作ったものがあり動かすことができれば多くの人の認識を揃えるやすくなります。 荒削りでもダッシュボードがあれば間違っている計算や不足している観点を洗い出すことができます。 自分たちのチームで使うならどんなデータが不足しているのか想像することができるでしょう。 そのための課題も具体的に見えてきます。 動くものがあればできることや難しいことのイメージを捉えやすくなるため進める方向性や優先度の認識が揃えやすいでしょう。 おわりに ここまでに述べたような理由からデータ分析基盤の構築は使う前から最初に時間をかけて大きく作るものではありません。 まずは小さく作りそれを絶えず修正・改善しながら大きく拡張するものなのです。 では、具体的にどのように小さく作ればよいのでしょうか？ 次の記事ではMVPについて考察します。

データ分析基盤を構築するとき避けて通れないのが「どうやってデータを取得するか」という問題です。 SaaSのETLツールを使うのか、APIを自前で叩くのか、手動でCSVを取り込むのか。 データを取得する手法は選択肢が多く状況に応じて最適な手法は変化します。 また、技術的な問題だけではなく分析する側であるビジネス上の要求も考える必要があります。 本記事では技術選定の判断基準を整理し、筆者の経験をもとに実際によくある検討のパターンを解説します。 データの鮮度・更新頻度 更新頻度は技術選定に最も直接的な影響を与える要素です。 一般にデータを更新する頻度が上がるほど自動化の設計は複雑になります。 日次であれば夜間バッチで全件更新というシンプルな仕組みで済みますが、これが数時間おきとなるとAPIのレートリミットを意識した設計が必要になるかもしれません。 更にリアルタイムになれば差分検知やリトライの仕組みまで求められます。 つまり更新頻度は「どの程度の仕組みを作る必要があるか」を決める起点であり実装・運用コストに直結します。 逆にいえば「どれくらいの頻度でデータを更新する必要があるか」を最初に固めることで選択の幅が大きく絞り込むことができます。 低頻度 低頻度とは年に数回くらいの想定です。 こういったデータの場合は手動で全件を更新するというケースが多くなります。 データソースと分析上の要求として増分・差分をわざわざ検知する必要がないため全件更新で問題がないこと、そして頻度が低いため自動化のメリットを享受しにくいこと多いためです。 更新頻度が低いデータの場合はそもそもデータの形式や用途が安定しないこともあり処理の内容を毎回検討する必要が多いことも自動化の優先度が下がる要因の1つです。 自動化を選ばないケースでいうと、たとえば特定のプロジェクトや顧客で単発で発生するようなケースがあります。 プロジェクトで単発的にデータが発生したり、顧客ごとにデータの形式にばらつきがあったりという状況です。 このような不定期でデータの形式も完全に固まっていない場合は自動化のコストが高くなりがちです。 担当者がその都度手動で取り込む運用でも十分でしょう。 逆に頻度が低いとはいえデータの形式が固まっており処理が複雑という場合は自動化のメリットが上回ります。 エクスポートしたデータをエクセルなどで細々と整理してからアップロードするようなプロセスが必要だとしたら手間もかかりますしミスも起きやすいので自動化が望ましいでしょう。 たとえば、年に数回しか更新されないマスタデータがありながらインポートにひと手間必要という場合はこのケースに該当します。 完全に自動化する必要もないので無理にワークフローに載せずにスクリプトとして保存しておくなどの対処もありえます。 月次・週次 月次・週次で更新する場合は全件更新するケースが多くなります。 データソースの特性として月次・週次で更新するデータは何らかの作業がひととおり終わったものを保存するというケースが多く、そのため増分・差分を検知して保存するというよりも全件を保存したいことが多いからです。 たとえば締め作業が終わって確定した会計データや、週次で棚卸し作業をしている在庫情報などが挙げられます。 月次・週次くらいの頻度で恒常的に発生するとなると自動化による作業コストが削減できるメリットが大きくなるため多くの場合で自動化を検討します。 1つ2つくらいのデータソースであればなんとかなりますがデータ分析基盤には多くのデータソースを結合していくことになりますので自動化することを前提に設計するべきでしょう。 また、作業ミスによるリスクも考慮に入れるべきです。 それなりの頻度で作業することになりますから必然的にミスも発生します。 作業ミスはそのままデータ品質の問題に、そして誤った意思決定へと繋がります。 より確かな意思決定という観点からも週次・月次くらいの更新頻度が定常的に発生するようであれば自動化が前提という意識でいるのがよいでしょう。 日次更新 最も一般的な更新頻度です。 毎晩にバッチ処理を走らせ朝出社したときには最新のデータが見られるようになっている、というサイクルは多くのビジネスの意思決定に十分なサイクルです。 日次の更新ではデータ量がよほど大きくない限り全件を取得してそのまま更新するシンプルな設計をベースに検討します。 この頻度になると自動化は原則です。 毎日の作業となると手動では作業の負担が大きくなります。 あわせて作業頻度が増えることでミスも起きやすくなるため担当者の業務を圧迫します。 スケジュール実行で毎日自動的に動くように設計しておくことで安定した運用が実現できます。 基本は全件更新ですがデータ量が多い場合は全件更新が難しくなるため増分・差分更新を検討する必要も出てきます。 ただし増分・差分更新は実装が複雑になるため、まずは全件更新でシンプルに作り必要に応じて改善するアプローチを取るほうが無難です。 現代ではデータの保存・処理コストは非常に安いので実装が複雑になることのデメリットの回避を優先したほうがよいケースは多いでしょう。 数時間に一度 日次よりも高い頻度で更新したいがリアルタイムだと工数が高すぎるという場合にとる選択肢です。 ログデータのような量が多く変化を素早く検知したいようなケースです。 もしくは日次だとデータ量が多くなるため分割したいという場合です。 数時間おきに更新するときは同時に増分・差分更新が要件となることが増えます。 差分を検知して変更があった分だけを取得する設計が取れるか検討しましょう。 増分・差分更新が求められがちな理由はいくつかあります。 数時間ごとに更新したいデータはログデータのようにデータ量が多く変更よりも追記が多いデータであるため増分・差分更新が要件になりがちです。 そうでなくとも数時間ごとに実行すると日次の数倍の処理量になるためさすがにコストが無視できない状況になってきます。 合わせてAPIの実行頻度が増えるため毎回全件更新するとAPIのレートリミットに引っかかるリスクも高まります。 このような理由の組み合わせから増分・差分更新になりやすくなります。 もちろん全件更新で要件として十分なのであればそのほうが望ましいことは言うまでもありません。 注意点として、増分・差分更新の実装には「どのレコードがいつ変更されたか」を追うことが必須です。 そのためのタイムスタンプや連番IDがデータソース側に存在することが前提になります。 これが整備されていない場合は差分の検知自体が難しくなるためデータソースの特性を事前に確認することが重要です。 即時〜数分のリアルタイム連携 リアルタイム連携はデータソースの変更が即時もしくは数分程度の遅延で反映されるような設計です。 ユーザーの行動ログデータや広告データなどデータ量が非常に多く、同時に変化を検知したいという場面で求められることが多いです。 リアルタイム連携は更新頻度としては理想ではありますが一方で他の更新頻度に比べて実装・運用コストが高くなります。 リアルタイム連携には大きく2つのアプローチがあります。 一つはデータソース側で変更が発生した時点でイベントとして通知を受け取るイベント駆動型で、もう一つは数分おきに差分だけを取得するミニバッチ形式です。 どちらも「変更をほぼリアルタイムで検知して取り込む」という点では共通しており日次のバッチ処理とは設計の考え方が大きく異なります。 どちらのアプローチが現実的かはデータソースの特性やAPIなどのインターフェイスによって変わります。 リアルタイムにデータを連携しようとすると要求される技術的な難易度が一気に上がります。 単純なAPI連携で全件更新するバッチ処理に比べると差分の検知に加えてリトライ設計や運用の監視など考えるべき要素が増えるためです。 障害発生時も全件更新であれば再度実行すれば簡単に復旧することが可能ですがリアルタイム連携の場合はどこまでデータが取れているのか確認する必要があるなど復旧のコストと難易度が高くなります。 一方で、リアルタイム連携が求められやすいデータソースは公式や外部SaaSにリアルタイム連携のコネクタが用意されていることもあるのでその場合は比較的実現しやすくなります。 ...