見出し画像

BI化する前に決めるべき7つのこと

ぶんけい

前段：東京アラートとBI

とてもお久しぶりになってしまいました…
新型コロナと色々な繁忙期が重なり、まったくこの活動ができず。まぁすべては言い訳になりますが。汗

そんななか、東京の感染者数が増え、東京アラートの曖昧さが色々な議論を呼んでいるようです。このテーマが実は、最近僕が感じていたことにリンクしていたので、久々に筆を執ってみようと思いました。

松本さんも仰っていますが、データだけあっても意味がなく、可視化だけされていても意味がない。結局、データは、最終的に意思決定に接続しなければ霧消していくものだということです。おそらくこれは、データ分析界隈の方々だと一層痛感していることかと思います。

それは、東京都副知事の宮坂さんが素晴らしいDashboardをご準備されたのに、これだけ世間の混乱を呼んでいることからも明らかです。BI化しても、それが意思決定、つまりは何らかのActionに繋がらないと、意味がないのです。

しかし、「意思決定が重要」という話はよく聞きますが、「どのように意思決定を促すか」「どのように次のActionに繋げるのか」を言及したものは少ない気がしています。これも当然、「気を付けよう」「頑張ろう」ではダメなわけで、仕組化し、構造としてActionに繋がるようにしなければなりません。

（ちなみに前回は、意思決定に繋がりやすいBI表現の一端、をお話させていただきました）

今回は、BI化する前に決めるべきこと、BIから意思決定までを繋ぐプロセスを整理してみたいと思います。

BI化する前に決めるべき7つのこと

冒頭から結論になりますが、自分なりに整理した結果、下記の7つを押さえるべきだと考えています。

1. Goal
2. 指標
3. 閾値
4. Action（レバー）
5. Owner & Reviewer
6. 閲覧頻度
7. 粒度

1つ1つ、以下で述べていきます。

1. Goal

まず、もはや陳腐化されている印象も否めませんが、BI構築のGoal、目的を明確に定めましょう。

何のために作るのか
このBIで何を達成したいのか
このBIはどんなフェーズで役割を終えるのか

これが軸にないと、後述の議論が二転三転して迷走することがあります。まずは現時点のStartと目的地のGoalを仮定で良いので直線で繋ぐ。そしてその方向性を全員で見定める。関係者全員でこの感覚を共有することが大切だと感じます。

なお、Goalというのは抽象的になりがちですが、以下の2~7を議論していくと自然と具体化されていく部分もあるかと思います。まずは大きな方向性を立て、そのあと解像度を上げていく形でも問題ありません。

2. 指標

何を追うのか。俗にいうKPIで良いかと思います。
ただし、徹底的に具体的に話しましょう。●●率を追う、など話が出てくることがありますが、

例えば、その分母は何で、分子は何なのか。
例えば、その率はいつからいつまでのデータで出すのか。

Business側までその理解が浸透するように、出どころ不明、接続不能な言葉が出ないように、徹底的に定義を繋ぐこと。

別の議論になりますが、このKPIが部署全体もしくは会社全体のKGIにどのように影響するものなのか、ツリー構造で接続なんかできていると素敵です。そうすると、後述するReviewerの責任範囲等も明らかになるので。

3. 閾値

指標を追っていくと、「前週50.5%でしたが今週53.3%でした」「好調…なんだろうけど、ふーん、そうか、そうなんだね」とよくわからない空気になることが多いです。これは、指標とActionの間に、トリガーになる「閾値」がないためだと思います。人やビジネスとは、何らかのトリガーを以ってActionを始めるものなので、この閾値がないとDashboardの役割は半減します。

指標Aを追うと定めた
→ 指標Aが閾値を超えた（＝トリガー）
→ 従前から決めていたActionに移る
●●を超えたら、良い兆候。何が押し上げているのかを調査・報告
●●を下回ったら、悪い兆候。何が足を引っ張っているのかを調査・報告

上記のような形で、Actionを起こすべき上下の閾値（片方だけでもOK）を事前に敷いておくべきでしょう。調査・報告から施策案の立案までできていると尚良しです。

