2.8 リーンのバリューストリーム指標

概要と動機

このパートがこれまで扱ってきたすべての指標、フロータイム、フロー負荷、サイクルタイム、使用率は、はるかに古い道具一式に由来します。古典的なリーンのバリューストリームマッピングの五つの基本測定であり、トヨタで開発され、ソフトウェアがそれらを採用するずっと前から製造業、オペレーション、サービス提供にわたって一般化されたものです。リードタイム(LT)は、仕事が依頼されてから届けられるまでの総経過時間です。プロセスタイム(PT)は、単一の単位に取り組むのに実際に費やされる手作業の時間です。サイクルタイム(CT)は、ストリーム内の単一のノードや段階を完了するのに必要な平均時間です。完全正確率(%C/A)は、下流のチームが手戻りを必要とせずに処理できる単位の割合です。タクトタイムは、顧客の需要にきれいに合致するように単位を完了するための最大許容時間です。

本トピックが存在するのは、ソフトウェアエンジニアリングがこれらのアイデアを発明したのではなく、それらを借用したからであり、その借用は時として、わずかに異なるものに同じ言葉を再利用しました。本書自身のサイクルタイム(トピック2.6)は、ある変更のエンジニアリングの段階、コーディング、レビュー、テスト、デプロイを特に測定するのに対し、リーンの古典的なCTは、どんなプロセスにも適用される、より一般的な「ノードあたりの平均時間」です。フロータイム(トピック2.4)は、リーンが「リードタイム」と呼ぶものに対する本書の呼び名です。この対応関係を知ることが重要なのは、製造業、物流、ヘルスケア、政府の業務で一般的なリーンシックスシグマの背景を持つ読者が、これらの正確な用語を元の意味で使うからであり、同じ言葉を話さないソフトウェアチームは、エンジニアリングの外の同僚への簡単で証拠に裏づけられた橋をみすみす手放すことになるからです。

大規模なチームにとって、%C/Aは本トピックにおける最も活用されていない指標です。それは、トピック2.3とトピック2.4のフロー指標が捉えないものを捉えます。ある段階が生み出すもののうち、どれだけが送り返されることなく次の段階によって実際に使用可能であるかです。多段階のバリューストリームにわたって積み上げると、製造業が累積スループット歩留まりと呼ぶ概念である%C/Aは、手戻りが引き継ぎを通じてどのように目に見えずに積み重なっていくかを明らかにします。これは、長い複数チームのパイプラインを持つ企業組織や、複数の承認ゲートを持つ政府プログラムが特に陥りやすく、めったに直接測定しないパターンです。

重要な原則

これら五つの指標はソフトウェアより前から存在し、その外側に一般化する。 それらは、大企業や政府の業務で一般的なリーンシックスシグマの訓練を受けた利害関係者がすでに流暢に話す共通の語彙です。
用語の衝突は本物であり、明示的に名指しする価値がある。 本書のサイクルタイム(トピック2.6)とリーンの古典的なCTは関連していますが同一ではありません。この対応関係を文書化し、職能を横断した会話が静かにすれ違わないようにしてください。
%C/Aは、最後に一度だけ測定されるのではなく、すべての段階にわたって積み上げられなければならない。 ストリームの早い段階で導入され、遅くに捕まった手戻りは、最終提供時にのみ測定される指標には見えません。
タクトタイムは、容量計画を努力ではなく需要を中心に再構成する。 問いは「どれだけ速く行けるか」から「どれだけ速く行く必要があるか」へと移り、これは使用率(トピック2.7)とフロー負荷(トピック2.4)に直接つながります。
これらは虚栄の指標ではなく診断的な指標である。 それぞれが特定の運用上の問いに答えるために存在し、ダッシュボードのために印象的な数字を生み出すためではありません。

推奨事項

ソフトウェア固有のフレームワークを採用する前に、五つのリーン指標すべてであなたのバリューストリームを地図に描く

