リーン原則とソフトウェア開発

リーン原則
と
ソフトウェア開発

発表バージョン
2011/05/28 You&I

わんくま同盟東京勉強会 #59

自己紹介

• H/N You&I(読み：ユーアンドアイ)
• 出身生まれも育ちも名古屋市
• 年齢 30代前半
• 本職商学部出身の職業プログラマ
• 言語 C++,C#,VisualBasic 6.0,日本語COBOL
• 日記 http://d.hatena.ne.jp/youandi/
• 所属名古屋アジャイル勉強会
プログラミング生放送名古屋支部
わんくま同盟


ナゼ、イッタイ。

• リーン原則はトヨタ生産方式から生まれた
– トヨタ自動車って愛知県内にあるし、名古屋勉強
会っぽいよね・・・？
• ウチの会社の親会社がリーンのカイゼン活動
というのをやっていてウチの社内ではかなり
不評
– どうも数値ありきの活動内容になっているらしい。
→そもそもリーン(lean)って何だろう？


Agenda

1. リーン原則の背景
2. リーン原則とは
3. リーン原則とリーンソフトウェア開発
4. まとめ


1.リーン原則の背景

4. まとめ


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サイクル)と称している。



– デミング博士が信望していた４つの要点
1. システムの正しい理解
システム内の部分間の相乗効果が、全体の成功の鍵となる
2. 変動についての知識
低品質・低生産性の大半の原因はシステムに内在し、個々の作
業者にはどうしようもない
3. 知識の理論
仮設を立て、実験し、学習し、学習を組み入れる(PDSA)
4. 心理学
数字が全てではない。人に関係することは、スキル・誇り、専門
知識、自信、そして協力による影響が大きい



– デミングの14項目(1/3)
1. 長期に渡って必要とされる企業となる。
2. 遅れやミス、欠陥品、質の悪いサービスは受け入れ
られない。
3. 欠陥を発見する為に検査するのではなく、製品を作
る過程で品質を作り込む。
4. サプライヤの選定は、誠実さと信頼に基づき長期的
な関係を確立し、費用を抑える。
5. 生産やサービス提供のシステムを改善する為、絶え
ず努力を続ける。改善は一度で終える作業ではない。



6. 訓練を制度化する。作業者だけではなく管理者も訓
練を受ける必要がある。
7. リーダーシップを育てる。管理者の仕事は人々がより
良く仕事できるように手助けし、作業者の邪魔になる
事象を取り除く事である。
8. 恐怖感を持たせない。良い仕事をする為には身の安
全を感じていなくてはならない。
9. 部署間の垣根を壊す。部署の枠を超えたチーム作り。
個人評価等のチームワークを乱す事をしない。



10. スローガンや説教、到達目標の使用をやめる。欠陥
や低生産性の原因は人ではなくシステムである。
11. 作業者への数量的なノルマや管理者層の数量的目
標をなくす。開発チームへの身勝手な締め切り設定
をやめる。
12. 技術者の誇りを奪う制度をなくす。
13. 全員に対して教育と自己改善を奨励する。
14. 変化を遂げる為の行動を取る。実際の行動によって
変化が導かれる。



• トヨタ生産方式(TPS:Toyota Production
System) (1/4)
– 戦後の日本の復興において、欧米の大量生産方
式による低コスト化に対抗する為に生み出された。
– TPSは、1960年代にかけてトヨタ自動車の社内プ
ロセスを大野耐一氏らが体系化したもので、その
考えの中心は「ムダを排除せよ」である。



System) (2/4)
– ジャストインタイム
工程間での在庫を最小に抑える
– カンバン
工程間での納入・生産指示の役割
– 平準化
様々な種類の製品を均等にバラして生産



System) (3/4)
– アンドン
生産ラインにおける生産状況報告システム
– ポカヨケ
作業ミスを防止する為の仕組み
– 自働化
にんべんのついた自働化とも言われる。不良発生時に
は機械が自動的に停止し、人の手によって不具合原因
の解消を行う。



System) (4/4)
– 改善
工場の作業者が中心となって行うボトムアップ活動の事。
改善活動は一度ではなく持続性・継続性が重視される。
– 見える化
組織内における情報共有を目的として、情報の可視化を
行う事。
– ムダ
７つのムダで表される、顧客にとって価値を生み出さない
ものの事。


• TPSの７つムダ
– 作りすぎのムダ
– 手待ちのムダ
– 運搬のムダ
– 加工のムダ
– 在庫のムダ
– 動作のムダ
– 不良を作るムダ



