Transcript Slide 1

Lean
Software Development(Favorite Selection)
An Agile Toolkit
Mary Poppendieck
Tom Poppendieck
[email protected]
[email protected]
www.leantoolkit.com
リーン
ソフトウェア開発（傑作スライド集）
アジャイル・ツールキット
訳： 平鍋健児(ver 03/10/25)
Mary Poppendieck
Tom Poppendieck
[email protected]
[email protected]
www.leantoolkit.com
訳注：
この資料は，2003年６月，米国Salt Lake Cityで行われた，Agile Development Conferenceのチュートリアルの資料から，著者であるポペン
ディック夫妻自身が選んだFavorite Selectionであり，平鍋が許可を得て日本語公開するものです．
「リーン」とは，やせ細った，とか，スリムな，という意味で元来トヨタ生産方式を
体系化，一般化する際に使われた言葉．このスライドは，書籍，“Lean Software Development”
http://www.amazon.co.jp/exec/obidos/ASIN/0321150783/xpjp-22/ の概要となっている．
これが表紙
の写真
「ソフトウェア開発は工業生産技術から学ばなければならない，といいつつ，私達は学ぶべき場所を間違えていた．工業生産は，フォード式
Taylorismを２０年も前に捨てているのだよ！」というのだ．著者は，リーン生産方式を米国３Mで実践していた．そして，それをソフトウェアに持
ちこもうと考えたのだ．
表紙の写真は，実際にポペンディック夫妻が所有する，トライシクル．旅行が大好きな二人は，XP2002へ向かうSardinia（地中海の島，イタリ
ア領）の南海岸でこの写真を撮ったという．Addison-Wesleyのアジャイルシリーズ書籍は，表紙に写真を入れることになっている（例えばアリ
スタコバーンは，トラの写真．彼は「トラの動きはアジャイルだ．向きを俊敏に変える．チーターはファーストだが，アジャイルではない」と言って
いた）．カンファレンス終了後も，二人はソルトレイクからホームタウンのミネソタまで数日掛けてドライブして帰ったという．なんてタフな．．．
なお，このスライドの日本語訳は，英語をそのまま残し，奇数ページを英語，偶数ページを日本語としている．
Principles of
Lean Thinking
1. Eliminate
Waste
2. Amplify Learning
3. Decide as Late As Possible
4. Deliver as Fast as Possible
5. Empower the Team
6. Build Integrity In
7. See the Whole
リーン思考の原則
1. ムダをなくす
2. 学習過程を増幅する
3. 決定をできるだけ遅らせる
4. 出荷をできるだけ早める
5. チームをエンパワーする
6. 一貫性を作りこむ
7. 全体を見る
訳注：「リーン生産」(Lean Production)は，MITの James P. Womack/Daniel Jonesがトヨタ生産方式を研究，再体系化し
て世界に紹介した名前．1990に“The Machine That Changed the World”(『リーン生産方式が世界の自動車産業をこう
変える』)を書き，欧米にセンセーションを巻き起こす．90年代多くの米国製造業はリーン生産方式を取り入れた．その後，
同著者は，1996に“Lean Thinking”を刊行．
The Toyota
Production
System

Approach to Production




Taiichi Ohno
Build only what is needed
(1912-1990)
Stop if something goes wrong
Eliminate anything which does not add value
Philosophy of Work



Respect for Workers
Full utilization of workers’ capabilities
Entrust workers with responsibility & authority
June, 2003
Copyrignt©2003 Poppendieck.LLC
5
大野耐一
トヨタ生産方式

生産のアプローチ




必要最低限のものを作る
(1912-1990)
何かおかしな事が起きたらラインをストップ
価値を付加しないものはすべてムダとして削除
仕事の哲学