冒頭の東京アラートは、この重要性がわかる良い一例かと思います。感染者数が5月以来100人を超えました。「そうか…そうだね、大変なんだけど…うーん、どうしようか。どうなんだろう」おそらく、多くの都民が似たような感覚だったかと思います。結局、基準（閾値）とActionが連動していなかった。そこに都民は違和感を抱いてしまった。都で整合できていないことを、数多くの都民に納得してほしいというのはとても難しいのだろうなと感じました。（同時に、都には多くのプロフェッショナルが在籍していると思うので、色々な数値と行政判断をまとめるのはもっと難しかったのだろうな…と思わずにはいられません。。。）

なお、そこから一歩先の閾値設定の方法は…色々触れそうなため割愛させていただきます（お察しください案件）

4. Action（レバー）

では、閾値を超えたら、どのようなActionをとるのでしょうか。ここでは、閾値の挙動に対して、何通りかのActionを事前に準備しておくと良いかと思います。

東京アラートの件も、基準（指標と一部の閾値）までは定めていた時期もあったかと思います。ただ、それがActionとは接続しなかった。

画像1

ここでもう一つ大切なのは、「その指標を上下させられる（controllableな）レバーは、そもそも手元にあるのか」ということ。指標を作り、閾値を設け、「さぁActionだ」となっても、実際に指標改善ができるレバーがないと意味がありません。「可視化できたとして、その後、私たちが操作できるレバーはあるんでしたっけ」といった議論が出ると、個人的には「分かっている方々だなぁ」と安心したりします。

例えば、社員の満足度をモニタリングしている企業で、コロナ情勢下でそれが低下している場合。売上が下がり、利益が圧迫され、賞与が出なくなった。それが一因だったとします。「では賞与を出しましょうよ！」というのはActionになりませんよね。それを決めるのは経営層のはずで、しかも実現はかなり厳しいことが自明です。つまりこれはモニタリングしている部門に「レバーがない」という状況です。

こういう手詰まりにならないためにも、事前に「自分らの部門で、左右できるレバーをいくつか整理しておこう」と考えておくのは大切です。なお、こちらは後述する「粒度」で準備します。

5. Owner & Reviewer

指標が定まりました。閾値が決まりました。Actionの選択肢もそろっています。そしてとうとう、モニタリングしていて、閾値を超えました。

…で、誰がやるんだっけ。

で、止まることはよくあります。ここでは、明確なDashboardのOwnerが必要です。これはDashboardを作る担当者とは別で、Business側の数値を追うべき担当者を立てましょう。BI作成者とこのBusiness Ownerが二人三脚の関係になると、Business的には良いドライブをかけられる印象があります。

逆に、こういった明確にOwnさせる（責任が発生する）役割分担をしないと、Dashboardというものは機能しません。気が向いたときに見て「ふーん、そうか、そうなんだね。今こんな感じなんだね」という感想だけで消えていったDashboardたちは多いのではないでしょうか…

また、ちゃんと上司にも責任を持っていただきましょう。その報告先、Reviewerは誰なのかということです。指標のところで少し記載しましたが、KPI→KGIの構造を、Reviewerが把握していると理想です。そしてReviewer側も、「●●の報告を受けたら、このKPIはKGIにどのように作用するから、●●の指示を出さなければならない」などのActionが想定できていると、部下にとっては大変有難い存在になります。ただまぁそこは上司の器量、実力によるところもある（意味深）ので、上司にお任せしましょう。

6. 閲覧頻度

これは単純に、この指標をどのくらいの頻度でみますか、ということ。個人がdashboardを見る回数ではなく、会議体として、モニタリングするのは日次ですか、週次ですか、月次ですか、ということ。感覚的には、現場では日次～週次で、その上だと週次～月次とかになるイメージでしょうか。そもそも、この時点で月次以上のものなら、BIでdashboard化するまでもないかもしれないですね。

7. 粒度

これは前述したAction（レバー）に影響します。指標が閾値を超えたときに、Actionにつながる要素を持っておく必要がある。指標を多面的に掘り下げる（要素分解する）ドリルダウンの粒度を指します。

