デス・マーチ著者Ed Yourdonさんの『ソフトウェア工学で大切な10の考え方』を再読する(中編)

前回記事の続き。デス・マーチ著者のEd Yourdonさんが先日(2016/1/22)亡くなったとのこと。合掌。これを機会に同氏が2009年に公開し平鍋さんが和訳を公開している『ソフトウェア工学で大切な10の考え方』を再読してみた。今回は「5.欠陥が下流に「漏れる」と修正コストが増加する」からを取り扱う。勉強不足により誤読、勘違いをしているかもしれない。指摘やフィードバックは大歓迎。

Top Ten SE Concepts V11.1 Jp from Kenji Hiranabe

5.欠陥が下流に「漏れる」と修正コストが増加する

コストはライフサイクルのフェーズを1つ越えるごとに10倍になる。
1980年代前半の、Barry Boehmによる文書
Agileの人たちは不賛成であり、継続的なリファクタリングを強調している。
しかし、 Boehmは同意していない
それはプロジェクトサイズに依存している『アジャイルと規律』(2004)

ソフトウェアの修正コスト曲線に関する話である。ソフトウェア開発のライフサイクル(設計→実装→テスト→運用)の後ろに行くほど修正にかかるコストが指数関数的に増加していくというもの。

初期のAgile界隈からの反論はおそらくXPエクストリームプログラミング懐疑編―XPはソフトウェア開発の救世主たりえるのか (The XP Series)に書かれているものを指していると思われる。残念ながら同書は未読なのだけれども、だいたい書かれていることは

俺もエクストリームプログラミング入門

で読める。

そして、変更コスト曲線の話については(Yourdonさんのスライドにも書かれている通り)『アジャイルと規律』で改めてBoehmがアップデートを書いている。同書でBoehmが言っていることを要約すると次の通り。

大規模プロジェクトにおいては再検証してみても、やはり「納品後のソフトウェアの変更は要求フェーズでの変更より100倍も高くつく」傾向にある
変更コストの80%はシステム全体に影響を及ぼす20%の変更からもたされれる。よって早期のリスク軽減や、変更の影響を局所化するアーキテクチャの設計をすることで、大規模システムでも「高価な20%」の変更コストを大幅に削減できる可能性がある。
一般的に大規模プロジェクトは、変更コスト曲線の勾配がきつくなる傾向にあるので、XPを採用するのにふさわしい候補ではない。
小規模なアジャイルプロジェクトについても、データを見る限りストーリー番号が増加するに従って変更コストは増加している。"これは、些細なものだとすませられる増加率ではないし、アジャイルの専門家がエピソードとして語る経験値ほど良くないことも明らかである"

とはいえ、その後Boehmは「すべてを先に決めないといけない」という考え方は誤りであることを認めている(2008年)。このあたりは平鍋さんの下記ブログも参考に。

「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログ：An Agile Way：オルタナティブ・ブログ

さらにBoehmは2010年、Making Software ―エビデンスが変えるソフトウェア開発においてこの議論を総括している。

第10章アーキテクティング：いつ、どれだけ？バリー・ベーム（Barry Boehm）
この章では、プロジェクトや組織がソフトウェア開発に際して、どのような時にアジャイル手法とアーキテクティングアプローチのどちらを使うべきかを判断する助けとなる研究を紹介します。ソフトウェアプロジェクトやソフトウェア主導なプロジェクトの管理者たちがアーキテクティングの重要性を十分に認識しているとしても、彼らの手持ち資源は常に有限であるため、「どれだけアーキテクティングを行えば十分なのか？」と自問することはよくあります。
Making Software ―エビデンスが変えるソフトウェア開発

詳細は同書を確認していただくとして、「すべてを先に決めないといけない」というわけではないながらも、プロジェクトの規模や特色によって慎重に検討する必要があるといった事が書かれている。少なくとも、欠陥が下流に「漏れる」と修正コストが増加することは否定されていないという点に注意が必要である。

Making Software ―エビデンスが変えるソフトウェア開発

発売日: 2011/09/24
メディア: 大型本

なお本書はオライリーでPDFを購入することができる(私はそっちを買った)。

6.トレードオフは非線形

人と時間のトレードオフは、3次多項式
Capers Jones ( 『ソフトウェア見積もりのすべて』) によると、欠陥 = k*ファンクションポイント**1.25
頭で計算することは困難！
小さくないプロジェクトでちゃんとした交渉をするためには、十分に強力な見積もりツールが必要 (例えば.,SLIM,Costar)

人と時間のトレードオフが非線形であることは以前に以下の記事でも取り上げている。

スケジュールの基本公式 - 勘と経験と読経

なにはともあれ、直感的な見積りほど信用ならないものはない。
この記事でも紹介しているけど以下の本がおすすめ。

ソフトウェア見積り　人月の暗黙知を解き明かす

作者:スティーブマコネル
発売日: 2014/06/03
メディア: Kindle版

7.再利用は重要

コードの再利用だけでなく、設計、仕様、プロセス、計画、予算テンプレート、チーム、などの再利用。
再度: 技術はビジネス/文化的な問題よりも重要ではない
再利用のコストを無視してはいけない

かなり古典だけれどもソフトウエア開発 55の真実と10のウソで詳しく取り上げられている問題ではある(その後に発表された技術書で本テーマを扱ったものをあまり知らない)。

15.小規模な再利用(例えば、ライブラリやサブルーチン)は50年前に始まり、既に解決済みの問題である。

16.大規模な再利用(コンポーネント単位)は、誰もがその重要性を認識し、なくてはならないと感じているが、今なお未解決である。

17.大規模な再利用は、類似システム間ではうまくいく可能性が高い。応用分野の類似性に依存するため、大規模流用の適用範囲は狭くなる。

18.再利用には、2つの「3つの法則」がある。

再利用可能なコンポーネントを作るのは、単一のプログラムで使うモジュールの開発に比べ3倍難しい

再利用可能なコンポーネントはライブラリに取り込む前に、3つの異なるプログラムでテストする必要がある。

19.プログラムを再利用する場合、流用母体の変更はバグの原因になる。20-25%も変更する必要があるなら、最初から作った方が効率が上がるし、品質も良い。

20.デザインパターン方式の再利用は、ソースコードの再利用における問題を解決する一手段である。

ソフトウエア開発 55の真実と10のウソ