あなたのバリューストリームを通過する仕事の代表的なサンプルについて、Flow Framework自身の指標(トピック2.3とトピック2.4)を上に重ねる前に、リードタイム、プロセスタイム、サイクルタイム、%C/A、タクトタイムを計算してください。これは、リーンシックスシグマに通じたどんな利害関係者も即座に理解できるベースラインを与え、しばしば、特定のソフトウェアフレームワークより前から存在し、それより長く続く語彙で表現された、トピック2.5が記述するのと同じ待ち時間の支配を表面化させます。

完全正確率をすべての段階にわたって乗法的に積み上げる

各段階で個別に%C/Aを測定し、それから段階レベルのパーセンテージを掛け合わせて、バリューストリームの累積スループット歩留まりを得てください。それぞれ個別に90%の完全正確率で動いている三つの段階は、全体としておおよそ73%に積み重なります。これはどの単一の段階自身の報告ともまったく似ていない数字であり、通常はより正直なものです。この単一の計算は、多段階のパイプラインが実際にどれだけの手戻りを吸収しているかを明らかにする最速の方法です。

容量ではなく実際の顧客需要データからタクトタイムを明示的に設定する

タクトタイムを、あなたのチームが今日たまたまどれだけ速く働けるかとは意図的に無関係に、利用可能な作業時間をその期間の顧客需要で割ったものとして計算してください。測定されたプロセスタイムとサイクルタイムをこの数字と比較してください。タクトタイムを余裕を持って下回るプロセスタイムは健全な余裕を示し、タクトタイムを超えるサイクルタイムは、物事が遅れているという感覚だけでなく、容量不足の具体的で定量化された証拠です。

リーンの用語と本書自身の語彙の対応関係を文書化する

あなたの組織がソフトウェアの外ですでにリーンシックスシグマのプログラムを運営している場合、あるいはエンジニアリングがその語彙に通じた指導層に報告している場合、対応関係を指標チャーター(トピック1.4)の中に明示的に書き留めてください。本書のフロータイムはリーンのリードタイムであり、本書のサイクルタイム(トピック2.6)はリーンのより一般的なCTの特定の適用であり、本書のアクティブな時間(トピック2.5)はリーンのプロセスタイムです。この単一の文書は、どちらの数字が「本物」なのかについての、繰り返される低価値の議論を防ぎます。

%C/Aをフロー速度の置き換えとしてではなく、それと並んだガードレールとして使う

本書があらゆる速度指標を安定性のガードレールと対にするのと同じように、累積スループット歩留まりをフロー速度(トピック2.3)と対にしてください。上昇するアイテム件数と下降する累積%C/Aは、バリューストリームがますます後で手戻りを必要とするより多くの単位を届けていることを意味し、これはまさにトピック1.2があらゆる指標の家系に対して守るよう警告する、品質なき速度のパターンです。

トレードオフ:長所と短所

アプローチ	長所	短所
古典的なリーン指標のみ(LT、PT、CT、%C/A、タクトタイム)	普遍的な語彙。ソフトウェアとソフトウェア以外のチームの両方で機能する	ソフトウェア固有ではない。エンジニアリング固有の段階には翻訳が必要
Flow Framework指標のみ(トピック2.3、トピック2.4)	ソフトウェアのバリューストリームとアイテムの種類の可視性のために目的別に作られている	エンジニアリングの外のリーンシックスシグマの訓練を受けた利害関係者にはなじみがない
両方を使い、明示的な対応関係を文書化する	両方の語彙を話す。最も強い職能横断の橋	対応関係を書き留め、最新に保つ前もっての規律が必要
最終提供時にのみ%C/Aを測定する	単純で、単一の数字	ストリームの早い段階で導入され捕まった手戻りを隠す

