こんにちは、事業開発部でプロジェクトマネージャー兼エンジニアをやっている新井(@SpicyCoffee)です。10 万円の申請書を書く前に 20 万円のパソコンを買いました。
クックパッドでは、毎日の料理を楽しみにするべく日々サービス開発がおこなわれています。本稿では、サービス開発の中でも重要かつ難解な「KPI の設定」について、私がプロジェクトマネージャーとして普段考えていることや注意している点を紹介します。
KPI を決めるのは難しい
サービス開発において KPI を設定し、それを改善するような施策や検証を繰り返していくことは基本中の基本です。しかしながら、現実には「KPI を設定する」という行為自体の難易度が非常に高く、日夜頭を悩ませている開発者のみなさんも多いのではないでしょうか。 以下では、その要因の一つである「KPI は複数の要件を満たす必要がある」ことについて考えます。
満たすべき要件
具体的にどういった要件を満たす必要があるかはケースによって変わることもあると思いますが、私は普段以下の３点を KPI が満たすべき要件として考えています。
- ユーザー体験 を表現する指標であること
- 事業の収益 に繋がる指標であること
- 自分たちの施策で 動かすことが可能 な指標であること
ユーザー体験を表現する指標であること
KPI を設定する行為は取り組むべき課題の設定であり、すなわちサービスの中で自分たちが次に改善するべきポイントを定義する行為であるとも言えます。このことから KPI は、その指標を改善することで なぜサービスを利用するユーザーの体験が向上するのか を説明できるものでなくてはなりません。
KPI を改善する方法は複数ある中で、この部分の論理立てが不十分なままプロジェクトを進めると「KPI はよくなるがユーザー体験は悪くなっている」というような方法を選んでしまうことにも繋がります。たとえば EC サイトの検索結果において「SEO に効果がある → "ページ閲覧数/セッション" を KPI に据えましょう」という意思決定をするのと、「複数の商品を見比べてもらうことで、ユーザーは真に満足する買い物をすることができるという仮説がある → "ページ閲覧数/セッション" を KPI に据えましょう」という意思決定をするのとでは、結果として設定した KPI が同じであっても意味合いが大きく異なります。
極端な例ではありますが、前者では "ページ閲覧数/セッション" を伸ばすために「１ページ辺りに表示される商品数を少なくする」といったような「指標しか見ていない施策」が実施される可能性が高くなります。一方、後者のようにユーザー体験と KPI を紐付けておくことで、例に上げたような施策はメンバーから異議が唱えられる可能性が高くなり、実施されづらくなります。このことは、ユーザー体験の担保が施策の実行に置いて一種の制約条件のように働いていると捉えることができるかもしれません。
事業の収益に繋がる指標であること
ユーザー体験と同様に重要になってくるのが、その指標を改善することで 事業の収益にいい影響を与えることができるか、そしてその規模は十分か という観点です。
長期間に渡ってユーザー体験をよくし続けるためには、その源泉となる収益を得ることについても必ず考えなければなりません*1。どれほど質の高いサービスや機能を提供できたとしても、それが収益につながらなければ継続的に改善を続けることは難しく、結果として機能を落としたりその領域から撤退したりすることになってしまいます。
したがって KPI は、現状存在しているマネタイズ方法に繋がるか、新しくマネタイズ方法を定義しそこに繋がるものである必要があります。
自分たちの施策で動かすことが可能な指標であること
当然のことではありますが、KPI は自分たちで 観測・改善ができるもの でなくてはなりません。それを担保するためのポイントとして「実装・集計の容易さ」と「外部要因の少なさ」があげられます。
前者については、実際にログを仕込んだり集計をする作業が自分たちが持っているリソースで可能かどうかを考える必要があります。たとえば、サービスのログ基盤が大量のログを収集・加工するのに十分なほど整っていないのであれば、複数の画面操作を組み合わせたような複雑な指標は避けるべきでしょう*2。プロジェクトに与えられた時間が３ヶ月なのであれば「一ヶ月後の再利用率」のような観測に時間のかかる指標は避けた方が無難です。
後者については、KPI の変動要因が多すぎないかどうかを考える必要があります。たとえば、施策を打っていない状態で A/A テストをした結果に差があるような指標は、平時からの変動が激しすぎる（≒多くの外部要因がある）と考えて避けるべきです。また、一般的には指標を実現するために必要な操作が多くなるほど、ノイズに近い離脱・誤操作が発生しやすくなり、施策を打ったときの効果が見えづらくなってしまう傾向にあります。
どう考えるべきか
以上に挙げたポイントを満たすような KPI を設定するのは非常に難しく、どこから手を付ければいいかわからなくなることも多々あります。しかし、一段抽象化して考えれば、これは複数の制約条件を持つ問題をいかに解くかという話になります。一般に複数の制約を満たす必要がある問題を考える際には、制約の最も厳しい条件から考えた方が後の手戻りが少なくなります。したがって、まず最初に手を付けるべきは、自分たちの環境において どの条件が最も厳しい制約か を考えることです。
「複数の制約を満たす」と聞くといわゆるベン図が頭に浮かぶ人も多いかもしれません。たとえば『ビジョナリー・カンパニー２』には、「情熱をもって取り組めるもの」「自社が世界一になれるもの」「経済的原動力になるもの」のすべてを満たすコトを対象にビジネスをしなさいと書かれており、その図解として以下のベン図が掲載されています。
私自身この考え方は好きで似たような図もよく頭に思い浮かべますが、一つだけ疑問があるのは「この円のサイズは果たして本当におなじなのだろうか？」という点です。そして上記の主張をこの疑問に沿って捉え直すと、「まずは 最も小さな円について 考えよう」という話になります。
たとえば、すでに多くの機能を持ち、提供できるユーザー体験やそれを表現するための指標は大量に考えつくが、マネタイズの方法自体はそれほど多くないような大規模サービスでは下図左側のような図になります。この場合はまず事業の収益に繋がる指標をいくつか思い浮かべ、 その指標をよくしながらユーザー体験を向上させるにはどうすればいいか？ という考え方をした方がよいでしょう。
逆に立ち上げたばかりのサービスでは、実現するべきユーザー体験はこれと決まっているが、マネタイズの方法については模索中で多くの可能性があり、ベン図は右側のような図になるかもしれません。この場合は、ユーザー体験を表現する指標をまず設定し、 その指標をよくすることで収益を上げるにはどうすればいいか？ という考え方をするのがよさそうです。
このように、組織や置かれている状況や個人の知識・経験によってそれぞれの円の大きさが変化する中で、最も小さな円＝取りうる選択肢の少ない円についての要件から満たすように KPI を考えることで、すべての制約を満たした指標を設定しやすくなるのではないでしょうか。
またこれは、裏を返すと KPI や取り組むべき課題を設定する際には 円の一番小さいところから考えざるを得ない ということでもあります。つまり、たとえば先にあげた大規模サービスの例においてよりよいユーザー体験を作りたいなら、逆説的に一番小さな収益性の円を大きくする必要がある のです。これは個人の行動にするとたとえば書籍等からビジネスに関する知識を得たり、組織の置かれている状況について情報を収集したりして、収益に繋げる方法を新たに発見するといった行為になります。ログ基盤が整っていないせいで実現可能性の円が小さいのであれば、ログ基盤を整えることで取りうるユーザー体験の選択肢が広がるということです。これは、サービス開発に技術力が必要になる証左でもあります。
施策を実行する際の注意点
ここまでの話は KPI の設定について述べたものでした。ここからは、私が実際に実施する施策の中で指標に関して注意している以下の 3 点について述べます*3。
- KPI そのものも改善サイクルの中で変化しうる
- 施策で追う指標は３点セットで設定する
- 施策の採用ラインは必ず事前に設定する
KPI そのものも改善サイクルの中で変化しうる
KPI そのものも絶対に不変のものであるわけではありません。KPI の設定が課題の設定と密になっている以上、事業を取り巻く環境や自分たちのサービスに対する理解が変化する中で取り組むべき課題そのものが変化し、KPI を変更した方がよい可能性があることは頭に入れておくべきです。
もちろん中長期で改善を進めていく指標として設定する以上、あまりにコロコロ変化するのは好ましくありませんが、時には「この KPI は本当に追うべきなんだろうか（＝この課題を本当に解決すべきなのだろうか）」という思考を持つことも重要です。特にプロジェクトが発足してすぐのタイミングでは、先にあげた３条件に対する理解がチームの中でも不十分な可能性が高く、施策を重ねる中でその精度を上げた結果 KPI が変化することはよくあることかと思います。
施策で追う指標は３点セットで設定する
実際に KPI を改善するために施策を実施する際には、観測する指標を以下の３点セットで設定するようにしています。
- KPI
- 機能利用率
- 副作用指標
KPI
設定した KPI です。
機能利用率
施策の意図が実現できているかを確認するために、実装した 機能が実際に利用されているか が確認できる指標を設定します。たとえば「直帰率」という KPI を設定し、その改善のために LP に新しいコンテンツを設定した場合、そのコンテンツのタップ率等を設定することになります。この指標を確認しなかった場合、KPI が動いたとしてもそれが意図したユーザー体験の変化によるものであるということが担保できなくなってしまいます。
副作用指標
実施した施策によって 既存コンテンツに影響を与える 可能性がある場合、その影響も観測する必要があります。先にあげた直帰率を改善するためのコンテンツの例であれば、その LP にもともと存在していた別導線のタップ率等を設定することになります。この指標を設定しなかった場合、意図したとおりに KPI が改善できたとしても「他の指標が悪化してしまい事業全体としてはマイナスになってしまっていた」というケースに気がつけなくなってしまいます。
施策の採用ラインは必ず事前に設定する
それぞれの指標がどの程度の数値になったときに 施策を採用するのかという目安の数字は必ず事前に設定 します。事後になってから議論しようとすると、せっかく作ったのだから採用したい気持ちが勝ってしまったり、最悪の場合ロクな議論もなく施策が採用されたりすることになりかねません。むやみやたらに機能を増やしてもユーザーの混乱を招くことに繋がるため、施策の採用については慎重になるべきであり、そのためにも事前に期待される効果等から採用ラインを設定することには大きな意味があります。
加えて言うと PM の立場であれば、施策が成功したときと失敗したときのそれぞれで次にどういった手を打つのかということも事前に想定しておく必要があります。
終わりに
冒頭にも述べましたように、この記事は私が実際に KPI を設定したり、それに基づいて施策を実施したりする際に注意している点をまとめたものです。サービス開発についての知見はその性質上「絶対の正解」が存在せず、また、それゆえに明文化されることが少ないものでもあると思います。私自身にとっても、この記事は「言語化しづらい思考を明文化して残す」という挑戦の一つであったのですが、これがみなさんのサービス開発の参考になればうれしいです。
クックパッドでは、このようにサービス開発について考えを巡らせながら、自分で手を動かして実際に開発を進めることのできるエンジニアを大募集しております。興味のわいた方や、この記事の内容について話がしたい！と感じた方はぜひ気軽に声をかけていただければと思います。
採用ページ: https://info.cookpad.com/careers/
*1:事業が投資フェーズであり、会社全体としては別事業の収益でバランスを取っているケースなどは別です
*2:あなたがエンジニアであれば自ら基盤を整える選択肢を取ることもできます
*3:後半２つについては以前書いた記事でも触れているのでよければ合わせてお読みください → https://techlife.cookpad.com/entry/2018/02/10/150709
