変更のリードタイム改善事例
前回までの振り返り
hi-outcomeの中森です。
前回の記事で、エンジニアチームの生産性を測る指標として「リードタイム」「サイクルタイム」ではなく「変更のリードタイム」を計測すべきという話をしてきました。
今回は、私自身が行った「変更のリードタイム」改善活動について紹介したいと思います。
私の取り組み
さて、リードタイムは作業時間と待ち時間に分割して考えることができます。
ここで、待ち時間に注目してみて「開発における待ち時間の代表であるレビューを究極に短くする方法は何だろうか？」と考えてみました。
つまり、レビューをより高速で実現する手法はあるだろうか？と思考を巡らせました。
そこで以下のような仮説を立てました。
仮説その１
コーディングとレビューを同時に行うモブプログラミング・ペアプログラミングが最も高速にフィードバックループを回すことができる手法ではないだろうか？
この仮説は思いついたと同時に少々精度が低いとも思いました。
なぜなら、上記の仮説がそのまま正しいのなら、全てのエンジニア組織でモブプロが標準的な開発手法として定着しているはずです。
しかし、そうはなっていません。ということは、モブプロをそのまま導入しても大きな改善効果は生まない可能性があると思い始めました。
補足：モブプログラミングとは
開発チーム全員で1つのソースコードに対して同期的にコーディングを行うプラクティスのこと
仮説その２
そこでいくらか思案を経た結果以下の結論に辿り着きました。
モブプロで共同で作業をした方が良い領域と並行作業しても問題がない領域があるのではないだろうか？
なぜこのような疑問に至ったかというと、私自身が他のエンジニアのコードをレビューしている時に「ここの実装全然違うんだよなぁ」と感じ、レビューで指摘を入れる分野とそうでない分野に偏りがあることに気づいたからです。
具体的には、ドメイン層の実装についておいて手直しをしてもらうことが非常に多かったです。
ですので、ドメイン層の実装はモブプロで行うのは、かなり費用対効果高い施策だと考えました。
ドメイン層を守る
話は少し脇道に逸れますが、エンジニアとしてドメイン層のモデリングは非常に重要な仕事だと思っています。
ドメイン層は大袈裟に表現すると、アプリケーションのコアとなる部分です。
銀行システムを例にとると、利子であったり入出金というイベントは銀行という存在が成り立つには必須となる概念です。
しかも、これらコアの概念は様々な場所で共通して利用されるものです。
コアの実装が固まっていないと、当然それを利用する側のコードも不安定になり、レビューコストが増加してしまいます。
一方でドメイン層以外のロジックは、ある特定のユースケース固有のロジックだったりするわけです。
これらは、名前の通り特定のユースケース固有の実装なので、ドメイン層がある程度固まっていれば並行作業が容易です。
ユースケース層はドメイン層のロジックを使用するので、ドメイン層のモデリングと振る舞いを早め早めに固めていくことは非常に重要です
在籍チーム固有の課題
当時在籍していたエンジニアチームの抱える固有の事情として、本来ドメイン層に書かれるべき実装がそれ以外の部分に漏れ出しており、ドメインロジックが至る所で重複しているというものがありました。
こうした問題を防ぐ手立てとしても、ドメイン層の実装をモブプロで行う意味はかなり大きいだろうと考えました。
余談
変更のリードタイムを持続的に短くするというシンプルなアイデアが、DDDやアーキテクチャの話にしっかりつながっているというのは、非常に興味深いと思います。
一旦話を整理
話が少しアーキテクチャの方向に逸れたので元に戻します。
モブプロを採用することで、コーディング中に常時レビューを行うことができるので手戻りが減り「変更のリードタイム」が短くなるのでは？というのが第一の仮説です。
それをさらに発展させて、「開発者間の同意が非常に重要になるドメイン層はモブプロがかなり有効で、それ以外の実装は並行作業で問題ない。」というのが第二の仮説になります。
次に、第二の仮説が正しいことを検証する改善行動を定義しました。
改善行動
当時、私がリーダーをしていたチームでは以下のカイゼン行動を行うことで同意しました。
ドメイン層の実装は必ずモブプロで行う。
ドメイン層より外側の実装を先に行わない※インターフェースが決まっていた場合は別
ドメイン層より外側の実装は並行作業で問題ないが、タスクを小さく分解し、1日に複数のPRを出すようにすること
上記の取り組みを2ヶ月行ってみた結果を確認しましょう。
振り返り
数値改善
従来、「変更のリードタイム」が4日程度だったものが1日未満になりました。
State of DevOpsレポートの指標に照らせば、ハイパフォーマーの中でもかなり良い位置に持っていくことができました。
実際、コーディング中にレビューを行うので手戻りがほとんど発生しなかったばっかりか、ドメインロジックの理解がチーム全体で進んだので、ユースケース層の実装においても手戻りがほとんどなかったです。
これは仮説がある程度的を射ていたことを裏付けていたのだろうと判断しました。
副次的効果
数値上に現れない効果として、以下の3点が得られたのもチームとして非常に大きかったです。
エンジニア全員でコードのクオリティを上げていっている感覚
DDDの理解が深まり、良いコードが高速で書かれるようになったこと
コードの重複が減り、テストコードの増加を最小限に抑えられたこと
それぞれ解説します。
まず、モブプロをしていると、自然とメンバーからドメインロジックに関する重要な気づきが生まれることが多くありました。
そして、その気づきを即座にコードに反映させることができ、その場でどんどんとコードのクオリティが上がっていく実感をメンバーで共有できました。
自分達がコードを所有している感覚はエンジニアのエンゲージメントに大きく関わる要素であるのでこういった効果を得られたのは非常に大きかったと思います。
次に、全員で議論をしながらドメイン層の実装を行ったことで、DDDの理解が一気に進みました。
集約クラスであったり、値オブジェクトのクラスがどんどんと作られるようになり保守性の高いコードが以前に比べて作られるようになったのは非常に大きな収穫でした。
最後に、テストコードの増加を最小限にできたことは非常に大きいと思っています。
大前提、コードの重複が増えれば増えるほど、各クラスのテストが肥大化します。
例えば、ドメインロジックが特定のユースケース固有の実装を書くユースケースに重複して書かれるようになれば、本来1つのクラスのテストでいいテストをユースケース層のテストで重複して担保しないといけなくなります。
実際、ユースケース層のテストはかなり肥大化しており、新規開発の度にテストケースが大幅に増加していました。
結果として、CIで回すテストの実行時間がみるみる長くなっていました。
CIの実行時間の増加は「変更のリードタイム」の増加要因です。
仮に、1PRのマージを行うまでに、CIを20回回すとした場合、CIの実行時間が5分から10分になるだけで、「変更のリードタイム」は100分も遅くなってしまいます。
ですので、テストコードの増加を最小限に抑える試みは、非常に重要なわけです。
まとめ
モブプロの導入によって「変更のリードタイム」を改善した事例を紹介しました。
数値を改善できただけでなく、チーム全体でドメインへの理解が一気に深まったりと多くの副次的効果がある非常におすすめの手法です。
モブプロやDDDは無駄が多い重量プロセスだと勘違いを受けることが多いと個人的に思っています。
だからこそ「変更のリードタイム」を改善する、つまり開発速度を上げるためにやるという目線をステークホルダーに共有した上で実践いただければと思います。
そのためにも、まずは「変更のリードタイム」を計測することから始めてみてください。
おわりに
私たち「hi-outcome」は、開発チームの規模が10-100名の企業を中心に、開発支援を行っています。
支援内容は、リーン開発の推進から、開発効率の向上、事業価値向上に即したプロダクト開発プロセスの再構築まで、幅広く対応しております。
開発にお悩みの方がいましたら、是非お気軽にお問い合わせください。
開発スピード向上サービス: https://corp.hi-outcome.com/
開発の予測精度向上サービス: https://corp.hi-outcome.com/inspection