More Related Content
Similar to リーン原則とソフトウェア開発 (20)
リーン原則とソフトウェア開発
- 1. リーン原則
と
ソフトウェア開発
発表バージョン
2011/05/28 You&I
わんくま同盟 東京勉強会 #59
- 2. 自己紹介
• H/N You&I(読み:ユーアンドアイ)
• 出身 生まれも育ちも名古屋市
• 年齢 30代前半
• 本職 商学部出身の職業プログラマ
• 言語 C++,C#,VisualBasic 6.0,日本語COBOL
• 日記 http://d.hatena.ne.jp/youandi/
• 所属 名古屋アジャイル勉強会
プログラミング生放送 名古屋支部
わんくま同盟
わんくま同盟 東京勉強会 #59
- 3. ナゼ、イッタイ。
• リーン原則はトヨタ生産方式から生まれた
– トヨタ自動車って愛知県内にあるし、名古屋勉強
会っぽいよね・・・?
• ウチの会社の親会社がリーンのカイゼン活動
というのをやっていてウチの社内ではかなり
不評
– どうも数値ありきの活動内容になっているらしい。
→そもそもリーン(lean)って何だろう?
わんくま同盟 東京勉強会 #59
- 4. Agenda
1. リーン原則の背景
2. リーン原則とは
3. リーン原則とリーンソフトウェア開発
4. まとめ
わんくま同盟 東京勉強会 #59
- 5. 1.リーン原則の背景
1. リーン原則の背景
2. リーン原則とは
3. リーン原則とリーンソフトウェア開発
4. まとめ
わんくま同盟 東京勉強会 #59
- 6. 1.リーン原則の背景(1/10)
• ウィリアム・エドワーズ・デミング博士(1/5)
– アメリカの統計学者
– 1950年7月に日本科学技術連盟(日科技連:
JUSE)から招待されて講演。
– 1951年6月に日科技連にデミング賞が創設される。
– PDCAサイクル(Plan-Do-Check-Actサイクル)で
有名。PDCAサイクルはShewhart Cycle、
Deming Wheelとも呼ばれる。
– デミング博士は後にPDCAサイクルをPDSAサイ
クル(Plan-Do-Study-Actサイクル)と称している。
わんくま同盟 東京勉強会 #59
- 7. 1.リーン原則の背景(2/10)
• ウィリアム・エドワーズ・デミング博士(2/5)
– デミング博士が信望していた4つの要点
1. システムの正しい理解
システム内の部分間の相乗効果が、全体の成功の鍵となる
2. 変動についての知識
低品質・低生産性の大半の原因はシステムに内在し、個々の作
業者にはどうしようもない
3. 知識の理論
仮設を立て、実験し、学習し、学習を組み入れる(PDSA)
4. 心理学
数字が全てではない。人に関係することは、スキル・誇り、専門
知識、自信、そして協力による影響が大きい
わんくま同盟 東京勉強会 #59
- 8. 1.リーン原則の背景(3/10)
• ウィリアム・エドワーズ・デミング博士(3/5)
– デミングの14項目(1/3)
1. 長期に渡って必要とされる企業となる。
2. 遅れやミス、欠陥品、質の悪いサービスは受け入れ
られない。
3. 欠陥を発見する為に検査するのではなく、製品を作
る過程で品質を作り込む。
4. サプライヤの選定は、誠実さと信頼に基づき長期的
な関係を確立し、費用を抑える。
5. 生産やサービス提供のシステムを改善する為、絶え
ず努力を続ける。改善は一度で終える作業ではない。
わんくま同盟 東京勉強会 #59
- 9. 1.リーン原則の背景(4/10)
• ウィリアム・エドワーズ・デミング博士(4/5)
– デミングの14項目(2/3)
6. 訓練を制度化する。作業者だけではなく管理者も訓
練を受ける必要がある。
7. リーダーシップを育てる。管理者の仕事は人々がより
良く仕事できるように手助けし、作業者の邪魔になる
事象を取り除く事である。
8. 恐怖感を持たせない。良い仕事をする為には身の安
全を感じていなくてはならない。
9. 部署間の垣根を壊す。部署の枠を超えたチーム作り。
個人評価等のチームワークを乱す事をしない。
わんくま同盟 東京勉強会 #59
- 10. 1.リーン原則の背景(5/10)
• ウィリアム・エドワーズ・デミング博士(5/5)
– デミングの14項目(3/3)
10. スローガンや説教、到達目標の使用をやめる。欠陥
や低生産性の原因は人ではなくシステムである。
11. 作業者への数量的なノルマや管理者層の数量的目
標をなくす。開発チームへの身勝手な締め切り設定
をやめる。
12. 技術者の誇りを奪う制度をなくす。
13. 全員に対して教育と自己改善を奨励する。
14. 変化を遂げる為の行動を取る。実際の行動によって
変化が導かれる。
わんくま同盟 東京勉強会 #59
- 16. 1.リーン原則の背景(10/10)
• 戦後の日本の生産現場には、デミング博士に
よる統計的な品質管理方法の影響があった。
• そのデミング博士の考えを基本として、トヨタ
自動車では顧客中心としたムダを排除する独
自の生産方式を作り出し、会社として業績を
伸ばした。
• 1980年代に欧米の研究者達が日本の生産方
式についての研究を行い、それらを体系化し
てリーン生産方式として一般化した。
わんくま同盟 東京勉強会 #59
- 17. 2.リーン原則とは
1. リーン原則の背景
2. リーン原則とは
3. リーン原則とリーンソフトウェア開発
4. まとめ
わんくま同盟 東京勉強会 #59
- 18. 2.リーン原則とは(1/5)
• TPSから他の分野へ
– トヨタ製品開発システム
1. 起業家的リーダーによるシステム設計
チーフエンジニア主導による開発
2. エキスパートエンジニアの尊重
ある分野を極めるまでは他の部署へは異動しない
3. 責任ベースのプランニングと制御
決められた期日に成果物は提出するが、その過程の進捗状況は
トラッキングされることはない
4. 集合ベースのコンカレントエンジニアリング
複数の設計を探索していき、徐々に選択肢を狭めていく
わんくま同盟 東京勉強会 #59
- 19. 2.リーン原則とは(2/5)
• リーン生産方式から他の分野へ
– リーンソリューション
– リーン消費
– リーン供給
– リーン企業
– リーンサプライチェーン
– リーン開発(リーンソフトウェア開発)
• リーンとは基本的に顧客を中心に物事を考
える。これはどの分野においても変わらない。
わんくま同盟 東京勉強会 #59
- 20. 2.リーン原則とは(3/5)
• 余談ですが、ソフトウェア開発では「製造工
程」とか使われますが・・・
– そもそも工場での作業工程とソフトウェア開発の
工程って違いますね。
– 建築に例えられる事があります。
• プロジェクト・ブック (建築文化シナジー)
• ISBN : 978-4395241019
– 料理に例えられる事もあります。
わんくま同盟 東京勉強会 #59
- 21. 2.リーン原則とは(4/5)
• 「原則」とは考え方の指針であり、「プラクティ
ス」はその「原則」を実行する為に何をするか、
である。
• 今日の話でのリーン原則
– リーンの研究者である、メアリー&トム・ポッペン
ディーク夫妻が定義する、ソフトウェア開発におけ
る7つのリーン原則を主体とします。
– でもポッペンディークさんの著書によって、原則も
尐しずつ変更されていたりします。
わんくま同盟 東京勉強会 #59
- 24. 3.リーン原則とリーンソフトウェア開発(1/12)
• リーン生産方式とリーンソフトウェア開発の類
似点(1/2)
リーン生産方式 リーンソフトウェア開発
頻繁な設定変更 頻繁な製品リリース
短い製品スループット時間 短い開発時間
製造工程間の未完成在庫の削減 開発工程間の情報在庫の削減
製造工程間で部品を頻繁に交換 開発工程間で仮決定の情報を尐しずつ
移動させる
在庫削減にはリソースのゆとりや工程 開発時間削減にはリソースのゆとりや
間でさらなる情報フローが必要 工程間での情報フローが必要
数量、製品構成、製品設計の変更への 製品設計、スケジュール、原価目標の変
順応性 更への順応性
わんくま同盟 東京勉強会 #59
- 25. 3.リーン原則とリーンソフトウェア開発(2/12)
• リーン生産方式とリーンソフトウェア開発の類
似点(2/2)
リーン生産方式 リーンソフトウェア開発
製造作業者への幅広いタスク割り当て エンジニアへの幅広いタスク割り当てに
により高生産性を得る よって高生産性を得る
素早い問題解決と継続的なプロセス改 頻繁で反復的な革新と継続的な製品・
善の重視 プロセスの改善の重視
品質、納期、製造生産性の同時改善 品質、開発時間、開発生産性の同時改
善
わんくま同盟 東京勉強会 #59
- 27. 3.リーン原則とリーンソフトウェア開発(4/12)
1. ムダを排除する(1/2)
– ウィンストン・ロイス博士が1970年に発表した論
文「MANAGING THE DEVELOPMENT OF
LARGE SOFTWARE SYSTEMS」
分析やコーディングほどに最終的な製品に直接寄与するものは
無いと書かれている。逆を言えばそれ以外はムダである。
1. プログラム設計を最初に行う。
2. 設計の文書化。
3. 2度行う。
4. テストを計画、管理、監視する。
5. 顧客を巻き込む
わんくま同盟 東京勉強会 #59
- 28. 3.リーン原則とリーンソフトウェア開発(5/12)
1. ムダを排除する(2/2)
– ムダの排除はリーン原則の根本にある。
– 具体的にどのようなムダがあるかは今回省略。
製造のムダ ソフトウェア開発のムダ
在庫のムダ 未完成の作業のムダ
加工のムダ 余分なプロセスのムダ
作り過ぎのムダ 余分な機能のムダ
運搬のムダ タスク切り替えのムダ
手待ちのムダ 待ちのムダ
動作のムダ 移動のムダ
不良をつくるムダ 欠陥のムダ
わんくま同盟 東京勉強会 #59
- 29. 3.リーン原則とリーンソフトウェア開発(6/12)
2. 品質を作り込む(1/2)
– 品証部門は、後からテストによって品質を保証す
るのでは無く、最初からコードに品質を作り込ま
せるプロセスに重点を置くべきである。
– 「最初から正しく」実装をする為にポカヨケの仕組
みをソフトウェア開発に導入し、テスト駆動開発
や継続的インテグレーションを導入する。
– コードベースをシンプルに保つ。その為に新たな
機能を考慮して、設計をリファクタリングしていく。
– 早期にテストし、速く失敗する。
わんくま同盟 東京勉強会 #59
- 30. 3.リーン原則とリーンソフトウェア開発(7/12)
2. 品質を作り込む(2/2)
– 5S(ご-えす)
1. 整理(Sort)
ソースコード上の使われていないコードを削除する。
2. 整頓(Systematize)
余計な依存関係はないか?
3. 清掃(Shine)
エラーはワーニングは解消する。
4. 清潔(Standardize)
リファクタリングや仕様変更が入っても綺麗なままで保つ。
5. 躾(Sustain)
これらの規律を手順化し、守り続けていく。
わんくま同盟 東京勉強会 #59
- 31. 3.リーン原則とリーンソフトウェア開発(8/12)
3. 知識を作り出す
– ソフトウェア開発は知識創造のプロセスである。
– タイムボックス(イテレーション・スプリント)での開
発により定期的にフィードバックを得る。
– 定期的なリファクタリングにより素早い変更が可
能となる。
– 継続的インテグレーションにより素早いフィード
バックを得る。
– プロセスは守る為にあるのではなく、改善され続
けていくものである。
わんくま同盟 東京勉強会 #59
- 32. 3.リーン原則とリーンソフトウェア開発(9/12)
4. 決定を出来るだけ遅らせる
– 従来、開発が進むにつれて変更のコストが増大
すると考えられていた。
– 後で撤回・変更が難しい決定を行う際には出来
るだけその判断を遅らせるべきである。
– 難しい問題に対して複数の選択肢を用意するオ
プション思考を行う。
– 問題をシンプルにする為に、関心を分離・カプセ
ル化したり、不要な機能は入れない。
わんくま同盟 東京勉強会 #59
- 33. 3.リーン原則とリーンソフトウェア開発(10/12)
5. 速く提供する
– カンバン方式により、「プル(Pull)」形式によるス
ケジュール管理を行う。予め作業に担当を割り
振らない。手の空いた人に次の作業を割り振る。
– 速く提供する為には現在のやり方を分析して、ど
の工程にどれだけ時間が掛かっているか分析す
る必要がある。仕様変更が決まってから顧客の
気が変わる前にその変更が提供出来るか?
– 余計な機能は入れないようにし、作業の見積もり
をし易くする為にタイムボックスで作業を区切っ
て、提供する。
わんくま同盟 東京勉強会 #59
- 34. 3.リーン原則とリーンソフトウェア開発(11/12)
6. 人を尊重する
– 「唯一最高のやり方」などは存在しない。常にプ
ロセスは守るものでは無く、改善し続けていくも
のである。
– 先に紹介したトヨタ製品開発プロセスにおいても
人を重視したものになっている。
– チームを信頼し、チームに権限を与える。この自
律的な作業により、プロセスがシンプルになり速
く提供出来る。
– 技術を磨くのでは無く、解決手順を身につける。
わんくま同盟 東京勉強会 #59
- 35. 3.リーン原則とリーンソフトウェア開発(12/12)
7. 全体を最適化する
– 部分最適化を行わない。プロセス全体を見渡し
てムダを見つける。ある一部のみを最適化する
と逆に全体の最適化を阻害される事がある。
– 最適化する為には計測や指標が必要となるが、
分析すべきは、サイクルタイム、財務指標、顧客
満足度である。最適化にあたり指標を細分化し
がちであるが、それは逆で1つ上の段階で分析
すべきである。
わんくま同盟 東京勉強会 #59
- 36. 4.まとめ
1. リーン原則の背景
2. リーン原則とは
3. リーン原則とリーンソフトウェア開発
4. まとめ
わんくま同盟 東京勉強会 #59
- 37. 4.まとめ(1/4)
• リーン手法導入の注意点
1. 他人のやり方を模倣しない。「原則」を理解し自
分に合った「プラクティス」を実施する。
2. ベストなやり方は存在しない。常にカイゼンある
のみ。
3. 部分最適化をしない。常に全体を見渡す事。
4. 最適化する為にはシンプルに保つ。
わんくま同盟 東京勉強会 #59
- 38. 4.まとめ(2/4)
• 今回の話の中で「アジャイル」という言葉は出
てきませんでしたよね?
– 但し、幾つかのアジャイルプラクティスは出てきま
した。(タイムボックス、TDD、CI、素早いリリース)
– 7つのリーン原則を踏まえた上で、現時点での「よ
り良い」やり方として、アジャイルプラクティスが選
ばれたと捉えるべきです。
– アジャイルにも「アジャイルソフトウェア開発宣言」
及び「アジャイルソフトウェアの12原則」という「原
則」があり、様々な「プラクティス」が存在します。
わんくま同盟 東京勉強会 #59
- 39. 4.まとめ(3/4)
• 今回リーンに興味を持った事の1つに現場の
カイゼンがあります。
– いち開発者として、ボトムアップで現場のカイゼン
が出来るのか?が実は知りたかった事。
– 「開発者にはeXtream Programmingの本を、プロ
ジェクトマネージャーにはScrumの本を、そして経
営者にはリーンの本を渡せ」という一文が・・・
– PDCAサイクルにせよ、リーン開発にせよ、プロセ
スの見直しをするのは、管理者であるように思い
ました。
わんくま同盟 東京勉強会 #59
- 40. 4.まとめ(4/4)
• 参考書籍
– リーンソフトウェア開発
• ISBN: 978-4822281939
– リーン開発の本質
• ISBN: 978-4822283506
– リーンソフトウェア開発と組織改革
• ISBN: 978-4048687416
わんくま同盟 東京勉強会 #59