例えば先ほどの社員満足度のモニタリング、「総合満足度」と「賞与への満足度」「給与・待遇への満足度」しか見ていなかった場合、数値もそれしか見えないので、レバーもそれしか候補がありません。ここに「上司とのコミュニケーション」「同僚とのコミュニケーション」「テレワークの満足度」などを設けておくと、テレワークでのコミュニケーションに課題があり、例えば雑談のような軽めのコミュニケーションを増やそうというActionを出せるかもしれません。

ここの差は「凡事徹底」で言い表されるかも

それぞれを見ると、正直、当たり前のことが多く、新鮮なものはほとんどないかと思います。ただ、これらがすべて準備できた段階でBIを設計する、あるいはLaunchすることも稀な気がしています。

個人的に頭によぎったのは、「凡事徹底」という言葉でした。

- 凡事徹底 -
なんでもないような当たり前のことを徹底的に行うこと、または、当たり前のことを極めて他人の追随を許さないことなどを意味する四字熟語
（「実用日本語表現辞典」より）Link

KPIだとかPDCAサイクルだとか、おそらく登場してから何十年と経過している言葉だと思いますが、未だに上手くサイクルを回せていないケースにあたるのは、この凡事徹底の差なのかもな…と感じています。

まとめた後の気づき…「グラフ表現がない」

振り返って気がついたのですが、「どのように見せるか」（≒グラフ表現）は一切考えていないことが自分でも再認識できました。追うべきものが確定した後、それをどのように表現するかは、あとで自由にやれば良い話なんですよね。センス任せとも言えますが、そこは上記の7要素を確定させる以上に重要なものではないと感じています。

画像2

逆に芸術的なアウトプット、BIを作っておきながら、結局workしないで「So What?」の域を出なかったものはたくさんあるのではないでしょうか。冒頭に記載しましたとおり、Businessへの貢献にならない、つまりはBusiness側の意思決定に寄与しないBIは空虚なものです。

あとこれは…個人の株式投資とかもあてはめられるかもしれないですね。どのくらいの評価損になったら、どんなActionをとるか、閾値とActionが決まっていない方もいるのではないでしょうか。…なにせ僕自身決まっていないので。。。何をコイツは偉そうにぬかしていやがるんだと思いました。汗

終わりに

以上、曲がりなりにもBI Engineerと名乗っている経験者からの整理でした。簡便なBIツールも増えてきて、学習コストも低くなり、今後ますますBIは乱立していくのかなと思います。それらが少しでもBusinessにしっかりと接続され、改善サイクルを回せるようになることに、少しでもお役立てできますと幸いです。また、個人的にBI関連で意見交換できる方も少ないので、ご指摘、ご意見等もたくさんお待ちしております。

[7/9 update] 東京都 新モニタリング項目を公開

東京都が新モニタリング項目を定め、それに対応するようダッシュボードを更新したようです。定義も細かく補足が入っており、素晴らしいですね。

一方で、やはり基準は明示していないようです。
つまり、今回の整理でいくと、「2. 指標」が新モニタリング項目として入れ替わったものの、「3. 閾値」（≒Actionのトリガー）が設定されていないということになります。

◎ 2. 指標
×  3. 閾値
 ?  4. Action（レバー）

ただ、おそらく内内では基準になる閾値が設けられていて、おおよそ、どのくらいの域までいったら「4. Action」をどのようにとるのかは決めているのだと思います。「3. 閾値」ほど明確ではないですが、「新モニタリング項目の全指標を総括して、4段階の総括コメントを出す」という旨の記載があるようです。一部感覚的なものになるのかもしれませんが、総合成績として4段階の基準を準備しているのは間違いないので、その4段階に応じて想定の「4. Action」も準備しているのだろうなと推測します。

素晴らしいエンジニアの方々も参戦して作られている行政を代表するダッシュボードだと感じています。プロジェクトのゴールに接続できるよう、引き続き効果的に運用されますように。


この記事が気に入ったらサポートをしてみませんか？