リーンソフトウェア開発の極意：2022年RaleighのCTO向け実践ガイド

適切なソフトウェア開発方法論を選ぶのは困難です。当然のことながら、ソフトウェア開発は常に高コストであり、完了まで数ヶ月から数年を要するプロセスだからです。

リーンは最も信頼できるソフトウェア開発哲学の一つで、無駄の排除と迅速な製品提供の最適化に焦点を当てています。その背後にある考えは、製品に不必要なものを盛り込むのではなく、できるだけ早く価値を提供することに集中するというものです。そうすることで、計画以上の価値を提供できるようになります。

どう始めればよいか迷っているなら、ここにステップバイステップのガイドを用意しました。リーン開発の概要と7つの原則を解説し、アジャイルとの違い、リーンの役割と責任について説明します。始めましょう！

リーン開発とは？

リーン開発（LSD）は、リーンの原則をソフトウェア開発に適用したものです。リーンの原則は、日本の自動車製造大手トヨタが、製造プロセスにおける開発時間とリソースの最適化、無駄の排除のために最初に打ち出したものです。リーン開発方法論は、同じ原則で働くソフトウェア開発者たちの作業を合理化・最適化します。これはLSDがMVP（最小実行可能製品）戦略に従うことを意味し、開発プロセスを高速化し、製品のベアミニマムバージョンを市場に素早くリリースできます。構築されたMVPはユーザーフィードバックから学び、そのフィードバックに基づいてさらなるイテレーションを行うことで、不必要な事前計画プロセス段階をすべて排除します。

リーン開発の7原則

効率的にソフトウェア製品を構築するのに役立つ、7つの確立されたリーン開発原則があります。各原則には即座に適用できる実践と戦術が伴っており、顧客価値を最大化し、プロセス上の無駄を回避できます。詳しく見ていきましょう。

画像出典

原則1：無駄を排除する

ソフトウェア開発において、無駄とは顧客にビジネス価値をもたらさず、製品の品質を向上させないものすべてです。無駄排除の原則では、ソフトウェア開発から不必要な活動を体系的に特定・除去することが不可欠です。以下の活動が無駄となります：

• 不要なコードや機能： 顧客に重要な価値をもたらす機能のみの開発を優先すべきです。それ以外は議論、開発、テストの時間を要し、製品のTTM（市場投入までの時間）を遅らせます。
• 完了可能以上のタスク着手： システムに不必要な複雑さを加え、コンテキストスイッチング、引き継ぎ、ワークフローの中断を招きます。
• 開発プロセスの遅延： エンドプロダクトの提供とフィードバックループを遅らせます。
• 不明確で変化する要件： チームの焦点喪失、手戻り、フラストレーション、最終的には製品の品質問題を招きます。
• 官僚主義： 適切な組織と管理は重要ですが、必要以上の官僚主義は開発プロセス全体を遅らせます。
• コミュニケーション不足： ITチームとステークホルダー間の非効率的なコミュニケーションを含み、不必要な遅延、フラストレーション、焦点低下を招きます。
• 未完了の作業： 不完全で部分的な仕事は、顧客に価値をもたらさず、チームメンバーが仕事から学ぶこともできません。
• タスク切り替え： 計画不備によりチームメンバーをタスク間でジャンプさせると、回避可能な遅延、コミュニケーション断絶、士気低下、仕事の質低下を招きます。
• コードエラーと品質問題： 欠陥とバグは追加作業を強制します。プログラマーは現在の作業を中断しバグ修正に集中せざるを得ず、作業放棄、計画遅延、顧客満足度低下を招きます。

開発プロセスから無駄を特定・除去するには、事前に詳細な計画を立てるのを避け、代わりに短いイテレーションごとに定例会議を開催すべきです。チームメンバーは進捗報告、ボトルネックの提示、次イテレーションで実装すべき変更の提案ができます。これにより継続的なコード改善の余地が生まれます。

原則2：品質を組み込む

すべての組織が製品に品質を組み込みたいと願いますが、すべてが効率的にできているわけではありません。品質確保活動の一部が、過度なコードテストを通じて異なる種類の無駄を生んでいます。これは時間がかかり、開発コストを大幅に押し上げます。「品質を組み込む」原則は、こうした問題を発生前に解決します。後から大量のテストに頼るのではなく、最初から品質を重要な要件とし、すべてのステップでそれを追加します。リーン開発で品質をプロセス全体で確保するために用いられるツールと技術：

