Lean Software Development at ADC2003 Japanese subtitled
Upcoming SlideShare
Loading in...5
×
 

Lean Software Development at ADC2003 Japanese subtitled

on

  • 11,376 views

Japanese subtitled version of Lean Software Development by Mary and Tom Poppendieck

Japanese subtitled version of Lean Software Development by Mary and Tom Poppendieck

Statistics

Views

Total Views
11,376
Views on SlideShare
2,669
Embed Views
8,707

Actions

Likes
9
Downloads
51
Comments
0

7 Embeds 8,707

http://blogs.itmedia.co.jp 8671
http://d.hatena.ne.jp 22
https://twitter.com 6
http://webcache.googleusercontent.com 4
http://cache.yahoofs.jp 2
http://clipboard.com 1
http://hrt.happy.nu 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Lean Software Development at ADC2003 Japanese subtitled Lean Software Development at ADC2003 Japanese subtitled Presentation Transcript

    • LeanSoftware Development(Favorite Selection) An Agile Toolkit Mary Poppendieck Tom Poppendieck mary@poppendieck.com tom@poppendieck.com www.leantoolkit.com Japanese Translation by Kenji Hiranabe
    • リーンソフトウェア開発(傑作スライド集) Mary Poppendieck アジャイル・ツールキット Tom Poppendieck mary@poppendieck.com 訳: 平鍋健児(ver 03/10/25) 平鍋健児 tom@poppendieck.com www.leantoolkit.com訳注:この資料は,2003年6月,米国Salt Lake Cityで行われた,Agile Development Conferenceのチュートリアルの資料から,著者であるポペンディック夫妻自身が選んだFavorite Selectionであり,平鍋が許可を得て日本語公開するものです.「リーン」とは,やせ細った,とか,スリムな,という意味で元来トヨタ生産方式を これが表紙体系化,一般化する際に使われた言葉.このスライドは,書籍,“Lean Software Development” の写真 http://www.amazon.co.jp/exec/obidos/ASIN/0321150783/xpjp-22/ の概要となっている.「ソフトウェア開発は工業生産技術から学ばなければならない,といいつつ,私達は学ぶべき場所を間違えていた.工業生産は,フォード式Taylorismを20年も前に捨てているのだよ!」というのだ.著者は,リーン生産方式を米国3Mで実践していた.そして,それをソフトウェアに持ちこもうと考えたのだ.表紙の写真は,実際にポペンディック夫妻が所有する,トライシクル.旅行が大好きな二人は,XP2002へ向かうSardinia(地中海の島,イタリア領)の南海岸でこの写真を撮ったという.Addison-Wesleyのアジャイルシリーズ書籍は,表紙に写真を入れることになっている(例えばアリスタコバーンは,トラの写真.彼は「トラの動きはアジャイルだ.向きを俊敏に変える.チーターはファーストだが,アジャイルではない」と言っていた).カンファレンス終了後も,二人はソルトレイクからホームタウンのミネソタまで数日掛けてドライブして帰ったという.なんてタフな...なお,このスライドの日本語訳は,英語をそのまま残し,奇数ページを英語,偶数ページを日本語としている.
    • Principles ofLean 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”を刊行.
    • Taiichi OhnoThe ToyotaProductionSystem Approach to Production 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 & authorityJune, 2003 Copyrignt©2003 Poppendieck.LLC 5
    • 大野耐一トヨタ生産方式 生産のアプローチ 必要最低限のものを作る (1912-1990) 何かおかしな事が起きたらラインをストップ 価値を付加しないものはすべてムダとして削除 仕事の哲学 作業者に敬意を払う 作業者の能力を最大限使う 作業者に責任と権限を合わせて委譲June, 2003 Copyrignt©2003 Poppendieck.LLC 6
    • Eliminate Waste Seven Wastes of Seven Wastes of Manufacturing* 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
    • ムダどり生産工程の7つのムダ* ソフトウェア開発の7つのムダ在庫のムダ 半完成の成果物のムダ加工そのもののムダ 文書作成のムダ作りすぎのムダ 余分な機能のムダ運搬のムダ タスクスイッチのムダ手待ちのムダ 手待ちのムダ動作のムダ 動作のムダ不良を作るムダ 欠陥(バグ)を作るムダ*新郷重夫, トヨタのエンジニアであり,JIT技術のオーソリティ 訳注:80年代後半,アメリカで活躍したトヨタ生産方式のコンサルタント.アメリカでは,トヨタ生産方 式を米国産業に広めた人として有名.ユタ州大学にはShingo賞がある.日本におけるデミング賞 のようなもの.(ただし,この「7つのムダ」は大野耐一によって定式化されていた.) June, 2003 Copyrignt©2003 Poppendieck.LLC 8
    • Development vs. Production Development ProductionDesigns the Recipe Produces the DishQuality is fitness for use Quality is conformance to requirementsVariable results are good Variable results are badIteration generates value Iteration generates waste (rework) What does Quality mean at Disneyland? Every guest has a wonderful timeJune, 2003 Copyrignt©2003 Poppendieck.LLC 9
    • 「開発」と「生産」 開発 生産レシピを設計する 料理をつくる品質 は実践利用に適していること 品質 は要求に適合していること可変性 がある結果は善 可変性 がある結果は悪反復 は価値を生み出す 反復 はムダを生み出す (再作業) ディズニーランドにおいて,品質とは何か? ディズニーランドにおいて,品質とは何か すべてのゲストがすばらしい時間をすごすことJune, 2003 Copyrignt©2003 Poppendieck.LLC 10
    • Amplify Learning Waterfall Iterative Development Doesn’t Work. Works!June, 2003 Copyrignt©2003 Poppendieck.LLC 11
    • 学習過程を増幅する ウォーターフォール イテラティブな開発 うまくいかない. うまくいく!June, 2003 Copyrignt©2003 Poppendieck.LLC 12
    • 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 IterationJune, 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 Coding Standards Version Control Tool Automated Build Process Automated TestingJune, 2003 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 Rarely 19% 16%Often13% Always 7% Never 45% Standish Group Study Reported in 2000 Chaos Report.June, 2003 Copyrignt©2003 Poppendieck.LLC 17
    • 早期仕様決定に伴う最大のコスト⇒ 余分な機能 平均的なシステムの機能のうち,実際に利用される割合 Sometimes Rarely 19% 16% ときどき利用する ほとんど 利用しない よく利用するOften いつも 全く利用しない13% 利用する Always 7% Never 45% Standish Group Study Reported in 2000 Chaos Report.June, 2003 Copyrignt©2003 Poppendieck.LLC 18
    • Cost EscalationTwo 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!June, 2003 Copyrignt©2003 Poppendieck.LLC 19
    • コストの増加変更には2つの種類がある 高リスク制約 例: 言語 レイヤ分割 変更コスト ユーザビリティ 約 制 セキュリティ ク ス スケーラビリティ リ 高 ルール: 少数しかない ほとんどの変更 高いレベルで決定すること ほとんどの変更 コストを低いまま保て! 時間 訳注:変更コストを平坦にすることが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」が紹介されて いる.1つ選択肢に決定せず,複数の設計可能性をオープンに提示する方法.June, 2003 Copyrignt©2003 Poppendieck.LLC 22
    • Reduce Cycle Time1. Steady Rate of Arrival Develop In Short Iterations2. Steady Rate of Service Test Features Immediately3. Small Work Packages Integrate Features Individually4. Reduce Utilization You Don’t Load Servers to 90%5. Eliminate Bottlenecks Everyone Pitches In Wherever They Are Needed 5June, 2003 Copyrignt©2003 Poppendieck.LLC 23
    • サイクルタイムを短く1. 安定した要求到着率 短いイテレーションで開発2. 安定したサービス率 機能をすぐにテスト3. ワークパッケージを小さく 機能を独立して統合4. 利用率を小さく サーバーに90%の負荷をかけない5. ボトルネックの解消 必要な部分に全員が協力 訳注:TOC(Theory of Constraint)とも通じる.最 初の原則である,全体最適から導かれるJune, 2003 Copyrignt©2003 Poppendieck.LLC 24
    • Software Kanban Story Cards or Iteration Feature List How do developers know what to do? Information Radiators White Boards To Do Story YY Checked Out Tests Passed Login New User Story XX Story YY Story XX Login New User Charts on the Wall Get Password Login New User Login New User Get Password Afal;jdsa;fuwe Afal;jdsa;fuwe Story XX Afal;jdsa;fuwe Afal;jdsa;fuwe Login New User Story YY Afal;jdsa;fuwe Story XX Login New User Login New User Story YY Get Password Story YY Afal;jdsa;fuwe Login New User Afal;jdsa;fuwe Login New User Get Password Get Password Daily Meetings Afal;jdsa;fuwe Story XX Login New User Afal;jdsa;fuwe Afal;jdsa;fuwe Story YY Login New User Get Password Story XX Login New User Afal;jdsa;fuwe Afal;jdsa;fuwe Status Commitment NeedJune, 2003 Copyrignt©2003 Poppendieck.LLC 25
    • ソフトウェア・カンバン ストーリーカード,フィーチャリスト 開発者が何をすべきかを知る方法 情報発信器(アナログなビジュアル情報) ホワイトボード To Do Story YY Checked Out Tests Passed Login New User Story XX Story YY 壁に張り出したチャート Story XX Login New User Get Password Login New User Login New User Get Password Afal;jdsa;fuwe Afal;jdsa;fuwe Story XX Afal;jdsa;fuwe Afal;jdsa;fuwe Login New User Story YY Afal;jdsa;fuwe Story XX Login New User Login New User Story YY Get Password Story YY Afal;jdsa;fuwe Login New User Afal;jdsa;fuwe Login New User Get Password 日々のミーティング Story XX Get Password Afal;jdsa;fuwe Login New User Afal;jdsa;fuwe Afal;jdsa;fuwe Story YY Login New User Story XX Get Password Login New User Afal;jdsa;fuwe Afal;jdsa;fuwe ステータス コミット 課題 訳注:「カンバン」はJIT(just-in-time)生産のキラー手段であり,後工程(顧客に近い側)からのプル で生産をコントロールする生産指示票のこと.作りすぎのムダをなくすために,注文されていないも のは作らない.これは,顧客がストーリーカードを書き,その優先順位をつけることに対応している. なお,カンバンは大野耐一自身が米国のスーパーマーケットの商品補充からヒントを得ている (1956).June, 2003 Copyrignt©2003 Poppendieck.LLC 26
    • Center on the peoplewho 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 plantJune, 2003 Copyrignt©2003 Poppendieck.LLC 27
    • 「価値を作り出す人々」を中心に据える 1982 – GMがカリフォルニア州フリーモントの工場を閉鎖 最低の生産性 最高の欠勤率 1983 –NUMMI (Toyota & GM)として再開 同じ労働力 ホワイトカラーの役割は,指示ではなく支援 訓練された小さなチームが,自身の仕事を,設計・計測・標準化・ 最適化 1985 生産性と品質は2倍に.GM全工場を抜く. ドラッグとアルコール中毒がなくなる. 欠勤がなくなる 工場の拡張June, 2003 訳注:GMとヨトタが共同で設立したNUMMI(New United Motor Manufacturing, Inc.)は,GMに Copyrignt©2003 Poppendieck.LLC 28 ショックを与えた.(GMのどの工場よりも生産性が高かった)
    • A new product machineWilliam McKnight If you put fences around people, you get sheep. Give people the room they need. Hire good people, and leave them alone. 1887 - 1978 Let people run with an idea. Accept that mistakes will be made. Encourage experimental doodling. Give it a try – and quick!June, 2003 Copyrignt©2003 Poppendieck.LLC 29
    • A new product machineWilliam 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 Architect Systems Engineer Chief ProgrammerJune, 2003 Copyrignt©2003 Poppendieck.LLC 31
    • 尊敬されたリーダー チャンピョン ビジョンを創造 チームメンバーを決定,召集 支援を探す デザインに関する責任を負う チーフエンジニア ターゲットカスタマを理解している 製品コンセプトを書く カスタマビジョンを技術的な作業者に伝える キーとなる技術的トレードオフを決定する (ソフトウェア開発)マスターデベロパー 以下の名前で呼ばれる 訳注:企業によって,呼び方は違うが,尊敬されたリーダーが アーキテクト キーパースンである,ということ. トヨタのチーフエンジニア制度(CE制度)は、以前は主査制度とよ システムエンジニア ばれていたもの(現在はCEの下に主査がつく)。トヨタには、伝説 チーフプログラマ のCEが多くいる。CEは設計コンセプトの創造から車両設計、生 産、販売、サービスにいたるまですべてのプロセスに采配をふるJune, 2003 う。トヨタ生産方式を「プロセス」のシステムとすると、CE制度は Copyrignt©2003 Poppendieck.LLC 32 「組織」のシステムである。これがトヨタの2大システムといえる。
    • Software Integrity Perceived Integrity The totality of the system achieves a balance of function, usability, reliability and economy that delights customers. Conceptual Integrity The systems central concepts work together as a smooth, cohesive whole.From: Clark & Fujimoto, Product Development Performance, 1991They 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 IntegrityJune, 2003 Copyrignt©2003 Poppendieck.LLC 35
    • ソフトウェア一貫性の鍵June, 2003 Copyrignt©2003 Poppendieck.LLC 36
    • Refactoring1. Simplicity The goal of most patterns2. Clarity With Refa Common language ct oring Encapsulation W Self-documenting code ith ou3. Suitable for Use t Re fa Usability c to Performance rin g4. No Repetition NO REPITITION!5. No Extra Features No Code Before its Time No Code After its TimeJune, 2003 Copyrignt©2003 Poppendieck.LLC 37
    • リファクタリング1. シンプルさ ほどんどのパターンの目標2. 明確さ リファクタリ 共通言語 ン グあり カプセル化 自己説明的コード リフ リフ リフ リフ ァク ァク ァク ァク3. 利用に適している タリ タリ タリ タリ ユーザビリティ ン ンン ン グ ググ グ パフォーマンス な なな な し し4. 重複が無いこと 重複がないこと!5. ムダな機能が無いこと 出番前のコード 出番が無くなったコードJune, 2003 Copyrignt©2003 Poppendieck.LLC 38
    • Multiple Roles of Testing Requirements Feedback System Under Current Test Customer Business Needs Comparison Code Current Current Developer Design System Intent CapabilityScaffolding As-BuiltJune, 2003 Copyrignt©2003 Poppendieck.LLC 39
    • テストの役割は複数ある 要求 フィードバック テスト中の システム 現在のビジ 顧客 ネスニーズ 比較 コード 現在の設計 現在のシス 開発者 意図 テム開発の足場 製品コードの生き写し仕様June, 2003 Copyrignt©2003 Poppendieck.LLC 40
    • See the Whole: Measure UPDecomposition Aggregation You get what you measure You get what you measure You can’t measure everything You can’t measure everything Stuff falls between the cracks Stuff falls between the cracks You add more measurements You measure UP one level You get local sub-optimization You get global optimizationSpan of Control Span of Influence Hold people accountable for Hold people accountable for what they can control what they can influence Measure at the individual level Measure at the team level Fosters competition Fosters collaboration June, 2003 Copyrignt©2003 Poppendieck.LLC 41
    • 全体を見る: 上に向かって測定部分分割 全体統合 測定する 測定する すべては測定できない すべては測定できない モレ・ヌケが出る モレ・ヌケが出る さらに測定項目を追加 もう1レベル上を測定する 部分最適を得る 全体最適を得る制御範囲での責任 影響範囲での責任 コントロールできる範囲の責任を 影響できる範囲の責任を持たせ 持たせる る 個人レベルの測定 チームレベルの測定 競争心を育成する 協力体制を育成する 訳注:全体最適を行うには,当然全体を見なければ,という話し.システム思考に 通じる.分割すれば,部分最適とコマンドコントロール型の指示になる.全体を重視 すれば,全体最適とコラボレーションが生まれる.June, 2003 Copyrignt©2003 Poppendieck.LLC 42