• 戦後の日本の生産現場には、デミング博士に
よる統計的な品質管理方法の影響があった。
• そのデミング博士の考えを基本として、トヨタ
自動車では顧客中心としたムダを排除する独
自の生産方式を作り出し、会社として業績を
伸ばした。
• 1980年代に欧米の研究者達が日本の生産方
式についての研究を行い、それらを体系化し
てリーン生産方式として一般化した。


2.リーン原則とは

4. まとめ


2.リーン原則とは(1/5)

• TPSから他の分野へ
– トヨタ製品開発システム
1. 起業家的リーダーによるシステム設計
チーフエンジニア主導による開発
2. エキスパートエンジニアの尊重
ある分野を極めるまでは他の部署へは異動しない
3. 責任ベースのプランニングと制御
決められた期日に成果物は提出するが、その過程の進捗状況は
トラッキングされることはない
4. 集合ベースのコンカレントエンジニアリング
複数の設計を探索していき、徐々に選択肢を狭めていく



• リーン生産方式から他の分野へ
– リーンソリューション
– リーン消費
– リーン供給
– リーン企業
– リーンサプライチェーン
– リーン開発(リーンソフトウェア開発)
• リーンとは基本的に顧客を中心に物事を考
える。これはどの分野においても変わらない。



• 余談ですが、ソフトウェア開発では「製造工
程」とか使われますが・・・
– そもそも工場での作業工程とソフトウェア開発の
工程って違いますね。
– 建築に例えられる事があります。
• プロジェクト・ブック (建築文化シナジー)
• ISBN : 978-4395241019
– 料理に例えられる事もあります。



• 「原則」とは考え方の指針であり、「プラクティ
ス」はその「原則」を実行する為に何をするか、
である。
• 今日の話でのリーン原則
– リーンの研究者である、メアリー＆トム・ポッペン
ディーク夫妻が定義する、ソフトウェア開発におけ
る７つのリーン原則を主体とします。
– でもポッペンディークさんの著書によって、原則も
尐しずつ変更されていたりします。



• ７つのリーン原則
1. ムダを排除する
2. 品質を作り込む
3. 知識を作り出す
4. 決定を出来るだけ遅らせる
5. 速く提供する
6. 人を尊重する
7. 全体を最適化する


3.リーン原則とリーンソフトウェア開発

4. まとめ


3.リーン原則とリーンソフトウェア開発(1/12)

• リーン生産方式とリーンソフトウェア開発の類
似点(1/2)
リーン生産方式リーンソフトウェア開発
頻繁な設定変更頻繁な製品リリース
短い製品スループット時間短い開発時間
製造工程間の未完成在庫の削減開発工程間の情報在庫の削減
製造工程間で部品を頻繁に交換開発工程間で仮決定の情報を尐しずつ
移動させる
在庫削減にはリソースのゆとりや工程開発時間削減にはリソースのゆとりや
間でさらなる情報フローが必要工程間での情報フローが必要
数量、製品構成、製品設計の変更への製品設計、スケジュール、原価目標の変
順応性更への順応性



• リーン生産方式とリーンソフトウェア開発の類
似点(2/2)
リーン生産方式リーンソフトウェア開発
製造作業者への幅広いタスク割り当てエンジニアへの幅広いタスク割り当てに
により高生産性を得るよって高生産性を得る
素早い問題解決と継続的なプロセス改頻繁で反復的な革新と継続的な製品・
善の重視プロセスの改善の重視
品質、納期、製造生産性の同時改善品質、開発時間、開発生産性の同時改
善



• ７つのリーン原則の解説
1. ムダを排除する
2. 品質を作り込む



1. ムダを排除する(1/2)
– ウィンストン・ロイス博士が1970年に発表した論
文「MANAGING THE DEVELOPMENT OF
LARGE SOFTWARE SYSTEMS」
分析やコーディングほどに最終的な製品に直接寄与するものは
無いと書かれている。逆を言えばそれ以外はムダである。
1. プログラム設計を最初に行う。
2. 設計の文書化。
3. 2度行う。
4. テストを計画、管理、監視する。
5. 顧客を巻き込む



1. ムダを排除する(2/2)
– ムダの排除はリーン原則の根本にある。
– 具体的にどのようなムダがあるかは今回省略。
製造のムダソフトウェア開発のムダ
在庫のムダ未完成の作業のムダ
加工のムダ余分なプロセスのムダ
作り過ぎのムダ余分な機能のムダ
運搬のムダタスク切り替えのムダ
手待ちのムダ待ちのムダ
動作のムダ移動のムダ
不良をつくるムダ欠陥のムダ



2. 品質を作り込む(1/2)
– 品証部門は、後からテストによって品質を保証す
るのでは無く、最初からコードに品質を作り込ま
せるプロセスに重点を置くべきである。
– 「最初から正しく」実装をする為にポカヨケの仕組
みをソフトウェア開発に導入し、テスト駆動開発
や継続的インテグレーションを導入する。
– コードベースをシンプルに保つ。その為に新たな
機能を考慮して、設計をリファクタリングしていく。
– 早期にテストし、速く失敗する。



