| 原則 1 全体を最適化する |
| |
システム全体を見て行動する。
| ・ |
目的を明確にする
偉大な企業は利益のためでなく、重要な目的を達成し続けるために利益をあげる |
| ・ |
顧客価値創造の流れ全体を理解する
コンセプト作成から利益を得るまでの価値創造の流れ全体を見て最適化する |
| ・ |
長期的な視点を持つ
複雑な事象を全体として解明し、足元の状況に左右されることなく、長期的に見通す |
|
| 原則 2 ムダをなくす |
| |
顧客にとって価値を生まない活動・事象 (ムダ) を徹底的に排除する。ソフトウェア開発におけるムダの例は以下のとおりである。
| ・ |
未完成の作業 |
| ・ |
使われないコードや余分な機能 |
| ・ |
余分なプロセス |
| ・ |
作業の引き継ぎ |
| ・ |
作業の切り替え |
| ・ |
開発の遅れ |
| ・ |
欠陥 |
|
| 原則 3 チームに権限委譲する |
| |
個々人を細かく管理するのでなく、チームに権限委譲し、創造性のある個々人が尊重しあいチームとして共鳴し合って自律的に働くことで、個人成果の総和以上の成果をあげることができる。チームは自己組織的チームである。
|
| 原則 4 学習を強化する |
| |
失敗を恐れず、失敗から学ぶ。
| ・ |
顧客に動く製品を早く提示し、顧客からのフィードバックから学ぶ |
| ・ |
失敗を隠さず迅速に正し、個人的過誤に求めず、常に構造的な問題を探して対策を打つ |
|
| 原則 5 早く提供する |
| |
早期に連続的に価値のある製品を提供することを通じて顧客を満足させることである。そのためには、短い時間で顧客に動く製品を見せることで、顧客からのフィードバックを得ることにより、顧客の期待した価値のある製品を早く提供することができる。
|
| 原則 6 品質を作り込む |
| |
製品の最終テスト段階で、欠陥を見つけるべきではなく、可能な限り開発プロセス内で早期に欠陥を見つけ、修正することが重要である。最終テスト段階で欠陥が見つかるということは開発プロセスに欠陥があるということである。リーンソフトウェア開発では、製品をリリースするまでに開発プロセス中下記のような品質保証を実施し高い品質を確保している。
| ・ |
顧客の開発参加 |
| ・ |
テスト駆動開発 |
| ・ |
リファクタリング |
| ・ |
継続的結合 (毎日結合、ソフト間の不具合チェック) |
| ・ |
テスト自動化 |
| ・ |
頻繁な反復デモとフィードバック |
|
| 原則 7 決定を遅らせる |
| |
決定すべき時まで早く決定しても、決定するまでの間のその後の状況変化により決定を変えなければならないことが起こる。ぎりぎりまで決定を遅らせれば、状況変化を踏まえた良い決定ができる。「必要なものを必要な時に必要な量だけ作る」ジャストインタイムの考えを反映する。
これらのリーン原則は、ソフトウェア開発のみだけでなくあらゆる仕事の進め方に適用でき、ビジネス価値向上に大変有効であることが実証されている。 |
(AJ000557)
