はじめに
この記事は「エンジニア組織の開発生産性・開発者体験向上の取り組みをシェアしよう！ by Findy Advent Calendar 2023」の25日目の記事になります。
私は、キネカという会社のCTOをしており、開発チームの生産性の可視化と最適化のために、3年前よりFour Keysへの取り組みを始めました。
本記事は、Four Keysへの取り組みと、それによる良かったこと・悪かったことを箇条書きで振り返りたいと思います。
良かったこと
- リリース増加による自己肯定感アップした
- PRが分割されてレビューしやすくなった
- 新規メンバーがオンボーディングしやすい
- フィーチャーフラグが整備された
- CI時間が高速化した（副次的効果）
- ダッシュボード作成など、可視化の取り組みが進んだ
悪かったこと
- リリースの定義が曖昧になり、ビジネス的に寄与しないリリースも増えた
- ビジネス的にうまくいっていないときも、なんとなくうまくいってる感でちゃう
- リリースできないメンバーが焦燥感を感じる
良かったこと考察
弊社では2020年頃から「LeanとDevOpsの科学」に触発されてFourKeysの取り組みを始めました。リリース数を計測し始めて、良かったのは、当時会社としてもスケールしていくなかで、定量的な指標を開発チームも持てるようになったことです。
そのおかげで、週次の全社MTGなどで、定量的に数値を共有することができ、チーム全体としての自己肯定感（役にたってる感）などが得られたのが良かったです。
また、FourKeysの指標に関しては、リリース数をあげ、リリース後の失敗を減らすという目的のもと、フィーチャーフラグやCI時間の高速化、ロールバックの仕組みの整備などが進んだのも良かったことの一つです。
新規メンバーのオンボーディングという面でも、常に何かリリースするタスクがあるため、すぐにリリースという形でバリューが出せるのも良かったです。何かしら、本番環境にコミットすることが、未経験、中途問わず、心理的安全性を高めることに有効だったと思っています。
最後に、社内の4K50型ディスプレイにリリースKPIの推移を乗せるなど、可視化の取り組みが行えたのも良かったです。dev発信で取り組んだことがビジ側の問い合わせ対応や流通目標の常時表示などに応用できたのが良かったと思っています。
※ちなみに今はTableau導入により、もっとクオリティ高いダッシュボードになってます。
※現在時刻が乗っているのはオフィスに時計がなかったから。
悪かったこと
リリースを指標としたことで、チーム全体の肯定感や生産性は上がった認識ですが、PJが詰まってるときなど、リリースKPIが悪くなったタイミングで「これってリリース数としてカウントして良いのか？」というようなリリースがでることもありました。
「LeanとDevOpsの科学」には、生産性が高い企業はビジネスも成功していることを言及していたと思いますが、上記のようなリリースを繰り返していてはビジネス的には上手くいかんだろう、と思っています（その動きは是正しましたが、時たま、そういう引力が発生してる気もします）
また、リリース数を指標に置きすぎてるせいか、1〜2週間リリースできないと焦りを感じるメンバーが出てくることもありました。PJ的に、大きい施策、小さい施策はあるので、メンバー単位で見たときにリリースまでの期間が空いてしまうのはしょうがないとは思いますが、変わる指標も無いため、なんとも難しいとは思っています。
今後について
最近、悪かったなと思っている「リリースとして含めて良いのか？」というものまで、リリースに含めるという状況が、missreading chatの#121で言及されており、チームとしてもこのKPIを見直して良いかな？というタイミングがきたと思っています。
「LeanとDevOpsの科学」も原著が出てから5年以上たち、SPACEなど新しい指標が登場している中、
できれば来年、なにかしらアップデートしたものをアドベントカレンダーでかけると良いなー。