トヨタによれば、最高の製品を生み出すのは従業員であり、システムではありません。従業員のスキルを開発せずに良い製品を作ることは不可能です。このため、トヨタは、優秀な従業員の育成を目的とする生産システムであるトヨタ生産システム（TPS）を構築しました。
Jeff Sutherland氏とKen Schwaber氏は、複雑な製品またはサービスを開発するためのフレームワークであるスクラムフレームワークを構築するために、TPSに一部依存しています。
スクラム：起源
スクラムの起源は、1986年にハーバードビジネスレビューでハーバードビジネススクールの教授である竹内博隆氏と、一橋大学名誉教授の野中郁次郎氏がThe New New Product Development Gameと題して公開した記事にまでさかのぼることができます。
1993年、この記事とリーンマニュファクチャリングの原理に基づいて、Jeff Sutherland氏は、コンピューター製品の開発のために根本的に異なる方法を開発しました。1995年、Ken Schwaber氏の助けを借りて、彼はメソッドを公式化しました。スクラムが生まれました。
スクラムは、リズミカルな計画方法です。コンピュータシステムの構築では、開発、テストに進む前にまず分析を完了する必要があることを考慮すると、従来のバッチタイプのアプローチとは異なります。この非常に面倒で費用のかかるアプローチにより、多くのプロジェクトが行き詰まりました。
それどころか、スクラムは、スプリントと呼ばれる小さなバッチで製品の構造を切り取ることにより、このモデルを破壊します。スプリント中、チームはクライアントが最も価値があると考えるものを分析、開発、テストします。スプリントは1～4週間続きます。スプリントの終わりに、スプリントのレビュー中に、製品の追加分が顧客に提示され、顧客はフィードバックを迅速に提供します。チームは、スプリント後および顧客に応じて製品スプリントを修正および調整します。徐々に製品が形になります。この継続的な顧客ニーズへの適応に加えて、スクラムは、振り返りの概念を導入することにより、チームプラクティスを改善するための正式な構造を提供します。それはスプリント終了時の特別な瞬間であり、チームは次のスプリントでプラクティスを改善するためにプラクティスを振り返ります。
スクラム、トヨタウェイ、トヨタ生産システム
スクラムをリーンアングルから見ると、この方法はトヨタウェイとトヨタ生産システムにルーツがあることが明らかです。
[画像をクリックして拡大]
トヨタウェイの観点から、継続的な改善と人々への敬意が明確に表されています。スクラムのまさにその構造は、Deming氏によって定義されているように、Plan Do Check Act（PDCA）の構造を持つ問題解決メタ構造です。スプリント計画を伴うPlan、スプリントを行うDo、スプリントのレビューとクライアントへのデモンストレーションを行うチェック、振り返りのActです。この学習ループは、製品の構築を通じて継続的に繰り返され、顧客のニーズ、個々の開発、チームワークを理解するのに役立ちます。
スクラムは、トヨタ生産システムの特定の原則、特にビジュアル管理とジャストインタイムにも依存しています。スプリントスケジュールの最後に、チームには、Todo / Wip / DoneあるいはKanbanビジュアル管理タイプを使って視覚化できるユーザーストーリーのバックログがあります。チームのパフォーマンスは、バーンダウンチャートインジケーターを通して、スプリントの最後にすべてのユーザーストーリーをデリバリする能力によって測定されます。各スプリントは「タイムボックス」です。 1か月以内の期間で、「完成」した、使用可能で公開可能な製品の追加分が作成されます（スクラムガイドを参照）。製品の構築は小さなバッチに分割され、そのデリバリは一定のペースでタイミングが取られます。これは、TPSのJust In Timeの柱にあるTaktの概念です。
Toyota ConnectedのチーフアジャイルオフィサーであるNigel THURLOW氏は、彼の恐るべきトレーニングScrum The Toyota Wayでこれを見事に実証しています。しかし、私はさらに先へ進むことができると思っています。スクラムが優れた計画ツールである場合、それは、Jeff Sutherland氏が言うところの、他の技術、方法、および実践のコンテナでもあります。そして、この意味で、Wahoo製品の生産のために必要不可欠な人々の育成のための完璧なフレームワークです。実際、2008年にMarie-Pia IGNACEとMichael BALLEでリーンを発見して以来、私がリードしたさまざまな経験において、スプリント内でのトヨタ生産システムの厳密な実装が学習とさらに有力な生産の点で、非常に優れた結果をもたらすことを示されています。
[画像をクリックして拡大]
図2 - トヨタ生産システム
ここで現れる質問は、どのようにトヨタ生産システムのツールを実装して製品の各追加分を達成し、チームが毎日直面する障害をリアルタイムで明らかにし、それらを解決する手段を提供するかです。
TPSは、問題が発生したときに見えるようにすることを目的とする足場と見なす必要があります。最初にシステムを構築してから動作させる必要があります。
- 優れたビジュアル管理を構築する
- ストリームをプルする
- 適切な問題を特定する
- 問題の解決する
- 正しいレッスンを描く
適切なビジュアル管理の構築
[画像をクリックして拡大]
図3 - ビジュアル管理例
すべてがそこから始まります。進歩するための優れたビジュアル管理を持つことが基本です。何がOKで何がOKでないかを区別できるようにする必要があります。チームは適切な品質と適切なペースでデリバリしていますか。チームは異常やバグの修正に時間を費やしていますか。他のチームからの情報を待ったり、テスト環境が利用可能になるのを待っていることでユーザーストーリーはブロックされていますか。一目で、状況が制御されているかどうか、チームの全体的なパフォーマンスが改善されているかどうかを確認できる必要があります。優れたビジュアル管理には、4つのパネルを含める必要があります。顧客のインシデントをキャプチャするクライアントウォール、品質、時間、コスト、生産性指標を備えたパフォーマンスパネル、生産パネル、最後に問題解決専用のパネルです。
フローをプルする
スプリント内でのジャストインタイムの実装は、Taktの計算から始まります。スクラムはマクロレベルで製品構築のペースを設定するため、スプリント内で生産リズムを設定し、安定したペースでユーザーストーリーを開発することが重要です。Taktの計算は、スプリントのストーリー数をスプリントの作業日数で割るだけです。10日間のスプリントで20ユーザーストーリーの場合、1日あたり2ユーザーストーリーのデリバリ率が得られます。そして、プロダクションをプルフローにします。つまり、プロセスの最後に自分自身を置き、出口に最も近いものからユーザーストーリーを引き出します。毎日の目標はTaktによって定義されます。この例では、チームは2つのユーザーストーリーを選択しました。まず、本番に最も近いステージにあるユーザーストーリーから始めました。チームは毎日、生産目標をコミットします。この場合、毎日、プロセスの終了に最も近いものから2つのユーザーストーリーが選択されます。チームが目標に到達した場合は完璧です。それが実現しなかった場合、それはさらに良いことです。学ぶべきことがあり、改善するための新しい機会です。
適切な問題を特定する
品質の問題を見る
TPSの2番目の柱であるスクラムである、小さいバッチにカットする原則のJidokaがうまく活用されていることは、はるかに少ないです。Jidokaは、プロセスに品質を導入して、プロセスに沿って品質の問題が顧客に伝わらないようにすることです。 最初の欠陥で停止、自動化、レッドビン、andonなどのいくつかの手法により、本番環境に広がり、アプリケーションまたはサービスのユーザにペナルティを科す前に非品質問題を発見することができます。
最も先進的なチームは、テスト駆動開発や継続的インテグレーションなどのエクストリームプログラミング手法を使用して、Jidokaの一部を実装します。ただし、すべてのチームがこれらの手法を実装するために必要なレベルの能力を備えているわけではありません。さらに言うと、それらの手法はプロセス全体をカバーしていません。 そこから生まれる質問は、これらのプラクティスの習熟度に関係なく、プロセスにおいて品質問題をどのように識別するかです。1つの答えは、生産プロセスの各ステージで、レッドビンリーンテクニックを導入することです。
[画像をクリックして拡大]
図4 - 品質の問題を見る
プロセスのあるステージで品質の問題が発見されるたびに、情報はレッドビンに保存されます。コンテンツの厳密かつ体系的な分析により、チームはフローをブロックしているものをよりよく理解し、これらの障害を永続的に取り除くために長期的に必要な顧客と問題解決を保護するための即時アクションをトリガーできます。
図5 - レッドビンの例
フローの問題を見る
プルフローを使用すると、以下の図に示すように、開発プロセスのダイナミクスに関連する一連の問題、つまり過負荷および過剰生産の問題、あるいは他のプロセスとの同期を強調できます。
[画像をクリックして拡大]
図6 - フローの問題を見る
問題解決
上記の唯一の目的は、足場を作成して、チームが制御していないものを強調することです。したがって、プルフローとJidokaの実装により、ビジュアル管理でさまざまな問題の原因が明らかになります。
- レッドビンで見つかった、主にスキル不足を表す品質問題
- 進行中の作業の列でユーザーストーリーが保留中の場合の他のフローとの同期
- 準備完了または実行中の列にユーザーストーリーが積み重なった場合の過剰生産または過負荷の問題
これらの障害をリアルタイムで表示することにより、チームは非常に短いフィードバックループを使用して、障害のあるユーザーストーリーをストリームに戻すために非常に迅速に対応できます（修正 = クライアント保護）。その後、チームは問題に確実に対処するために一歩戻ることができます（解決 = 問題の永続的な除去）。そのために、リーンはPDCA（Plan Do Check Act）による問題解決への科学的アプローチを提唱しています。
この方法の全体のポイントは、学習機会の蓄積と問題解決の意識的なプロセスにあります。従業員は偶然ではなく、問題の体系的な分析、根本原因の検索、適切な対策の実装、テスト、およびチームが学んだことの活用によって成功しています。この繰り返される活動は、個人および集団のパフォーマンスを大きく加速させます。レッドビンの処理により、頻繁にスキルの問題から生じる品質問題の原因を正確に特定することができます。これは、スクラムマスターまたはチームリーダーが、より関連性の高いユーザーストーリーやよりクリーンなコードを書くなどの特定の作業に取り組むために、スキルマトリックスやトレーニング道場をセットアップする機会となります。
図8 - 能力マトリックスの例
フロー、過剰生産、待機時間の分析により、プロジェクトまたは製品と他のエコシステムとの密着性をより理解できます。チームメンバーは、チーム内だけでなく、より重要なこととして、関連するトピックに取り組む相手と集中的なコラボレーションを構築します。問題解決はもはや個人的な問題ではなく、広義のチームの問題です。少しずつ、組織全体がより良く機能します。改善が集合的に行われるため、プロセスがシンプルになります。
結果
この方法論を適用した20のチームについて、パフォーマンスの大幅な改善を計測されました。
生産品質の向上
したがって、品質の分野では、未処理のインシデントの在庫が平均59％減少しました。同時に、新しいインシデントの量は37％減少しました。これにより、顧客満足度が平均25％向上しました。
図9 - 品質改善
価値生産の加速
インシデントの解決、小さな変更の開発、または新しいユーザーストーリーの実現のいずれにおいても、加速は顕著です。リードタイムは平均で1/6.5となり、生産量は3倍になりました。
図10 - 価値生産の加速
経済的影響
たとえば、40人のビジネスユニットでは、5人の従業員に相当する人がインシデントの修正を担当します。実験的に、マネージャーはインシデントの削減に専念するチームを作成することにしました。6か月で、この新しいチームはTPSの実装のおかげで、インシデントを根絶し、常時80インシデントのストックと毎日発生する3インシデントから、0のストックと月当たり2インシデントのボリュームに遷移しました。インシデントを解決するコストは消えてなくなります。年間720 000ユーロから0ユーロ（5人×600ユーロ×240日）。 6か月で、マネージャーはRUN予算から50万ユーロ以上を稼ぎ出しました（品質改善によって引き起こされた節約を含めずに）。そのため、予算を価値生産に再配分できます。この生産性の向上により、小さな変更のバックログの処理を加速し、それにより顧客により多くの価値をもたらすことができます。
結論
リーン管理システムの目的は、優れた従業員を育成し、優れた製品を生産することです。トヨタの生産システムであるTPSは、従業員がスキルを開発することでそれらを解決できるようにプロセスの弱点をハイライトすることを唯一の目的とする一連のプラクティスです。スクラムは、コンピューターシステム生産のためのジャストインタイムの実装です。この方法は、PDCAの形式を持つ一連の追加分（システムの構築）を律動的に処理します。（Plan）スプリント計画、（Do）スプリント、（Check）スプリントレビュー、（Act）振り返りです。
ただし、TPSの適用はそこで停止してはなりません。プロセスの各ステージで、従業員は、プロダクトオーナー、開発者、アーキテクト、テスターなど、生産チェーン全体を通して個々に、あるいは集合的に成長できます。したがって、問題の発生場所をリアルタイムで明らかにし、状況を改善する機会を提供するシステムを持つことは、全員の開発にとって基本です。状況とは、スキル、プロセス、または異なるサービス間の相互作用です。
TPSは下記に必要なツールを提供します。
- プロセスのさまざまなステップを示す状態のビジュアル管理
- 生産にリズムを与え、納期を守る能力について即座にフィードバックできるプルフロー
- 生産物の品質に関するフィードバックを即座に提供するレッドビン
このシステムでは、チームは日々の目標の達成を妨げる運用上の問題に集中します。厳密な科学的分析手法のおかげで、チームメンバーはスキルを磨き、問題を次々に解決します。各PDCAにより、すべてのユーザーストーリーが製造プロセスを経てスムーズに生産に至る、生産の理想に近づけられます。Jidokaの実装により、通常はスキルの問題に関連する品質の問題が明らかになります。ジャストインタイムは、フローの問題と、システム間の残りの部分との密着性を示し、チーム間の問題解決をトリガーします。
少しずつのユーザーストーリーがより適切に記述され、サイズが縮小することで、開発者はより良い品質で、より保守性、堅牢性、信頼性の高いコードを生成します。インテグレーターは欠陥が少なくなり、境界テストや自動化に集中する時間を増やせます。他のチームとの共同作業により、システムが簡素化され、交換が簡素化します。チームは新しいスキルを開発し、新しいプラクティスを採用します。品質が向上し、生産が高速化され、コストが削減されると、チームの能力が向上します。顧客は微笑みます:-)
著者について
Pierre Jannez氏は、ITチームのパフォーマンスの向上に特化したリーンITシニアコーチです。彼は2001年からアジャイルプラクティスに興味を持ち、フランスの開発チーム内で10年間ノキアとノキアシーメンスネットワークスでそれらを展開しました。展開したプラクティスは、エクストリームプログラミング、TDD、継続的インテグレーション、BDD、継続的デリバリー、スクラムです。2008年、彼と彼のチームはリーンを発見しました。最初のアプリケーションは即座に結果を出し、品質とリードタイムが大幅に向上しました。2010年以来、彼はOperae Partners社のIT分野におけるトヨタ生産システムの適用に専念しています。