作業者に敬意を払う
作業者の能力を最大限使う
作業者に責任と権限を合わせて委譲
June, 2003
Copyrignt©2003 Poppendieck.LLC
6
Eliminate Waste
Seven Wastes of
Manufacturing*
Seven Wastes of
Software Development
Inventory
Partially Done Work
Extra Processing
Paperwork
Overproduction
Extra Features
Transportation
Task Switching
Waiting
Waiting
Motion
Motion
Defects
Defects
* Shigeo Shingo, an engineer at Toyota and a noted authority on just-in-time techniques.
June, 2003
Copyrignt©2003 Poppendieck.LLC
7
ムダどり
生産工程の７つのムダ* ソフトウェア開発の７つのムダ
在庫のムダ
半完成の成果物のムダ
加工そのもののムダ
文書作成のムダ
作りすぎのムダ
余分な機能のムダ
運搬のムダ
タスクスイッチのムダ
手待ちのムダ
手待ちのムダ
動作のムダ
動作のムダ
不良を作るムダ
欠陥（バグ）を作るムダ
*新郷重夫, トヨタのエンジニアであり，JIT技術のオーソリティ
訳注：80年代後半，アメリカで活躍したトヨタ生産方式のコンサルタント．アメリカでは，トヨタ生産方
式を米国産業に広めた人として有名．ユタ州大学にはShingo賞がある．日本におけるデミング賞
のようなもの．（ただし，この「７つのムダ」は大野耐一によって定式化されていた．）
June, 2003
Copyrignt©2003 Poppendieck.LLC
8
Development vs. Production
Development
Production
Designs the Recipe Produces the Dish
Quality is fitness for use
Quality is conformance to requirements
Variable results are good
Variable results are bad
Iteration generates value
Iteration generates waste (rework)
What does Quality mean at Disneyland?
Every guest has a wonderful time
June, 2003
Copyrignt©2003 Poppendieck.LLC
9
「開発」と「生産」
開発
生産
レシピを設計する
料理をつくる
品質 は実践利用に適していること
品質 は要求に適合していること
可変性 がある結果は善
可変性 がある結果は悪
反復 は価値を生み出す
反復 はムダを生み出す (再作業)
ディズニーランドにおいて，品質とは何か?
すべてのゲストがすばらしい時間をすごすこと
June, 2003
Copyrignt©2003 Poppendieck.LLC
10
Amplify Learning

Waterfall
Doesn’t Work.
June, 2003

Iterative Development
Works!
Copyrignt©2003 Poppendieck.LLC
11
学習過程を増幅する

ウォーターフォール
うまくいかない.
June, 2003

イテラティブな開発
うまくいく!
Copyrignt©2003 Poppendieck.LLC
12
Simple Rules for Iterations

Business Sets Priority


Development Team Determines Effort


Team chooses and commits to iteration goal
Deliver on Commitment


Art of the ‘doable’
Use a Short Time Box


High Priority First
Develop Confidence
Create Business Value

Every Iteration
June, 2003
Copyrignt©2003 Poppendieck.LLC
13
シンプルな規則（イテレーション）

ビジネスが優先度を設定する


開発チームが活動のコストを見積もる


イテレーションの目標はチームが決めてそれにコミットする
コミット通りに出荷する


イテレーションで「できること」をやる
短いタイムボックスを使う


高優先度を先に
自信を作り上げる
ビジネス価値を創造する

すべてのイテレーションで
June, 2003
Copyrignt©2003 Poppendieck.LLC
14
Simple Rules for Teams
1. Small Team
2. Clear Mission
3. Short Timeframe
4. Staffed with the necessary skills


Technology Expertise
Domain Experience
5. Enough information to determine feasibility
6. Assured of getting needed resources
7. Freedom to make decisions
8. Basic environment for good programming




June, 2003
Coding Standards
Version Control Tool
Automated Build Process
Automated Testing
Copyrignt©2003 Poppendieck.LLC
15
シンプルな規則（チーム）
1. 小さなチーム
2. 明確なミッション
3. 短い時間
4. 必要なスキルを持つスタッフ


技術的熟練
問題領域の経験
5. フィージビリティを決定するのに十分な情報
6. 必要な資源が入手できる保証
7. 意思決定を行う自由
8. よいプログラミング環境




June, 2003
コーディング標準
バージョンコントロール
自動化されたビルド
自動化されたテスト
Copyrignt©2003 Poppendieck.LLC
16
The Biggest Cost of Early Specification:
Extra Features
Features and Functions Used in a Typical System
Sometimes
16%
Rarely
19%
Often
13%
Always
7%
Never
45%
Standish Group Study Reported in 2000 Chaos Report.
June, 2003
Copyrignt©2003 Poppendieck.LLC
17
早期仕様決定に伴う最大のコスト
⇒ 余分な機能
平均的なシステムの機能のうち，実際に利用される割合
Rarely
19%
Sometimes
16%
ときどき利用する
ほとんど
利用しない
よく利用する
Often
13%
いつも
利用する
全く利用しない
Always
7%
Never
45%
Standish Group Study Reported in 2000 Chaos Report.
June, 2003
Copyrignt©2003 Poppendieck.LLC
18
Cost Escalation
Two Kinds of Change

