リーン　ソフトウェア開発（その１）

マリー・ポッペンディーク/トム・ポッペンディーク
平鍋健児/高嶋優子/佐野建樹訳
日経BP社

1日30分は勉強することにしているのですが、読む本がなくなったからと言って、期待せずに読み始めた、積読だった本書。「はじめに」と「イントロダクション」だけで衝撃を受けました。実に鋭い考察の数々。これから何回かにわたって、そのエッセンスをお送りします。

はじめに

CMMやPMIを非難するわけではない。ただ、産業界でのリーン改革を経験してきたものから見れば、それらはソフトウェア開発にムダな要素を与えやすいように思える。ソフトウェア開発のパラダイムを、プロセスから人へ、ばらばらの個から集団へ、推測からデータにもとづいた決定へ、計画から学習へ、トレーサビリティからテスティングへ、コストとスケジュールの管理からビジネス価値の提供へと変えることが、本書のねらいである。
高品質と低価格とスピードは、本当に共存できないのだろうか？リーン手法を知る前、製造や製品開発を行っていたころには、私たちも「できない」と思っていた。しかし、価値とフローと人に焦点を当てることによって、高品質、低コスト、迅速な出荷を実現できる。それを私たち自身、市場からから逃げ出していった競合他社から学んだのだ。

イントロダクション

メタファを使いあやまった場合にリスクがあることを承知で言えば、ソフトウェア開発は製造ではなく製品開発と似通っていると私たちは信じている。

製造の最終段階での変更による莫大な損失の回避方法として、最初から設計に関して正しい決定を下し、それ以降、変更する必要をなくす、という方法がある。これがデトロイトの手法だ。トヨタやホンダは、設計に関する不適切な決定の損失を避けるのに別の方法を発見した。それは、「取り消しのきかない決定を最初にしないこと」だ。設計に関する決定をできるかぎり先延ばしにし、決定するときには、わかっている情報を総動員して、正しく決定する。この思考は、トヨタが開拓したジャストインタイム生産の背後にある、「顧客の注文を受けるまで、何を作るべきか決めてはいけない。注文を受けてから、できるだけすばやくそれを作れ」という思考に通じるものがある。

「原則」が、ある分野についての指針となる考えや洞察であるのに対し、「プラクティス」は、原則を実行するために、何をするか、である。原則は普遍的なものだが、それらが特定の環境にどう当てはまるのかが、わかりにくい場合もある。一方プラクティスは、何をすべきかについて明確なガイダンスを示してくれるが、それぞれの分野に適応させる必要がある。私たちは、「ベスト」プラクティスなどというものはない、と信じている。プラクティスは、コンテキストを考慮しなくてはならない。

ムダを排除する。
ムダとは、顧客が認める価値を、製品に付加しないもの、すべてのことだ。リーン思考では、ムダという概念を最大の問題としている。部品がちりの積もった棚に置かれたままになっていたら、それはムダだ。要求を集めた文書が、使われないまま埃をかぶっていたら、それはムダだ。製造工場が、すぐに必要となる以上の量を生産しているのなら、それはムダだ。開発者がすぐに必要となる以上の機能をコーディングしているのなら、それはムダだ。製造の過程で、製品をあちこち移動させるのはムダだ。製品開発において、あるグループから別のグループに開発を引き継ぐのはムダだ。理想は、顧客が欲しがっているものが何かを見つけだし、製造するか開発して、顧客が要求するそのものをただちに納品することだ。顧客のニーズをすぐに満たすのにじゃまとなるものはすべて、ムダなのだ。

決定を遅らせることには価値がある。なぜなら、推測ではなく、事実にもとづいている方が、より的確な決定を下せるからだ。成長中の市場では、早期に確定するよりも、いろいろな設計オプションを選択可能にしておくことに価値がある。複雑なシステムを開発している場合に、決定を遅らせるためにキーとなる戦略は、システムに変更可能性を組み込むことだ。