lean software development at adc2003 japanese subtitled

Mary Poppendieck

Tom Poppendieck

[email protected]

[email protected]

www.leantoolkit.com

LeanSoftware Development(Favorite Selection)

An Agile Toolkit

Japanese Translation by Kenji Hiranabe

Mary Poppendieck

Tom Poppendieck

[email protected]

[email protected]

www.leantoolkit.com

リーンソフトウェア開発（傑作スライド集）

アジャイル・ツールキット

訳：訳：訳：訳：平鍋健児平鍋健児平鍋健児平鍋健児(ver 03/10/25)

訳注：

この資料は，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”を刊行．

June, 2003 Copyrignt©2003 Poppendieck.LLC 5

The Toyota

Production

System

� Approach to Production� Build only what is needed

� 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

Taiichi Ohno

(1912-1990)


トヨタ生産方式

� 生産のアプローチ� 必要最低限のものを作る

� 何かおかしな事が起きたらラインをストップ

� 価値を付加しないものはすべてムダとして削除

� 仕事の哲学� 作業者に敬意を払う

� 作業者の能力を最大限使う

� 作業者に責任と権限を合わせて委譲

大野耐一

(1912-1990)


Eliminate Waste

DefectsDefects

MotionMotion

WaitingWaiting

Task SwitchingTransportation

Extra FeaturesOverproduction

PaperworkExtra Processing

Partially Done WorkInventory

Seven Wastes of

Software Development

Seven Wastes of

Manufacturing*

* Shigeo Shingo, an engineer at Toyota and a noted authority on just-in-time techniques.


ムダどり

欠陥（バグ）を作るムダ不良を作るムダ

動作のムダ動作のムダ

手待ちのムダ手待ちのムダ

タスクスイッチのムダ運搬のムダ

余分な機能のムダ作りすぎのムダ

文書作成のムダ加工そのもののムダ

半完成の成果物のムダ在庫のムダ

ソフトウェア開発の７つのムダ生産工程の７つのムダ*

*新郷重夫, トヨタのエンジニアであり，JIT技術のオーソリティ

訳注：80年代後半，アメリカで活躍したトヨタ生産方式のコンサルタント．アメリカでは，トヨタ生産方式を米国産業に広めた人として有名．ユタ州大学にはShingo賞がある．日本におけるデミング賞

のようなもの．（ただし，この「７つのムダ」は大野耐一によって定式化されていた．）


Development vs. Production

Iteration generates waste (rework)Iteration generates value

Variable results are badVariable results are good

Quality is conformance to requirementsQuality is fitness for use

Produces the DishDesigns the Recipe

ProductionDevelopment

What does Quality mean at Disneyland?

Every guest has a wonderful time


「開発」と「生産」

反復はムダを生み出す (再作業)反復は価値を生み出す

可変性がある結果は悪可変性がある結果は善

品質は要求に適合していること品質は実践利用に適していること

料理をつくるレシピを設計する

生産生産生産生産開発開発開発開発

ディズニーランドにおいて，品質とは何かディズニーランドにおいて，品質とは何かディズニーランドにおいて，品質とは何かディズニーランドにおいて，品質とは何か?

すべてのゲストがすばらしい時間をすごすこと


Amplify Learning

� Waterfall

Doesn’t Work.

� Iterative Development

Works!


学習過程を増幅する

�ウォーターフォール

うまくいかない.

� イテラティブな開発

うまくいく!


Simple Rules for Iterations

� Business Sets Priority

� High Priority First

� Development Team Determines Effort

� Art of the ‘doable’

� Use a Short Time Box

� Team chooses and commits to iteration goal

� Deliver on Commitment

� Develop Confidence

� Create Business Value

� Every Iteration


シンプルな規則（イテレーション）

� ビジネスが優先度を設定する

� 高優先度を先に

�開発チームが活動のコストを見積もる

� イテレーションで「できること」をやる

�短いタイムボックスを使う

� イテレーションの目標はチームが決めてそれにコミットする

� コミット通りに出荷する

� 自信を作り上げる

� ビジネス価値を創造する

� すべてのイテレーションで


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� Coding Standards

� Version Control Tool

� Automated Build Process

� Automated Testing

Simple Rules for Teams


1. 小さなチーム

2. 明確なミッション

3. 短い時間

4. 必要なスキルを持つスタッフ� 技術的熟練� 問題領域の経験

5. フィージビリティを決定するのに十分な情報

6. 必要な資源が入手できる保証

7. 意思決定を行う自由

8. よいプログラミング環境� コーディング標準� バージョンコントロール� 自動化されたビルド� 自動化されたテスト

シンプルな規則（チーム）


The Biggest Cost of Early Specification:

Extra Features

Features and Functions Used in a Typical System

Standish Group Study Reported in 2000 Chaos Report.

Always

7%

Often

13%

Sometimes

16%

Rarely

19%

Never

45%


早期仕様決定に伴う最大のコスト⇒ 余分な機能

