【りーんそふとうぇあかいはつ】
リーンソフトウェア開発 とは?
最終更新:
💡 価値につながる開発の流れを、全体で改善する
リーンの考え方をソフトウェア開発に応用し、利用者の価値と開発全体の流れを改善する考え方。7原則と、単なる作業削減との違いを解説します。
📌 このページのポイント
- リーンの考え方をソフトウェア開発へ応用
- ムダだけでなく、学習・品質・チームも重視
- 判断に必要な情報を集め、選択肢を保つ
- 一工程の効率だけでなく、価値を届ける全体を見る
リーンソフトウェア開発は、仕事を減らすこと?
利用者へ価値を届ける流れを改善する考え方だ。不要な機能や待ち時間などを見直すが、人数や必要な作業をただ削ればよいわけではない。
ムダには、何がある?
途中のままの作業、不要な機能、切り替えや待ち時間、不具合による手戻りなどがある。何が不要かは、利用者や仕事の目的に照らして判断する。
7つの原則は?
2003年の著書では、ムダの排除、学習の増幅、できるだけ遅い意思決定、速い提供、チームへの権限付与、整合性の作り込み、全体を見ることを挙げている。日本語の訳し方は資料によって異なる。
決定は、遅らせた方がよい?
不確かな段階で決めて選択肢を失わないための考え方だ。判断に必要な情報を集め、いつまで選択肢を保てるかも確認する。締め切りを忘れて先送りすることとは違うよ。
テストや資料も、削ってよい?
品質を確かめるテストや、保守に必要な情報には価値がある。何のために使うかを確認しよう。削った結果、手戻りや引継ぎの待ちが増えるなら、全体の改善にならない。
アジャイルとは、対立するの?
対立する考え方と決める必要はない。著書もアジャイルの実践を考える道具として示している。開発の一部分の速さだけでなく、利用者に届くまでの流れと学びを見よう。
もっと詳しく知りたい人へ
7原則は、トヨタの7つのムダと同じ一覧?
同じ一覧ではありません。2003年の著書には、7原則とは別に、ソフトウェア開発のムダの例が載っています。学習やチーム、品質、全体を見ることまで含む原則を、ムダの種類だけに置き換えないことが大切です。
最初は、どこから改善する?
例えば一つの変更が依頼から利用者に届くまでを追い、作業と待ち時間、手戻りの理由を整理します。工程単体の処理件数だけで判断せず、利用者への価値や品質に結び付いたかを確かめます。
まとめ:ざっくりこれだけ覚えればOK!
「リーンソフトウェア開発」って出てきたら「価値を届ける流れを見て、待ち時間や手戻りを改善する開発の考え方」と思えばだいたいOK!
📖 おまけ:英語の意味
「Lean Software Development」 = リーンの考え方を応用したソフトウェア開発
💬 Mary PoppendieckとTom Poppendieckの2003年の著書『Lean Software Development: An Agile Toolkit』が、7原則と実践を考える道具をまとめています。