High Stakes
Constraints

Examples:






Rule:



Language
Layering
Usability
Security
Scalability
Only a Few
At a High Level
Most Changes

June, 2003
Keep the Cost Low!
Copyrignt©2003 Poppendieck.LLC
19
コストの増加
変更には２つの種類がある
高リスク制約

例:






ルール:



言語
レイヤ分割
ユーザビリティ
セキュリティ
スケーラビリティ
変更コスト

ほとんどの変更
少数しかない
高いレベルで決定すること
ほとんどの変更

コストを低いまま保て!
時間
訳注：変更コストを平坦にすることがXPの考え方であるが，ここでは「すべての変更」が必ずしも平
坦コストではない，ことを明確化している．平坦にならないものを，「高リスク制約」と呼び，これらは
少数であること，高いレベル（ステイクホルダ）の判断が必要であることを指摘している．
June, 2003
Copyrignt©2003 Poppendieck.LLC
20
Delay Commitment

Share partially complete design information.
 Develop a sense of when to make decisions.
 Develop a sense of how to absorb changes.
 Implement only what is currently needed.
 Develop a quick response capability.
 Encapsulate Variation.
 Separate Concerns.
 Avoid Repetition.
June, 2003
Copyrignt©2003 Poppendieck.LLC
21
決定を遅延させる
 部分的に完成した設計情報を共有する．
 決定を行うタイミング感覚を開発する．
 変更を吸収する方法を開発する．
 現在必要なもののみ実装する．
 すばやい反応を行う能力を得る．
 変化を隔離する．
 関心事を分離する．
 重複をなくす．
訳注：決定を遅延させるための重要なツールとして，「Set-based Decision Making」が紹介されて
いる．１つ選択肢に決定せず，複数の設計可能性をオープンに提示する方法．
June, 2003
Copyrignt©2003 Poppendieck.LLC
22
Reduce Cycle Time
1.
Steady Rate of Arrival
Develop In Short Iterations
2.
Steady Rate of Service
Test Features Immediately
3.
Small Work Packages
Integrate Features Individually
4.
Reduce Utilization
You Don’t Load Servers to 90%
5.
Eliminate Bottlenecks
Everyone Pitches In Wherever They Are Needed
June, 2003
Copyrignt©2003 Poppendieck.LLC
5
23
サイクルタイムを短く
1.
安定した要求到着率
短いイテレーションで開発
2.
安定したサービス率
機能をすぐにテスト
3.
ワークパッケージを小さく
機能を独立して統合
4.
利用率を小さく
サーバーに90%の負荷をかけない
5.
ボトルネックの解消
必要な部分に全員が協力
June, 2003
訳注：TOC(Theory of Constraint)とも通じる．最
初の原則である，全体最適から導かれる
Copyrignt©2003 Poppendieck.LLC
24
Software Kanban

Story Cards or Iteration Feature List


Information Radiators



How do developers know what to do?
White Boards
Charts on the Wall
To Do
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Story XX
Login New User
Afal;jdsa;fuwe
Story XX
Login New User
Afal;jdsa;fuwe
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Daily Meetings



Checked Out
Story XX
Login New User
Afal;jdsa;fuwe
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Story XX
Login New User
Afal;jdsa;fuwe
Story XX
Login New User
Afal;jdsa;fuwe
Tests
Passed
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Story XX
Login New User
Afal;jdsa;fuwe
Status
Commitment
Need
June, 2003
Copyrignt©2003 Poppendieck.LLC
25
ソフトウェア・カンバン

ストーリーカード，フィーチャリスト


情報発信器（アナログなビジュアル情報）



開発者が何をすべきかを知る方法
ホワイトボード
壁に張り出したチャート
日々のミーティング