• リファクタリング： 定期的に実践し、コードをクリーンで構造化された状態に保つ
• ペアプログラミング： 1人ではなく2人の開発者の専門性を活用する優れた方法。すべてのタスクを2人で実施し、より効果的な解決策を得る
• テスト駆動開発（TDD）： コードを書く前にテストを書くことで品質問題を回避。開発者がコードのテスト方法を知っているため、すべてのシナリオを満たすコードを書く可能性が高まる
• インクリメンタル開発と継続的フィードバック： こうしたフィードバックは貴重で、良い品質を保証する
• 待ち状態の最小化： コード作成、テスト、バグ修正間の時間を最小化すれば、開発サイクルからコンテキストスイッチングと知識ギャップを低減できる
• テスト自動化： 面倒で手作業であり、ヒューマンエラーを起こしやすいすべてのプロセスを自動化する

原則3：知識を創造する

シンプルに見えますが、実装には規律が必要なもう一つのリーン原則です。ここでは学習を通じて知識を創造します。チームは貴重な学びをこの原則に従って文書化し、保持しなければなりません。以下のツールの組み合わせで実現します：

• コードレビュー
• ペアプログラミング
• ドキュメンテーション
• 徹底的にコメントされたコード
• 知識共有セッション
• トレーニング
• 要件管理のためのアセットベース設計などの手法

原則4：コミットメントを遅らせる

このリーン原則は、責任ある意思決定に関するものです。しかし、チームに仕事のコミットメントについて気ままで無責任であってよい自由を与えるものではありません。むしろ逆です。この原則を用いると、チームは選択肢を開いたままにし、必要な情報を継続的に収集し、必須データなしでコミットメントしないよう促されます。意味するところは：

• 事前に過度に詳細な計画を立てない
• ビジネス要件を十分理解せずにアイデアにコミットしない
• 重要な意思決定に関する必須情報を継続的に収集・分析する

原則5：速やかに提供する

綿密な長期計画がビジネス成功の鍵だと信じられがちです。しかし残念ながら、これは戦略のあらゆる側面が徹底的に検討され合意され、厳格な開発マイルストーンが確立されて初めてソフトウェア市場に参入できることを意味します。理論上は素晴らしいですが、実践ではしばしば問題を引き起こします。このアプローチでは、エンジニアが不要な機能と未修正バグのバックログを抱えた複雑なモノリシックシステムの構築に多大な時間を費やすことになります。また、常に変化する市場シナリオとクライアント要件への製品適応を阻害します。だからこそリーンのエンジニアは、必須機能を持つMVPを構築し、できるだけ早く市場に投入します。ユーザーフィードバックがエンジニアの学習と修正を助けます。これは、顧客フィードバックに基づいてコードを増分的に改善し、価値のないものをすべて捨てるのに効果的です。

原則6：人を尊重する

リーンは、チームメンバーをコントロールするのではなく、エンパワーすることを目指します。この原則は基本的な人間的礼儀を超え、プロジェクト内に信頼を生み出します。どうやって？ エンジニアに、自身の知識と判断に基づいて意思決定する自由を与えます。もちろん、十分な経験があることが前提です。このアプローチは、ソフトウェアに必要な変更を迅速に適用するのに大きく貢献し、開発者のモチベーションも維持します。開発者をコードを書くロボットではなく、有能で意欲的なプロフェッショナルとして扱うことが鍵です。

原則7：全体を最適化する

これは、開発フェーズだけでなく、ソフトウェア提供プロセス全体の改善に焦点を当てる必要があることを意味します。サブ最適化はソフトウェア開発における大きな問題です。リーン開発チームはサブ最適化により、2つの悪循環に陥りがちです。第一は、速度のためだけに粗悪なコードの製品をリリースすること。開発者にあらゆるコストをかけて提供するようプレッシャーをかけると、品質基準を満たさない可能性のあるコードをリリースします。これによりコードの複雑性が増し、バグが増え、開発者の仕事が増え、速やかに提供するプレッシャーが増す…というサイクルが止まらなくなります。第二の問題はテストで起きます。テスターが過負荷になると、開発者がコードを書いてからテスト、フィードバックまでに長い遅延が生じます。これにより開発者は欠陥のあるコードを書き続け、多くのバグと更なるテストを必要とする結果になります。「全体を最適化する」原則は、キャパシティとインパクトをより良く理解して運用することで、こうした問題を除去するようリーンチームを促します。

