リーンソフトウェア開発とは？7つの原則と進め方5ステップを解説
こんにちは。Wakka Inc.メディア編集部です。
製造業でムダを省くために確立した「リーン生産方式」をご存知の方も多いのではないでしょうか。
近年、このリーン生産方式をIT業界へ転用したリーンソフトウェア開発が注目されています。
リーンソフトウェア開発とは、プロジェクトにおけるムダを省き、より効率的にプロダクトを開発するための手法です。
ただ、リーンソフトウェア開発にはフレームワークが存在しないため、どのような手法なのかをイメージしづらい方も多いでしょう。
本記事では、リーンソフトウェア開発の概要と基本原則を解説。
後半では、プロジェクトの進め方や注意点を紹介しているので、ぜひ最後までご覧ください。
●開発リソースの不足にお悩みなら●
＞＞＞Wakka.Inc独自の海外子会社設立サービスがおすすめ！
無料でサービス資料をダウンロードできますのでぜひご覧ください。
【基礎知識】リーンソフトウェア開発とは
本章では、リーンソフトウェア開発の概要と、よく似た開発手法であるアジャイル開発との違いについて解説します。
リーンソフトウェア開発はリーン生産方式の応用
リーンソフトウェア開発（Lean Software Development）とは、ムダをなくすことに重点を置いた開発手法です。
製造業で普及した、必要なものを必要なだけ生産するという「リーン生産方式」の考え方が採り入れられています。
リーン生産方式は、トヨタ自動車が1980年代にジャストインタイム、カンバン、自働化といった独自の生産方式を研究する中で生まれました。
トヨタ自動車が生み出した生産方式を、アメリカのマサチューセッツ工科大学のジェームズ・ウォマック博士が研究し、一般向けに体系化されたのがリーン生産方式です。
リーン生産方式がIT業界に浸透し、リーンソフトウェア開発と呼ばれるようになりました。
リーンソフトウェア開発とアジャイル開発の違い
アジャイルとは、素早いという意味です。
アジャイル開発ではその名前が示すように、小さな機能単位に区切って開発工程を2～3週間ほどのサイクルで繰り返し、短期間で製品の完成を目指します。
プロジェクトが変化するのを前提としているため、仕様変更に強く、顧客にとって価値の高い製品を提供することに重点を置いた開発手法です。
リーンソフトウェア開発とアジャイル開発は、ともに個別の原則を定義しています。
例えば、リーンソフトウェア開発の場合は
- ムダをなくす
- 速く提供する
などの原則がありますが、抽象的な項目がほとんどで、具体的な内容は定義されていません。
これに対してアジャイル開発には、以下のように具体的な定義が存在します。
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します
- 動くソフトウェアを、2～3週間から2～3か月というできるだけ短い時間間隔でリリースします
参照：アジャイルソフトウェア開発宣言｜Manifesto for Agile Software Development
目指すところは同じですが、原則を比較してみるとリーンソフトウェア開発の原則は抽象的で、アジャイル開発の方がより具体的な印象です。
別の言い方をすれば、リーンソフトウェア開発の概念を実現するために、より実践的な行動まで定義したものがアジャイル開発と言えるでしょう。
リーンソフトウェア開発に取り組むメリット
リーンソフトウェア開発を採り入れるとムダを省いた生産が可能になるため、生産効率や品質の面でいくつかのメリットがあります。
本章では、リーンソフトウェア開発に取り組むメリットについて解説します。
ムダがなくなり生産性が向上する
リーンソフトウェア開発にはムダをなくすという原則があります。
そのため、取り組むことで生産性の向上が期待できるでしょう。
生産性が向上すると時間あたりの生産量が増えるため、開発期間も短縮できます。
すなわち、開発期間が短縮されることでコストを下げられ、短期間で製品をリリースできるようになるのです。
顧客がビジネスに必要とするシステムや機能を、短期間でスピーディーに提供できることは、顧客にとって高い価値があります。
そのため、生産性の向上によって短期間でのリリースにつながれば、顧客の満足度も向上するでしょう。
ソフトウェアの品質が向上する
ムダをなくす取り組みには、製品の欠陥を早期に発見して修正することも含まれます。
なぜなら、製品の欠陥は発見が遅くなるほど修正の手戻りが大きくなり、時間やコストのムダも大きくなるからです。
また、リーンソフトウェア開発の原則には品質を作りこむという項目があります。
これは、製品の欠陥を早期に発見できる開発プロセスを確立することを意味し、そのためには開発プロセスの中に製品の品質を保証するための取り組みを組み込むことが必要です。
さらに、品質を作りこむとは製品の欠陥をなくすだけではなく、使い勝手の良い製品、ヒューマンエラーが起きにくい製品など、顧客にとってより価値の高い設計にすることも含まれています。
このように、ムダをなくし、品質を作りこむ取り組みを実施することで、ソフトウェアの品質向上が期待できるでしょう。
新規ビジネスに取り組みやすくなる
従来の開発手法であるウォーターフォール型の開発では、最初に要件定義工程で開発するシステムの要件を決定します。
システムの要件が決定したら次に設計工程を実施し、設計工程が終わったら製造工程というように、前工程が終了しないと次工程に進めない開発手法です。
その性質上、ウォーターフォール型の開発はソフトウェアをリリースするまでにかかる期間が長くなる傾向があります。
また、開発するシステムの要件が決まらないと開発が進まないため、新規ビジネスの取り組みに伴うソフトウェアの開発に向いているとは言えません。
なぜなら、新規ビジネスに取り組む際は、ビジネスモデルを確立するための試行錯誤や軌道修正が付きものだからです。
つまり、ビジネスの試行錯誤や軌道修正に合わせて、ソフトウェアの要件も柔軟に変更できることが望まれます。
リーンソフトウェア開発の場合は、ソフトウェアの調整や計測、学習をスピーディーに繰り返し、顧客のニーズに合った製品に仕上げていきます。
そのため、新規ビジネスの試行錯誤や軌道修正にも素早く対応でき、ソフトウェア開発がボトルネックになってビジネスを進められないといった事態にはなりにくいでしょう。
この点において、リーンソフトウェア開発は新規ビジネスに取り組みやすい開発手法と言えます。
リーンソフトウェア開発を成功に導く7つの原則
リーンソフトウェア開発には7つの原則が定義されています。
本章では、7つの原則の具体的な内容についてそれぞれ簡単に見ていきましょう。
なお、7つの原則についてはメアリー・ポッペンディーク、トム・ポッペンディークの共著である『リーンソフトウェア開発～アジャイル開発を実践する22の方法』で詳しく解説されています。
興味がある方はぜひ参考にしてください。
原則1：ムダをなくす
リーンソフトウェア開発の7つの原則は、この原則が核になっていると言えるでしょう。
なぜなら、この開発方式の原点とされているリーン生産方式は、徹底してムダをなくすものだからです。
ソフトウェア開発において、開発するソフトウェア製品の価値つながらないムダは徹底してなくさなければいけません。
なくすべきムダには次のようなものがあります。
- 完了していない作業
- 使われないコードや機能
- 余分な作業
- 作業の引継ぎ
- 作業の切り替え
- 開発の遅れ
- 製品の欠陥
原則2：品質を作り込む
製品の欠陥は発見が遅れるほど手戻りが大きく、修正にかかるコストも増大します。
設計時点で発見した欠陥の修正コストと比較すると、最終テスト段階で発見した欠陥の修正コストは20倍にもなると言われているので、決して軽視はできません。
そのため、欠陥をいかに開発の早い段階で発見するかが非常に重要です。
開発プロセスの中で品質を保証するための取り組みを実施し、欠陥を早期に発見することで手戻りのムダをなくして高品質の製品を提供できるようにしましょう。
また、使い勝手の良い設計をする、ヒューマンエラーを起こしにくい仕組みを設計するなど、顧客にとって製品の価値や信頼性を高める取り組みも品質の作りこみには含まれます。
例えば、次のような取り組みが品質の作りこみには役立つでしょう。
- 顧客の開発参加
- テスト駆動開発（製造よりもテストを優先的に設計する開発手法）
- テスト自動化
- リファクタリング（ソフトウェアの振る舞いは変えず、内部構造を合理化する技術）
- 顧客への頻繁なデモンストレーションとフィードバックの獲得
原則3：知識を作り出す
ソフトウェア開発では、開発に必要な知識やノウハウを身につけ、チームで共有していくことが大切です。
なぜなら、知識やノウハウをチームメンバーが身につけることで、チーム全体として的確な判断ができ、高品質な製品作りに役立つからです。
そのためには、製品のデモを繰り返し顧客に見せ、できるだけ多くのフィードバックを得るのがポイントになります。
知識を共有・蓄積することでチームの学習が強化され、顧客にとって価値の高い製品を開発できる可能性が高くなるでしょう。
原則4：決定を遅らせる
リーンソフトウェア開発では、短期間でスピーディーにソフトウェア製品のリリースを繰り返します。
そのため、製品のコンセプトや方向性を左右するような重要な決定は、できるだけ遅らせるという考え方が基本です。
まずは、重要な判断が必要ない部分から着手し、判断材料となる情報がより多く集まってから重要な決定を下すようにします。
そうすることで、より精度の高い適切な決定ができるようになるでしょう。
原則5：速く提供する
リーンソフトウェア開発では、製品の開発期間を短縮し、できるだけ速く顧客に提供できるようにします。
そのためには、一度の開発規模を小さくすることとムダをなくすことが必要でしょう。
速く提供する目的は、規模の小さな開発をスピーディーに繰り返し、そのたびに顧客のフィードバックを得ることで、より顧客のニーズに合った製品へと調整していくことです。
原則6：人を尊重する
チームによる開発を成功させるためには、人を尊重することが大切です。
つまり、チームメンバーを細かく管理するのではなく、メンバーの意見を尊重し、権限を委譲して自律的に動いてもらいます。
そうすることで、メンバーが互いに尊重しあい、創造性を発揮し、的確な判断ができるチームになることが期待できるでしょう。
そのためにはチームリーダーが、知識やノウハウの共有を通してチームの学習を強化し、メンバーを育成することが重要です。
原則7：全体を最適化する
最終的に顧客へ提供するソフトウェア製品は、顧客が価値を生み出すために利用し、課題の解決やビジネスの成果につながらなければいけません。
そのためには、顧客のビジネスや業務全体を理解して全体最適を図る必要があります。
ソフトウェアを完成させて終わりではなく、本当に顧客のビジネスにとって価値のあるソフトウェア製品の提供を目指しましょう。
リーンソフトウェア開発の進め方 － 5ステップ －
本章では、リーンソフトウェア開発の流れを見ていきましょう。
リーンソフトウェア開発は一般的に次の5つのステップで進めていきます。
- 仮説
- 構築
- 計測
- 学習
- 意思決定
それぞれ詳しく解説します。
1.仮説
最初に顧客ニーズの仮説を立てます。
顧客から明確なニーズを聞き出せている場合は、それに従っても良いのですが注意が必要です。
なぜなら、顧客が認識しているニーズが誤っていたり、潜在ニーズが隠れていたりする可能性があるからです。
したがって、この時点ではあくまで仮説としておきましょう。
2.構築
仮説を立てたら次に、MVPと呼ばれる試作品を構築します。
MVPとは、仮説を検証するために必要最低限の機能だけに絞った試作品のことです。
MVPはなるべく低コスト、短期間で構築します。
もし、仮説が間違っていた場合のリスクを最小限に抑えるためです。
MVPは簡易的なWebサイトやアプリ、パワーポイントのスライドなど、実際の操作感がイメージできるものであれば問題ありません。
3.計測
MVPが完成したら顧客に使用してもらうか、デモンストレーションを見せてフィードバックをもらいます。
パッケージ製品やSaaSサービスを開発する場合は、製品のターゲット層にあたる顧客を選定すると良いでしょう。
顧客から得たフィードバックを分析してニーズを計測します。
対象の顧客は少人数で良いので、なるべく複数の人を選定しましょう。
人数が多いほど信頼性の高い計測ができるからです。
4.学習
学習のステップでは、計測で集めたデータをもとに検証します。
仮説どおりの計測結果を得られた部分については継続し、仮説とは違った部分については改善や方向転換を検討しましょう。
MVPのマイナス要素について改善策を検討する際は、直接的な原因だけを見てアプローチするのではなく、原因をできるだけ深く掘り下げて根本原因に対してアプローチするのがコツです。
5.意思決定
意思決定のステップでは、学習で検討した結果をもとに製品をどのように改善し、ブラッシュアップするかを意思決定します。
製品をより顧客ニーズに近づけていくため、違っていた部分の仮説を修正して構築～学習のステップを繰り返すことが必要です。
開発の5ステップを繰り返して顧客ニーズが十分に満たされた場合は、これまでの検証結果をもとに本開発に移行する意思決定も必要になるでしょう。
ソフトウェア開発の専門家を活用する
以上、リーンソフトウェア開発の進め方5ステップを解説しました。
リーンソフトウェア開発を採り入れてみたいけれど、スキルの習得や体制の構築に専念するだけの人材を自社で確保できないという企業も多いのが現実ではないでしょうか。
また、導入を検討しているけれど、何からどのように進めていけばよいかわからないケースもあるでしょう。
そのような場合は、ソフトウェア開発会社など専門家の豊富な知識やスキルを活用するのがおすすめです。
やりたいことやアイデアがまだ明確になっていなくても、まずは気軽に相談してみましょう。
リーンソフトウェア開発の注意点
本章では、リーンソフトウェア開発を採り入れる際の注意点について解説します。
小規模な開発で適用する
リーンソフトウェア開発では、開発ステップを何度も繰り返しながらMVPをブラッシュアップする進め方をします。
つまり、大規模な開発では軌道修正や方向転換による影響が大きくなるため、向いているとは言えません。
もし、大規模な開発でリーンソフトウェア開発を適用する場合は、一部の機能に限定して実施するなど、MVPの規模が大きくならないようにしてリスクを減らしておくのがおすすめです。
当初の目的を見失わないように注意
リーンソフトウェア開発のステップを何度も繰り返し、改善や軌道修正をしているうちに、当初の目的やゴールが変わっていってしまうことがあります。
軌道修正によって仮説を見直すのであれば問題ないのですが、顧客ニーズを満たすという当初の目的から外れているのに気づかず、ステップを繰り返すことが目的になってしまっては本末転倒です。
当初の目的を常に意識しながら、改善や軌道修正を実施していきましょう。
リーンソフトウェア開発でビジネス環境の変化にスピーディーに対応する
リーンソフトウェア開発では、徹底的にムダを排除する取り組みを軸として、あらゆる取り組みがソフトウェア製品のスピーディーな提供につながっています。
「ビジネス環境の激しい変化に、ソフトウェア開発がついていけていない」と、危機感をお持ちであればぜひ取り組んでみてはいかがでしょうか。
まずは徹底的にムダを排除する取り組みをしてみるだけでも、効果が目に見えてくるはずです。
ぜひとも本記事を参考に、リーンソフトウェア開発に取り組んでみてください。
【あわせて読みたい】おすすめ関連資料
●すぐに使えるRFPテンプレート｜システム開発用
＞システム開発のRFPについて、情報を埋めるだけで簡単に作成ができるテンプレートです。
●すぐに使えるRFPテンプレート｜サイトリニューアル用
＞サイトリニューアルの際に、テンプレートの情報を埋めるだけで簡単にRFPが作成できます。
●DX進め方ガイドブック
＞DXプロジェクトを検討している担当者の方に向けて、失敗しない社内体制の構築から開発リソース確保までを網羅して解説しています。
