本記事は開発生産性 Advent Calendar 2022 カレンダー2の25日目の記事です。
24日目はFindyさんの@dai___youさんの開発生産性可視化・向上の取り組みにおける投資対効果の考え方でした。
はじめに
株式会社うるるの @hokutohagi です。
NJSS というサービスにてデータ基盤の構築やスクレイパーの開発に携わっています。
アドベントカレンダーの枠があいていたので急遽飛び入り参加してみました。
NJSS の開発チームでは、開発生産性に対して取り組み始めました。
さらに10月からスクレイパー開発のチームに入ることになったので具体的な改善の取り組みを行ってみたら大きな変化があり、その振り返りと一連の経緯から生産性について考え直してみたことを書き連ねています。
取り組みを始めた経緯
正直、最初は深く考えずに勢いで取り組みを始めようと思い立ちました。
元々、7~8年程前にはなると思いますが、自身で GitHub の Pull Request（以下、プルリク） のデータをスプレッドシートに吐き出して傾向を分析するなどをしていたことがあり、必要性の高さを認識していたのが大きいかもしれません。
また、こういったテーマについてはEMとしての役割を担っていた頃から課題感を覚えていました。チームのベロシティなどを含めて可視化しながら改善活動に使えるツールを探してCode Climate Velocityを検討したものの、サポート担当から言語の壁とタイムゾーンの壁があるとサポートができないからと利用を断られたりなどしていたこともあります。
そういったことがあったので細々とアンテナを貼っていたところにFindy Team+というサービスが始まったことを知り問い合わせをしてみたところ、やりたいことにピタリとハマりそうだったので急いで予算の調整をして利用を開始しました。
（Code Climate Velocity と比較して費用が5分の2（40%）ほどだったのでキタコレ!!!、となりました）
なぜ開発生産性に着目したのか
そもそも、なぜ生産性に対して取り組むことが大事なのかという話については 「マーケットに対しての打席に立つ数を増やすこと」 に他ならないと考えているのですが、具体的な部分はこの記事では記載しません。
ランサーズさんの以下の記事に記載されているような内容に共感を覚えており、目にされている方は多いかもしれませんが是非ご参照ください。
開発生産性は企業にとって競争力そのものであるという話
実際の取組みと成果
さて実際にわたしがいるチームで取り組みをしてみた内容とその結果について見ていきたいと思います。
まずざっと半年間のサマリーです。
具体的な取り組みは11月前半から取り組み始めたのですが、明らかに「1人あたりのプルリク数」が上がってきています。
また、プルリク作成数と各種リードタイムの数値にも相関関係があることが見て取れます。
結論から言うと、 意識的に取り組んでみたら着実に成果に繋がった という結果なのですが、まず何を取り組んだのかを記載してみます。
取り組んだこと
取り組んだテーマは1つでした。それは 意図的なプルリクの分割 です。
可視化を始めた後、様々な指標が見えるようになったことで大変テンションが上りました。
指標単位/時期単位/チーム単位/個人単位で比較したりしてみたのですが、欲張りすぎていていました。
上記の単位ごとに見方を変えて比較していたことで差異を見つけることはできたのですが、改善に繋がる具体的な一手が見出しきれませんでした。
（これについてはまさにわたしの分析と仮説設定の能力が未熟であることを痛感させたことは言うまでもありません）
この状況において、Findy Team+ を運営するFindy社のCSの方から 「とりあえずプルリク分割取り組んでみたらどうですか」 という旨の提案を受けました。
有無を言わずに「そりゃそうだ、やってみるほかない」と感じたのを記憶しています。まっとうに切り込んで頂けるサポートに感謝しています。
なぜすんなり受け入れることができたかと言うと、自身の経験則に加えて過去にオフショア開発文脈で同様のことにアプローチしていたことがあったからでした。
オフショア開発経験から感じていたこと
オフショア開発をしていた当時、オフショア開発現場を任せれていた自分に対して多くの意見がありました。
それを集約するとこんな感じてす。
- オフショア現場での開発のスピードが遅い
- オフショア現場での開発の品質が低い
- オフショア現場、コスト高いのでは
ざっくり、QCDの中のQuality/Deliveryが期待に足りないので、結果的にCostに跳ね返っているという構造でした。
（つまりチームをうまく運べていなかったことは察してください）
オフショア開発現場で動いている立場としては否定したい感覚を持ちつつも否定しきれないような話でありながら、ただそれでも違和感がありました。
冒頭に記載したようにGitHub上の活動を分析したことがあるのですが、プルリクを中心にしたコミュニケーションに課題があることがわかりました。
プルリクが大きいのでレビューに臨むのが億劫になる、リリースが怖い、だから最終的なリリースまで辿り着くのが遅くなる。
だから分割を試して改善を試みよう、という文脈があり、今回の文脈も同じ話だと捉えたので取り組みやすかったということでした。
具体的に取り組んだこと
具体的に「プルリクの分割」に対して取り組んだことを記します。
...
偽らず、他社で取り組まれている下記のようなことを真似させて頂きました！🙇♂️
プルリクエストを作りまくることで得られたFindyの爆速プロダクト開発術
コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTips
その中で我々のチームで採り入れたやり方としては、まず下記を大前提としていました。
- フィーチャーの中でタスク分割
- タスク毎にプルリク作成
イケイケ分割いいですね！（当然がむしゃらではなく、分割意図ありです）
その上で出てきた課題に対して下記のやり方をしました。
- 人によって分割の粒度が違う => プランニング時に全員でタスク洗い出しを実施して分割粒度を揃える
- お互いのタスクを疎結合にしたい(干渉を避けたい） => タスクを個別にデプロイして影響がない形に維持する
具体的な成果と考察
まず、サマリで示した以外の Four Keys の半年間の傾向は以下のとおりです。
※グラフは「デプロイ頻度」のみを示しており、サマリで示したのと同様で右肩上がり傾向が確認できますが、他指標も数値は確認できるかと思いますのでご参照ください
半年間の内で、取り組み前後を比較してみます。
まずは可視化を開始した後からの具体的な取り組みを活性化させる前のタイミング（2022/10末まで） を確認してみました。
↑
比較してみてください
↓
さらに、具体的な取り組み（プルリク分割）をし始めたタイミング以降（2022/11以降） を確認してみました。
上記の半年間のデータと比較すると変化は大きく見えないかもしれませんが、数値としては良化したことが見て取れます。
各指標において、DORAチームが定義する分類（※）の中で以下のグループまで到達することができました。
- デプロイ頻度：Eliteパフォーマー
- 変更のリードタイム：Highパフォーマー
- 変更障害率：Eliteパフォーマー
- 平均修復時間：Highパフォーマー
※参照：エリート DevOps チームであることを Four Keys プロジェクトで確認する
ここまで各種指標が上がっている傾向を雰囲気として感じられたと思いますが、Four Keys 指標以外のスタッツはどうだろうかと気になったので、同じく取り組み前後の比較（2022/11以降とそれ以前の同期間）を見てみました。
いずれの指標においても気持ち良いほど上昇傾向⤴️⤴️⤴️にあり、実行に移した現場メンバーに称賛と敬意を覚えています👏
取り組んでみた感じたこと
さて、ここまで自画自賛な状況を挙げてきましたが、正直違和感は様々感じています。
大きな違和感としては、パフォーマンスが良化したこと自体は確かに感じているが、生産性が上がった感覚とは遠い感覚がある、ということです。
取り組み前の段階でも悪くない数値を示していたことも関係するとは思うものの、それだけではない違和感があったので生産性について考えてみました。
我々はユーザーに価値を提供するために生産している
今回考えを整理してみているときに、生産性という言葉が指す意味を考えてみると、アウトカムではなくアウトプットを出すことに対する効率性を意味しているものなのだろうという理解をしました。
ただ、わたしは元々アウトカムも含めた効率性を指すものとしてなんとなく理解していた節があったのだと気が付きました。
それは生産性を英語で言い表した Productivity という言葉に対して Product + Activity という正確な語源ではない理解から、プロダクトを活発化させる力 = 良いプロダクトを効率よく作る力と誤解をしていたからです。
今回生産性に対して取り組んでみて感じた違和感は、ここのズレがあったことが理由だったのです。
ただ、やはりユーザーに対して提供する価値を最大効率で高めていくことは目指したいという気持ちはあり、
Four Keys自体がここにアプローチしていないことや、アプローチしていない背景としてそもそも不確実性の高い状況において「打席に立つ数を増やすこと」が大事であり研究結果としても出ていることが事実としてあったとしても、この観点を何か考えてみたいと思いました。
Four Keys とその他の指標を組み合わせてみる
こんな考え方ができないものだろうか、と思考をしてみたことがあります。
アウトカムも含めた生産性を何かの指標として表現できないか、ということです。
元々わたしは、EMを担っていた頃からチームメンバーに対しては効果性と効率性の両側面を高めていくことを大事にしたいというのを伝えていたことがあります。
- 効果性 = アウトカムを増やす
- 効率性 = アウトプットを増やす
という整理です。
冒頭で野球を例にしているので同じように例えてみると、以下のような整理になります。
- 効果性 = アウトカムを増やす = ヒットを増やす確率を上げる
- 効率性 = アウトプットを増やす = 打席に立つ回数を増やす
そして Four Keys 自体の指標はどう当てはまるのかと言うと、効率性側に当てはまるものだと考えています。
Four Keys全体としては広義の意味での効率性であり、狭義の意味での効率性は「デプロイ頻度」「変更のリードタイム」の2つになるはずです。
では「変更障害率」「平均修復時間」は何を指すかというと、狭義の意味で効率阻害性であると捉えました。
何を言っているんだとわかりにくくなってきたので簡単に図示してみると以下のような考え方です。
左下の効果性を表現できる指標は果たしてどう考えるとよいでしょう。
「ヒットを増やす確率を上げる」と上に記載しましたが、まさに打率を意味する指標と捉えればよいので、
KGIもしくはKPI（上昇率でもいいかも） / デプロイ回数 というような考え方をしてみたらどうかと考えました。
ただこの指標だと、効率性を上げてデプロイ回数が増えると効果性が下がっていってしまうという状況にぶつかってしまいます。
指標は相互に作用し合わない数値を、増やしたいもの / 減らしたいものという分数構造で考えるといいとプロダクトオーナー研修で学びましたが、難しいものです...。
みなさま、この辺りどう考えたり取り組んだりされていますでしょうか？
そして各範囲をどの領域から向上させに攻めていくのかについても記載してみました。
最後に
特に結論の無い記事となりました。
記事内容についてご意見などあれば是非フィードバック頂きたいです。
そして開発生産性アドベントカレンダーの記事はどれも気づきと示唆に富み、良い勉強をさせて頂きました。
これで2022年のアドベントカレンダーも最終日、みなさま良いお年をお迎えし、良いエンジニア生活を！