こんにちは、エンジニアリングマネージャーの(@shibe23)です。
この記事は Chatwork Product Day 2023 の応援記事です。
「開発生産性」という単語が取り沙汰されるようになってしばらく経過します。
いまではDORAのFour Keysをきっかけとして、これらの「生産性」に向き合う機会が増えたと実感しています。
Chatworkでもこれらの取り組みを進めているのですが、今回は私が開発生産性に興味を持ったきっかけから、現在までどのような取り組みを行なってきたのかをお話したいと思います。
一例として、フロントエンド開発部での導入事例をご紹介します。
「自分たちの仕事がビジネスに良い影響を与えている」を客観的に示したい
ご存知の通りソフトウェア開発は非常に複雑です。
影響を与える変数が多く、それらが動的に変わるため定量的に「良い開発ができているか」を判断するのは非常に難しいというのは、ソフトウェア開発に携わる方であればみなさん実感するところではないでしょうか。
一方でビジネスとして「この組織はきちんと成果を挙げられているか」を判断したいというのも自然な欲求です。
こうした中で、非エンジニアの方へエンジニアの仕事を理解してもらうことはとても難しいことだと思います。
そんな中で、texta.fmの「Accelerate」回を聴いて「LeanとDevOpsの科学」について知りました。
yasaichiさんとt_wadaさんの「自分達が正しいと思っていたことがビジネスに良い影響をもたらしていることが、学術的な手順を踏んで証明された」という話に惹かれ、自分でもFour Keysを測ってみたいと思うようになりました。
自前でダッシュボードを作る
自動化する前に最初はミニマムに始めようということで、
id:shiba_yu36さんの作成したPRベースの集計ツールを利用しました。
週次でツールを使って集計し、ダッシュボードに反映していきました。
余談ですが、PRベースでのリードタイムの取得は、Four Keysの定義とは異なると考えています。
「LeanとDevOpsの科学」では「変更のリードタイム」「デプロイ数」を指標とした背景について"外的な変動要因を極力排除している"とあります。 原文は「How long does it take to go from code committed to code successfully running in production?」となっており、ある程度解釈の余地を持たせていそうです。 (参考: DORA )
個人的にはmainブランチへのコミット(= デプロイ可能な状態)からデプロイまでの時間をリードタイムとして定義していると捉えていますが、このようにある程度正確に取ろうとすると集計のために実装が必要になるため、課題に感じているところでもあります。
運用する上でのつらさ
自前運用はクイックに試すことができたので、全体の傾向は掴むことができました。 どんな値の取り方をすれば良いかが固まりやすくメリットも大きかったのですが、課題となる点もいくつかありました。
- 祝日、休日、有給など、メンバーの稼働状況の変動によってリードタイムが伸びたように見えてしまう
- チーム外のメンバーがPRを作成した場合、リードタイムに変動が出てしまうので、PRの除外やメンバーでフィルタリングするといった考慮が必要になる
- 集計するクエリによってある程度コントロールは可能
- メンバーの増減があった時に都度メンテナンスが必要
- 過去の値を再取得したいケースで、その時期ごとに対象メンバーを設定しないと一定の基準で値が取れない
- リポジトリを横断して開発した時にメンテナンスが必要
- 自動化やダッシュボードのメンテナンスがやや手間
これらの課題は、後述するFindyTeam+を導入することである程度解決することができました。
Findy Team+で運用を楽にする
Findy Team+はGitHubと連携することでPRベースのアクティビティを集計してくれます。 メンバーの増減で多少調整は必要なもののチームやメンバーの設定は柔軟にできますし、レビューを行った人の関係性をグラフィカルに示したり、マージ・クローズ時間とコメント分量の分布を散布図で表すことで、全体の傾向を掴みやすくなっていたりと、便利な機能が用意されています。
デメリットとしては、集計の定義に合わせて運用フローを変える必要があるという点ですが、集計のために運用フローを曲げるのは本末転倒ということもあり、無理に集計に乗せずに、取れる値を取っていくスタンスで活用しています。
「この結果から何を読み取れば良いかわからない」問題
集計した結果はスプリントの振り返りで確認することにしました。
これでダッシュボードを作成してチームで振り返りの際に見る、というフローができました。
全員でダッシュボードを見ながら改善を進めていく一方で、メンバーからは「集計した値はわかったものの、それをどう活用して良いか分からない」という声も挙がっていました。
メンバーの意見はもっともです。あくまでこれらはGitHubのアクティビティであって、集計した値自体が何か問題を示してくれるわけではありません。
そもそもFour Keys自体は「DevOpsのプラクティスがビジネスにとって良い影響を与えるという関連性を示した」ものであって、大事なのはむしろDevOpsを実現するための27のケイパビリティの方だと言えます。
Four Keysというわかりやすく可視化された数値に意識を向けるあまり、適切な目的を設定できていなかったのだなと思いました。
これまでの経験から、例えば「デプロイ頻度が今スプリントで下がっている、どうしてだろう？」という課題だと「メンバーの休みが多かったから」「割り込みタスクが多かったから消化不良のものが残った」のような"各メンバーの振る舞い"に関する改善に留まりやすいです。
一方で「今デプロイ頻度は PRベースでx 個/ 日だけど、これは自分達の理想としてどうあるべきだろう？現状のどこを改善すれば数値が改善されていくだろう？」のように仮説を元に改善を繰り返していくことができれば、振る舞いに左右されず、ブランチ戦略やリリースフローの改善といった課題に意識を向けることができるように思います。
そのための手がかりとして、27のケイパビリティやDX Criteriaなどを参考にしても良いと考えています。
「管理されてしまう」を払拭するための文化づくり
こうした計測指標が社内に浸透するにあたって一番大事なのは、利用するメンバーに「管理するためのツール」と捉えられないことです。
「キャンベルの法則(グッドハートの法則)」にもある通り、評価指標として使用した瞬間、計測した数値が意味をなさなくなってしまいます。
この点は非常に大事だと捉えていたため、ダッシュボードを作る上で下記に注意していました。
- あくまで利用するかどうかはチームの判断に委ねる
- 「その指標だけを見て短絡的な評価はしない」ことを明示する
- 目に見えていない良いポイントを見つけるために使う
また、偶然にも社内でt_wadaさんの「質とスピード」についての勉強会を開いたことで、開発生産性について社内で議論する良いきっかけになりました。
指標をベースとした改善は「自分ごととして取り組めるかどうか」が大事なため、強制的に施策として実施するのではなく、外部から講師をお招きしたり、メンバーと1 on 1などで対話をしながら一緒に取り組んでいく文化を作ることが大事だと思います。
まとめ
- texta.fmの「Accelerate」回をきっかけにFour Keysに興味を持ちました
- まずはid:shiba_yu36さんの作成したPRベースの集計ツールを利用し、手運用で集計しました
- 集計・運用に関する課題は、Findy Team+を利用することで部分的に改善され、集計の自動化ができました
実際にFour Keysを活用して、メンバーがレビュー負荷の状況をチェックしたり「PRを小さくすることでレビューしやすくしよう」といった取り組みを進めてくれました。 その結果、全体のデプロイ数としては上昇している傾向です。
一方で「この結果から何を読み取れば良いかわからない」という悩みについては引き続き改善を進めていく必要があると思います。
Four Keysは管理するための指標ではなく、DevOpsを浸透させるための指標のはずです。 指標に捉われすぎず、フラットに自分達の課題に向き合っていければと考えています。
最後に宣伝になりますが、この記事が公開される10/19にEMメンバーでイベントを行います、ぜひご参加ください！
また、Chatworkでは、より良い開発を一緒に目指していただける方を募集しています。 Chatworkの開発に触れることができるProduct Day 2023もどうぞご期待ください！
