はじめに

　ぼのたけさんに時間を頂いて、贅沢な雑談をしてきました。メトリクスについてもいい話が聞けたので、自分の備忘も兼ねて記録します。
　ぼのたけさんは、話している内容は論理的なんだけど、感覚を大事にして話す印象を受けました、ゆっくり噛み締めて話してくれるので、言葉が伝わってきて、僕のとっ散らかった言葉も受け取ってくれて、素敵でいい時間をすごすことができました（また声かけますのでよろしくお願いします！！）

人類はメトリクスを扱うにはまだ早い（のかもしれない）

メトリクスに対する（残念な）両極端なふれあい方

　ぼのたけさんとしては、メトリクスは「スクラムで言う検査の道具」なので、適切に使おうよというスタンス。
　しかし「４Keysだけ見て、現場の状況を把握しよう」といった誤った使われ方や、「メトリクス計測よりも優先すべきことがある」の様に、うまく使えないなら使うのを辞めちまおう、的な考え方が目につくことが多く、話が極端になってて、中間がないなーと感じていた様子

数字の魔力

　なんでうまく使えないのかなって考えた時に、数値にとらわれるって事に気がついたらしい。「数値化すると、いつの間にか達成の約束になっている事が多いし、そうなると逆らうのは容易なことじゃない（ぼのたけ）」

現場用・マネージャー用の見せ方

　過去、現場改善のためにメトリクス使う際に心がけていたことは、２種類の見せ方をすること。チームが自分自身のふるまいを評価するためにメトリクスを使うことに懸念がはない、自分たちで実態を知っているから。ただ、マネージャーがメトリクスを知りたがったら、地獄の釜が開く音が聞こえる。ひとりひとりではなく、数値を見てしまうことが多いから。そして、数値の魔力は強い。

メトリクス対するリテラシーが足りてない

　そもそもが４Keysにしても、正しく理解している人が少ない。まだ、マーケティングの領域の方が多い。例えば、アクティブユーザー数が下がったら、直接的な施策を打つ前に、原因を考えるマーケターやプロダクトマネージャーが多いはず。けど、デプロイ頻度が下がったら、デプロイ頻度を直接上げようとするような改善施策を考えるような開発現場の話を聞く。なんで開発領域になった途端に短絡的になるのだろうか。。。。という話で盛り上がった。

スクラムフェス福岡

　そんな話もあって、スクラムフェス福岡で4keysについて登壇したとのこと。僕は過去に、ぼのたけさんのはてぶの４Keysの記事を読んで、全然知らなかったーってなってたので、今回の福岡の話とか、けずった裏話もちょっと聞けて、最高でした。

あらためて、ぼのたけさんにとってのメトリクスとは

少なくとも、スピードメーターではない

　自動車のスピードメーターは、アクセルとブレーキが付いていて、直接的に操作できるようになっているメトリクスだけど、全くそのイメージではない。

体温計みたいな、目安を示してくれるもの

　朝、熱を測って37.5℃だったとする。すると、そこから、先日電車でマスクをしてなかったから風邪をもらったのかなーとか、思えばちょっとお腹も痛いので、昨日食べたお肉がちょっと生だったのかもなーとか、原因分析が始まるはず。その中から、あー風邪かもなーってなったら、ちょっと様子見てみるかーってなり、熱が上がったとしても、状況によってはそのまま自然治癒に任せる、みたいな介入をしないという選択肢を取ったりする。
　ぼのたけさんにとって、メトリクスってそういうものらしい。
「37.5℃：胃腸炎。5日間抗生物質」、「38.0℃：インフルエンザ、即タミフル」とか、体温だけで直接的で短絡的にソリューションを決めてないでしょ、とのこと。そういうことだぞ。

メトリクスで浮き出た状況を的確に表現するための工夫

結局は表現の話みたいだけど、緻密な論理は意識している

　特定条件で20％の確率で観測可能な事象と80％の確率で観測可能な事象は、同じ表現で「発生している」とは書かないでしょ？とのこと。
　一見、ただ表現を変えているだけのようにも見えるけど、裏にあるのはメトリクスで浮き上がってきた事象を緻密な論理で構成して表現しようとする意識。言葉を正確に選んでいる。
　あと、伝える相手にとって意味があり、発生確率が0じゃなければ、主張を伝えるのはありだけど、そのときには、どのくらいの確度なのかもセットでつたえる。シンプルだけど、大事なのはそういうことだぞ。

脱線（Side B)

考える、を使うポイント

　メトリクスの話から転がって、ロジカルに考えるべきポイントってどこがコスパいいのか、っていう話をしました（話がとっ散らかっていたし、自分ひとりで合点したので、この辺のあたりは、ぼのたけさんには理解いただけてないかもしれない。。。）
　自分の思考のクセをふりかえると、ロジカルに考えるポイントはソリューションに偏っていて、そこにリソースを投下していたんですが、実は、状況把握や問題特定を考えることにリソースを投下したほうが、費用対効果が高いのでは？？という気づきを得ました。

多分、ソリューションを実施するコスト ＞ 問題を特定するコスト

　まだうまく言語化できないけど、多分、効果的に考える、を使うポイントは、問題特定へのリソース投入な気がする。問題特定で一度、発散と収束を行わずに、ソリューション検討の段階でいきなり発散と収束をやろうとすると、収束ができないもしくは、発散した状態での運頼みな対応になる気がする。今回、ぼのたけさんと雑談する中で、メトリクスで浮き上がった現状を的確に表現することを意識している姿勢を見て、いい気付きを得られたことに感謝しかない！！あざました！！

Before：
メトリクスが悪化
→　目に付くわかりやすい事象を特定
→　ソリューション検討＆実施（ここに、考えるリソースを投入）
→　効果出ない、再分析（これが経験学習だ、という勘違い）

After：
メトリクスが悪化
→　状況把握、メカニズム分析、問題特定（ここに、考えるリソース投入）
→　特定された問題に対する対応策と効果の仮説を検討
→　効果最大・コスト最小なタイミングでソリューション適用