中心にある緊張関係は普遍性と特異性です。古典的なリーン指標は、製造業、オペレーション、あるいはシックスシグマの経験を持つ誰にとっても即座に読み取れますが、それらはコードレビュー、自動テスト、デプロイ承認といったソフトウェアの特定の段階を念頭に設計されたものではありません。この緊張を解消するには、リーン指標を職能横断的で経営陣との会話のための共有されたベースラインの語彙として使い、Flow Framework自身の指標(トピック2.3とトピック2.4)を、エンジニアリングチームが日々行うソフトウェア固有の診断的な仕事のために使ってください。

チームで話し合うべき問い

今日、私たちのバリューストリームについて五つの古典的なリーン指標すべてを計算できるでしょうか。それとも一部しか持っていないでしょうか。ほとんどのソフトウェアチームは、フロータイムとサイクルタイムの相当物を持っていますが、プロセスタイム、%C/A、タクトタイムを明示的に計算したことがありません。隙間が小さいと仮定する前に、五つのうちどれが本当に欠けているかを特定してください。
私たちは、バリューストリームのすべての段階にわたって%C/Aを積み上げたことがあるでしょうか。それとも最終提供時にのみ測定したでしょうか。 単一のストリーム末尾での測定は、まさに本トピックの累積スループット歩留まりの計算が明らかにするように設計された、積み重なる手戻りを隠します。実際のデータで積み上げの計算を試みてください。
私たちは、実際の顧客需要から計算されたタクトタイムを知っているでしょうか。そして測定されたサイクルタイムはそれとどう比較されるでしょうか。ほとんどのチームはこの比較を一度も明示的に行ったことがなく、これは容量についての会話が定量化されるのではなく逸話的なままであることを意味します。
もしエンジニアリングの外からのリーンシックスシグマの訓練を受けた利害関係者が私たちのサイクルタイムについて尋ねたら、私たちは彼らと同じことを意味していると確信できるでしょうか。本書のサイクルタイム(トピック2.6)とリーンの古典的なCTは関連していますが同一ではありません。その区別が、あなたの組織で本物の誤解を引き起こしたことがあるかを話し合ってください。
私たちの累積スループット歩留まりが、どの単一の段階自身の報告された%C/Aよりも意味のあるほど低かったことがあるでしょうか。 もし積み上げを計算したことがないなら、何を見つけると予想するかを話し合い、それから実際のデータと照らし合わせて確認してください。
私たちの組織はすでに、エンジニアリング指標を一度も接続したことのない、ソフトウェアの外でのリーンやシックスシグマのプログラムを運営しているでしょうか。多くの企業や政府機関にはすでにこのインフラストラクチャがあります。エンジニアリングがそれに実際につながったことがあるかを確認してください。

業種別の視点

スタートアップ。 完全なリーンのバリューストリームマッピングは、この規模ではめったに儀式に値するものではありませんが、タクトタイムは非公式に理解する価値があります。恣意的な内部のペースではなく、実際の顧客需要に合わせるためにチームが本当にどれだけ速く動く必要があるかをおおよそ知ることは、容量を早く作りすぎることと、成長が訪れたときに作り足りないことの両方を防ぎます。

中小企業。 %C/Aは、ここでの五つの指標の中で最も即座に有用なものです。なぜなら、それは「私たちが出荷するものの、どれだけがやり直しを必要とするか」という、オーナーや小さなチームが数字を伴わなくても痛切に感じる問いに直接答えるからです。もっと精巧な何かに投資する前に、あなたの一つか二つの重要なプロセスについて非公式にそれを追跡してください。

企業。 ここでこそ古典的なリーンの語彙がその価値を発揮します。なぜなら、大企業は非常にしばしば、オペレーション、製造業に隣接する部門、あるいは共有サービスですでにリーンシックスシグマのプログラムを運営しており、同じ言葉を話すエンジニアリングは、別個のソフトウェアだけの指標群をゼロから正当化する必要なく、それらの機能への即座の信頼できる橋を得るからです。

