KPIだけのプロダクト品質評価はやめよう
こんにちは。@rilmayerです。
最近は仕事の中で「施策評価のための指標の整備や運用」、「データに関わるシステム設計の相談」、「データのビジネス活用提案」などの仕事に関わっていました。
さて、そんな中、誤ったKPIマネジメントによってプロダクトがうまく評価できていないことがあるのではないかということが気になっており、それについてまとめてみようと思いこの記事を書きました。
この記事では主にWebサービスやソフトウェア、スマホアプリといったプロダクト（この記事ではまとめて"IT系プロダクト"と呼びます）のディレクションで「KPIの達成だけを目指すこと」や「特定指標の（短期的な）上昇・下降によってプロダクトの品質評価をしてしまうこと」などの危険性について考察します。
KPIマネジメントの有効性については様々なメディアで語られており、私自身もその有効性には賛成です。したがって、この記事ではKPIの危険性にフォーカスしてはいますが、KPIマネージメントを否定するものではないことにご注意ください。
KPI：重要業績評価指標
この記事はKPIに馴染みのある人向けに書かれてはいますが、まずはこの記事で扱う「KPI」という用語について整理しておこうと思います。
以下は「中尾隆一郎. 最高の結果を出すＫＰＩマネジメント」で説明されているKPIの説明です。なお、KPIについてはKGI、CSFという考え方とセットで理解するのが良いので両者についても一緒に示しています。
KGIはKey Goal Indicatorの略で、最終的に期末に到達したい最も重要な数値目標のことです。
[中略...]
CSFはCritical Success Factorの略です。直訳すると「重要成功要因」。
[中略...]
KPIは、KGIの先行指標で、（現場がコントロールできる）プロセス指標で、CSF（事業成功の鍵）の数値目標です。
（「第1章 01 KPIって何ですか？」より）
この記事でも上記の定義に順って「KPI＝事業成功のために選択した手段の成否を定量的に測れるようにした数値目標」という意味で用います。
ではKPIマネジメントとは何でしょうか？
同著では以下のように述べています。
ＫＰＩマネジメントは、最も重要な数値だけに焦点を絞ってマネジメントしようということなのです。
（中略）
なぜ組織にＫＰＩマネジメントが必要とされるのでしょうか？一言でいうと、ＫＰＩマネジメントを活用してマネジメントそのものを進化させるためです。
（「第2章 KPIマネジメントを実践するコツ」）
つまり、KGI（重要な数値目標）を達成するために必要なCSF（重要成功要因）を選定し、それを測るKPI（重要成功指標）を設計することによって、方向性を定めてチームの力を集中して、目標に向かうことができます。きちんとしたKPIマネジメントがなされていれば、クイックかつ組織の力を集中して成功要因の検証を行うことができます。
このKPIマネージメントについて、私は2つの危険性が存在すると考えています。
1つは「マネージする側・マネージされる側がきちんとKPI（KPIマネージメント）を理解して行動に移せていない可能性」、2つめは「KPI選定の失敗を検知できず、無意味もしくは有害なKPIを追い続けてしまう可能性」です。
まずは1点目についてです。KPIをきちんと理解せずに組織で活用してしまうと、様々なトラブルが生じます。たとえば、経営陣がKPIを設定して現場のメンバーがそうしたKPIを追いかける場合を想像してみます。
設定されたKPIが納得感のないものである場合は、現場のメンバーは「きちんと考えてKPIを設定しているのだろうか？」と考え経営への不信感が高まったり、「意味のあることなのだろうか？」と思いモチベーションの低下が起こったりすることがあります。
そうした事態を防ぐためにも「なぜそのKPIを用いるのか」をKPI向上に責任を負うすべてのメンバーが納得して、KPI向上に取り組む必要があるです。
2点目のKPI選定の失敗を検知できずに無意味もしくは有害なKPIを追ってしまう可能性については、常に注意する必要があります。
KPIとはビジネスの最重要指標であるKGIを達成するために、仮説として設定された要因を測る指標です。事業スタートのフェーズでは仮説が間違うことはよくありますし、そもそも人が作った仮説が必ず当たるは考え難いです。
そのため、一定の期間や定期的にKPIそのものを見直す必要がありますが、KPIの未達成や仮説の間違いを認めたくないという組織的な力学が働いてしまうこともあり、それらを問い直すのは中々骨の折れる仕事です。
ですが、いつまでも間違った仮説を追い続けるほど無意味なことはありませんし、それが時としてサービスを殺してしまうことも十分に注意する必要があります。
KPIマネジメント ≠ IT系プロダクトの品質評価方法
ここまで見てきたように、KPIはあくまでも「売上や利益といった達成したいゴール=KGI」に対して、「こうすればうまくいくという仮説=CSF」を数値により定量的に測れるようにしたものです。
このことから分かるように、KPIの主戦場はプロダクトの品質評価ではなく、目標を達成するためのマネジメントです。
では、プロダクトの品質評価とは何かと言うと、現状の分析を通して「どこが」「どのくらい」「良いのか/悪いのか」「どうするとより良くなるのか」を明らかにすることだと私は考えます。この考えは一般的とは言い難いですが、ソフトウェアの品質評価などの文脈を参考にして定義しているため、そこまで受け入れ難いものではないかと思います。
こうした評価を行うためには、プロダクトの目的達成を測る軸に加えて、多面的な側面からの分析が必要となります。
指標はあくまで結果の一側面でしかない
当たり前のことですが、これは気をつけないと意外と忘れてしまうことだと思います。
設定されたKPIには「切り捨てられた側面」や「隠された変数」が大量に含まれています。さらに、KPIには設計の段階で「AよりもBの方を重視する」といった思想がふんだんに含まれているために注意が必要です。
そこに注意がいかないと、KPIにより隠されてしまったAが見えづらくなってしまうことがあります。
以下はKPIを追う際に、隠れた変数を見逃して失敗してしまうような事例です。
KPIの失敗事例
例えば、とあるカタログサイトが「今よりも多くのユーザーにカタログを届ける」ことを目指して、KPIを「カタログの問い合わせ数（CV数）」に設定したとします。
ある日Webサイトの運営者が行った施策によって、CV数が今までよりも改善したとします。
しかし、よくよく調べてみると、日に日に訪問ユーザー数が減っており、一部のユーザーが大量にカタログを仕入れている状態であることが分かりました。
この施策は良いものでしょうか？
上記の例はKPI設計の段階で単純に欠如している観点があったということなのですが、ここは普通に考えて「訪問ユーザー数」も大事な例ではないでしょうか。
もし、上記の例でKPI至上主義の元にひたすらCV数を追ってしまっていたら、状況がかなり悪化した時に初めて「やばいかも！？」ということに気付くことになるかもしれません。
「有意差」が特定指標による判断を後押ししてしまう
実際の業務においては意思決定の補助ツールとして、統計分析が行われています。その際たるものがA/Bテストによる施策間のKPI指標比較です。
こうした一般的なA/BテストによるKPIで判定できるのは「観測したある指標の変化が2つの施策間で統計的にどの程度起こりにくいものだったか」という事実のみです。
（手法によっては他の情報も得ることができます）
「有意差」と言われるとなんとなく良さそう（もしくは悪そう）という意思決定がなされてしまうことも多いのですが、指標の差が統計的に大きいという「事実」をもとに、結論を「考察」することが重要だと私は思います。
現実のプロダクトは1つの指標で測れるほど単純ではない
一部の人ですが、上記のような統計分析の「有意差」を単純にGood or Badが測れる魔法のツールのようにみなす空気がありますが、そんなことはありませんし現実の問題はもう少し複雑です。
確かにシンプルな指標だけ追えば、わかりやすいですし時間を節約できるかもしれません。
しかし、企業、そしてプロダクトのオーナーによる最も重要な財産であるプロダクトの評価において、特定の指標だけで良し悪しを判断するのは本当に良いことなのでしょうか。現実の問題は複雑だからこそ、頭を使わなくてはいけないと思うのです。
どのようにKPI（指標）を活用すべきか、あるいはプロダクトをどう評価をすべきか
Search Quality Meeting: Spelling for Long Queries (Annotated)
この動画はgoogleの検索において、とある新機能を追加すべきかどうかという議論の様子を写したものです。
この動画のポイント
・指標についてはインパクトの議論等で軽く触れられているのみ
・参加者（＝決定権を持つ人たち）が、新機能についてその内容をきちんと知ろうとしている
・新機能がユーザーに対してどんな影響を与えて、今後のサービスがどうなるかが議論されている
この動画から学ぶべきこと
会議の参加者、特に意思決定者が新たな機能を出すことが会社にとって本当に良いか、ユーザーのためになるか、ということを機能の中身からきちんと考えています。そして、考察を補助する道具として各種指標を元に結論を出しています。
これがある種プロダクトと向き合う一つのあるべき姿なのかもしれません。
とはいえ現実でこのような判断を実践するのは難しく、以下のような状態に陥ることもあるかと思います。
現実で起こりうる意思決定の危険信号
あなたやあなたのチーム、もしくは会社における意思決定者が以下のような思考をしている場合はちょっと危険かもしれません。以下の例はちょっと大げさですが、これに近いことが起こっている場合もあるのではないでしょうか。
その他シグナルの軽視：「他の指標がどうなったかよりも、その施策で売り上げがどうなったかを知りたい。」
特定の指標だけ動くということは通常ありません、連動して複数の指標が動くのでその背後のメカニズムに意識を向けれると良いかもしれません。
副作用の無視：「（UU数が減少しているけれど）CVRが向上しているなら良かったね。」
強力な施策ほど何らかの副作用が起こりえます。通常KPI設定時に「ただしこの指標は下げない」といったカウンターインデックスを設けますが、最初からうまく設定するのは困難な場合もありますので分析時に追えると良いかもしれません。
長期的視点の欠如：「（長期的には悪影響が出るかもしれないけれど）今期のKPI目標はとりあえず達成できそうで良かった。」
短期的に効果があったとしても、効果の先食いである場合も往々にしてあります。施策による各種指標の伸びが短期的なものなのか、今後も期待できるものなのかを考慮に入れる必要があります。
因果推定の放棄：「機能の内容とかどうでも良いから、結果がどうなったかだけ教えて？」
機能の内容をきちんと理解せずに結果の意味を解釈できるだろうか？なぜ、その機能によって指標が変化したかがまったく分からない場合、効果があったかの結論はつけられません。
特定指標だけで判断し続けた先にあるもの
KPIを追い続けることによるもう一つの弊害として「手段の目的化」が挙げられます。以下のブログで良い事例が紹介されていました。
ここでは、とある本の紹介を通して、計測する値がいつの間にか目標にすり替わることによって生じる種々の不都合が説明されていました。以下はブログ内容の引用です。
たとえば天下りマネージャーがやってきて、今度のプロジェクトでバグを撲滅すると言い出す。
そのため、バグを出したプログラマやベンダーはペナルティを課すと宣言する。そして、バグ管理簿を毎週チェックし始める。
すると、期待通りバグは出てこなくなる。代わりに「インシデント管理簿」が作成され、そこで不具合の解析や改修調整をするようになる。「バグ管理簿」に記載されるのは、ドキュメントの誤字脱字など無害なものになる。天下りの馬鹿マネージャーに出て行ってもらうまで。
こうした例はKPIだけをひたすら追い続けてしまった場合の末路として簡単に想像できます。
事業やプロダクトとして、本来であれば「売り上げ」や「利益」といったKGIを伸ばすことが目標であるはずなのに、KPIを伸ばすことが目標になってしまうと良く分からないことになってしまいます。
KPI上がった/下がっただけで判断し続けていたら、色々とダメになるかもしれない
現場の分析者がKPI上がった・下がった（だから成功・失敗）という単純な報告をしてしまうと、大企業の場合は経営者に（報告されるまでいくつかの報告者が挟まるので）さらに単純化した報告がなされることになります。
そうした単純なKPIの達成・未達成による施策の判断を繰り返していくと、非常に単純な結果のみを元に経営判断がなされる可能性があります。
もしそういう進め方をしている場合、その先にどんな状況になっていくのかは分かりませんが、きちんと考えることを放棄するのはあまり良いことではないかもしれません。
おわりに
ここまで書いてきてなんですが、上記の状態は意識しないと自分もやってしまいます。（その方が楽なことが多いのです。）
「このKPIが上がったから、この施策は成功です。（ ⇔ 長期的な影響は知りませんし、その他指標についても知りません）」
「KPI下がったのでこの施策は失敗です。（他のところでユーザーにとって良い効果があるかもしれませんが・・・）」
自分も以前、上記のような報告をやってしまっていました。
もしかすると今も気を抜いたらやってしまっているかもしれません。
この記事はデータから施策の良し悪しを判断するような仕事に関わる自分への自戒を込めたものでもあります。
しつこいようですが、この記事はKPI達成や単純な指標だけを追っていると危険かもしれないということを主張するものであり、KPIを設定しなくて良い・KPIマネージメントをやめようという主張は一切していないのでご注意ください。
また現実の問題は複雑ではありますが、よりシンプルに考えられるならばもちろんそちらの方が色々と有益です。複雑なモデルと単純なモデルがあり、実際の問題に関する表現力がそこまで変わらなければ（もしくはある程度表現力が落ちたとしても）単純なモデルの方が有益なことは多いと思います。
細心の注意を払いながらKPIを扱うことで、私やあなたが関わるプロダクトはもっと良いものになっていくのではないかと思う今日この頃です。
もしこうした、データに関する意思決定や活用にお困りの方がいらっしゃいましたらTwitter等お気軽にご相談ください。
参考リンク
この記事を書くにあたって、以下のリンクを参考にさせてもらいました。
システム／ソフトウェア製品の品質要求定義と品質評価のための
メトリクスに関する調査報告書