2. 品質を作り込む(2/2)
– 5S(ご-えす)
1. 整理(Sort)
ソースコード上の使われていないコードを削除する。
2. 整頓(Systematize)
余計な依存関係はないか？
3. 清掃(Shine)
エラーはワーニングは解消する。
4. 清潔(Standardize)
リファクタリングや仕様変更が入っても綺麗なままで保つ。
5. 躾(Sustain)
これらの規律を手順化し、守り続けていく。


– ソフトウェア開発は知識創造のプロセスである。
– タイムボックス(イテレーション・スプリント)での開
発により定期的にフィードバックを得る。
– 定期的なリファクタリングにより素早い変更が可
能となる。
– 継続的インテグレーションにより素早いフィード
バックを得る。
– プロセスは守る為にあるのではなく、改善され続
けていくものである。



– 従来、開発が進むにつれて変更のコストが増大
すると考えられていた。
– 後で撤回・変更が難しい決定を行う際には出来
るだけその判断を遅らせるべきである。
– 難しい問題に対して複数の選択肢を用意するオ
プション思考を行う。
– 問題をシンプルにする為に、関心を分離・カプセ
ル化したり、不要な機能は入れない。



– カンバン方式により、「プル(Pull)」形式によるス
ケジュール管理を行う。予め作業に担当を割り
振らない。手の空いた人に次の作業を割り振る。
– 速く提供する為には現在のやり方を分析して、ど
の工程にどれだけ時間が掛かっているか分析す
る必要がある。仕様変更が決まってから顧客の
気が変わる前にその変更が提供出来るか？
– 余計な機能は入れないようにし、作業の見積もり
をし易くする為にタイムボックスで作業を区切っ
て、提供する。


– 「唯一最高のやり方」などは存在しない。常にプ
ロセスは守るものでは無く、改善し続けていくも
のである。
– 先に紹介したトヨタ製品開発プロセスにおいても
人を重視したものになっている。
– チームを信頼し、チームに権限を与える。この自
律的な作業により、プロセスがシンプルになり速
く提供出来る。
– 技術を磨くのでは無く、解決手順を身につける。



– 部分最適化を行わない。プロセス全体を見渡し
てムダを見つける。ある一部のみを最適化する
と逆に全体の最適化を阻害される事がある。
– 最適化する為には計測や指標が必要となるが、
分析すべきは、サイクルタイム、財務指標、顧客
満足度である。最適化にあたり指標を細分化し
がちであるが、それは逆で1つ上の段階で分析
すべきである。


4.まとめ

4. まとめ


4.まとめ(1/4)

• リーン手法導入の注意点
1. 他人のやり方を模倣しない。「原則」を理解し自
分に合った「プラクティス」を実施する。
2. ベストなやり方は存在しない。常にカイゼンある
のみ。
3. 部分最適化をしない。常に全体を見渡す事。
4. 最適化する為にはシンプルに保つ。


4.まとめ(2/4)

• 今回の話の中で「アジャイル」という言葉は出
てきませんでしたよね？
– 但し、幾つかのアジャイルプラクティスは出てきま
した。(タイムボックス、TDD、CI、素早いリリース)
– ７つのリーン原則を踏まえた上で、現時点での「よ
り良い」やり方として、アジャイルプラクティスが選
ばれたと捉えるべきです。
– アジャイルにも「アジャイルソフトウェア開発宣言」
及び「アジャイルソフトウェアの12原則」という「原
則」があり、様々な「プラクティス」が存在します。


4.まとめ(3/4)

• 今回リーンに興味を持った事の1つに現場の
カイゼンがあります。
– いち開発者として、ボトムアップで現場のカイゼン
が出来るのか？が実は知りたかった事。
– 「開発者にはeXtream Programmingの本を、プロ
ジェクトマネージャーにはScrumの本を、そして経
営者にはリーンの本を渡せ」という一文が・・・
– PDCAサイクルにせよ、リーン開発にせよ、プロセ
スの見直しをするのは、管理者であるように思い
ました。


4.まとめ(4/4)

• 参考書籍
– リーンソフトウェア開発
• ISBN： 978-4822281939
– リーン開発の本質
• ISBN： 978-4822283506
– リーンソフトウェア開発と組織改革
• ISBN： 978-4048687416


リーン原則とソフトウェア開発

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to リーン原則とソフトウェア開発

Similar to リーン原則とソフトウェア開発 (20)

Recently uploaded

Recently uploaded (8)

リーン原則とソフトウェア開発