政府。 特に規制、製造業に隣接する、あるいは物流の機能に根を持つ政府機関は、しばしば既存のリーンやプロセス改善の義務を持っています。デジタルサービスのバリューストリームを、機関のプロセス改善事務局がすでに使っているのと同じ古典的な用語(リードタイム、プロセスタイム、%C/A、タクトタイム)で枠組みづけることは、しばしばソフトウェアの近代化の取り組みへの本物の制度的支援を確保する最速の方法です。

事例

企業。 ある製造業企業の社内ソフトウェア部門は、工場の現場からリーンシックスシグマに通じたオペレーション指導チームに自分たちのエンジニアリング指標を真剣に受け止めてもらうことに何年も苦労していました。同じ五つの古典的な指標を使って部門の提供パイプラインを再構成し、そのソフトウェアのバリューストリームについてリードタイム、プロセスタイム、サイクルタイム、%C/A、タクトタイムを計算することで、初めてこの部門の数字がオペレーション指導層にとって読み取れるものになりました。パイプラインの四つの段階にわたる累積スループット歩留まりの計算は、どの個々の段階自身の報告された数字よりもはるかに低い、実際の%C/Aが61%であることを明らかにし、これがオペレーション指導層が同じ四半期以内に資金提供した手戻り削減の取り組みの証拠基盤になりました。

政府。 ある州運輸局のデジタル許認可チームは、長年続くリーンのプロセス改善事務局を持つ機関に報告していましたが、自分たちの指標がその事務局が認識しないソフトウェア固有の言葉を使っていたために、その事務局と一度も関わったことがありませんでした。許認可のバリューストリームをリードタイム、プロセスタイム、%C/Aに翻訳した後、このプロセス改善事務局は、このチームの本当の制約がエンジニアリングの速さではなく、許認可の需要に対してその独自の効果的なタクトタイムをはるかに下回って動いている下流の法務レビューの段階であることを特定しました。これは、なじみのある用語で枠組みづけられていたために、この事務局がすぐに行動できる発見でした。

ビジネスケース:動機、ROI、総所有コスト

本書のソフトウェア固有の指標と並んで古典的なリーンの語彙を採用することからの見返りは、大規模な組織の他の場所にすでに存在することが多い、プロセス改善の専門知識と資金への信頼できる即座の橋です。上記の製造業企業の例、再構成が主張を読み取り可能にした同じ四半期に手戻り削減の資金を確保したことは、本トピックのアプローチが確実に生み出すパターンです。洞察自体は新しいものではありませんでしたが、それを正しい聴衆にとって行動可能にした語彙が新しかったのです。

総所有コストは低いものです。これら五つの指標は、トピック2.4からトピック2.6がすでに収集しているもの以上の新しい計測基盤を必要とせず、%C/Aの手戻り分類は通常、既存の欠陥とフローアイテムの追跡(トピック2.2)への単純な追加です。主な投資は翻訳です。本書の用語とリーンの古典的な用語の間の対応関係を書き留めることであり、これは職能横断の誤解を一度防ぐだけで元が取れます。

アンチパターンと落とし穴

%C/Aを最終提供時にのみ測定する。 本トピックの中心にある操作のベクトルです。あるチームは、早い段階が、誰かがそれを測定する前に修正される手戻りを静かに生み出している間、高い最終段階の%C/Aを報告することができ、バリューストリーム全体を実際よりも健全に見せかけます。ガードレールは、%C/Aをすべての段階にわたって乗法的に積み上げること、つまり累積スループット歩留まりの計算であり、各段階の「完全で正確」の定義が時間とともに静かに狭まらないよう、それを定期的に監査することです。
本書のサイクルタイムとリーンの古典的なCTがまったく同じものを意味すると想定する。 二つの語彙が文書化された対応関係なしに出会うとき、本物の職能横断の混乱を生み出します。
タクトタイムを実際の顧客需要ではなく現在の容量から設定する。 需要と容量の間の隔たりを明らかにするという指標の目的を打ち負かし、すでに存在するペースを確認するだけになります。
ソフトウェア固有のフレームワークが採用されれば古典的なリーン指標は陳腐化したと扱う。 組織にすでに存在しているかもしれない、プロセス改善の専門知識への信頼できる証拠に裏づけられた橋を捨てます。
組織の他の場所にある既存のリーンシックスシグマのプログラムを無視する。 共有された言葉で提供指標を再構成することが解き放てたはずの資金、専門知識、制度的な信頼を放棄します。
フロー速度と対にせずに%C/Aを報告する。 上昇するスループットの数字が下降する手戻り率を隠すことを許してしまいます。これは本書が全体を通じて警告する同じガードレールの隙間です。

