2022年のリーンソフトウェア開発：ローリーCTOへのステップバイステップガイド

適切なソフトウェア開発方法論を選択するのは難しい場合があります。

そして、なぜですか？結局のところ、ソフトウェア開発は常に費用のかかるプロセスであり、完了するまでに数か月から数年かかることがよくあります。

リーンは、最も信頼性の高いソフトウェア開発哲学の1つであり、無駄を排除し、製品の迅速な納品を最適化することに重点を置いています。

その背後にある考え方は、製品に不要なものを構築するのではなく、できるだけ早く価値を提供することに集中し続けることです。このようにして、計画したものよりも多くの価値を提供します。

開始方法がわからない場合は、こちらのステップバイステップガイドをご覧ください。

リーンソフトウェア開発の概要と、すべての基本的なリーン原則について説明します。この哲学がアジャイルとどのように異なるかについて説明し、リーンの役割と責任について説明します。

さぁ、始めよう！

リーンソフトウェア開発とは何ですか？

リーンソフトウェア開発またはLSDは、リーン原則を適用してソフトウェアを開発します。

リーン生産方式は、日本の自動車製造大手であるトヨタによって、製造プロセスの開発時間とリソースを最適化し、無駄をなくすために最初に策定されました。

リーンソフトウェア開発方法論は、同じ原則に取り組んでいるソフトウェア開発者を合理化および最適化します。

これは、LSDがMVP –最小実行可能製品戦略に従うことを意味します。これにより、開発プロセスをスピードアップし、製品の最低限のバージョンを市場に迅速にリリースできます。

構築されたMVPは、ユーザーフィードバックから学習し、そのフィードバックに基づいてさらに反復を実行するのに役立ちます。これにより、事前に計画された不要なプロセスステージがすべて排除されます。

リーンソフトウェア開発の7つの原則は何ですか？

リーンソフトウェア開発には、ソフトウェア製品を効率的に構築するのに役立つ7つの確立された原則があります。

すべての原則には、すぐに適用し、顧客価値を最大化し、プロセスの無駄を省くことができる一連の実践と戦術が付属しています。

これらの原則をさらに深く掘り下げましょう。

画像ソース

原則1：無駄をなくす

ソフトウェア開発において、無駄とは、顧客にビジネス価値をもたらし、製品の品質を向上させることに失敗するものです。

無駄の排除の原則に従って、ソフトウェア開発から不要なアクティビティを特定し、体系的に削除することが不可欠です。次のソフトウェア開発活動は無駄になります–

不要なコードまたは機能 ：お客様に大きな価値をもたらす機能のみを開発することを優先するようにしてください。それ以外の場合は、話し合い、開発、テストに時間がかかり、製品のTTM（市場投入までの時間）が遅れます。
完了できるよりも多くのタスクを開始する ：これにより、システムに不要な複雑さが加わり、コンテキストの切り替え、ハンドオフ、ワークフローの中断が発生します。
ソフトウェア開発プロセスの遅延 ：遅延により、最終製品の配信とフィードバックのループが遅くなります。
要件が不明確で変化している ：これにより、チームの集中力の欠如、やり直し、欲求不満、そして最終的には製品の品質の問題が発生します。
官僚主義 ：優れた組織と管理が不可欠ですが、必要以上の官僚主義を許可すると、ソフトウェア開発プロセス全体が遅れます。
コミュニケーション不足 ：これには、ITチームと利害関係者の間の効果のないコミュニケーションが含まれます。その結果、不必要な遅延、欲求不満、焦点の低下が発生します。
部分的に行われた作業 ：不完全で部分的に完了した仕事は、顧客に価値を付加することも、チームメンバーが仕事から学ぶことを可能にすることもありません。
タスク切り替え ：計画が不十分なためにソフトウェアチームのメンバーをタスクからタスクにジャンプさせると、多くの場合、回避可能な遅延、コミュニケーションの途絶、チームの士気の低下、作業の質の低下につながります。
コードエラーと品質の問題 ：欠陥やバグは余分な作業につながります。彼らはプログラマーに彼らが現在取り組んでいることをやめさせ、バグ修正に集中するように強制します。その結果、作業が放棄され、計画が遅れ、顧客満足度が低下します。

ソフトウェア開発プロセスの無駄を特定して取り除くには、事前に綿密な計画を立てないようにする必要があります。代わりに、短い反復ごとに定期的な会議を開くことができます。

チームメンバーは、進捗状況を報告し、ボトルネックを強調し、後続の反復中に実装する変更を提案できます。これにより、コードを継続的に改善する余地が生まれます。

原則2：品質を構築する

すべての組織が製品に品質を組み込みたいと考えていますが、誰もが効率的にできるわけではありません。私たちの品質保証活動のいくつかは、過度のコードテストを通じてさまざまな種類の無駄に貢献しています。これには時間がかかり、開発コストも大幅に高くなります。

リーンソフトウェア開発の「品質の構築」の原則は、そのような問題が発生する前にすべてに対処します。後で大規模なテストだけに頼るのではなく、最初から重要な要件として品質から始め、すべてのステップで品質を追加します。

リーン開発では、プロセス全体の品質を確保するために、次のツールと手法が使用されます。

