KPI設計について最近色々考えたり調べたりしたので考えをまとめてみた。ここではKPIの決め方と運用の仕方、それを開発組織にどう落とし込むかを考えていく。規模的には30-40人ぐらいの開発体制で自社サービスの組織という前提で考える。
KPIの決め方
KPIの目的
KPIを設定する目的を下記においてまとめていきます。
- 施策を本質的なものに集中させる
- 戦略を明確化することでメンバーがなにをすればいいか考えられるようにする
- チームのモチベを上げる
本質的な価値と経済的な価値を分ける
KPIのその先の目標には二種類あると思っていて経済的な指標と本質的な指標があると思います。KGIは企業でやっている以上、最終的には大体が利益になるのかなと思います。ただ利益というのは短期的には本質的な価値でなくても上げれます。例えば極端にいうとアプリへの広告掲載を２倍にしたら短期的には２倍とまでいかなくても1.数倍にはできるでしょう。ただこれってアプリの本質的な価値を上げているわけではないので長期的に見ると大きな損をしています。経済的な指標、利益のみを短期で追うと本質的な価値を下げかねません。
そこで本質的なそのサービスの価値と経済的な価値を分けて考え、
- それぞれをどう上げるか
- 本質的な価値を通じて経済的な価値をあげれているか
を考える必要があるのかなと思っています。
因数分解して率と母数どちらかにKPIを設定するのは危険
多くのKPIが因数分解をすると実数×率になると思う。例えば
CV数=リーチ×CVR
みたいな。
この場合、各チームにリーチとCVRをそれぞれ上げてもらうとすると質の悪いリーチを片方のチームが集めてきてCVRのチームの目標を下げるなんてことが起きがち。それが起こらないように両チームに全体のKPIも持たせたほうがいいかなーと思っています。つまりチームのKPIを通してちゃんと全体のKPIもあげようと設定することになります。
それをKPIにおいて意味があるのか？実際にコントロールできるのか？
KPIの目的にチームのモチベを上げるを入れています。これはKPIがチームの努力で上げれるものであることが前提になります。どんだけ努力しても上がらない数値をみるのは気が滅入るものです。実際にコントロールできる数値まで因数分解して落としていくことが重要になってきます。
実際に運用してみよう
上記で決めたKPIをどう運用していくかを考えてみた。
チームとのコミュニケーション
KPIを上記のようにチームのモチベアップなどを目的にしている場合もちろんチームが納得するものでないと意味がない。そのためにはどこをチームと握ってどこを経営陣が決めないといけないかの線引きをちゃんとすることが重要なのかもしれない。今のところ経営陣が事業全体のKGI、それを達成するための途中経過としてKPIを決め、そのKPIの達成する数字と手法をチームと決めるがベストだと思う。
どの時点で達成するのかとその共通認識をメンバーと確認する
KPIはかならず時間軸とセットにして考えないといけない。１００年後だったらどんなKPIもいつか達成してしまうので。
チームへのKPIのもたせ方、振り返り方
ある程度大きい目標を達成しないといけないので３ヶ月単位ぐらいで目標は設定すべきだけど振り返りは細かいほうがいいだろう。週や隔週で振り返ってそのKPIにどれくらい近づいているかをちゃんと確認したほうがいい。プロマネはチームのメンバーに進捗や効果測定をちゃんと伝えるのが義務。基本数字をメンバー全員が追って正確に効果測定をするのは難しい。ちゃんと噛み砕いて伝えるのが重要。
またKPIは運用していく中で修正する必要がある。例えば思ったよりリソースが足りない、思わぬ要因でKPIが動かないなど確実と言っていいほどある。ちゃんとその修正の振り返りもする。
開発組織はどう目標を持つのが良さそうか？
自社サービスの会社の場合、受託ではないのでエンジニアがコードだけ書きたいと言う人のみの場合きつい。受託ではなくなぜ自社でエンジニアを持っているかというとエンジニアにそのプロダクトの文脈を理解し、それを仕様に落とし込むところを求めているから。KPIもエンジニア、開発組織も一緒に考えていく組織こそ自社サービス会社の開発組織のあり方だと思う。
プラットフォーム、機能でのチーム分けは機能しなさそう
開発組織に目標をもたせる際によくやるミスはプラットフォームごと、つまり開発組織のチームごとに目標をもたせてしまうことだと思う。KPIはプロダクトの目標に紐付いていないといけない。開発組織としては同じ言語、プラットフォームでの連携が多くなるためそのチーム分けでもいいけどもしプラットフォームごとにKPIを設けると例えばandroidをリファクタするなど技術に向いた目標になりがち。これではプロダクト自体の進捗は無い。
連携を図るためにプラットフォームごとに分けてもいいが目標はプロダクトの目標ごとに持たせるべき。
仕様ぎめのメンバーとできれば一緒に
じゃあ目標をもたせるチームはどういう構成になるのかと考えたときに仕様ぎめをするチームとイコールになったほうがいい。例えばアプリの滞在時間を伸ばすチームにKPIを滞在時間をもたせた場合、アプリの仕様を決めるサーバー、android、iOSからそれぞれ連れてきてそのメンバーに目標と仕様を考えてもらう。目標を持つ人と実際に仕様を考える人が別だと頭と体が別なのでコミュニケーションコストが発生する。またモチベもわかない。
そのチームで仕様ぎめが完結するようにプラットフォームを横断したチームを作るのが良いかなと現時点で思っている。
エンジニアにKPIを担当させるべきか？
そもそもエンジニアにプロダクト側のKPI、例えば滞在時間などをもたせるべきなのか？という議論もあると思うけど基本的には持たせるべきだと思う。上記にも書いたように自社サービスの会社の場合、求められるエンジニア像はユーザーに価値を与えるために行う施策を技術面で実現することで技術だけで完結することはない。ただ、技術力と施策を考える力は別で技術に特化した人もほしい。これは人によって向き不向きがあるのでエンジニアとちゃんとコミュニケーションを取って決めるべき内容だと思う。
技術負債を貯めないためにすべきこと
と上記でプロダクトの目標をどう開発組織で実現するかを書いてきたがこれだけだとその目標からはずれたものは対処できない。そうなると例えば技術的な負債がそのままになったりする。これの対処は正直まだいい案が見つかっていない。強制的にリファクタの期間を用意するなどいろいろあるが根本的には技術を理解した人間がちゃんと経営陣に影響力をもって発言し、経営陣が正確に天秤にかけられるかが重要な気がする。
