システム開発における「 リーン 」の考え方

システム開発における「 リーン 」の考え方について

アジャイル開発について色々調べてたときに、 Scrum の他に Lean ( リーン ) という手法もよく出てきていたので、 リーン の基本的な考え方について調べてみました。

リーン　は「７つの原則」を持っています。　リーン　が持つ「7つの原則」について、簡単にではありますが順番に説明していきたいと思います。

７つの原則

原則１：ムダをなくす

• 余分な機能のムダ
  • パレートの法則にあるように実際に使われる機能は20%程度
• 遅れのムダ
  • クリティカルパスに注意を払う。手詰まった時にすぐに対処できるように関係者が一カ所に集まっているorすぐに連絡がつくのが理想
• 引き継ぎのムダ
  • 暗黙知の引き継ぎの難しさ。形式通りのドキュメント＋１回の引き継ぎでは多くが失われてしまう
• 再学習のムダ
  • 知識、経験を保存可能にしたり、プロセスに組み込む
• 未完成のムダ
  • アジャイル、CIなどの導入により短い間隔でリリースし、未完成の作業が増えないようにする
• タスク切り替えのムダ
  • 複数タスクの兼任等をするとコンテキストスイッチで作業効率が落ちる
• 欠陥のムダ
  • テスト駆動開発、振る舞い駆動開発、CI等を導入

原則２：品質を作り込む

テスト駆動開発、CI等により欠陥をすぐに排除し欠陥数を少なく保つことで、品質が高く維持されるとともに、欠陥への対応の為のコストも減らすことができる

原則３：知識を作り出す

知識は実体験とフィードバックの繰り返しから生まれるもので、最初に完璧な知識があることを前提とし、後戻りを許されないウォーターフォール型開発はリスクが高い

• 早期リリース
• デイリービルド

などから得たフィードバックを元に

• チーム、リーダが経験・直感を蓄え、的確な判断を下す
• 機能追加に強いアーキテクチャのシステムを構築する

管理の為に工程を完全固定化するのは悪習で、常に改善を意識しながら工程を進める

原則４：決定を遅らせる

リスクの高い部分に関する決定は可能な限り遅らせる。
また、そのような箇所はできるだけ柔軟に対応できるアーキテクチャにしておく。

原則５：速く提供する

• 素早く開発することで、顧客の気変わりの前にソフトウェアを提供できる。
• 徹底したムダの削減を行い、スピードを上げる。
• 継続してスピードを上げるには品質が重要になる。
• 従来のプロセスの失敗は長期的で硬直的なプロセス管理に原因がある。
• プロセスは現時点での最善や知識ではあるが、常に改善すべきものとして考える。
• またはそのように考えられる人材を育成する。

原則６：人を尊重する

• 起業家的リーダー
  • 成功するプロダクト → 優秀なリーダー → 優秀な人材が育成される → 人は成功するプロダクトに関わりたがる → のループ
• エキスパートエンジニアの尊重
  • 外注しか利用していないなら、他社に対する優位はない
  • エキスパートを育成して初めて、競争優位を得ることができる
• 責任ベースのプランニングと制御
  • やるべきこととやり方を指示するのではなく、自律的に考えて動くことができる人材の集まる組織にする

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

部分的な利益が全体的な利益に勝る様な体制にしていると、部分最適化が発生して、全体としては損失を生む。

22の思考ツール

1. ムダを認識する
2. バリューストリーム・マップ
3. フィードバック
4. イテレーション
5. 同期
6. 集合ベース開発
7. オプション思考
8. 最終責任時点
9. 意思決定
10. プルシステム
11. 待ち行列理論
12. 遅れのコスト
13. 自発的決定
14. モチベーション
15. リーダーシップ
16. 専門知識
17. 認知統一性
18. コンセプト統一性
19. リファクタリング
20. テスティング
21. 計測
22. 契約