リーン原則と実践の背景にある科学と数学を理解することで、エンジニアリングリーダは、職場でそれらを提唱し、実装することができます。この方法は、David Van Couvering氏がQCon Plus 2020で価値を提供するためのリーン原則と実践の適用についての講演で説明したように、従業員のエンゲージメントと士気、そして収益に直接影響を与えることができる。
書籍「LeanとDevOpsの科学 (Accelerate) 」から、会社全体のパフォーマンスの向上を最もよく予測するソフトウェアデリバリメトリックは、リードタイム、デプロイ頻度、平均修復時間、および変更の失敗率であることを学んだ。この書籍の著者は、これらの指標に貢献する特定のプラクティスも特定しており、Van Couvering氏は、2つの主要なプラクティスセットは継続的デリバリとリーンであると述べている。
継続的デリバリは主に、変更を加えてからその変更をプロダクション環境に移行するまでのプロセスの自動化に重点を置いているが、リーンは、開発プロセス全体の全体的なフローとスループットを大幅に向上させることができるプロセスと手法に重点を置いている。
チームメンバもリーンの原則と実践を適用することで利益を得ることができる。Van Couvering氏が説明したように、これらの原則を適用すると、フローが改善され、燃え尽き症候群が減少し、フィードバックの高速化により、チームはより幸せで意欲的になる:
私は、より速く「やり遂げる」ことができれば、私ははるかに幸せになることを知っています。また、私が構築しているものが顧客に真の価値をもたらし、リーダシップは私がしていることを本当に見て感謝していることを知っています。しかし、書籍「LeanとDevOpsの科学 (Accelerate) 」の研究はこれを裏付けています。これらのプラクティスを採用すると、開発チームのエンゲージメントの向上と燃え尽き症候群の減少を予想できます。
Van Couvering氏は、承認ゲートの数を減らしてより頻繁にリリースしたり、自動化に投資したりするなどのプロセスを変更することは、リーダにソフトウェアの最新のトレンドにエンジニアが興奮しているだけではないと納得させるのは難しいと述べ、彼を助けたのは、リーン原則の背景にある数学と科学を知ることだった:
私は今、これが彼らの最善の利益であり、彼らに本当の結果をもたらすであろうという説得力のある証拠をしばしば躊躇し抵抗するリーダに提供する権限を与えられています。
InfoQは、eBayの著名なMTSであるDavid Van Couvering氏に、ソフトウェアデリバリのパフォーマンス、遅延の原因への対処、仕掛中の作業の削減とフローの増加、フィードバックと応答サイクルの改善についてインタビューした。
InfoQ: ソフトウェアデリバリのパフォーマンスをどのように定義し、エンジニアリングリーダにとって重要なのは何でしょうか ?
David Van Couvering氏: 私は、Nicole Forsgren博士、Jez Humble氏、その他による著書「LeanとDevOpsの科学 (Accelerate) 」で定義されているソフトウェアデリバリパフォーマンスという用語を使用します。彼らは4年間の調査を通じて、組織がソフトウェアをどれだけ効果的に提供するかを測定する一連の指標を特定しました。彼らの調査によると、このソフトウェアデリバリパフォーマンスの測定値は、企業全体のパフォーマンスの向上 (収益性、市場シェア、生産性) を確実に予測します。特に、ソフトウェアデリバリのために高性能クラスタに適合する組織は、低パフォーマンスクラスタと比較して会社のパフォーマンス目標を2倍超える可能性がありました。これはかなり重要です。
これは非常に価値があると思います。何年もの間、主に衝動、感情、直感に基づいて、ソフトウェアデリバリの慣行が採用されているかどうかは不明です。しかし、この書籍は、企業規模と業種の多様なセットにわたって、改善されたビジネス成果および改善された従業員の士気を直接予測するために示されている尺度を提供します。それはもはやあなたが議論しなければならないことではありません - あなたはただデータを示すことができます。
InfoQ: 何が遅延を引き起こす可能性があり、それらの原因にどのように対処できるのでしょうか ?
Van Couvering氏: 遅延は、提供するものの経済的価値を低下させることを理解することが重要です。遅延にはコストがかかり、かなり大きくなることがあります。特に競争の激しい市場セグメントにおいて、ソフトウェア製品の納品が遅れた場合の機会または収益の損失について考えてみてください。遅延はフィードバックの速度も低下させるため、新しい情報への適応が難しくなります。また、機能の提供が遅れると、停止や顧客の離職の重大なリスクが発生する可能性があります。これを念頭に置いて、ソフトウェアシステムのレイテンシとスループットの最適化と調整に多くの時間を費やすのと同じように、開発プロセスのレイテンシとスループットの最適化と調整にも時間を費やす必要があります。
プロダクトデリバリパイプラインの数学とダイナミクスを見ると、遅延の最大の原因はキューをバックアップさせることです。製造業とは異なり、これらのキューはソフトウェア開発では見えないため、キューを見えるようにして、迅速かつ積極的に対処することが重要です。キューを減らす2つの強力な方法は、進行中の作業を制限することと、バッチサイズを小さく保つことです。
InfoQ: 仕掛作業を減らし、フローを増やすために何ができるでしょうか ?
Van Couvering氏: 数学的には、チームのリソースの使用率が100%に近づくと、キューの長さが指数関数的に増加することが示されています。また、キューの長さが長くなると、その状態から抜け出すのは非常に困難です。これらの理由から、入ってくる作業のバーストを処理するために、チームにキャパシティバッファリングを用意することが非常に重要です。
これを行うための最も一般的なアプローチは、チームが引き受ける作業の量に制限を設定することです。これは現在取り組んでいるものだけでなく、コミットされたバックログにあるものであることに注意してください。その制限がどうあるべきかを正確に判断するのは難しいので、チームサイズの倍数 (2倍が適切な出発点です) として最良の推測を考え出し、バックログを監視して、それが短く安定しているかどうかを確認することをお勧めします。必要に応じて調整します。アイドル時間が長くなりすぎて、遅延を減らすという利点がアイドル状態のチームメンバのコストによって消費されるため、低く設定しすぎないようにする必要があることに注意してください。
その制限を設定すると、その制限を超える作業を受け入れないようにするさまざまなメカニズムがあります。これらは、ソフトウェアシステムで行うことと非常によく似ています。制限を超えた新しい作業をドロップするだけで、負荷を減らすことができます。背圧 (backpressure) を使用して、作業を停止するようにチームに指示できます。あなたはこれについて賢くなり、価値の低い仕事をドロップすることができます。ビジネス価値だけでなく、リスク、機会の有効化、適時性などの遅延コストの要因を考慮して作業に優先順位を付けることができる、Weighted Shortest Job Firstのような優先順位付け手法があります。
仕掛中の作業を制限してキャパシティを管理することで、輻輳の可能性を減らし、フローを改善します。バッチサイズを小さく保つことで、フローも大幅に改善され、途切れ途切れの変動の量が作業を提供する速度まで減少します。改善されたフローは、改善されたフィードバックループ、より予測可能なデリバリ、全体的な改善されたスループットなど、重要なダウンストリーム効果をもたらします。
InfoQ: フィードバックと応答サイクルはどのように改善できるのでしょうか ?
Van Couvering氏: 高速フィードバックループは、大量の価値を提供します。何が機能していて何が機能していないかを学習するときに、バックログの不要な作業を排除できます。目標に向かってより効率的に進むことができ、提供しているものがビジネスを前進させていることをより確信できます。
この重要な側面は、優れた指標を特定することです。OKRはビジネス指標の一般的な例ですが、多くの場合、提供するもので直接測定できないため、適切な代理指標を特定する必要があります。また、コースを変更したい場合に、より迅速に見つけることができる先行指標を探したいと思います。
上記の手法を使用してデリバリパイプラインの遅延を減らすと、フィードバックをすばやく取得できます。バッチサイズが小さいと、増分値をより速く提供できるため、フィードバックをより早く取得できます。これにより、調整が可能になり、バックログから作業がなくなる可能性があります。これにより、サイクルタイムが改善され、フィードバックが速くなります。