リーンソフトウェア開発

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

これも今頃読んでみた。原著は2003年刊。

この本のアイデアは、「TPS(トヨタ生産方式)をソフトウェア開発に当てはめてみたよ！　みたよ！(AA略」に尽きると思った。

それに、どちらかと言えばこれはぼんくら管理者が「分かった気になる」ための新書群にとても近い気がする。他のレビューでも言われているが、参考文献の数に比べて、それらを引用するロジックが非常に脆弱で、ほとんどつまみ食いでしかない。世の中にはセンスのあるつまみ食いというのもあるのだが、この本ではそれも感じない。
また、豊富な比喩・まれな具体例のほとんどに、矛盾や解釈の曖昧さが含まれることにも苛立つ。例えば、片方で、ソフト開発は生産ではなく開発(設計)である、と言いながら、リーンソフト開発の構成要素でいちいちトヨタのラインの例を引いて見せたりする。設計の重要項目はできるだけ意志決定を遅らせろと言いつつ、その方法として最初にモジュール・インターフェース・パラメータ等を決めろと言う(その設計こそがソフトウェアにとっては最重要項目だろうに)。

首を傾げながら取りあえず読み通した結果、自分にとってこの本で一番面白いのは

• 変動する要求に対して、設計の重要な決定を「最終責任時点」なるポイントまで遅らせろとした
• そのために「コンカレント開発」という概念をソフトウェア開発に持ち込んだ

点かなと思った。

しかし。

例えば、今適当にググって見つけた野村総研のこれにもあるように、コンカレント開発の目的は、商品開発以降のスピードアップであって、垂れ流される変更要求に応え続けることではない。また、一般にコンカレント開発と言った時は、設計を遅らせるのではなく、「後工程の設計も先にやってしまう」ところがポイントだ。設計とは、つまるところ取捨選択である。従って、意志決定を遅らせるどころか、「より多くの問題に対して、先行して意志決定をする」のが、競争力の源泉としてのコンカレント開発のツボなはずだ。

その辺が電機メーカーの中の人の端くれたる自分の中の世界観と違っていて混乱するし、文章全体にわたるいい加減さと相まって、警戒してしまう。

例えば、(こういうのは自分がやらないので分からないけど)、SI案件が降ってきたときに、システム屋、DB屋、ネットワーク屋、Web屋が集まって、協議の末、リーダーが全体のコンセプト・メトリクスをずばり決める。全員で概念設計、重要な設計原則、ノウハウを摺り合わせる。その後、各チームに持ち帰って中身の詳細設計を始めるが、チーム同士が互いに密に連絡を取り合って変更点を共有している。こういうのはコンカレント開発だと思う。でもそれは、意志決定を遅らせるためでは決してないと思う。

また、現在、日本の電機メーカーの開発スタイルは批判にさらされている。曰く「日本的摺り合わせ型開発はコストが高すぎる」「ソフトウェアのように水平分業・モジュラー型にすべき」だそうだ。あれれ、おかしいなｗ　自動車はそれでも究極の複雑さを持つ製品として、摺り合わせ型の牙城と思われていたが、それでもモジュラー化はどんどん進んでいる(クルマの「モジュラー化」はどこまで進むのか---トヨタの決算説明会を聞いて | 日経 xTECH（クロステック）)。1プロジェクトのマネジメント手法とは次元が違う話ではあるが、摺り合わせが効果的に適用できる範囲は決して広くはない。モジュラー化できるなら、そっちの方が早いのだ。

そんなわけで、この本は本当にそんな有り難い本なのか、私には良く分からなかった。恐らく5人〜50人規模の、新規性の高い案件に限られた話なのではないかと思う。しかしその場合だったら、XPだのUPだのの方がプラクティスとしてずっと分かりやすいんじゃないかと思った。