平均的なシステムの機能のうち，実際に利用される割合

Standish Group Study Reported in 2000 Chaos Report.

Always

7%

Often

13%

Sometimes

16%

Rarely

19%

Never

45%

全く利用しない全く利用しない全く利用しない全く利用しない全く利用しない全く利用しない全く利用しない全く利用しない

ほとんどほとんどほとんどほとんどほとんどほとんどほとんどほとんど利用しない利用しない利用しない利用しない利用しない利用しない利用しない利用しない

いつもいつもいつもいつもいつもいつもいつもいつも利用する利用する利用する利用する利用する利用する利用する利用する

よく利用するよく利用するよく利用するよく利用するよく利用するよく利用するよく利用するよく利用する

ときどき利用するときどき利用するときどき利用するときどき利用するときどき利用するときどき利用するときどき利用するときどき利用する


Cost Escalation

Two Kinds of Change� High Stakes Constraints

� Examples:

� Language

� Layering

� Usability

� Security

� Scalability

� Rule:

� Only a Few

� At a High Level

� Most Changes� Keep the Cost Low!


コストの増加変更には２つの種類がある

� 高リスク制約� 例:

� 言語

� レイヤ分割

� ユーザビリティ

� セキュリティ

� スケーラビリティ

� ルール:

� 少数しかない

� 高いレベルで決定すること

� ほとんどの変更� コストを低いまま保て!

変更コスト

変更コスト

変更コスト

変更コスト

ほとんどの変更ほとんどの変更ほとんどの変更ほとんどの変更

高リスク制約

高リスク制約

高リスク制約

高リスク制約

時間訳注：変更コストを平坦にすることがXPの考え方であるが，ここでは「すべての変更」が必ずしも

平坦コストではない，ことを明確化している．平坦にならないものを，「高リスク制約」と呼び，これらは少数であること，高いレベル（ステイクホルダ）の判断が必要であることを指摘している．


� 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.

Delay Commitment


�部分的に完成した設計情報を共有する．

�決定を行うタイミング感覚を開発する．

�変更を吸収する方法を開発する．

�現在必要なもののみ実装する．

�すばやい反応を行う能力を得る．

�変化を隔離する．

�関心事を分離する．

�重複をなくす．

決定を遅延させる

訳注：決定を遅延させるための重要なツールとして，「Set-based Decision Making」が紹介されて

いる．１つ選択肢に決定せず，複数の設計可能性をオープンに提示する方法．


Reduce Cycle Time

1. Steady Rate of ArrivalDevelop In Short Iterations

2. Steady Rate of ServiceTest Features Immediately

3. Small Work PackagesIntegrate Features Individually

4. Reduce UtilizationYou Don’t Load Servers to 90%

5. Eliminate BottlenecksEveryone Pitches In Wherever They Are Needed

5


サイクルタイムを短く

1. 安定した要求到着率短いイテレーションで開発

2. 安定したサービス率機能をすぐにテスト

3. ワークパッケージを小さく機能を独立して統合

4. 利用率を小さくサーバーに90%の負荷をかけない

5. ボトルネックの解消必要な部分に全員が協力訳注：TOC(Theory of Constraint)とも通じる．最

初の原則である，全体最適から導かれる


Software Kanban

� Story Cards or Iteration Feature List

� How do developers know what to do?

� Information Radiators

� White Boards

� Charts on the Wall

� Daily Meetings

� Status

� Commitment

� Need

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 XX

Login New User

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

Story YY

Login New User

Get Password

Afal;jdsa;fuwe

Story YY

Login New User

Get Password

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

Tests PassedChecked Out 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 XX

Login New User

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

Story YY

Login New User

Get Password

Afal;jdsa;fuwe

Story YY

Login New User

Get Password

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

Tests PassedChecked Out To Do

訳注：「カンバン」はJIT(just-in-time)生産のキラー手段であり，後工程（顧客に近い側）からのプル

で生産をコントロールする生産指示票のこと．作りすぎのムダをなくすために，注文されていないものは作らない．これは，顧客がストーリーカードを書き，その優先順位をつけることに対応している．なお，カンバンは大野耐一自身が米国のスーパーマーケットの商品補充からヒントを得ている(1956)．


Center on the people

who add value

� 1982 – GM Closed the Fremont, CA Plant� Lowest Productivity

� Highest Absenteeism

� 1983 – Reopened as NUMMI (Toyota & GM)� 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


「価値を作り出す人々」を中心に据える� 1982 – GMがカリフォルニア州フリーモントの工場を閉鎖

� 最低の生産性

� 最高の欠勤率

� 1983 –NUMMI (Toyota & GM)として再開� 同じ労働力

� ホワイトカラーの役割は，指示ではなく支援

� 訓練された小さなチームが，自身の仕事を，設計・計測・標準化・最適化

� 1985 � 生産性と品質は２倍に．GM全工場を抜く．

� ドラッグとアルコール中毒がなくなる．

