機能ベースリリースにおけるKPIの取り方について

この記事はミックス・スクラムシリーズの記事の１つです。

こういう質問をされました

質問「リリース単位のKPIの取り方ってどう決めればいいんですか？」

チームがスクラムに沿って運営されているというので、リリースゴールのKPIの決め方で迷っているのかな？と思いました。
しかしよく聞いてみると違うそうです。

• リリースは機能単位
• この機能をいついつまでにリリースせよという「プロジェクト」がある
• 今回「プロジェクト」の効果測定のためにKPIを決めることになった

これが前提で、開発チームでKPIの決め方がわからないために上の質問が出たそうです。

まず大前提から話をしましょう。

要するにやることと、いつまでにやるかという納期が決まっている訳です。
そこに後付けで効果測定を入れたい。だからそのためにKPIを決めたいが決め方が分からない、というのが上述の質問です。

はっきり言うと、後付けでKPIを決めることはほぼ不可能だし意味がありません。
テストコードのないプロダクトコードにテストコードを後付けでつけるようなものです。

「この機能をこのスコープでこの期間までにリリースするぞ」と決めた時点でなにかしらのコンテキストがあったはずです。
彼の現場ではその情報はプロダクトマネージャーがいるプロダクトチームから開発チームに渡される時点で切り捨てられています。
それを開発チームが頑張ってリバースエンジニアリングして想像しながらKPIを定めようとするのは無意味だしセンスがないと言う話をしています。

機能単位のKPIの決め方

freeeのリリースノートを例にとって説明していきましょう。

人事労務の申請でタグが使えるようになったそうです。
素晴らしいですね
これが企画段階でプロダクトチームから開発チームに降りてきたとして、KPIをどうするか？と言う話をしましょう。

なにをKPIにしますか？

• つけられたタグの数
• タグ付きの申請数
• タグを使ったユーザーの数
• タグを使ったユーザーがN人以上いるユーザー企業

なるほど。どれもいいですね。
ただ使われているか使われていないかしか分かりませんね。
推移数を追うと言うのは確かにありかもしれませんが、それだけです。

「この機能のリリースによってどの程度のビジネス価値が得られたか？」 を全く説明できていません。つまりKPIとしては不適切です。

たとえばこの機能を上級プラン限定にした場合、アップセルにどの程度寄与できるか分かりませんね。
このおかげで競合プロダクトに対してどの程度の優位になっているか分かりませんね。

あるいはターゲットは誰なのでしょう？
ターゲットが分からないなら使われているか分かる程度のKPIしか設定しようがありません。
クラスタ化していない全ユーザーからバルクで数値取って有益なインサイトが得られるケースは稀です。

そもそも数値分析とは、素人が取れやすそうなところから数字を取ってそれをグラフにしたら有益なインサイトが取れるほど甘いものではありません。
素人の開発チームにKPIを取らせても「それっぽい数値」しか取れないでしょう。

ではこうするとどうでしょう？

プロダクトチームから開発チームに降りてくる情報に利用例が追加されました。

これはいいですね。
「手当がつくケースにおいて、タグが手当の必要な出勤日に付与される」
タグを使って手当を計算する作業時間が短縮されることを狙っていた訳ですね。
ターゲットは「一部の出勤日において手当が付与されるケースがある従業員がいて、そこに作業時間を取られている企業」だった訳ですね。
手当に紐づいたタグを分析すればKPIも取りやすそうです。

機能単位のリリースで何があるとKPIが計算しやすいのか

• ターゲットにしているユーザーの属性
• リリースによりターゲットユーザーが得られる便益
• 便益を得るためにリリースに含まれる機能が使われる流れ
  この辺りが必要なのでしょう。

プロダクトチームが開発チームを「SEは仕様書を渡したら機能をプログラムとして出力するベンダー」扱いしているとこの情報が抜け落ちがちです。

Not 機能, But ユーザーストーリー

この情報を渡すのにシンプルで適したフォーマットはないものでしょうか？

あります。
ユーザーストーリーというものがあります。
INVESTの原則に基づいて作られたよりよいリリース単位のフォーマットです。
このスライドはアジャイルサムライ横浜道場からの引用です

ターゲットユーザーとゴール、完了要件が書いてあります。
ここからKPIが起こしやすいですね。

アトラクタの吉羽さんがいい記事を書いているのでそちらもみるといいでしょう。

機能単位のリリースと違って背景情報やビジネス価値から話が始まるのでKPIも設定しやすいですね。

なぜ機能単位のリリースがまかりとおるのか

ユーザーストーリーなしにリリースのKPIを取るのは不可能です。

しかしこの不便な機能単位のリリースがいまだはびこるには理由があります。

慣れているから

経営陣に対して「この機能 / このシステム」を導入すれば御社のビジネス価値はこれだけアップ！というわけで弊社に発注オナシャス！というコンサル時代の流れ。
コンサル上がりの人間にとって、これをプロダクトマネージャーになった後も社内提案的に繰り返しているに過ぎません。
またそれを社内受託として受ける開発チームの管理職にとってもまた、社内受託は「慣れている」ので気にもなりません。

むしろエンジニアがビジネス価値やユーザー理解をしないといけないスクラム的なユーザーストーリーというやり方は彼らからは奇異に映るでしょう。

リリースした機能についてのKPIが取れなかったとしても何も問題はありません。
SEが追うべきKPIは納期の達成率であって、リリースがゴールです。
ゴールした後に、リリースした機能がどれほどのビジネス価値を生んだかは「ビジネス側のやつら」が考えるべき話。
プロジェクトマネージャーであるマネージャーやメンバーらはそう考えています。

単純で直感的だから

エンジニアの上がりにテクニカル志向とプロジェクトマネージャー志向の２つしかないと思い込んでいる新卒上がりの人間に多い思考です。

初めてIT業界の門戸を叩いた人間にとってマネージャーたちが機能単位でリリースをするぞ！と言われればそういうものだろうと納得しやすいでしょう。

逆にこのリリースがどの程度のビジネス価値を生んだか？は理解することが難しいです。
「それはプロダクトマネージャーやセールスが考えることで、我々は納期までに決められた機能を開発すればいい」
という社内受託的なことを言われればキャッチアップコストが節約できます。

人間は目的がなければ易きに流れることは当然です。

リリースした機能についてのKPIが取れなかったとしても何も問題はありません。
理由は先輩たちがそう言っているから、そして仮に考えたとしてもユーザーやビジネス価値のことなんて知りもしないし知りたくもないからです。

それならユーザーストーリーってやつを導入すればいいのか

まあそうかもしれませんね。
ただ大変ですよ。

ワークさせるためにはプロダクトマネージャーと開発チームが一体となって動く必要があります。
エンジニアはビジネス価値やユーザーについて知る必要があります。
プロダクトマネージャーやカスタマーサポートに任せるなんてもってのほかです。

KPIをとるためにユーザーストーリーを機能させようとすることは分業制の否定です。
分業前提で、そこにユーザーストーリーをちょろっとだけ差し込んだら全て解決するという話ではありません。

そこまでの覚悟がないなら、機能をプロダクトマネージャーが決めた時にKPIも自分で決めればいいのです。
それなのに楽をしようとして開発チームに投げるから、上記の質問が出てきて「分業やめますか？それともKPIやめますか？」という話になる訳です。

あるいはそれっぽい数字ではあるが何のインサイトもない数字で経営陣相手にお茶を濁す話のもいいでしょう。
そういうのは本質的ではないから嫌？
おやそれは残念。

だとすると話が戻るんですけど「分業やめますか？それともKPIやめますか？」という話になりますね。