Data Analystのメモ帳

機械学習とかデータ分析とかしているData Analystのメモ帳です

ダッシュボードとかKPIを作るときにやっていること

普段やっていることをメモしてみる。

概要

すごくザックリ言うと考えるフェーズと作るフェーズがある。 最初の考えるフェーズはダッシュボードとかKPIを使う人(以下、決裁者)からヒアリングしたり基盤やサービスを調査して実現性を考えるフェーズ。 作るフェーズは実際にクエリ書いたりBIツールをアレコレするフェーズ。 個人的に重要だと思っているのは考えるフェーズと作るフェーズをなるべく疎にすること。

考えるフェーズ

ここでやることは3つです。上から着手はしますがお互いに関係するので同時並行に進めることが多いです。

  1. 決裁者から目的や要件を聞き出す
  2. データ基盤やシステムを調査して実装に必要なものを洗い出す
  3. 類似のダッシュボードやKPIを探して比較検討する

まず1番はいわゆる要件定義です。 決裁者が数字を見てやろうとしていることや条件なんかを聞き出します。 最終的なアウトプットが役に立つかどうかはここにかかっているので精緻にやることが求められます。 基本的にはドキュメントに条件とかを書き出して問題ないが確認してもらいます。 口頭とかチャットだと漏れや認識のズレが発生するので最終的なアウトプットはドキュメントにします。 言った・言わなかったみたいな事故は防ぎましょう。

2番は要件をもとにそれが実装可能なのか調べたり、追加で必要な開発を洗い出します。 要件で求められたデータや条件を既存のもので表現できなかったら当然追加で開発したり、場合によっては今は抽出できませんとか返す必要があります。 なので実装に入る前の調査フェーズでそもそも実現可能なのか調べます。 ここはチーム内で確認したり開発チームなんかに相談することが多いです。 重要なのは妄想ではなくファクトを取ること。

3番は似たような案件を探します。 当然、似たようなものがあれば流用したり参考にしたりできます。 また、類似のダッシュボードがある場合はそれと平行して見たいとか、そういう意図があるケースも多いので見せ方としてどうしたほうがいいのか考えたりします。 類似のケースがある場合はなるべく類似ケースを理解したほうが良いです。 少なくともそれの担当者に軽く話を聞くくらいはするべきでしょう。

ここまでやることで何を作るのか、どうやって作るのか、過去の例があるのか調査が完了します。 これらを踏まえたドキュメントを作成しチーム内や決裁者、他の関係者にレビューしてもらい概ね問題がないことが認められたら実装へ移ります。

作るフェーズ

これに関しては粛々と実装するだけなのであんまり言うことはないです。 考えるフェーズでアーキテクチャや細かい条件と実装は考えられているはずなので実装で考えることはそんなにないです。 良いコード、詳細な設計となるように心がけましょう。 逆に、この段階であちこちに相談したりするようならば、それは事前準備が甘かったという意味なので次への反省とします。

とはいえ、実装途中に「聞いてた話と違う」とか「よく考えたら間違ってた」ということは起きます。 変更・追加が発生したら前述のドキュメントに変更を追記しましょう。 なるべくドキュメントと成果物は対応しているようにします。

あと、実装段階に入ったあと要件の追加を依頼されても基本的には断ります。 よほど重要であったり簡単かつ少量であれば受付けますが、そうでなければバックログとして次の開発案件として積むだけにとどめます。 どちらにせよ次回から考えるフェーズで出すように先方にお願いしておきましょう。

実装が終わったらチーム内で確認を決裁者にレビューしてもらいOKがでたら作業完了です。 念の為、実装とドキュメントを比較して相違がないか確認して、チケットをdoneにします。

なぜ明確にフェーズを分けるのか

一番の目的はステークホルダーを減らすためです。 分析は多くのステークホルダーが存在するため調査と実装を同時でやると情報が錯綜して非常に厳しい状態になります。 また、調査と実装を並行すると要件定義がダラダラとしがちです。 これによりダラダラと追加の要件が生まれたりします。 なので要件はバシッと決めてそれ以降の追加については断れるような体制をつくります。 こうしないと無限に要件が追加され一生完成しないけど誰も見ていない数字がならぶダッシュボードが生まれます。

ドキュメントについて

私は案件ごとに簡易的なドキュメントを作成するやり方が好きです。 要件や実装の方法、セキュリティなど留意点をならべたものです。 これはDesignDocという手法を真似しています。 この方法の良いところは、作るために必要な情報が集まっておりドキュメントを見れば誰もが理解できる点です。 これはレビューを容易にし成果物のクオリティを高めます。

スライドや付箋、ワイヤーフレームなど様々な表現方法はありますが私は箇条書きでドキュメントにするのを好みます。 前者のような方法は一見は見やすくわかったように感じますが一方で網羅的に表現したり細かい追記をすることが難しいです。 箇条書きであれば細部まで必要に応じて記入することが可能です。 またGoogle Docsであればコメント機能を使うことで追記や確認を依頼したり留意事項を残すことが簡単で非常に便利です。

おわりに

あらためて俯瞰してみると脳みそを使う部分として自分は考えるフェーズをすごい意識しているのだと実感しました。 作るときがケースバイケースすぎて書けないというのもありますが。

この記事でなにが言いたかったのかというと、みんなドキュメントを書こう。