リファクタリング： 定期的に練習し、コードをクリーンで構造化してください。
ペアプログラミング： これは、1人ではなく2人の開発者の専門知識を使用する優れた方法です。その結果、すべてのタスクは2人の開発者によって実行されるため、より効果的なソリューションを得ることができます。
テスト駆動開発： コードを書く前にテストを書くことで、品質の問題を回避できます。開発者はコードがどのようにテストされるかを知っているため、すべてのシナリオを満たすコードを作成する可能性が高くなります。
段階的な開発と絶え間ないフィードバック： このようなフィードバックは貴重であり、優れた品質を保証します。
待機状態を最小限に抑える： コードの記述、テスト、バグ修正の間の時間を最小限に抑えると、開発サイクルからのコンテキスト切り替えと知識のギャップを確実に減らすことができます。
テストの自動化： これには、面倒で手動で人為的エラーが発生しやすいすべてのプロセスを自動化することが含まれます。

原則3：知識を生み出す

これは、単純に見えますが、実装するには規律が必要なもう1つの無駄のない原則です。ここでは、学習を通じて知識を生み出すことができます。

チームは、この原則に従って貴重な学習を文書化し、保持する必要があります。これは、次のツールの組み合わせを適用することによって行われます。

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

原則4：コミットメントを延期する

この無駄のない原則は、責任ある意思決定に関するものです。ただし、それはチームに彼らの仕事のコミットメントにおいて不安定で無責任である自由を与えません。

代わりに、それは反対を促進します。この原則を使用して、チームは、オプションを開いたままにし、必要な情報を継続的に収集し、重要なデータなしでコミットメントを行わないようにすることで、責任を持って決定することが奨励されます。

意味は次のとおりです：

事前に過度に詳細な計画はありません。
ビジネス要件を完全に理解しない限り、アイデアにコミットすることはできません。
重要な決定に関する重要な情報の一貫した収集と分析。

原則5：迅速に提供する

多くの場合、綿密で長期的な計画がビジネスの成功の鍵であると考えられています。ただし、残念ながら、これは、戦略のあらゆる側面が徹底的に検討され、合意された場合にのみ、ソフトウェア市場に参入できる厳格な開発マイルストーンが確立されることも意味します。

これは理論的には素晴らしいように聞こえますが、実際には問題が発生することがよくあります。このアプローチでは、エンジニアは、不要な機能と未修正のバグのバックログを備えた複雑なモノリシックシステムの構築に多くの時間を費やします。

さらに、絶えず変化する市場シナリオやクライアントの要件に製品を適応させることを制限します。

そのため、無駄のないエンジニアは、不可欠な機能を備えたMVP（最小限の実行可能な製品）を構築し、MVP製品をできるだけ早く市場に投入します。ユーザーのフィードバックは、エンジニアがそれに応じて学習し、修正するのに役立ちます。

これは、顧客のフィードバックに基づいてコードを段階的に拡張し、価値のない他のすべてのものを捨てるのに適しています。

原則6：人の尊重

リーンは、チームメンバーを管理するのではなく、チームメンバーに権限を与えることを目的としています。

この原則は、基本的な人間の礼儀を確立することを超えています。プロジェクト内で信頼を生み出します。

どのように？

エンジニアには、知識と判断に基づいて決定を下す自由が与えられます。もちろん、彼らはそうするのに十分な経験を積んでいます。

このようなアプローチは、ソフトウェアに必要な変更を迅速に適用することに大きく貢献し、開発者の意欲を維持します。

ここで重要なのは、開発者をロボットがコードを書くのではなく、有能で意欲的な専門家として扱うことです。

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

これは、開発フェーズだけでなく、ソフトウェアを提供するプロセス全体の改善に集中する必要があることを意味します。

部分最適化は、ソフトウェア開発における大きな問題です。最適化が不十分なためにリーン開発チームが陥る傾向がある2つの悪循環があります。

1つ目は、速度を上げるために、コーディングが不十分な製品をリリースすることです。開発者にすべてのコストで提供するように圧力をかけると、開発者は品質基準に対応する場合と対応しない場合があるコードをリリースします。

これにより、コードが複雑になり、バグが増える可能性があります。これは、開発者の作業が増え、迅速に提供するようにプレッシャーがかかることを意味します。そのため、サイクルはノンストップで継続されます。

2番目の問題はテストにあります。テスターが過負荷になると、開発者がコードを記述してからテストし、フィードバックを提供するまでに長い遅延が発生します。これは、開発者が欠陥のあるコードを書き続けることを意味し、多くのバグが発生し、より多くのテストが必要になります。

原則全体を最適化することで、リーンチームは、キャパシティと影響をよりよく理解するように運用することで、このような問題を取り除くことができます。

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

リーンとアジャイルは、人気のあるソフトウェア開発方法論です。どちらの方法も生産性と短納期を促進しますが、正しいアプリケーションが保証されていることの相違点を理解することを強くお勧めします。

見てみましょう。

	リーン	アジャイル
財団	それは製造業でその旅を始め、その後他のセクターが続きました。	それはソフトウェア開発部門で生まれ、その後他の部門がそれに続きました。
コア哲学	この方法論は、無駄の排除とソフトウェア開発に向けた最小限のアプローチに焦点を当てています。	コラボレーションはアジャイル方法論の中核です。
原則	リーンソフトウェア開発には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.アジャイルは、一貫した応答とフィードバックを通じて製品構築に取り組みます。