リーンソフトウェア開発

リーンソフトウェア開発は、リーン製造の原則と実践をソフトウェア開発分野に翻訳したものです。トヨタ生産方式^[1]から採用され、アジャイルコミュニティ内のプロリーンサブカルチャーの支援を受けて登場しました。リーンは、アジャイル組織をサポートする、経験から得られた堅実な概念フレームワーク、価値と原則、および優れた実践を 提供します。

「リーンソフトウェア開発」という表現は、メアリー・ポッペンディークとトム・ポッペンディークが2003年に書いた同名の本に由来しています。^[2]この本では、従来のリーン原則と22のツールセットを再述し、それらのツールを対応するアジャイルプラクティスと比較しています。ポッペンディーク夫妻は、いくつかのアジャイルカンファレンスでの講演を含むアジャイルソフトウェア開発コミュニティに関与しており、^[3]こうした概念はアジャイルコミュニティ内でより広く受け入れられるようになりました。

リーン開発は、リーン製造の原則に非常に近い概念である7つの原則に要約できます。^[4]

1. 無駄をなくす
2. 学習を増幅する
3. できるだけ遅く決める
4. できるだけ早くお届け
5. チームに力を与える
6. 誠実さを築く
7. 全体を最適化

リーン哲学では、顧客に価値をもたらさないものはすべて無駄（ムダ）とみなします。そのような無駄には次のようなものが含まれます。^[5]

1. 部分的に完了した作業
2. 追加機能
3. 再学習
4. タスクの切り替え
5. 待っている
6. ハンドオフ
7. 欠陥
8. 管理活動

無駄をなくすには、それを認識できなければなりません。あるアクティビティをバイパスしたり、そのアクティビティがなくても結果を達成できる場合、それは無駄です。開発プロセス中に最終的に放棄された、部分的に完成したコーディングは無駄です。書類作業や顧客があまり使用しない機能などの余分な機能は無駄です。タスク間で人を切り替えるのは無駄です (コンテキスト切り替えに関係する人が時間を費やし、多くの場合、その時間を無駄にするため)。他のアクティビティ、チーム、プロセスを待つのは無駄です。作業を完了するための要件を再学習するのは無駄です。欠陥や品質の低下は無駄です。実際の価値を生み出さない管理上のオーバーヘッドは無駄です。

バリューストリーム マッピング手法は、無駄を特定するために使用されます。2 番目のステップは、無駄の原因を特定して、それを排除することです。一見必須のプロセスや手順さえも排除されるまで、無駄の除去は繰り返し行う必要があります。

ソフトウェア開発は、コードを書く際の反復に基づく継続的な学習プロセスです。ソフトウェア設計は、開発者がコードを書き、学んだことを基に問題解決を行うプロセスです。ソフトウェアの価値は、要件への適合性ではなく、使用への適合性で測定されます。

ドキュメントや詳細な計画を追加する代わりに、コードを書いて構築することでさまざまなアイデアを試すことができます。エンドユーザーに画面を表示して入力を取得することで、ユーザー要件収集のプロセスを簡素化できます。コードが書き込まれたらすぐにテストを実行することで、欠陥の蓄積を防ぐことができます。

学習プロセスは、短い反復サイクルの使用によって加速されます。各反復サイクルは、リファクタリングと統合テストと組み合わされています。顧客との短いフィードバック セッションを通じてフィードバックを増やすことは、現在の開発フェーズを決定し、将来の改善に向けて努力を調整するときに役立ちます。これらの短いセッション中に、顧客担当者と開発チームの両方がドメインの問題について詳しく学び、さらなる開発のための可能なソリューションを見つけ出します。このようにして、顧客は開発努力の既存の結果に基づいてニーズをよりよく理解し、開発者はそれらのニーズをよりよく満たす方法を学びます。顧客とのコミュニケーションと学習プロセスにおけるもう 1 つのアイデアは、セットベースの開発です。これは、将来のソリューションの制約を伝えることに集中し、可能なソリューションを伝えることではないため、顧客との対話を通じてソリューションの誕生を促進します。^{[専門用語]}

ソフトウェア開発には常に不確実性が伴うため、セットベースまたはオプションベースのアプローチでより良い結果を達成し、不確実な仮定や予測ではなく事実に基づいて決定を下せるまで、決定をできるだけ遅らせる必要があります。システムが複雑であればあるほど、変更の能力を組み込む必要があり、それによって重要で決定的なコミットメントを遅らせることができます。反復的なアプローチは、この原則、つまり変更に適応し、システムのリリース後に発見された場合に非常にコストがかかる可能性がある間違いを修正する能力を促進します。