To Do
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Story XX
Login New User
Afal;jdsa;fuwe
ステータス
コミット
課題
Story XX
Login New User
Afal;jdsa;fuwe
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Checked Out
Story XX
Login New User
Afal;jdsa;fuwe
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Story XX
Login New User
Afal;jdsa;fuwe
Story XX
Login New User
Afal;jdsa;fuwe
Tests
Passed
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Story YY
Login New User
Get Password
Afal;jdsa;fuwe
Story XX
Login New User
Afal;jdsa;fuwe
訳注：「カンバン」はJIT(just-in-time)生産のキラー手段であり，後工程（顧客に近い側）からのプルで
生産をコントロールする生産指示票のこと．作りすぎのムダをなくすために，注文されていないもの
は作らない．これは，顧客がストーリーカードを書き，その優先順位をつけることに対応している．な
お，カンバンは大野耐一自身が米国のスーパーマーケットの商品補充からヒントを得ている(1956)．
June, 2003
Copyrignt©2003 Poppendieck.LLC
26
Center on the people
who add value

1982 – GM Closed the Fremont, CA Plant



1983 – Reopened as NUMMI (Toyota & GM)




Lowest Productivity
Highest Absenteeism
Same work force
White-collar jobs switch from directing to support
Small work teams trained to design, measure,
standardize and optimize their own work
1985




Productivity & quality doubled,
exceeded all other GM plants
Drug and alcohol abuse disappeared
Absenteeism virtually stopped
Time to expand the plant
June, 2003
Copyrignt©2003 Poppendieck.LLC
27
「価値を作り出す人々」を中心に据える

1982 – GMがカリフォルニア州フリーモントの工場を閉鎖



1983 –NUMMI (Toyota & GM)として再開




最低の生産性
最高の欠勤率
同じ労働力
ホワイトカラーの役割は，指示ではなく支援
訓練された小さなチームが，自身の仕事を，設計・計測・標準化・
最適化
1985




生産性と品質は２倍に．GM全工場を抜く．
ドラッグとアルコール中毒がなくなる．
欠勤がなくなる
工場の拡張
June, 2003
訳注：GMとヨトタが共同で設立したNUMMI(New
United Motor Manufacturing, Inc.)は，GMに
28
Copyrignt©2003 Poppendieck.LLC
ショックを与えた．（GMのどの工場よりも生産性が高かった）
A new product machine
William McKnight


1887 - 1978




June, 2003
If you put fences around people,
you get sheep. Give people the
room they need.
Hire good people, and leave them
alone.
Let people run with an idea.
Accept that mistakes will be made.
Encourage experimental doodling.
Give it a try – and quick!
Copyrignt©2003 Poppendieck.LLC
29
A new product machine
William McKnight




1887 - 1978


回りに柵を立てれば，人々は羊になる．
必要なスペースを与えること．
良い人材を雇い，自由にさせる．
彼らにアイディアを自由に発展させる．
間違いを容認する．
実験的な指向錯誤を推奨する．
とにかくやってみる．すぐに！
訳注：Mary Poppendieckは，3Mで働いていた期間が長い．
June, 2003
Copyrignt©2003 Poppendieck.LLC
30
Respected Leaders

Champion




Creates the vision
Recruits the team
Finds Support
‘Responsible’ for the design

Chief Engineer




Understands the Target Customer
Writes the Product Concept
Brings Customer Vision to Technical Workers
Makes Key Technical Tradeoff Decisions

Master Developer

AKA



June, 2003
Architect
Systems Engineer
Chief Programmer
Copyrignt©2003 Poppendieck.LLC
31
尊敬されたリーダー
チャンピョン





ビジョンを創造
チームメンバーを決定，召集
支援を探す
デザインに関する責任を負う
チーフエンジニア






ターゲットカスタマを理解している
製品コンセプトを書く
カスタマビジョンを技術的な作業者に伝える
キーとなる技術的トレードオフを決定する
（ソフトウェア開発）マスターデベロパー

以下の名前で呼ばれる



June, 2003
訳注：企業によって，呼び方は違うが，尊敬されたリーダーがキー
パースンである，ということ．
トヨタのチーフエンジニア制度（ＣＥ制度）は、以前は主査制度とよ
ばれていたもの（現在はＣＥの下に主査がつく）。トヨタには、伝説
のＣＥが多くいる。ＣＥは設計コンセプトの創造から車両設計、生
産、販売、サービスにいたるまですべてのプロセスに采配をふる
う。トヨタ生産方式を「プロセス」のシステムとすると、ＣＥ制度は
32
Copyrignt©2003 Poppendieck.LLC
「組織」のシステムである。これがトヨタの２大システムといえる。
アーキテクト
システムエンジニア
チーフプログラマ
Software Integrity
 Perceived
