書籍「実践的データ基盤への処方箋」を読んだ
今年初めての5連続仕事を乗り切った皆様、お疲れさまでした。いかがお過ごしでしょうか。
今日は、私の業務にも関係している、データ基盤に関しての本を読んだので自分的なまとめを書いていこうと思います。
どんな本？
一言でいうと、「データ基盤作りました！だけじゃダメなんよ」という本。
冒頭で、著者はこのように言っている。
- 真のデータ活用とは、一時的ではなく、継続的に企業の成長を支えることである。
- しかし、企業においてこれができているかというと、そうではない。
- データ基盤の作り方のノウハウは世間的にも認知されてきているのに、なぜか？
- 「データ基盤の活用のさせ方」が広まっていないからである。
確かに、データ基盤の作り方という意味では、巷にはパブリッククラウドを使ったハンズオンや、pythonの書籍などがあふれかえっている。
それにも関わらず、データ分析基盤作りがうまくいかない！という声は、よく聞くように思える。
思うと、こういうギャップは日常生活でもよく起きているように思う。
- 実家の親がスマホに変えたいということで手続して変えてあげたが、使いにくそうにしている。
- 仕事でチームのタスク管理のためにチケット管理ツールを導入したが、だれも使ってない。
- 同居人が「初めて資料作成の仕事を任された」というので、実際に自分が参考にした書籍やサイトを送ったが、何も見ない。
このように、使う側と提供する側が違うと、このようなことが起こりうるのだろう。
今回は、その「データ分析基盤版」というわけだ。（キバンバンって語呂悪いな…）
この本では、実際のビジネスの現場で起きた課題、解決したノウハウをデータ/システム/ヒトの観点で紹介している。
今回は、その中でも私が重要だと思った「データ」の観点の中から、特に大事なべし/べからずをピックアップして紹介する。
ユースケースからつくるべし（not データ基盤）【1-9】
why？
ユースケースがビジネス価値を生むものだから。基盤だけ整えても、「結局何がしたかったんだっけ？」となりがち。
how？
- 自社の目標、現状、課題、施策を洗い出す。
- 施策の優先順位を決める。
- その施策の中で、「どの顧客or社員の」「どの作業or判断を」「どのように置き換えるか」を検討する。
（例）
デジタル広告配信による登録促進、という施策の場合。
・経営企画部門が売り上げを集計している→手間削減のためにダッシュボードを作る
・顧客自らページをクリックして商品を探している→手間削減のために検索機能を作る
このあたりのユースケースへの落とし込みは、この本だけだと詳細には分からなかった。
著者からも、「業務改善やUXデザインの手法が役に立つからほかの書籍を参考にしてみてね」ということだった。
この部分に関しては、このブログ記事がよく言語化されている。
ただ、やはり実際の経験が積みたいところ。仕事であればいいが、なにか過去事例などないものか…。
【保存版】初心者でも分かるデータ分析の本質とスキルアップの道のり｜naki｜note
サービスレベルを設定/計測して継続的に改善するべし【1-11】
why？
ユーザが期待しているサービスレベルをクリアしないと使われなくなっていくから。
how？
ユースケースごとにサービスレベルを設定し、そのサービスレベルが守れているかを定期的にモニタリングする。
（例）
毎営業日の午前9時までに欠損なく前日の売り上げレポートが作成されていること
この「サービスレベル」は、なかなか難しい。なぜなら、ユーザにざっくり「守るべきサービスレベルって何にすればいいですか？」と聞いても答えが返ってこないだろうからだ。
（もちろん、例のようにはっきりしているものもあるだろうが、ユーザの暗黙的な期待もあるはず。）
SIer思考だと、サービスレベルの種類を網羅したどでかいexcelがどこかにあって、その1行ごとにレベルを定義してユーザと合意したくなる。
以下の非機能グレードのように。
システム構築の上流工程強化（非機能要求グレード）：IPA 独立行政法人 情報処理推進機構
ただ、データ分析基盤では、とりあえずエイヤで分かりやすいレベルだけ決めて、定期的に振り返っていき、途中で何か問題が起きたらサービスレベルに追加していくのがいいのだろう。
例えば、nullが入らないはずのidカラムにnullが入ってしまっている、という障害が起きたら、csvファイルのnullチェックを実装してモニタリングする、など。
著者の1人であるゆずたそさんのブログで、この部分はより詳細に述べられていた。
サービスレベル：設計と運用のプラクティス - 下町柚子黄昏記 by @yuzutas0
また、オライリーのこの書籍も参考になりそうだ。
利害対立が生じる、データの生成者と活用者をうまくつなげるべし【1-3, 1-10】
why？
- データが高品質で利用できる形で生成されないと、データ活用者がデータをうまく使えないから。
- データソースに一番詳しいデータ生成者がメタデータの更新作業をしてもらわないと、データ活用者のデータ調査コストが膨れ上がるため。
おわりに
以上、重要そうなところだけをピックアップし、参考になりそうなものがあれば載せてみた。
この中でも特に重要なのは、1つ目のユースケースに関わるところだろう。
ユースケースがうまく決まれば、あとはそれをどう検証/実現していくかという話になるので、動きが速い。
また、ユースケースはビジネス価値に直結するので周りも説得させやすい。
インフラエンジニアでも、データスチュワードでも、「どのようにビジネス価値につながっているのか」は、常に意識しておくべきだろう。
案件が来るたびに、それを確認するような仕組みを作っておくとよいかもしれない。
仕組みは文化を創り出す。ビジネス価値を意識できるチームは、強いチームになれるはずだ。