セットベースの開発では、たとえば、自動車に新しいブレーキ システムが必要な場合、3 つのチームが同じ問題に対するソリューションを設計することがあります。各チームは問題領域について学習し、潜在的なソリューションを設計します。ソリューションが不合理であると判断されると、そのソリューションは削除されます。期間の終了時に、生き残った設計が比較され、他の設計から学んだことに基づいていくつかの変更を加えて 1 つが選択されます。これは、可能な限り最後の瞬間までコミットメントを延期する優れた例です。ソフトウェアの決定も、このプラクティスの恩恵を受けることができ、大規模な事前設計によってもたらされるリスクを最小限に抑えることができます。さらに、正しく機能するが、異なる (実装上、内部的に) 複数の実装が存在することになります。これらを使用して、複数の実装にわたってすべての入力と出力の正しさを同時にチェックするフォールト トレラント システムを実装できます。

アジャイルソフトウェア開発アプローチでは、顧客向けのオプションの構築を早めることができるため、顧客がニーズをよりよく理解するまで、特定の重要な決定を遅らせることができます。これにより、後で変更に適応したり、コストのかかる初期の技術制限された決定を回避したりすることもできます。これは、計画が不要であることを意味するものではありません。逆に、計画活動はさまざまなオプションと現在の状況への適応に集中し、迅速な行動のパターンを確立して混乱した状況を明確にする必要があります。さまざまなオプションを評価することは、それらが無料ではないが、遅い意思決定に必要な柔軟性を提供することを認識すれば、効果的です。

技術が急速に進化する時代において、生き残るのは最大のものではなく、最速のものです。最終製品が大きな欠陥なく早く納品されればされるほど、フィードバックを早く受け取り、次のイテレーションに組み込むことができます。イテレーションが短いほど、チーム内での学習とコミュニケーションは良くなります。スピードがあれば、決定を遅らせることができます。スピードがあれば、顧客の現在のニーズを満たすことができ、昨日必要としていたものを満たすことはできません。これにより、顧客は、より深い知識を得るまで、本当に必要なものについての決断を遅らせることができます。顧客は、高品質の製品を迅速に納品されることを高く評価します。

ジャストインタイム生産の理念は、ソフトウェア開発の特定の要件と環境を認識しながら、ソフトウェア開発に適用できます。これは、必要な結果を提示し、チームが組織化して、特定の反復で必要な結果を達成するためのタスクを分割できるようにすることで実現されます。最初に、顧客が必要な入力を提供します。これは、小さなカードまたはストーリーで簡単に提示できます。開発者は、各カードの実装に必要な時間を見積もります。このようにして、作業組織はセルフプルシステムに変わります。毎朝のスタンドアップミーティング中に、チームの各メンバーが昨日行われたこと、今日と明日行う予定のことを確認して、同僚や顧客からの必要な入力を求めます。これにはプロセスの透明性が必要であり、これはチームのコミュニケーションにも役立ちます。

この原則の根底にある神話は「急ぐと無駄が生まれる」というものです。しかし、リーン実装により、できるだけ早く出力を確認して分析するためには、迅速に提供することが良い方法であることが証明されました。

ほとんどの企業では、組織内の意思決定について、マネージャーが従業員に自分の仕事のやり方を指示するという伝統的な考え方があります。ワークアウト手法では、役割が逆転します。マネージャーは開発者の話を聴く方法を教えられ、どのような行動を取るべきかをより適切に説明し、改善の提案をすることができます。リーンアプローチは、アジャイル原則^[6]「やる気のある個人を中心にプロジェクトを構築し、彼らが仕事をやり遂げることを信頼する」^[7]に従っており、進歩を奨励し、エラーをキャッチし、障害を取り除きますが、細かい管理はしません。

もう一つの誤った考えは、人をリソースとみなすことです。統計データシートの観点からは、人はリソースかもしれませんが、ソフトウェア開発やあらゆる組織ビジネスでは、タスクのリストとタスクの完了中に邪魔されないという保証以上のものが必要です。人にはモチベーションと、チームが独自のコミットメントを選択できるという保証を備えた、達成可能な現実の範囲内でのより高い目的が必要です。開発者には顧客へのアクセスを与える必要があります。チームリーダーは困難な状況でサポートと支援を提供し、懐疑論がチームの精神を損なわないようにする必要があります。人を尊重し、その仕事を認めることは、チームに力を与える1つの方法です。