Integrity
The totality of the system achieves a
balance of function, usability, reliability and
economy that delights customers.
 Conceptual
Integrity
The system's central concepts work
together as a smooth, cohesive whole.
From: Clark & Fujimoto, Product Development Performance, 1991
They use the term ‘External Integrity’ for perceived integrity, and
‘Internal Integrity’ for conceptual integrity.
June, 2003
Copyrignt©2003 Poppendieck.LLC
33
ソフトウェアの一貫性
訳注：書籍，リーン・シンキング（日本語訳）では，
Integrityを「完全性」と訳している．一つの製品と
して統一感があるか，ということを言っている．
 認識される一貫性
システムが，顧客を満足させる機能性，使用性，
信頼性，経済性のトータルバランスを達成して
いる．
 コンセプトの一貫性
システムの中心となるコンセプト群が，エレガン
トで統一感を持った一つの全体として機能して
いる．
From: Clark & Fujimoto, Product Development Performance, 1991
‘External Integrity’を認識される一貫性，
‘Internal Integrity’をコンセプトの一貫性として使っている．
June, 2003
Copyrignt©2003 Poppendieck.LLC
34
Keys to Software Integrity
June, 2003
Copyrignt©2003 Poppendieck.LLC
35
ソフトウェア一貫性の鍵
June, 2003
Copyrignt©2003 Poppendieck.LLC
36
Refactoring
1. Simplicity

The goal of most patterns
2. Clarity



Common language
Encapsulation
Self-documenting code
3. Suitable


4. No
NO REPITITION!
Extra Features


June, 2003
Usability
Performance
Repetition

5. No
for Use
No Code Before its Time
No Code After its Time
Copyrignt©2003 Poppendieck.LLC
37
リファクタリング
1. シンプルさ

ほどんどのパターンの目標
2. 明確さ



共通言語
カプセル化
自己説明的コード
3. 利用に適している


ユーザビリティ
パフォーマンス
4. 重複が無いこと

重複がないこと!
5. ムダな機能が無いこと


June, 2003
出番前のコード
出番が無くなったコード
Copyrignt©2003 Poppendieck.LLC
38
Multiple Roles of Testing
Requirements
Feedback
Customer
System
Under
Test
Current
Business
Needs
Comparison
Developer
Scaffolding
June, 2003
Current
Design
Intent
Code
Current
System
Capability
As-Built
Copyrignt©2003 Poppendieck.LLC
39
テストの役割は複数ある
要求
フィードバック
顧客
現在のビジ
ネスニーズ
比較
開発者
開発の足場
June, 2003
テスト中の
システム
現在の設計
意図
コード
現在のシス
テム
製品コードの生き写し仕様
Copyrignt©2003 Poppendieck.LLC
40
See the Whole: Measure UP
Decomposition
Aggregation
You get what you measure
You can’t measure everything
Stuff falls between the cracks
You add more measurements
You get local sub-optimization
Span of Control
Span of Influence
Hold people accountable for
what they can control
Measure at the individual level
Fosters competition
June, 2003
You get what you measure
You can’t measure everything
Stuff falls between the cracks
You measure UP one level
You get global optimization
Hold people accountable for
what they can influence
Measure at the team level
Fosters collaboration
Copyrignt©2003 Poppendieck.LLC
41
全体を見る: 上に向かって測定
部分分割
全体統合
測定する
すべては測定できない
モレ・ヌケが出る
さらに測定項目を追加
部分最適を得る
測定する
すべては測定できない
モレ・ヌケが出る
もう１レベル上を測定する
全体最適を得る
制御範囲での責任
影響範囲での責任
コントロールできる範囲の責任を
影響できる範囲の責任を持たせ
持たせる
個人レベルの測定
競争心を育成する
る
チームレベルの測定
協力体制を育成する
訳注：全体最適を行うには，当然全体を見なければ，という話し．システム思考に
通じる．分割すれば，部分最適とコマンドコントロール型の指示になる．全体を重視
すれば，全体最適とコラボレーションが生まれる．
June, 2003
Copyrignt©2003 Poppendieck.LLC
42