３つのM - リーンの３要素

作者 Roman Pichler, 翻訳者 沼田 暁子 投稿日 2008年3月22日 午後9時43分

コミュニティ

Agile

トピック

Delivering Value,

方法論

タグ

継続的な改善,

補完実践,

Lean

リーン主義をソフトウェア開発に適用することについての議論では、主にムダ（無駄：Muda）なものを特定して排除することに関心が向けられてきました。リーン思考は同様に、ムリ（無理：Muri）とムラ（ばらつき：Mura）を削除することも目指しています。ムダ、ムリ、ムラは「３つのM」と呼ばれています。これらが一緒になると、不調和な３和音を作り出されるのです。持続可能なリーン・プロセスを作り出すためには、３つのMはすべて排除されなければなりません。この記事では、３つのMの関係について論じるとともに、ソフトウェアを開発する組織がリーン・プロセスを作り出すためには、ムリの排除が初めの一歩でなければならないかについて述べています。

ムダ

ムダは、リーン思考では、次のように定義されています：顧客から見た価値を高めず、排除することが可能なすべての活動。例えば、過剰生産や過剰なプロセス、仕掛品や在庫、欠陥、引継ぎやタスクの変更、待機、そして従業員の創造性が生かされないことです。

価値を生み出す活動は、顧客の観点から製品をより良いものにします。次のような質問をするといいでしょう。「私が顧客だったら、この活動にお金を払ったら満足するだろうか？」もしも答えがYESなら、価値を生み出す活動になりそうなものでしょう。例えば、顧客が必要としているものを見つけ出して理解し、コードを書くことです。さらに、プロトタイピングのような活動は、ソフトウェアシステムの開発に関する知識を生み出すものであり、Allen C. Ward氏が指摘しているように、価値のあることです。価値を生み出さず、現在の状況では排除することの出来ない活動はどれも、「価値を生まない」活動と呼ばれます。例えば設定の管理やプロジェクトの計画といった活動です。

アジャイル宣言では包括的なドキュメントよりも動くソフトウェアのほうが重要であると述べており、ソフトウェア開発において価値を創造する活動に重点を置くことの重要性が認められているのです。ムダを排除することによって、より優れた製品をより速く作成できます。

ムリ

それでは、真っ先にムダを見つけ除去することには、どういった問題があるのでしょう？たとえ大多数の従来の開発組織が真に価値を高める活動をほとんど実行していないとしても、適切なアプローチとなるのは、たいていの場合まず別の病である「ムリ」に取り組むことです。人々がバカみたいに長時間働く限り、そしてプロジェクトやチームがたくさんの仕事に埋没している限り、ムダの除去だけでは効果がありません。私達が組織で受け入れられる量や能力に合わせて仕事の量を制限しないかぎり、ムダはいつのまにか戻っている可能性が高いのです。あなたが欠陥を排除しようとしていて、でもプロジェクトはいまだにムリに悩まされているとしましょう。品質の問題は再現する可能性があります。なぜなら、プロジェクトのメンバは未だにプレッシャーを感じていますし、働きすぎているからです。事実ムリは、仕掛品、待機や遅れ、タスクの変更や欠陥などといったムダの主な原因なのです。

受け入れられる量や能力にあわせて要求を制限することは、まさにスクラムやエクストリーム・プログラミングが行っていることです。与えられたイテレーションで行う現実的な仕事量を選ぶ権限をチームに与えることで、ムリをすることは抑えられ体系的に避けられます。長期間維持できるペースが得られるのです。さらに、スクラムやXPではプル型のプロセスと安定したリズムを作り出しました。チームは基本的にプロダクトバックログから要求を取り出し、定期的にインクリメンタルに製品へと変えていきます。

プル型プロセスの利点の一つは、ムリの回避に加え、ムダやその他の問題を見える化することです。度を越した在庫バッファがなくなり、もはや問題はすぐに表面化するのです。スクラムでは、問題や障害を認識し排除することの重要性を認めています。毎日のスクラムミーティングによって、体系的に問題を認識することができるのです。

ムラ

安定したリズムのあるプル型のプロセスは、ムラを見える化します。例えば、イテレーションの計画ミーティングでチームに出された要求のサイズや粒度の違いなどがあります。その他のムラの例としては、異なる開発ツールを使ったり、例えばテストファーストとリファクタリングのような矛盾する開発プラクティスを適用したり、コーディング標準に従わなかったり、というのがあります。ムラは、欠陥製品や過剰なプロセス、やり直しといったムダを生みます。標準や基準はムラを排除します。

しかし、ソフトウェアを開発する上で、すべてのばらつきが悪いわけではありません！例えば、プロダクトバックログで様々な詳細レベルで要求を述べることによって、過剰生産や過剰なプロセス、やり直しを避けることができるのです。プロトタイプを作成して様々な技術や設計オプションを調査することは、一種の必要なばらつきであり、これによって関連知識が得られ、アーキテクチャや技術を決定する際に正しい判断ができるのです。気をつけて欲しいのですが、早期にきちんと計画して試すことに時間をかけるのは、素晴らしいけれどもひょっとしたら実証されていない設計案だけをあてにして後から部分的にソフトウェアシステムを書き直すよりも、ムダがありません。

まとめ

リーン・プロセスを定着させるためには、従来の開発方法を根本的に変更し、適切なプロセスを構築しなければなりません。ソフトウェアを開発する組織の場合は、スクラムやXPが作り出した安定したリズムをもったプル型プロセスを適用することで、最もうまくいくでしょう。これは一種の徹底的な改良であり、日本語でカイカクとよばれるものです。新しい仕事の進め方が一度定着すると、ムダやムラは体系的に排除されるはずです。このプロセスはしたがって、インクリメンタルに継続的に良くなっていきます。これは継続的改善あるいは日本語のカイゼンとして知られています。反映や継続的改善は、定期的なふりかえりによって促進されます。要するに、まずムリを無くして適切なプロセスを作り上げます。それから、絶えずムダやムラを排除する権限をチームに与えて奨励するのです。

資料

• Jeffrey K Liker: The Toyota Way. McGraw-Hill. 2003. （邦訳：ザ・トヨタウェイ、日経BP社、2004年）
• James M. Morgan, Jeffrey K. Liker: The Toyota Product Development System: Integrating People, Process and Technology. Productivity Press. 2006. （邦訳：トヨタ製品開発システム、日経BP、2007年）
• Mary and Tom Poppendieck: Implementing Lean Software Development: From Concept to Cash. Addison-Wesley. 2006. （邦訳：リーン開発の本質ソフトウエア開発に生かす７つの原則、日経BP社、2007年）
• Donald G. Reinertsen: Managing the Design Factory. A Product Developer's Toolkit. Free Press. 1997.
• Allen C. Ward: Lean Product and Process Development. Lean Enterprise Institute. 2007.
• James P. Womack, Daniel T. Jones: Lean Thinking. Touchstone Books. 1996. （邦訳：リーン・シンキング、日経BP社、2003年）

著者について

Pichler Consulting社のRoman Pichler氏(source) は、独立コンサルタントやトレーナー、コーチとして働いています。世界的な大企業はもちろん創業間もない企業の手伝いからリーン思考やスクラムの適用にまでおよぶ、彼の豊かで多様な経験をRomanの顧客たちは評価しています。彼は「Scrum - Agiles Projektmanagement richtig einsetzen」(dpunkt 2007)という本を書いています。

原文はこちらです：http://www.infoq.com/articles/lean-muda-muri-mura

• 次へ >