リーン vs アジャイル：主な違い

リーンとアジャイルは人気のソフトウェア開発方法論です。両方とも生産性と迅速な提供を促進しますが、確実な正しい適用のために、相違点を理解することを強くお勧めします。比較表で見てみましょう。

	リーン	アジャイル
基盤	製造業から始まり、他業界へ波及	ソフトウェア開発から始まり、他業界へ波及
核心哲学	無駄排除とソフトウェア開発へのミニマリスト的アプローチに焦点	コラボレーションがアジャイル方法論の核心
原則	リーン開発には7原則がある。 1. 無駄を排除 2. 品質を組み込む 3. 知識を創造 4. コミットメントを遅らせる 5. 速やかに提供 6. 人を尊重 7. 全体を最適化	アジャイル開発には12原則がある。 1. 最高優先事項は顧客満足 2. 要件変更を歓迎 3. ソフトウェアの頻繁な提供 4. ビジネス側と開発者の日々の協力 5. 意欲的な個人を中心にプロジェクト構築 6. 対面会話が最良 7. 動くソフトウェアが進捗の主要な尺度 8. 持続可能な開発ペース 9. 技術的卓越性と良い設計への継続的注力 10. 簡潔さ 11. 自己組織化チーム 12. 定期的な振り返りと適応
その他の違い	1. リーンは安定したワークフロー重視 2. リーンは開発プロセスを重視 3. リーンはコスト削減に適用可能 4. リーンは不必要なものを排除し体系的に製品構築	1. アジャイルは変更に適応的 2. アジャイルはプロセスより動く製品を重視 3. アジャイルでコスト削減は不可 4. アジャイルは継続的なフィードバックと応答で製品構築

CTOのためのリーン役割と責任ガイド

貴社でソフトウェア開発にリーンアプローチを採用するなら、主な焦点は開発プロセスの合理化と、価値をもたらさないすべての活動の除去にあるべきです。そしてこれは、リーン思考を持つチームがあって初めて実現できます。そんなチームは何で構成されるのか？ その役割と責任は？ リーンは小規模・大規模チームの両方で機能します。チームサイズはあまり重要ではなく、必要な主要なリーン役割は以下の通りです：

1. リーンマスター

リーンマスターは、同じ環境でクライアントと仕事をした経験豊富なプロフェッショナルです。そのため、プロジェクトと製品により精通しています。また、リーンの概念/手法に関する深い知識を持ち、無駄削減と効率改善への適用方法を知っています。リーンマスターはクライアントを以下で支援します：

• 各チームの目標と目的の設定
• 関連スキルを持つ人材（リソース）の選定と配置
• リーン思考でのメンタリングとトレーニング
• マスタープランと変更の管理
• チームが賢明な意思決定できるよう促進
• リーンツールと技術の知識

2. リーンプロジェクトリーダー

リーンプロジェクトリーダーは、リーンマスターとチーム間の核心的コミュニケーションチャネルとして機能し、モチベーターとしても働きます。主な責任：

• リーンプロジェクトとチームのリード
• プロジェクトの障壁除去と進捗報告
• 明確なコミュニケーションとプロジェクト活動の整理
• チーム改善への貢献

3. リーンチームメンバー

リーンチームは個々のプロセスを中心に設計されます。優秀なチームメンバーはそれぞれの仕事のエキスパートです。関連スキルを持つ開発者とテスターが含まれます。チームメンバーはソリューションの設計と実装に長けています。

Imaginovationで強力なカスタムソフトウェアを開発

無駄排除戦略を念頭に置いたユニークなソフトウェアを構築したいなら、Imaginovationのお問い合わせへ。貴社のビジネスニーズに応えるカスタマイズドソリューションの設計をお手伝いします。Imaginovationは、多様な企業に卓越したデジタル成功事例を創造する豊富な経験を持つ、受賞歴のあるWeb・モバイルアプリ開発会社です。お話ししましょう。