� 欠勤がなくなる

� 工場の拡張

訳注：GMとヨトタが共同で設立したNUMMI(New United Motor Manufacturing, Inc.)は，GMにショックを与えた．（GMのどの工場よりも生産性が高かった）


� 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!

William McKnight

1887 - 1978

A new product machine


� 回りに柵を立てれば，人々は羊になる．必要なスペースを与えること．

� 良い人材を雇い，自由にさせる．

� 彼らにアイディアを自由に発展させる．

� 間違いを容認する．

� 実験的な指向錯誤を推奨する．

� とにかくやってみる．すぐに！

William McKnight

1887 - 1978

A new product machine

訳注：Mary Poppendieckは，3Mで働いていた期間が長い．


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

� Architect

� Systems Engineer

� Chief Programmer


尊敬されたリーダー� チャンピョン

� ビジョンを創造� チームメンバーを決定，召集� 支援を探す� デザインに関する責任を負う

� チーフエンジニア� ターゲットカスタマを理解している� 製品コンセプトを書く� カスタマビジョンを技術的な作業者に伝える� キーとなる技術的トレードオフを決定する

� （ソフトウェア開発）マスターデベロパー� 以下の名前で呼ばれる

� アーキテクト� システムエンジニア� チーフプログラマ

訳注：企業によって，呼び方は違うが，尊敬されたリーダーがキーパースンである，ということ．トヨタのチーフエンジニア制度（ＣＥ制度）は、以前は主査制度とよばれていたもの（現在はＣＥの下に主査がつく）。トヨタには、伝説のＣＥが多くいる。ＣＥは設計コンセプトの創造から車両設計、生産、販売、サービスにいたるまですべてのプロセスに采配をふるう。トヨタ生産方式を「プロセス」のシステムとすると、ＣＥ制度は「組織」のシステムである。これがトヨタの２大システムといえる。


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.


ソフトウェアの一貫性

�認識される一貫性システムが，顧客を満足させる機能性，使用性，

信頼性，経済性のトータルバランスを達成している．

�コンセプトの一貫性

システムの中心となるコンセプト群が，エレガン

トで統一感を持った一つの全体として機能している．

From: Clark & Fujimoto, Product Development Performance, 1991

‘External Integrity’を認識される一貫性，‘Internal Integrity’をコンセプトの一貫性として使っている．

訳注：書籍，リーン・シンキング（日本語訳）では，Integrityを「完全性」と訳している．一つの製品と

して統一感があるか，ということを言っている．


Keys to Software Integrity


ソフトウェア一貫性の鍵


Refactoring

1.Simplicity� The goal of most patterns

2.Clarity� Common language

� Encapsulation

� Self-documenting code

3.Suitable for Use� Usability

� Performance

4.No Repetition� NO REPITITION!

5.No Extra Features� No Code Before its Time

� No Code After its Time

Without Refacto

ring

With Refactoring


リファクタリング1.シンプルさ

� ほどんどのパターンの目標

2.明確さ� 共通言語� カプセル化� 自己説明的コード

3.利用に適している� ユーザビリティ� パフォーマンス

4.重複が無いこと� 重複がないこと!

5.ムダな機能が無いこと� 出番前のコード� 出番が無くなったコード

リファクタリングなし




リファクタリングありリファクタリングありリファクタリングありリファクタリングあり


Multiple Roles of Testing

Requirements Feedback

Scaffolding As-Built

CodeComparison

Current

System

Capability

System

Under

Test

Current

Design

Intent

Developer

Current

Business

Needs

Customer


テストの役割は複数ある

要求フィードバック

開発の足場製品コードの生き写し仕様

コード比較

現在のシステム

テスト中のテスト中のテスト中のテスト中のシステムシステムシステムシステム

現在の設計意図

開発者

現在のビジネスニーズ

顧客


See the Whole: Measure UP

AggregationYou get what you measure

You can’t measure everything

Stuff falls between the cracks

You measure UP one level

You get global optimization

DecompositionYou 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 InfluenceHold people accountable for

what they can influence

Measure at the team level

Fosters collaboration

Span of ControlHold people accountable for

what they can control

Measure at the individual level

Fosters competition


全体を見る: 上に向かって測定

部分分割測定する

すべては測定できない

モレ・ヌケが出る

さらに測定項目を追加

部分最適を得る

影響範囲での責任影響影響影響影響できる範囲の責任を持たせる

チームレベルの測定

協力体制を育成する

制御範囲での責任コントロールコントロールコントロールコントロールできる範囲の責任を持たせる

個人レベルの測定

競争心を育成する

訳注：全体最適を行うには，当然全体を見なければ，という話し．システム思考に通じる．分割すれば，部分最適とコマンドコントロール型の指示になる．全体を重視すれば，全体最適とコラボレーションが生まれる．

全体統合測定する

すべては測定できない

モレ・ヌケが出る

もう１レベル上を測定する

全体最適を得る