2.0 第2部序論:フロー指標

第1部が測定の哲学であるなら、第2部はその哲学が提供そのものと出会う場所です。チームがアイデアから稼働するシステムへとコードをどれだけ速く、どれだけ安全に動かすかだけでなく、そもそもそのパイプラインを通じてどんな種類の価値が流れているのかを記述する指標です。このパートは、Flow Frameworkを中心に組み立てられています。これは、ミック・カーステンが2018年の著書『Project to Product』で生み出したモデルで、ソフトウェア提供をバリューストリームとして扱い、そのバリューストリームに共有語彙を与えます。4つのフローアイテムの種類と5つのフロー指標は、非技術的な利害関係者が実際に使える言葉で、エンジニアリングの活動をビジネス戦略に結びつけます。

この組織化の枠組みの選択は意図的なものです。DORA指標、つまりデプロイ頻度、リードタイム、変更失敗率、復旧時間は、本物の研究によって検証されており、入手可能な最もよく裏づけられた提供フレームワークの一つであり続けていますが、それらが測定するのはパイプラインの仕組みであり、その中を流れているものではありません。あるチームが優れたDORAの数字を発表しながら、その実際に届けられた価値は、静かに手戻りへと、あるいはシステムの未来を守る負債とリスクの仕事から離れる方向へと、ずれていくことがあります。このパートはDORAを完全に扱いますが、末尾の単一の統合された参考トピックとして扱います(トピック2.10)。なぜなら、ほとんどの組織にとってより緊急で、より一般的に欠けている問いは「私たちのパイプラインはどれだけ速いか」ではなく「私たちのパイプラインは実際に何を届けているか」だからです。このパートのすべてのトピックは、それでも第1部で確立された同じ規律に従います。メトリクスを述べ、それがどう操作されるかを名指しし、その操作を捉えるガードレールと対にすることです。

大規模なチームにとって、フロー指標は、価値を見失うことなくチームを横断した比較を可能にするものです。プラットフォームチーム、モバイルチーム、データチームは、日々の仕事においてほとんど共通点を持たないかもしれませんが、一貫して計算されたフロー速度とフロー分布は、経営陣が3つすべてにわたって公正な問いを投げかけることを可能にします。このチームは、その現在の段階が実際に必要としている種類の価値を届けているか。企業や政府の組織は、プラットフォーム投資を正当化し、競合する近代化の取り組みの間での見返りを比較し、逸話ではなく証拠をもって、エンジニアリングの能力が経営陣が信じているとおりに配分されていることを示すために、このパートの指標に頼っています。

本パートの各トピック

2.1 Flow Framework: このフレームワークの起源、そのバリューストリームモデル、そして本書がなぜDORAだけではなくこれを使って提供とフローの指標を組み立てるのか。
2.2 フローアイテム:機能、欠陥、リスク、負債: このフレームワークの4種類の分類法、そのゼロサムの容量配分、そして事後に適用された場合に分類がどう操作されるか。
2.3 フロー速度とフロー分布: どれだけ出荷されたか、そしてそれがどんな種類の価値だったか、常に一緒に読むこと。
2.4 フロータイムとフロー負荷: リトルの法則が、過負荷のバリューストリームがおそらくではなく数学的に遅くなることをどう証明するか。
2.5 フロー効率と仕掛かり作業: 忙しいことと速いことがなぜ同じではないのか、そして仕掛かり作業を制限することが直感に反してどう処理能力を改善するか。
2.6 サイクルタイムとその構成要素: ある変更のエンジニアリング時間をその構成段階へと分解し、チームが時間が実際どこへ行っているのかを正確に知ること。
2.7 待ち行列理論: フロー負荷、フロータイム、サイクルタイム、仕掛かり作業の根底にある数学、そして共有資源での待ち時間が、使用率がその限界に近づくにつれてなぜ爆発的に増えるのか。
2.8 リーンのバリューストリーム指標: このパートのソフトウェア固有の指標が由来する、リードタイム、プロセスタイム、サイクルタイム、完全正確率、タクトタイムという古典的なリーンの道具一式、そして二つの語彙をどう橋渡しするか。
2.9 プルリクエストとコードレビューの指標: 提供パイプラインの単一の段階の内側に生きる指標、そしてそれらが不注意に使われるとレビューの質をどう歪めうるか。
2.10 DORA指標フレームワーク: 4つのDORA指標を完全な形で、意図的に最後に配置しています。なぜなら、それらが測定するのはパイプラインであり、その中を流れる価値ではないからです。

各トピックのつながり

トピック2.1はFlow Framework全体を紹介し、トピック2.2はそのフローアイテムの分類法を示し、トピック2.3とトピック2.4はその5つのフロー指標を二つに分けて扱います。速度と分布を一緒に、そして時間と負荷を一緒に、負荷と時間はリトルの法則に直接結びつけられています。トピック2.5からトピック2.7は、フロータイムとサイクルタイムの根底にある仕組みに特に焦点を当てます。フロー効率と仕掛かり作業は、エンジニアリングの段階がなぜ見かけよりもしばしば遅いのかを説明し、サイクルタイムはそのエンジニアリング部分をその段階へと分解し、待ち行列理論は、証明可能な数学的な言葉で、それ以前のすべてのトピックの負荷、待ち時間、使用率についての主張がなぜ真実なのかを形式化します。トピック2.8は一歩下がって、そのすべてを古典的なリーンのバリューストリームマッピングにおける起源までたどります。これは、このパートのソフトウェア固有の指標が一般化している共通の語彙です。トピック2.9は、ほとんどのチームが最も速く改善できる単一のパイプライン段階を扱います。トピック2.10は、DORA指標を完全な形でパートの締めくくりとして示し、先のトピックによるより広い、ビジネス向けの全体像がすでに視野に入った後の、よく裏づけられてはいるがより狭い参考の層として提示します。

このパートのガードレールの規律は、トピック1.2に直接つながっています。フロー速度は、フロー分布を一緒に伴わずに報告されることは決してなく、DORAの速度指標はその安定性指標と対になったままです。それにより、チームはリスクの高いコードや狭い価値の組み合わせを静かに出荷することで速度の数字を改善することができません。その対化はどちらのフレームワークにとっても偶然ではなく、それぞれのフレームワークの中心的な洞察であり、第6部の信頼性指標は、コードがすでに出荷された後の本番運用へと、その対化の安定性側を同じように拡張します。