ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)

2007年～2011年ごろまで はてなダイアリー に書いてた記事を引っ越してきました。

ベームがインクリメンタル開発を推奨していたのは本当？

雑記

・「リーンソフトウェア開発」
http://www.amazon.co.jp/dp/4822281930/

これを今更読んでるんだけど、そこでかなり吃驚した箇所に突き当たった。ちょっと長めだけど引用する。

・「リーンソフトウェア開発」(日経BP), p83

1987年にバリー・ベームはこう書いている。「ソフトウェアが出荷されてしまってから問題を見つけて直すと、初期設計フェーズでそれを行うよりも、100倍のコストがかかる」(Boehm, "Industrial Software Metrics Top 10 List")。この所見は、ベームが「一発勝負での完全な製品開発」ではなくインクリメンタルな開発を奨励していたのにもかかわらず、完全な要求分析と設計を先行して済ませる根拠となった(Boehm and Papaccio, "Understanding and Controlling Software Costs")。
2001年にベームは、小規模のシステムでは、その増大係数は100対1でｈなく、むしろ5対1程度であると述べた。そして、大規模なシステムであっても、優れたアーキテクチャを使用し、変更の入りそうな部分をうまくカプセル化して小さな領域に閉じこめれば、変更によるコストを大幅に削減できると述べた(Boehm and Basili, "Software Defect Rduction List")。

もしベームがインクリメンタルな開発を推奨していたのが本当であれば、問題の対処法を完全に読み違えていた事になる。「後になって問題が見つかるとコストがかかる」→「なので、予め要求分析や設計を完璧にしておこう」というのが自分が今まで@ITとかで見てきた話だけど、そうではなくて「なので、インクリメンタルな開発を推奨します。」となれば話が全く違ってくる。

というわけで、妙に気になったので引用されている原典をあたる事にした。

確認できた原点で、新しい2001年の方の"Software Defect Reduction List"の方を見てみる。

1. Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.

http://www.cebase.org/www/researchActivities/defectReduction/top10/index.html

これが問題の箇所。で、読んでみると速攻で気になる文が出てきた。

As in 1987, "This insight has been a major driver in focusing industrial software practice on thorough requirements analysis and design, on early verification and validation, and on up-front prototyping and simulation to avoid costly downstream fixes."

まず1987年版では、「この所見はソフトウェア開発において、以下の点に集中させる主な動機となってきた」みたいな感じで、以下のプラクティスを動機付けしてきたとある。

  • "on thorough requirements analysis and design"
    • 徹底的な要求分析と設計
  • "on early verification and validation"
    • 早期の検証と妥当性の確認
  • "on up-front prototyping and simulation"
    • 前もってのプロトタイプ作成とシミュレーション

この段階では、ベームが特別にインクリメンタル開発を推奨しているようには読み取れない。プロトタイピングにも言及しているけれど、あくまでも問題の所見が理由となり、結果としてプロトタイピングを動機付けてきたという事実だけを述べているように見える。

2001年版ではこれに続き、「"often"を付けました。」→「小さくてクリティカルでないシステムの場合は5:1位になります。」と書いてある。インクリメンタル開発の推奨につながりそうなのは次の一文。

For one, the cost-escalation factor for small, noncritical software systems is more like 5:1 than 100:1, enabling such systems to be developed most efficiently in a less formal, "continuous prototype" mode -- but still with emphasis on getting things right early rather than late.

こうした小さなシステム開発では、あまり形式ばらずに「継続的なプロトタイピング」による効率的な開発を可能にしているからだ、という感じ。
但し、直後に but still with emphasis on getting things right early rather than late. → それでも、後よりは早期に物事を正すことは強調する・・・訳、合ってる？
つまり「小さなシステム開発では継続的なプロトタイピングで効率を高めて、後になって問題が見つかった時のコストを5:1位まで抑えられる。けれども、早期にちゃんとしておくのが重要な事には違いない。」と述べているように見える。"but still with emphasis"とわざわざ強調している以上は、やはり早期にちゃんとしておくことの重要性を押さえておきたかったのだろうと推測する。

後には、ざっくりとまとめると「大きなシステムでもアーキテクチャをちゃんと作れば、小さくて良くカプセル化したモジュールによりコストを抑える事が出来ます。」みたいな事が書いてある。

・・・なんか・・・淡々と至極真っ当な事実を述べているだけで、特別インクリメンタル開発やプロトタイピングを推奨しているようには読み取れない。元々2001年の記事は、CeBASEという「客観的なデータを元にソフトウェア工学を改善する」みたいな目的を持つ団体の立場から書かれているため、「客観的な数値としてこういう事実がありますよ。」と述べているにとどまり、だからどうこうまでは踏み込んでいないように読める。

となると残された手がかりは、19ドルを払う必要のあるIEEEの論文だけになるが・・・。さすがにそこまでやる気力は今はない。

こうしてみると、何だかAmazonの辛口書評の方が真実味があるように思えてくる。

...
トヨタ生産方式をアジャイル開発に応用するという「ひらめき」が最初にあり、それが正しいものであることをいろいろな文献の「断片」を持ち出して正当化することに終始している。そのことは脚注の多さが物語っている。だが、読者にしてみれば「活字で世に出ていることがすべて正しい」とは思っていないので、単に誰々さんがこー書いているから正しいんだと何度も書かれても、疑問が晴れない。
...

原典をおすすめします

実は
http://www.amazon.co.jp/dp/482228350X
の方を先に読んでいたのだけれど・・・こちらにもなんだか当てはまりそうな指摘。

初めの話に戻すと、今のところベームがインクリメンタル開発を推奨している事を読み取れる箇所は引用元からは見て取れない。
但し、ベーム自身の論文でGoogleに引っ掛かったものでは

などでインクリメンタル開発やスパイラル開発についての論文が見れるので、インクリメンタル開発の研究に深く関わっているのは確かっぽい。

何だかスッキリしない結末になったけど、少なくとも「リーンソフトウェア開発」については手放しでお奨めできる本ではない事は確かっぽい。沢山の事例や引用で勇気づけられる事は確かだけれど、鵜呑みにはできそうにない。

オチがついてないけど、今日のところはそんな感じ。