リーン ソフトウェア開発
David J. Anderson 著 David J. Anderson は 3 冊の本の著者です, Lessons in Agile Management: On the Road to Kanban は 2012 年に出版されました。Kanban: Successful Evolutionary Change for your Technology Business、[1] は 2010 年に出版され、そして、Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results、[2] は 2003 年に出版されました。 同氏は、1997 ～ 1999 年にシンガポールでフィーチャ駆動型開発というアジャイル ソフトウェア開発手法を生み出したチームのメンバーでした。 Mallory は MSF for CMMI Process Improvement v5.0 のプロセス テンプレートを作成し、ソフトウェア エンジニアリング研究所のテクニカル ノートを、"CMMI と、共著しました: 理由、容認両方とも!" Mallory は細いシステムの社会の使用者です (http://www.leansystemssociety.org)。 Mallory は傾きかんばん University Inc.のみなされての試験実行の CEO で、品質標準の組織のパートナー世界中に、自分のネットワークを通じて提供のかんばんの試験実行は、各国語管理者および教育を参照する企業、David J.説明します。 Anderson & Associates Inc. (http://www.agilemanagement.net) の代表を務めています。
Anderson 氏がリーン ソフトウェア開発について説明します。
対象
リーン、ソフトウェア開発、プロジェクト管理、Team Foundation Server
Introduction
リーンとアジャイル
アジャイルを超えたリーン
リーン ソフトウェア開発の定義
価値
原則
プラクティス
リーン ソフトウェア開発という用語は、1992 年 10 月に欧州連合の ESPRIT の主導によってドイツのシュトゥットガルトで開催された会議のタイトルとして作り出されました。 それとは別に、翌 1993 年には Robert ("Bob") Charette 氏が、ソフトウェア プロジェクトにおけるリスク管理方法の改善の研究の一部として "リーン ソフトウェア開発" という概念を示しました。 "リーン" という用語の登場は 1991 年にさかのぼり、James Womack、Daniel Jones、および Daniel Roos の著書『The Machine That Changed the World: The Story of Lean Production』[3] においてトヨタの管理手法を説明する語として用いられました。 リーンをソフトウェア開発にも適用できるという考えは、製造工程と生産工学の動向に関連してこの用語が初めて使われた 1 ～ 2 年後にはもう確立されていました。
Womack 氏と Jones 氏は、1995 年に刊行された 2 冊目の著書[4] の中で、リーン思考の 5 つの主柱を 次のように定義しました。
価値
価値の流れ
[フロー]
プル
完全性
これが、以後 10 年近くにわたってリーンの便宜的定義となりました。 同書では、完全性の追求はムダの排除によって達成されると示唆されていました。 柱は 5 つありましたが、幅広い読者の共感を得たのは、ムダの多い作業を系統的に特定して排除することで完全性を追求するという 5 番目の柱でした。 1990 年代後半から 21 世紀初頭にかけて、リーンは、ほぼ例外なくムダの排除の実践と関連付けられていました。
Womack 氏と Jones 氏によるリーンの定義は一般的に共有されていません。 トヨタにおける管理の原則ははるかに複雑です。 英語の "waste" という語は、3 つの日本語でさらに詳しく表されます。
ムダ: 文字どおり "無駄" を意味しますが、付加価値のない作業を暗に示します。
ムラ: "不均一" を意味し、"フローのばらつき" として解釈されます。
ムリ: "過負荷" または "不合理" を意味します。
完全性は、付加価値のない作業の削減に加えて、フローの円滑化と過負荷の排除によっても追求されます。 また、トヨタの手法は人に対する根本的な敬意に基づいており、W. Edwards Deming 氏をはじめとする 20 世紀の品質保証および統計的工程管理の専門家たちの教えの影響を大きく受けています。
残念ながら、リーンには、このテーマに関する著者の数と同じくらいの定義があります。
リーンとアジャイル
Bob Charette 氏は、2001 年にユタ州スノーバードで行われた、アジャイル ソフトウェア開発宣言[5] が作成された会議に招待されていましたが出席できませんでした。 この歴史的な会議への欠席にもかかわらず、リーン ソフトウェア開発は、ソフトウェア開発に対するいくつかのアジャイル アプローチの 1 つと見なされました。 Jim Highsmith 氏は、2002 年に刊行された著書[6] の中で、この話題についての Bob へのインタビューに 1 章を割いています。 その後、Mary & Tom Poppendieck 夫妻が 3 冊のシリーズ本[7,8,9] を執筆しました。 21 世紀の最初の数年間、リーン原則は、アジャイル方式が優れている理由を説明するために使用されました。 アジャイル方式が "ムダ" をほとんど含まないため高い経済的成果をもたらすということが、リーンによって示されました。 リーン原則はアジャイル方式を採用するための "お墨付き" として利用されていたのです。
アジャイルを超えたリーン
近年、リーン ソフトウェア開発は、アジャイル運動関連ではあるがその一部ではない独自の分野として浮上してきました。 この進化は、リーン製品開発の考えと Donald G. Reinertsen の研究[10,11] を、非アジャイル界の大規模なシステム エンジニアリングから生じた考えと James Sutton 氏および Peter Middleton 氏の著作[12] と組み合わせたことから始まりました。 また私は、Eli Goldratt 氏と W. Edwards Deming 氏の研究を組み合わせて、ムダの削減よりもフローに焦点を合わせました[13]。 2005 年ごろ、私は Reinertsen 氏の要請を受けてかんばん方式の使用を紹介しました。これは、仕掛品を抑え、システムが処理できる状態になったときにのみ新しい作業を "プル" するという方法です。 Alan Shalloway 氏は、2009 年に刊行された著書[14] の中で、リーン ソフトウェア開発に自らの見解を加えました。 2007 年以降、ソフトウェア開発界における新勢力として浮上したリーンは、フローの改善、リスクの管理、および (経営陣の) 意思決定の改善に重点を置いてきました。 かんばんは、IT 関連の作業でリーン構想を成功させるための鍵となっています。 ムダの排除よりもフローを重視することが、ソフトウェア開発のようなナレッジ ワーク活動での継続的改善を促進することが実証されつつあるようです。
リーン ソフトウェア開発の定義
リーン ソフトウェア開発には固有の手法またはプロセスがないため、リーン ソフトウェア開発を定義するのは困難です。 リーンは、パーソナル ソフトウェア プロセス、V モデル、スパイラル モデル、EVO、フィーチャ駆動型開発、エクストリーム プログラミング、スクラム、またはテスト駆動開発とは異なります。 あるソフトウェア開発ライフサイクル プロセスまたはプロジェクト管理プロセスが、リーン ソフトウェア開発運動の価値とリーン ソフトウェア開発の原則に沿っていると認められたときに、それを「リーン」であると言うことができます。 したがって、リーン ソフトウェア開発と名付けて従うことができる単純な手法を期待している方は失望されることでしょう。 リーン原則を理解し、リーンの中核的な価値を採用することによって自分のソフトウェア開発プロセスを作成または調整する必要があります。
リーン ソフトウェア開発にはいくつかの学派があります。 最大の誤りやほとんどなくルーティングは、School ドナルド Reinertsen、Jim Sutton、アラン Shalloway、Bob Charette (Mary Poppendeick、および David J.を含むリーン システムの社会です。 Anderson 著 クレイグ Larman、Bas Vodde[15,16]、およびように、社会および信条を使って構成の前に別に開発された Mary および作成 Poppendieck 作業の最新、Jim Coplien[17]の作業が。 リーン システムの社会の視点に、よく表す信条に表現されている概念との統合と概要を提供するこの記事の努め。
価値
リーン システムのリーンは、社会 2012 ソフトウェアとシステム会議[19]で[18] 信条を発行します。 これは、発行済みの値により以前基づいて。 これらの値は次のとおりです。:
人間の状態を受け入れる
ナレッジ ワークには複雑性と不確実性がつきものであることを受け入れる
優れた経済的成果を実現するよう努力する
その一方で、優れた社会学的成果を実現する
幅広い領域の思想を探求し、受け入れ、議論する
価値に基づくコミュニティはプラスの変化を加速し深める
人間の状態を受け入れる
ソフトウェア開発のようなナレッジ ワークを請け負うのは人間です。 我々人間は本質的に複雑であり、論理的思考をする一方で、感情や、理性では抑えられない動物的特徴に導かれることもあります。 人間が作業するシステムまたはプロセスを設計するときは、心理学および神経心理学を考慮する必要があります。 また、社会的マナーにも適応しなければなりません。 人間は本質的に感情的、社会的、および部族的であり、その振る舞いは疲労とストレスに伴って変化します。 人間の状態を否定して論理的、機械的な振る舞いを前提とするプロセスよりも、人間の状態を受け入れてそれに適応するプロセスが成功を収めます。
ナレッジ ワークには複雑性と不確実性がつきものであることを受け入れる
顧客の振る舞いと市場は予測不可能です。 プロセスや作業者の集まりの中の作業フローは予測不可能です。 欠陥と必要な再作業は予測不可能です。 ソフトウェア開発内の多くのレベルに、本来備わっている可能性や一見不規則な振る舞いがあります。 プロジェクトの目的、目標、およびスコープはプロジェクトの遂行中に変更されがちです。 このような不確実性と変動性の一部は、最初は未知であっても、調査、数値化、リスク管理できるという意味で把握が可能です。しかし変動性の中には、事前に知ることも適切に予測することもできないものがあります。 そのため、リーン ソフトウェア開発のシステムには、次々と明らかになる事象に反応し、変わりゆく環境に適応する能力が必要です。 したがって、すべてのリーン ソフトウェア開発プロセスは、次々と明らかになる事象に対する (プロセスの) 適応が可能なフレームワーク内に存在しなければなりません。
優れた経済的成果を実現するよう努力する
リーン ソフトウェア開発のような人間の活動は、優れた経済的成果を生み出すことに重点を置く必要があります。 資本主義は、ビジネスの価値と顧客の利益の両方に貢献する場合に受け入れられます。 ビジネスの投資者および所有者は、投資に対する利益を得る資格があります。 従業員および作業者は、作業の実行における正当な努力に対して、正当な率の報酬を受ける資格があります。 顧客は、支払われた正当な価格と引き換えに約束された利益をもたらす、優れた製品またはサービスを受ける資格があります。 優れた経済的成果には、投資者または所有者によって配置された資本をできる限り効果的な方法で管理しながら、より多くの価値を低いコストで顧客に提供することが含まれます。
優れた社会学的成果を実現する
優れた経済的成果は、作業者の犠牲のもとに実現されるものであってはなりません。 人間の状態を受け入れることで人を尊重した作業環境を作り、人の心理学的性質および社会学的性質を尊重した作業のシステムを提供することが重要です。 優れた作業のために優れた作業環境を作ることは、リーン ソフトウェア開発コミュニティの中心的な価値です。
原則
Lean Software & Systems コミュニティは、リーン ソフトウェア開発プロセスを支えるいくつかの原則に関してほぼ合意しています。
システム思考 & 設計アプローチに従う
創発的成果は複雑適応系のコンテキストの設計によって影響を受ける可能性がある
(システムの一部として) 人を尊重する
(改善を推進するために) 科学的手法を使用する
リーダーシップを奨励する
(作業、ワークフロー、およびシステム運用における) 可視性を実現する
フロー時間を短縮する
ムダを減らして効率を上げる
システム思考 & 設計アプローチに従う
これは、リーンの文献ではしばしば "全体を最適化する" と呼ばれます。最適化が必要なのはシステム (またはプロセス) 全体のアウトプットであり、部分の最適化によって全体が魔法のように最適化されるだろうという誤った期待を抱いてはならないことを意味します。 ほとんどの実践者は、部分の最適化 (ローカル最適化) が次善の成果をもたらすという推論が真実であると信じています。
リーンのシステム思考 & 設計アプローチでは、システムに関する外部の利害関係者 (顧客など) からの要求と、それらの利害関係者が求めている望ましい成果を考慮する必要があります。 要求の本質を調べ、提供するシステムの機能と比較しなければなりません。 要求には、いわゆる "価値の要求" (顧客が進んで代金を支払う対象) と "失敗の要求" (通常は、価値の要求の提供における失敗によって発生した再作業または追加の要求) が含まれます。 失敗の要求は多くの場合、以前に提供した価値の要求に対する再作業と、価値の要求の提供における失敗によって生じた追加のサービスまたはサポートという 2 つの形をとります。 ソフトウェア開発での失敗の要求は通常、バグ修正の要求と、カスタマー ケアまたはヘルプ デスク機能の要求です。
システム設計アプローチでは、Plan-Do-Study-Act (PDSA: 計画、実行、評価、改善) アプローチに従って設計および改善を進める必要もあります。 西部 Edwards Deming 氏は、システムの振る舞いの自然哲学を調べることを「評価」と「能力」という語で示しました。 このシステムは、ソフトウェア開発プロセスとそれを運用するすべての人で構成されます。 システムは、リード タイム、品質、提供される機能の量 (アジャイルの文献では "ベロシティ" と呼ばれます) などに関して観測可能な振る舞いを持ちます。 これらのメトリックは変動性を示すため、変動の平均と分布を調べることで能力の理解を深めることができます。 それが要求および顧客の期待と一致しない場合は、システムを再設計してギャップを埋める必要があります。
Deming 氏は、能力の 95% がシステム設計の影響を受け、個人の働きの貢献は 5% のみであるとも説きました。 つまり、能力と要求のギャップの責任を人に負わせず、成功のためにシステムを再設計することにより、人を尊重することができます。
システム設計を理解するには、システム能力のダイナミクスと、それがどのような影響を受ける可能性があるかについての科学的な理解が必要です。 システムのダイナミクスを予測するためにモデルが作成されます。 考えられるモデルは多数ありますが、経済的コスト (顧客価値のある製品またはサービスの生産に関連する、いわゆる取引コストと調整コスト) の把握、制約条件の理論 (ボトルネックの把握)、および深遠な知識の理論 (システム設計に共通の変動性またはシステム設計外の特殊な変動性の調査と認識) など、一般的に使用されているモデルがいくつかあります。
創発的成果は複雑適応系のコンテキストを設計することによって影響を受ける可能性がある
複雑系には、出発状態と、繰り返し実行されたときに創発的成果を生む単純な規則があります。 出発状態から創発的成果を予測することは困難または不可能です。 コンピューター科学の実験 "The Game of Life" は複雑系の一例です。 複雑適応系は自己認識機能と内部的な思考方法を備えており、それを使用して、望ましい成果を達成するために現在の規則セットがどの程度有効であるかを検討できます。 その後、複雑適応系は自ら適応 (自身の単純な規則を変更) して、現在の成果と望ましい成果の間のギャップを埋めることができます。 プレイ中に規則を書き換えられるほどに適応した "The Game of Life" は、複雑適応系の 1 つと言えるでしょう。
ソフトウェア開発プロセスにおける複雑適応系の "単純な規則" は、プロセス定義を構成するポリシーです。 ここで中核となる原則は、ソフトウェア製品およびサービスの開発は決定論的な活動ではないため、適応能力を持たない定義されたプロセスは予測不可能な事象への適切な答えにならないという信念に基づいています。 したがって、システム思考および設計アプローチの一部として設計されるプロセスには適応性が必要です。 プロセスは、それを構成するポリシーを変更することによって適応します。
リーン ソフトウェア開発へのかんばんアプローチはこの概念を利用し、かんばんのプル システムのポリシーを "単純な規則" として扱います。出発状態は、作業およびワークフローが視覚化されていること、フローがシステム ダイナミクスの知識を使用して管理されること、および、組織が科学的アプローチを使用してプロセスの改善を理解、提案、実施することです。
人を尊重する
リーン コミュニティは、自分の実行する作業に関して上司よりも豊富な知識を持っている作業者はナレッジ ワーカーであるという、Peter Drucker 氏のナレッジ ワークの定義を導入しています。 これは、作業者が作業の実行方法とそれを改善するためのプロセスの変更方法に関する意思決定を行うのに最適な位置にいることを暗示しています。 したがって、作業者の意見は尊重しなければなりません。 作業者は、自己組織化して作業を遂行し望ましい成果を得るための権限を与えられる必要があります。 また、プロセス改善の機会 (リーンの文献では "カイゼン イベント" と呼ばれます) を提案および実施するための権限も与えられる必要があります。 プロセスのポリシーを明確にして作業者が自分に課せられた規則を認識できるようにすることは、作業者を尊重するもう 1 つの方法です。 明確に定義された規則は、不安を取り除き勇気を不要にすることにより、自己組織化を促進します。 権限の付与と明確に宣言された一連のポリシーの提示によって人を尊重することは、人間の状態を尊重するという中心的価値にも当てはまります。
科学的手法を使用する
作業がどのように実行され、リーン ソフトウェア開発のシステムがどのように機能しているかを、モデルを使用して理解するように努めてください。 システムとその能力を観察し調査した後で、その振る舞いを予測するためのモデルを作成し適用します。 調査では定量的データを収集します。そのデータを使用して、システムの実行状態を把握し、プロセスを変更した場合にそれがどのように変わるかを予測します。
Lean Software & Systems コミュニティは、システムの能力を把握するために、リード タイムとベロシティの生データの統計的プロセス コントロール チャートやスペクトル解析ヒストグラムなどの統計的手法を使用します。 また、制約条件の理論 (ボトルネックを把握するため)、深遠な知識の体系 (システム設計内部の変動性と、外部から影響を受けた変動性を把握するため)、経済的コスト (顧客価値のある製品またはサービスの作成後に、調整、セットアップ、提供、クリーンアップのためだけに実行されたタスクという形で発生するコスト) の分析などのモデルも使用します。 その他にも、財務リスク管理の金融オプション理論を現実世界の意思決定に適用しようとするリアル オプション理論など、いくつかのモデルが使われ始めています。
科学的手法とは、調査を行い、モデルに基づいて成果を想定し、その予測に基づいてシステムを変更し、変更がモデルで予測した結果を生み出したかどうかを再度観察することを示します。 予測どおりの結果が得られない場合は、データをチェックし、モデルが正しいかどうかを再検討します。 モデルを使用してプロセスの改善を推進することは、プロセスを科学的な活動に移行させ、直感に基づく迷信的な活動から上のレベルへと引き上げます。
リーダーシップを奨励する
リーダーシップとマネジメントは同じではありません。 マネジメントとは、プロセスを設計し、ポリシーを作成、変更、および削除し、戦略上および業務上の意思決定を行い、リソースを収集し、資金と施設を用意し、戦略、目標、望ましい成果などのコンテキストに関する情報を伝える活動です。 リーダーシップとは、ビジョン、戦略、戦術、勇気、革新、判断、擁護、およびその他のさまざまな特性を指します。 リーダーシップは組織内のどのメンバーからも発生する可能性があり、またそうあるべきです。 作業者からの小さなリーダーシップ行為が、リーン ソフトウェア開発プロセスの作成に必要な変化をもたらす改善の流れを作り出します。
可視性を実現する
ナレッジ ワークは目に見えません。 目に見えないものを管理することは (ほとんど) 不可能です。 行われる作業と、その作業が個人、技能、および部門のネットワークを通じて完了されるまでのフローにおいて、可視性を実現する必要があります。 プロセスのフローを視覚化する手段を見つけ出し、プロセスのポリシーをだれもが確認および検討できるように明示することによって、プロセスの設計における可視性を実現する必要があります。 これらがすべて可視化されると、科学的手法の使用が可能になり、可能な改善についての客観的な話し合いを共同で行うことができます。 作業とワークフローが目に見えず、プロセスのポリシーが明らかでない場合、共同作業によるプロセス改善はほぼ不可能です。
フロー時間を短縮する
従来、ソフトウェア開発の従事者と学者は、1 つの活動への取り組みに費やされた時間の測定に重点を置いてきました。 リーン ソフトウェア開発コミュニティは、なんらかの処理が完了するまでに実際に経過したカレンダー時間を測定する方が有益であることに気付きました。 これは一般にサイクル タイムと呼ばれ、通常は、実行される活動の境界によって区切られます。 たとえば、分析から配置準備完了までのサイクル タイムでは、ユーザー ストーリーなどの作業項目が分析、設計、開発され、さまざまな方法でテストされ、運用環境への配置準備が完了した状態でキューに入れられるまでの合計経過時間を測定します。
プロセスを通過するのに要した作業時間を重視することは、いろいろな意味で重要です。 サイクル タイムの増加は、バグ率の非線形的増加と関連があることがわかっています。 したがって、サイクル タイムが短いほど品質は高くなります。 キューで待機中の、人間が実際に操作していないコードにバグが入り込むのはおかしいように思われるため、これは直感に反しています。 従来、このテーマを研究するソフトウェア エンジニアリングの従事者と学者は、このアイドル時間を無視してきました。 しかし、サイクル タイムが初期品質にとって重要であることは、経験的証拠によって示されています。
Alan Shalloway 氏も、"誘発された作業" という概念について述べています。同氏は、タスクの実行の遅れによって本来よりもはるかに大きな労力が必要になる場合があるという見解を示しました。 たとえば、発見後すぐに修正すれば 20 分で修正できるバグが、トリアージされ、キューに配置され、数日または数週間経ってから修正される場合には修正に何時間もかかることがあります。 つまり、サイクル タイムの遅延によって追加の作業が "誘発された" のです。 この作業は回避できるため、"ムダ" と見なさなければなりません。
サイクル タイムを重視する 3 番目の理由は、ビジネスに関連する理由です。 すべての特性、機能、またはユーザー ストーリーには値があります。 その値は不確定な場合もありますが、それでも値は存在します。 値は時間の経過と共に変化する場合があります。 時間の経過と共に変化する値という概念は、経済学的には市場ペイオフ関数として表すことができます。 作業項目の市場ペイオフ関数を理解すると、関数が不確実性をモデル化する値の分布を示していても "遅延のコスト" を評価できます。遅延のコストを使用して、サイクル タイムの削減に値段を付けることができます。
一部の作業項目では、将来の特定の日付まで市場のペイオフ関数が始まりません。 たとえば、米国の祝日である 7 月 4 日に使用するように設計された機能は、その日より前には何の価値もありません。 そのような例でも、サイクル タイムの短縮と、ある程度確実にサイクル タイムを予測できることは役に立ちます。 理想的には、目的の日付よりも早すぎず、遅くもなく (提供の遅れは遅延のコストを発生させます)、必要なときに "ジャスト イン タイム" で機能が提供されるように作業を開始する必要があります。 ジャストインタイム納品は、利用可能なリソースが最適に使用されたことを示します。 期日よりも早い提供は、他の作業を実行できた可能性があることを意味し、遅延の機会コストを発生させた可能性があることを暗に示します。
これらの 3 つの理由により、リーン ソフトウェア開発では、フロー時間の最小化と、フロー時間に関する予測を行うためのデータの記録に努めます。 目的は、バグによる失敗の要求とバグの修正の遅延から生じた過負荷によるムダを最小限に抑え、遅延のコストと遅延の機会コストの両方を回避することで得られる価値を最大化することです。
ムダを減らして効率を上げる
付加価値のあるすべての作業には、必要だがそれ自体は価値を付加しないセットアップ作業、クリーンアップ作業、および提供作業が含まれます。 たとえば、正しく機能するソフトウェアのインクリメントを開発するプロジェクト イテレーションでは、計画 (セットアップ作業)、環境と場合によってはバージョン管理のコード分岐 (これらはセットアップ作業であり、まとめて構成管理と呼ばれます)、リリース計画と実際のリリースの実行 (提供作業)、顧客へのデモンストレーション (提供作業)、および場合によっては環境の破棄または再構成 (クリーンアップ作業) が必要です。経済用語では、セットアップ作業、クリーンアップ作業、および提供作業は付加価値のある作業の実行に関する取引コストとなります。 リーンでは、これらのコスト (オーバーヘッド) はムダと見なされます。
あらゆる形の通信オーバーヘッドはムダと見なすことができます。 プロジェクトの状態を判定し、チーム メンバーに対する作業のスケジュールまたは割り当てを行うための会議は、経済用語では調整コストと見なされます。 リーン思考では、調整コストはすべてムダです。 リーン ソフトウェア開発手法では、チーム メンバーのコロケーション、対面による短時間の会議 (スタンドアップ ミーティングなど)、および目で見る管理 (壁掛けボードなど) を使用することで、調整コストの排除または削減に努めます。
リーン ソフトウェア開発における 3 つ目の一般的な形式のムダは、失敗の要求です。 失敗の要求はソフトウェア開発のシステムにとって負担となります。 失敗の要求は通常、不十分な品質の副作用として生じた再作業または新しい形式の作業です。 ソフトウェア開発で最もよくある失敗の要求は、バグ、製造不良、および、ソフトウェアを意図したとおりに使用できないことが原因で発生するカスタマー サポート作業です。 失敗の要求である仕掛品の割合は、失敗の負荷と呼ばれます。 失敗の要求に対する付加価値作業の割合は、システムの効率性の尺度となります。
付加価値のない取引コストと調整コストをすべて含めた作業全体に対する付加価値作業の割合によって、効率性のレベルが決まります。 取引コスト、調整コスト、および失敗の負荷がないシステムは 100% 効率的であると見なされます。
これまで、西洋の経営科学では、作業のバッチ サイズを大きくすることで効率性を高めることができると教えられてきました。 一般には、取引コストと調整コストは固定されているか、バッチ サイズを大きくしてもわずかしか増加しません。 そのため、バッチが大きい方が効率は良くなります。 この概念を "規模の経済" と呼びます。しかしナレッジ ワークの問題では、多くの場合、バッチ サイズを大きくすると取引コストは線形で増加しますが、調整コストは非線形で増加します。 したがって、効率性に対する従来の 20 世紀的アプローチはソフトウェア開発のようなナレッジ ワークの問題には適しません。
効率を向上するには、バッチ サイズを小さく抑えたままでオーバーヘッドを削減することに注力する方が得策です。 つまり、リーンでの効率向上の方法は、ムダを減らすことです。 リーン ソフトウェア開発手法では、高速、低コストで簡単な計画手法、低い通信オーバーヘッド、効率的で低オーバーヘッドの調整メカニズム (かんばん方式の目で見る管理など) を重視します。 また、提供の取引コストを削減するために、自動テストと自動配置を推進します。 環境のセットアップと破棄のコストを最小限に抑えるための新しいツール (新しいバージョン管理システムや仮想化の使用など) も、小さいバッチのソフトウェア開発の効率改善に役立ちます。
プラクティス
リーン ソフトウェア開発では、プラクティスを規定していません。 より重要なのは、実際のプロセス定義が基本原理と価値に沿っていることを示すことです。 しかし、多数のプラクティスが広く導入されています。 ここでは、その一部の概要を簡単に説明します。
累積フロー ダイアグラム
累積フロー ダイアグラムは、2005 年以降、Team Foundation Server のレポート作成の標準機能になっています。 累積フロー ダイアグラムは、ワークフローの各状態にある累積作業項目の面グラフをプロットします。 これは豊富な情報を含み、プロセス内のステップの平均サイクル タイムとスループット率 ("ベロシティ") を調べるために使用できます。 累積フロー ダイアグラムに表示される視覚的特徴は、ソフトウェア開発ライフサイクル プロセスによって異なります。 作業者は、面グラフに表示されたプロセスの機能不全のパターンを見分ける方法を習得できます。 真のリーン プロセスでは、安定したペースでなだらかに上昇する、均等に分布した色の領域が表示されます。 図は、のこぎり状になったステップや一見してわかる色の塊がなく、滑らかに見えます。
最も基本的な形式の累積フロー ダイアグラムは、作業項目ライフサイクルの特定のステップにある仕掛品の量を視覚化するために使用されます。 また、ボトルネックを検出し、"ムラ" (フローのばらつき) の影響を監視するためにも使用できます。
目で見る管理
累積フロー ダイアグラムの使用に加えて、リーン ソフトウェア開発チームは、物理的なボードまたは電子可視化システムの画像を使用して作業の視覚化とフローの監視を行います。 このような視覚化は、チーム メンバーが仕掛品の蓄積を監視するのを支援し、ボトルネックと "ムラ" の影響を確認できるようにします。また、目で見る管理によって、チーム メンバーは計画や管理者からの個別の指示または介入を必要とせずに自己組織化し、作業を選択して互いに協力し合うことができます。 これらの目で見る管理は一般に "壁掛けボード" と呼ばれますが、"かんばんボード" と誤って呼ばれることもあります。
仮想かんばんシステム
かんばんシステムは、リーン製造から導入されたプラクティスです。 これは、物理的カードのシステムを使用して、ワークフローの特定のステージにある仕掛品の数量を制限します。 そのような仕掛品を制限するシステムでは "プル" が作成され、新しい作業を特定の状態に "プル" して作業を進めることができることを示す空きかんばんがあるときにだけ、新しい作業が開始されます。
リーン ソフトウェア開発のかんばんは仮想的なかんばんであり、多くの場合、1 つの作業項目タイプのワークフロー内の指定したステップに対して最大数を設定することにより管理されます。 実装によっては、電子システムで仮想かんばんが追跡され、新しい作業が開始可能になったときに通知が行われます。 通知は視覚的に行われるか、電子メールなどの警告の形で行われます。
仮想かんばんシステムは、目で見る管理と組み合わせて、1 つまたは複数の作業項目タイプのワークフローを表す視覚的な仮想かんばんシステムとして使用されることがよくあります。 このようなシステムは通常、"かんばんボード" または "電子かんばんシステム" と呼ばれます。視覚的な仮想かんばんシステムは Team Foundation Server の Visual WIP[20] というプラグインとして提供されています。 このプロジェクトは、スウェーデンの Hakan Forss 氏によってオープン ソースとして開発されました。
小さいバッチ サイズ/シングルピース フロー
リーン ソフトウェア開発では、作業が "イテレーション" または "インクリメント" と呼ばれる小さいバッチで行われるか、作業項目が "シングルピース フロー" と呼ばれる独立したフローで処理される必要があります。シングルーピース フローには、不完全な作業を誤ってリリースすることなく完全な作業を提供できる、高度な構成管理が必要です。 これは通常、バージョン管理システムの分岐戦略を使用して実現されます。 一般に、小さいバッチの作業とは、8 人の小さなチームまたは 2 週間未満の期間で実行できるバッチです。
小さいバッチとシングルーピース フローでは、バックログ、キュー、または作業の補充のために経営者との頻繁なやり取りが必要です。 また、頻繁なリリースを行う能力も必要です。 経営者との頻繁なやり取りと頻繁な提供を実現するには、両方の活動の取引コストと調整コストを縮小する必要があります。 そのための一般的な方法が、オートメーションの使用です。
[オートメーション]
リーン ソフトウェア開発では、シングルピース フローを経済的に可能にし、品質の向上と失敗の要求の削減を推進するために、高レベルなオートメーションを必要とします。 デザイン パターンの配置とソース コードの変動の少ない反復部分の作成を自動化するための自動テスト、自動配置、およびソフトウェア ファクトリの使用はすべて、リーン ソフトウェア開発プロセスにおいては当たり前です。
カイゼン イベント
リーンの文献では、カイゼンという用語は "継続的な改善" を意味し、カイゼン イベントは改善をもたらす可能性がある変更をプロセスまたはツールに加える行為を指します。
リーン ソフトウェア開発プロセスでは、さまざまな活動を使用してカイゼン イベントを実施します。 それらを次に示します。 これらの活動はいずれも、能力に悪影響を及ぼす問題についての話し合いを活性化し、その結果として要求に応えられるようにすることを目的としています。 ナレッジ ワークのカイゼンで最も重要な点は、チームや技能がそれぞれ異なる人のグループ間で、問題についての話し合いを持つ必要があるということです。
毎日のスタンドアップ ミーティング
ソフトウェア開発者のチーム (通常は最大 50 人) が、ビジュアル コントロール システム (仕掛品を視覚的に表示したホワイトボードなど) の前でミーティングを行います。 チーム メンバーは、フローのダイナミクスと、作業のフローに影響を与える要因について話し合います。 特に、外部から阻害されている作業とバグによって遅延している作業に焦点が当てられます。 一連のスタンドアップ ミーティングによってプロセスの問題が明らかになることがよくあります。 その結果、ミーティング後に小さいグループが残って問題を議論し、ソリューションまたはプロセスの変更を提案します。 その後、カイゼン イベントが実施されます。 これらの自発的な会議は、古い文献では自発的品質管理サークルと呼ばれることもあります。 このような自発的な会議は、カイゼン文化の中核を成しています。 管理者は、組織でのリーンの導入を促進するために、毎日のスタンドアップ ミーティング後にカイゼン イベントの実施を奨励します。
振り返り
プロジェクト チームは、最近のパフォーマンスについて考察するための定例会議をスケジュールできます。 これは多くの場合、特定のプロジェクト成果物の完成後、または開発のタイムボックス化されたインクリメント (アジャイル ソフトウェア開発では、イテレーションまたはスプリントと呼ばれます) の後に行われます。
一般に、振り返りでは "何がうまくいったか?"、"違う方法があったことは何か?"、"何を止めるべきか?" のような問いかけによって考察する事例的手法を使用します。
振り返りでは、カイゼン イベントの提案のバックログが発生することがよくあります。 チームはその一部に実施のための優先順位を付けることができます。
運用の見直し
通常、運用の見直しは振り返りよりも大規模であり、バリュー ストリーム全体の代表者が参加します。 一般に、12 もの部門が、受け取った要求を示す客観的な定量的データを提示し、その要求に対する自らの提供能力について考察します。 運用の見直しは通常、毎月行われます。 運用の見直しと振り返りの主な違いは、運用の見直しの方が広範囲な機能 (プロジェクトおよびその他のイニシアティブのポートフォリオ) にわたり、客観的な定量的データを使用するという点です。 これに対して振り返りは、通常 1 つのプロジェクトを対象としており、分析、開発、テストなどのいくつかのチームだけが参加し、事例的性質を持ちます。
運用の見直しでは、パフォーマンスに影響を与えるダイナミクスについてのチーム間の議論が行われます。 あるチームで発生した失敗の要求が別のチームによって処理されていないか、 その失敗の要求が妨げとなって 2 番目のチームが任務を果たせず、要求に応えることができなかった可能性はないか。 運用の見直しでは、そのような問題を議論して変更を提案する機会を提供します。 運用の見直しでは通常、考えられるカイゼン イベントの小さなバックログが発生します。これに優先順位を付けて、将来の実施のためにスケジュールすることができます。
1 つのリーン ソフトウェア開発プロセスというものが存在するわけではありません。 あるプロセスがリーン ソフトウェア開発の価値と原則に明確に沿っているときに、それをリーンと呼ぶことができます。 リーン ソフトウェア開発ではプラクティスを規定していませんが、いくつかの活動が一般的に行われています。 リーン組織は、ワークフローおよび仕掛品の可視化と、フローのダイナミクスおよびそれに影響を及ぼす要因 (ボトルネック、即時でない可用性、変動性、ムダなど) の把握を通じてカイゼンを推進します。 プロセスの改善は、変動性の原因の削減、ムダの排除、フローの改善、または価値の提供やリスク管理の改善のための方法として提案され、正当化されます。 したがって、リーン ソフトウェア開発プロセスは常に進化し、それが進化する組織に合わせて独自に調整されます。 ある組織のプロセス定義をただ単に別の組織にコピーして、異なるコンテキストで機能することを期待するのは自然ではありません。 また、数週間または数か月ぶりに組織に戻ったときに、使用しているプロセスが以前見たときと同じである可能性は低いでしょう。 プロセスは常に進化します。
リーン ソフトウェア開発プロセスを使用している組織は、3 つの形の無駄 ("ムラ"、"ムリ"、"ムダ") が少ししかなく、効率的なリスク管理を通じて価値の提供を最適化していると見られる場合に、リーンであると言うことができます。 リーンにおける完全性の追求は常に旅です。 行き先はありません。 真にリーンな組織は常に、さらなる改善を追求します。
リーン ソフトウェア開発はまだ発展中の分野であり、今後 10 年間も進化し続けることが期待されます。
David J. Anderson 著『Kanban: Successful Evolutionary Change for your Technology Business』(Blue Hole Press、2010 年)
David J. Anderson 著『Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results』(Prentice Hall PTR、2003 年)
James P. Womack、Daniel T. Jones、および Daniel Roos 著『The Machine That Changed the World: The Story of Lean Production』(2007 年改訂版、Free Press、2007 年)
James P. Womack および Daniel T. Jones 著『Lean Thinking: Banish Waste and Create Wealth in your Corporation』(第 2 版、Free Press、2003 年)
Kent Beck ほか著『The Manifesto for Agile Software Development』(2001 年、http://www.agilemanifesto.org/)
James A Highsmith 著『Agile Software Development Ecosystems』(Addison Wesley、2002 年)
Mary Poppendieck および Tom Poppendieck 著『Lean Software Development: An Agile Toolkit』(Addison Wesely、2003 年)
Mary Poppendieck および Tom Poppendieck 著『Implementing Lean Software Development: From Concept to Cash』(Addison Wesley、2006 年)
Mary Poppendieck および Tom Poppendieck 著『Leading Lean Software Development: Results are not the Point』(Addison Wesley、2009 年)
Donald G Reinertsen 著『Managing the Design Factory』(Free Press、1997 年)
Donald G. Reinertsen 著『The Principles of Product Development Flow: Second Generation Lean Product Development』(Celeritas Publishing、2009 年)
James Sutton および Peter Middleton 著『Lean Software Strategies: Proven Techniques for Managers and Developers』(Productivity Press、2005 年)
David J. Anderson 著『Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results』(Prentice Hall PTR、2003 年)
Alan Shalloway、Guy Beaver、および James R. Trott 著『Lean-Agile Software Development: Achieving Enterprise Agility』(Addison Wesley、2009 年)
Craig Larman および Bas Vodde 著『Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum』(Addison Wesley Professional、2008 年)
『Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum』(Addison Wesley Professional、2010 年)
James O. Coplien および Gertrud Bjornvig 著『Lean Architecture: for Agile Software Development』(Wiley、2010 年)
http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/