成熟度モデル

レベル1、開始: 五つの古典的なリーン指標のどれも計算されておらず、提供はリードタイム、プロセスタイム、%C/Aへの言及なしに議論されます。
レベル2、発展: リードタイムとサイクルタイムは非公式に追跡されていますが、プロセスタイム、%C/A、タクトタイムは計算されておらず、本書自身の語彙への対応関係も存在しません。
レベル3、標準化: 五つの古典的な指標すべてが一貫して計算されており、本書のフローとサイクルタイムの語彙への対応関係が共有された指標チャーターに文書化されています。
レベル4、管理: 累積スループット歩留まりがバリューストリームのすべての段階にわたって計算されており、タクトタイムが測定されたサイクルタイムと比較されて容量の隔たりを明示的に定量化します。
レベル5、最適化: 組織はソフトウェア提供指標を、事業の他の場所にある既存のリーンやシックスシグマのプログラムに接続しており、共有された語彙がエンジニアリング以外の聴衆にとって洞察を行動可能にしたために行われた具体的な投資やプロセスの決定を指し示すことができます。

議論のためのアイデア

今日、私たちのバリューストリームについてリードタイム、プロセスタイム、サイクルタイム、%C/A、タクトタイムを計算できるでしょうか。
もしすべての段階の%C/Aを掛け合わせたら、私たちの累積スループット歩留まりはどうなるでしょうか。
私たちの組織は、エンジニアリング指標を一度も接続したことのないリーンやシックスシグマのプログラムをすでに運営しているでしょうか。
私たちの測定されたサイクルタイムは、実際の顧客需要から計算されたタクトタイムとどう比較されるでしょうか。

主な要点

五つの古典的なリーン指標、リードタイム、プロセスタイム、サイクルタイム、完全正確率、タクトタイムは、ソフトウェアより前から存在し、リーンシックスシグマの訓練を受けた利害関係者の共通語彙であり続けています。
本書自身のフロータイムとサイクルタイムは、リーンのリードタイムと古典的なCTに対応しますが、同一ではありません。 職能横断の混乱を避けるために対応関係を明示的に文書化してください。
本トピックの中心的な操作のベクトルは%C/Aを最終提供時にのみ測定することです。ガードレールは、累積スループット歩留まりとしてすべての段階にわたってそれを乗法的に積み上げることです。
タクトタイムは容量を、既存のペースではなく実際の顧客需要を中心に再構成します。 そして使用率(トピック2.7)とフロー負荷(トピック2.4)に直接対になります。
ソフトウェア提供を古典的なリーンの用語で再構成することは、しばしば大規模な組織にすでに存在する既存のプロセス改善の専門知識と資金につながる最速の方法です。

参考文献とさらなる読書

Rother, Mike, and John Shook. Learning to See: Value Stream Mapping to Create Value and Eliminate Muda. Lean Enterprise Institute, 1999。
Womack, James P., and Daniel T. Jones. Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Free Press, 1996。
Womack, James P., Daniel T. Jones, and Daniel Roos. The Machine That Changed the World. Free Press, 1990。
George, Michael L. Lean Six Sigma for Service: How to Use Lean Speed and Six Sigma Quality to Improve Services and Transactions. McGraw-Hill, 2003。
Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988。