雑記：データ分析パイプラインの「ラストワンマイル」問題をなんとかしたい

データ・パイプラインのラストワンマイル問題

物流業界には「ラストワンマイル」という言葉がある。

ja.wikipedia.org

「交通結節点から最終目的地までの人やモノの移動を表す」用語だそうだ。このラストワンマイルの管理が非常に難しく、Amazonとかヤマト運輸がいろいろ苦労したらしい。

データパイプラインにも似たようなものがあるな、と最近思うようになってきた。話を簡単にするため、社内のマーケティングチーム向けにデータを提供する場合を考えてみよう。

データウェアハウスに格納されたデータをマーケティングチーム向けに提供する方法は複数ある。

1. データ分析チームがダッシュボードを作り、マーケティングチームに見てもらう
2. データ分析チーム自身がSQLを書き、マーケティングチームにデータを提供する
3. マーケティングチーム自身にSQLを書き、データを抽出してもらう

ざっとこんなものだと思う。

体感、7割くらいのニーズはダッシュボードで満たせる。残り3割のニーズを満たすにはどうしたらいいだろう？

マーケターにSQLを書いてもらうのは難しい。そもそも彼らの主な仕事はユーザー体験の貢献とクライアントへの対応であって、SQLを書くことは複数ある業務の中の一つに過ぎないし、その割に学ぶべきことは多い。やることが多すぎる。現実的ではない。

そうなると、必然的にデータ分析チームに依頼が回ることになる。だが、抽出にかかる時間が長すぎて、今度はマーケター側の不満がたまってしまう。

この3割をどうやって満たせばよいのだろう？ということを考えるようになった。これがラストワンマイル問題だ。まとめると

• ダッシュボードの作成では見たせないニーズをいかにして素早く満たすか？

というのを「データパイプラインのラストワンマイル問題」と名付けたい。

解決策

として考えたもの

解決策1 : ダッシュボードをマーケター側に作ってもらう

• 管理できない野良ダッシュボードが作られてとんでもないことになるリスクが大きい

解決策2 : アナリストをマーケター側に張り付けさせる

• 定型的ではない柔軟な分析が可能
• しかし問題の構造は変わらない。結局はスケールしない状況になる。

解決策3 : 柔軟性のあるインターフェースの提供

• これなら、ダッシュボードでは実現できないような柔軟な分析をスケールする手段で提供できる
• ただし、定型的である前提がある
• 具体的にはStreamlitなど

とりあえず3をやってみることにした。 GitHub Actionsをいい感じに書いて、CI/CDの体制を整え、変更を迅速かつ容易にデリバリーできるようにすれば、なんとかできるはずだ。