技術本部 Mobile Applicationグループの山本です。名刺アプリEightの開発を行っています。
今回はMobile ApplicationグループのEight開発チームの生産性指標をFour Keysからベロシティを含む別の値に変更した話をします。
一般的にはベロシティは生産性指標にすべきではない、Four Keysは生産性指標として適切であるという評価だと思います。もちろんそれは理解した上でこの選択をしています。その理由について説明します。
なお組織全体がこのように考えているわけではないということに御注意ください。例えば同じMobile ApplicationグループでもSansan開発チームはFour Keysを生産性指標にしています。
生産量2倍計画
現在技術本部では中期的な課題として1年で単月の生産量を2倍にするという目標を掲げています。
ポイントとして、技術本部のレベルでは生産量を2倍にするという目標だけがあり、何を生産量の具体的な指標にするかという点は、各部署で決めることとなっています。そのためまずは、各部署において生産量の指標を何にするか考えるところからスタートします。
技術本部全体としては、プロダクト開発だけでなく、研究開発や、開発管理、データ化と多岐にわたる部署が存在するため、特定の生産性指標が適切、と一概に言うのは難しいです。そのためこのような判断になっています。
なお今後の文章では生産量指標ではなく、生産性指標という呼び方に統一します。生産性というのは単位あたりの生産量のことですが、今回の文章では単位量が時間、計測対象はEightアプリ開発チームで確定しています。そのためチームの時間あたりの生産量、つまりチームの生産性を計測していることになるからです。
Mobile Applicationグループの生産性指標
Mobile Applicationグループでは当初Sansanの開発、Eightの開発共通でFour Keysを生産性指標にしました。Four Keysは他社でも多く採用されていることから一定の合理性があり、一度これで進めてみて問題があれば見直すという判断になりました。Four Keysの説明については多く資料があるので割愛します。
当時EightはV10リリースの開発で非常に忙しく、Four Keysの計測基盤を作る余裕がありませんでした。そのためまずはSansan側で計測基盤の作成を先行して行い、運用しました。しかし、その中でモバイルアプリ特有の問題があることがわかりました。
モバイルアプリとリリース頻度
Four Keysはリリース頻度が強い影響を持つ指標になっています。デプロイ頻度はもちろん、リードタイムも結局はリリース頻度を増やさないと短くなりません。変更障害率とサービス復元時間も、基本的にはリリース頻度を増やして、1リリースあたりの変更量を減らすことにより、該当値を減らすということを目的とした値です。
一方でモバイルアプリでは、Webと比べて過度にリリース頻度を増やすとユーザ体験を損ねる場合があります。もちろん毎日アップデート申請すること自体は可能です。しかしユーザから見るとアップデートの通知もダウンロードも毎日発生するアプリになってしまいます。
Eightでは緊急のパッチリリースを除けば、概ね2週間から4週間に1回程度のリリースとなっています。他社を見てもモバイルアプリにおいては、リリースが多いプロダクトでも1週間に1回程度のリリース頻度のところが多いように見えます。仮に毎週リリースしても1カ月のリリース回数が4回程度になります。
この場合、外れ値の影響が大きくなりすぎてしまいます。1回のリリースで大きな障害があると、他のリリースが全て問題なくても、サービス復元時間を減らすのが難しくなります。結果として、たまたまその期間に大きな障害があったかで値が大きく変動します。
またEightにおいては、V10のような大型リリースの場合にそれ以外の開発を全て止めて集中するので、リリース自体が3ヶ月などの長期にわたり止まる場合があります。この期間も開発は行っているので実際の生産量は0ではありません。しかしリリースがなければ生産性0という判断になります。実際の生産量ではなく、施策に生産性指標が強い影響を受けてしまいます。
生産性指標を考える上で考慮すべき観点
ここで一旦Four Keysから離れて、別の生産性指標について再度考えてみます。完璧に正しい指標というのは存在しませんが、考慮すべき観点というのはあるように思います。
計測しやすく、単位時間内の量がそれなりにある
計測できないものは指標になりません。またリリース頻度の話でも出ましたが、単位期間内にそれなりの量がないと、外れ値の影響を受けやすくなります。
アウトプットに主体的に影響を与えることが可能である
これは例えばMobile Applicationグループの生産性指標としてEight事業の売り上げを利用することが適切かという問題です。
開発組織であっても最終的な目的は事業成長です。しかし品質の高い製品を適切な開発期間でリリースできたとしても、その製品が売り上げにつながるかというのは別です。品質だけではなく、製品の機能やマーケティングや営業の影響も大きいです。そうなった場合に、開発組織の生産性指標として売り上げは適切なのかという問題が出てきます。
事業のKPIであっても問題は同じです。これは開発組織の役割にも依存します。施策の企画と決定も開発組織の役割であるならKPIが適切だと思いますし、施策が別組織であるなら適切ではないと言えます。
意図的な操作が行いにくい
実際のところどのような値であっても意図的な操作は可能です。しかし行いにくい値というのは存在します。
例えば人が決める見積もりの値に比べて、コード行数はレビューが適切であるという前提であれば操作しにくいです。一方で、見積もりの値が他部署から検証されるので意図的な操作がしにくい、コード行数は開発に閉じているので操作しやすいという考えもできます。
多面的である
生産性というのは絶対に正しいものが存在しない以上、複数の値から多面的に捉えることが必要です。その際にお互いが強い相関をもたないようにしないと、多面的である意味がありません。
Four Keysは以下の3つの観点で生産性を測る方法と言えます。これは参考にできそうです。
- スループット
- リードタイム
- 品質
新しい生産性指標
検討の結果、Eight開発チームでは新しい生産性指標として以下を採用しました。いずれもリリース頻度には依存しない値になっています。
またスループットとリードタイムは、プロダクトバックログアイテムを元にした値とプルリクを元にした値を両方取って複数の観点から見ることで、異常値や改ざんについてある程度クロスチェックできるようにしました。
スループット
- プロダクトバックログアイテムの完了数
- 完了したプロダクトバックログアイテムのポイント数合計
- プルリクのマージ数
リードタイム
- プロダクトバックログアイテム着手から完了までにかかったスプリント数の平均値
- プルリクのマージ時間の平均値
品質
- QAの不具合数
- hotfixリリースの数
"完了したプロダクトバックログアイテムのポイント数合計"を採用した理由
上記指標の中で"完了したプロダクトバックログアイテムのポイント数合計"については議論がありそうなので、採用した理由を詳しく説明します。
完了したプロダクトバックログアイテムのポイント数というのは実質的にはスクラムのベロシティです。一般的にはベロシティを生産性の指標にすべきではないとされています。
ポイントは相対見積もりなので、全く同じ案件であってもチームが異なれば異なる値になります。だからペロシティを異なるチーム間の生産性の比較に使うことはできません。
一方でスクラムの書籍の多くでは、スクラムを導入するメリットとして、長期的に同じチームのベロシティが向上することが挙げられています。これは実質的には生産性が上がるということです。
例えばエッセンシャルスクラムでは7章でこの話題に触れられています。ここにおける書き方が微妙なのですが、確かに成長を計測はできるが、それを目標にした途端に作為的に増やそうという意思が発生するということです。
これは理解できる一方で、先に述べた通りどの値であっても意図的な操作はある程度行えます。
KPIのようなユーザによって決まる値は意図的な操作は難しいですが、先に述べた"アウトプットに主体的に影響を与えることが可能である"という点で難しいです。Eightの開発チームは施策に対する意見を言うことはもちろんできます。しかしプロダクトマネジャーとは別組織なので、施策を主体的に変更できるわけではありません。
ポイント数についてもいろいろ問題があることは理解しています。しかし測定したいのは同じチームの成長につながっているかどうかであること、見積もりの基準を明確化することで、意図的な水増しをある程度防げることから、今回はポイント数が適切と判断しました。
おわりに
生産性指標というのは難しいです。自身の組織の状態と計測する目的によって適切な指標は異なります。したがって自分たちで考えて、適切な指標を探すことが重要ではないかと考えます。
共にSansan / Eightのモバイルアプリ開発していく仲間を募集中です！
選考評価無しで現場のエンジニアのリアルな声が聞けるカジュアル面談もあるので、ご興味ありましたらぜひ面談だけでもお越しいただけたら幸いです！
open.talentio.com
