前回の記事ではデータ分析基盤開発において小さく動くものから作ることの必要性を解説しました。

では、データ分析基盤におけるMVPとはなんでしょうか？
一言でいうならば、意思決定者がデータを取得し意思決定に活かせる最小構成です。
ここでは2つの要素を取り上げます。

得られるデータがビジネスの意思決定の役に立つ

これは言うまでもないことですがビジネスの意思決定の役に立つことが目的です。
そのため、大なり小なり意思決定へ寄与することが求められます。
なんの役にも立たないデータしか取得できない分析基盤はMVPになりえないという話です。

もちろんMVPですからクリティカルで重要な知見を提供する必要はありません。
イノベーティブな指標を計算しようとすると仕様を決めるのに時間がかかるので数字がある程度わかっているものを選んだほうがよいくらいです。
スプレッドシートで計算しているものを自動化できるくらいでも良いでしょう。
自動化されれば手間や品質の改善が起きるのでこれも重要な成果です。
大事なのは役に立っているということです。

この基準はクイックウィン的な発想も入っています。
なにかしら役に立つことを証明し具体的なイメージをもってもらうことでその後の進行が円滑になりますし課題も見えてきます。
誰も注目しない数字では次のステップへのブーストになりません。
「この数字が見られるならこっちも見てみたいな」
そう思ってもらえるようなものをアウトプットすることで初めて積極的な投資が得られます。

実はデータ分析基盤のMVPとは利用者側の体勢の検証でもあります。
データドリブンな意思決定パイプラインは作れるか？
自分たちの意思決定に必要なデータはなにか定義できるか？
現場のデータ入力を掌握できているか？
こういった問いを自分たちに突きつけるシーンです。

データソースからBIまで取得・保存・加工・可視化が一気通貫に動く

ビジネスの意思決定に役立つことが重要だと述べましたが、そのためには使う側にデータを届けられるシステムが必要です。
これを満たすにはデータ分析にかかる一連の処理が一気通貫に動いていることが求められます。
重要なのは要件が把握されコントロールできていることです。

データ分析基盤を実装するにあたって最大の壁がデータの取り扱いです。
実際に実装を始めると想定外のデータの仕様にぶつかります。

  • データソースからデータが取得できない
  • 取得したデータのスキーマがおかしい
  • 入っているデータの仕様がわからない

…etcとさまざまな問題が噴出します。
これらの問題について必要な項目は仕様を調査したり対応を実装していきます。

ポイントはやりたい分析に必要な仕様がわかっており、必要なデータの取得 ~ 可視化までの処理が可能な限り自動化されていることです。

仕様を把握する

MVPなので入っているデータについてすべて整形し仕様を把握する必要はありません。
はっきりいってデータの仕様はすべてを理解しようとすると莫大な時間がかかります。
仕様書に書いてあることと実態がズレていることなんて当然に起きますし仕様書がないことも頻繁です。
達成したい最低限の問題についてだけ答えられればよいのでそこに絞って調査をおこないます。

指標の集計に必要な仕様の把握は必須です。
データの結合方法や集約キーの仕様、絞り込みに使うパラメータなどがあります。
使えるとおもっていたデータが実は集計に使えなかったということはよくあります。
たとえば、顧客の属性情報がCRMに入力されているが自由記述なので内容がバラバラで簡単に集約できないということはありがちです。
実際のデータを見るまでは油断しないほうがいいでしょう。

また、データ自体の仕様の整理も必要です。
取得するデータがどんな状態なのか実際にやってみるまでわからないことがほとんどです。
言い換えると仕様と実態がズレていたり仕様が明瞭でないことが頻繁に起きます。
スキーマの破損やデータの欠損などのデータ品質は前処理や集計に関わってきますし、場合によっては自動化の可・不可にまで影響します。
人によって入力にばらつきがあるようなデータの不整合は一括で対応できないため自動化ができなくなります。

このようなデータの状態は実際のデータを見ないとわかりません。
実態を見ながら対応を考え、MVPとしてどのように進めるのか？着地をどうするのか考えていきます。

自動化する

データ分析基盤をシステムとして実装している以上は当然自動化が期待されています。
最初から完全な自動化が必要というわけではありませんが可能な限り手作業は排除すべきでしょう。
処理をコードとして実装し自動で実行できる環境を構築していきます。
人がやっているからといって自動化できるとは限りません。
それぞれのステップの処理を自動化できるのかどうか、という観点だけでなくステップ同士をスムーズに連携できるかどうかもポイントです。

定期実行の設定も重要です。
データを閲覧したい時間や更新タイミング、処理の時間は重要な課題です。
あるデータは朝に更新され別のデータは夕方に更新されるので統合した結果がわかるのは次の日になってしまう、なんてケースは珍しくありません。
cronなどスケジューラーでもよいので自分たちの用途に合わせて自動化が構築され、あわせて今後の拡張の方向性が見えていることが望ましいでしょう。

とはいえ、自動化が難しいケースは珍しくありません。
前述したようにデータソースの品質の問題で自動化ができないようなデータはよくあります。
無理に自動化を目指してスケジュールが遅れるくらいなら手動でも良いとおもいます。
その場合は手作業を前提に誰がいつどのように行うのか？などを明確に整理し動作を検証する必要があります。

一方で自動化の仕組みはあるがエラーばかりで全然動かない状態は問題があります。
MVPとはいえスコープの範囲ではそれなりに想定されたとおりにシステムが動いている必要があります。

MVPの確認

上記に関する点を踏まえて進捗したあとどのような観点でチェックすべきでしょうか？
端的にいうなら意思決定者がデータを取得し意思決定に活かせるという実感があるかどうかです。

まずは意思決定者が自分でデータを取得することができるのか確認しましょう。
毎回エラーが起きてデータを出すために誰かの手を借りているようでは片手落ちです。
BIツールを開いたら必要な表やグラフが得られる状態を確認しましょう。

同時にその数値を意思決定者が活かせることを確認しましょう。
数値をだしても意思決定者が見ていない、使えてないのでは意味がありません。
その数値が意思決定に使われていることを確認します。

以上の要素を確認できたらMVPとして完成したといってもよいでしょう。
データドリブンな意思決定を支える重要なシステム開発の偉大な一歩を進めることができました。
ぜひチームでお互いを祝い、称賛しましょう。

ここまで来たら次はなにをするべきでしょうか？
機能の拡張とMVPの過程で見つかった課題を解決です。
指標やデータソースの拡張はもちろん、セキュリティや監視の改善、データモデリングによる実装の効率化などやることはたくさんあります。
メンバーで優先度を決めて対応していきましょう。
このステップでの考え方はまた機会があれば記事にしようとおもいます。