顧客は、システムの全体的な体験をする必要があります。これは、いわゆる知覚される完全性です。つまり、システムの宣伝、提供、展開、アクセス方法、直感的な使用方法、価格、問題解決の精度などです。

概念的整合性とは、システムの個々のコンポーネントが、柔軟性、保守性、効率性、応答性のバランスを保ちながら、全体としてうまく連携して機能することを意味します。これは、問題領域を理解し、それを順番にではなく同時に解決することで実現できます。必要な情報は、一度に大量にではなく、できれば対面でのコミュニケーションで、文書によるドキュメントではなく、小さなバッチ単位で受信されます。情報の流れは、顧客から開発者へ、そしてその逆の両方向で一定である必要があります。これにより、孤立した状態での長期にわたる開発の後に大量の情報にストレスを感じることがなくなります。

インテグラル アーキテクチャへの健全な方法の 1 つは、リファクタリングです。元のコード ベースに機能が追加されるほど、それ以上の改善を加えることが難しくなります。リファクタリングとは、コードのシンプルさ、明快さ、機能の数を最小限に抑えることです。コード内の繰り返しは、コード設計が悪い兆候であり、回避する必要があります (つまり、DRY ルールを適用します)。完全で自動化された構築プロセスには、システムの現在の状態と同じバージョン管理、同期、およびセマンティクスを持つ、完全で自動化された開発者および顧客テスト スイートが伴う必要があります。最後に、徹底的なテストで整合性を検証し、システムが顧客の期待どおりに機能することを保証します。自動テストも製造プロセスの一部と見なされるため、価値を追加しない場合は無駄と見なされます。自動テストは目標ではなく、具体的には欠陥の削減という目的を達成するための手段です。

現代のソフトウェア システムは、単に各パーツの合計ではなく、各パーツの相互作用の産物でもあります。ソフトウェアの欠陥は開発プロセス中に蓄積される傾向があります。大きなタスクを小さなタスクに分解し、開発のさまざまな段階を標準化することで、欠陥の根本原因を見つけて排除する必要があります。システムが大きくなるほど、開発に関与する組織が増え、さまざまなチームによって開発されるパーツが増えるほど、コンポーネントがスムーズに相互作用するシステムを作成するために、さまざまなベンダー間の関係を明確に定義することの重要性が高まります。開発期間が長くなると、短期的な利益の最適化よりも強力な下請け業者ネットワークの方がはるかに有益です。短期的な利益の最適化では、双方にメリットのある関係を実現できません。

リーン思考は、具体的な現実の状況で実施する前に、プロジェクトのすべてのメンバーに十分に理解されなければなりません。「大きく考え、小さく行動し、早く失敗し、素早く学ぶ」^[8] - これらのスローガンは、分野を理解することの重要性と、ソフトウェア開発プロセス全体にわたってリーン原則を実施することの適切さを要約しています。すべてのリーン原則が一緒に実施され、作業環境に関する強い「常識」が組み合わされて初めて、ソフトウェア開発の成功の基盤が築かれます。

リーン ソフトウェア開発のプラクティス、または Poppendiecks が「ツール」と呼ぶものは、アジャイル ソフトウェア開発における元の同等のプラクティスを少し言い換えたものです。このようなプラクティスの例には、次のものがあります。

• 無駄を見る
• バリューストリームマッピング
• セットベースの開発
• プルシステム
• 待ち行列理論
• モチベーション
• 測定
• テスト駆動開発

アジャイルソフトウェア開発は、アジャイル宣言で表現された価値観と原則に基づいた一連の方法と実践を包括する用語であるため、リーンソフトウェア開発はアジャイルソフトウェア開発方法であると考えられています。 ^[9]

• エクストリームプログラミング
• デブオプス
• カンバン
• カンバンボード
• リーン統合
• リーンサービス
• スクラム（開発）

• Ladas, Corey (2008 年 1 月)。Scrumban: リーン ソフトウェア開発のためのカンバン システムに関するエッセイ。Modus Cooperandi Press。ISBN 978-0-578-00214-9。
• リース、エリック（2011 年 9 月）。『リーン スタートアップ: 今日の起業家が継続的なイノベーションを活用して、劇的に成功するビジネスを創り出す方法』。クラウン ビジネス。ISBN 978-0307887894。