ソフトウェア開発201の鉄則

著者 : アラン・M.デービス 松原友夫

• 日経BP (1996年3月22日発売)

作品紹介・あらすじ

本書は、ソフトウェア工学の原理を1冊にまとめた本である。原理とは、選択した技法、ツール、言語がどんなものであるかに関係なく、ソフトウェア工学に関して言える基本的な真理、原則、または仮説を指す。わずかな例外を除いて、本書に掲載した原理は私自身のものではなく、多くのソフトウェア工学の実践者や研究者の論文から抜粋したものである。失敗を未然に防ぐノウハウ。

感想・レビュー・書評

[michiyamakiさんの感想 · 2022年4月25日]

悩んだ時に、経験則を振り返りながら考えられる。手元に置いておきたい一冊。

[nakaizawaさんの感想 · 2013年8月28日]

(2002.08.27読了)(2002.06.30購入)
（「BOOK」データベースより）amazon
本書は、ソフトウェア工学の原理を1冊にまとめた本である。原理とは、選択した技法、ツール、言語がどんなものであるかに関係なく、ソフトウェア工学に関して言える基本的な真理、原則、または仮説を指す。わずかな例外を除いて、本書に掲載した原理は私自身のものではなく、多くのソフトウェア工学の実践者や研究者の論文から抜粋したものである。失敗を未然に防ぐノウハウ。

[monte301さんの感想 · 2013年4月10日]

技術本の善し悪し、あるいは有用性を自分で判断するのは難しいものです。

ここに書かれている「原理」は、まえがきにあるように「原理とは、選択した技法、ツール、言語がどんなものであるかに関係なく、ソフトウェア工学に関して言える基本的な心理、原則、または仮説を指」します。
数学の定理のようなものとも言えますが、序章に書かれているとおり、「原理は、学問分野の成長につれて進化するもの」です。この２０１の原理は「こんにち（日本版の初版は１９９６年）」のものです。それにしては、ここに書かれている原理は色あせていません。ソフトウェア開発やテストがさほど進化していないとも言えますし、だからこそこれらが「原理」としての価値を失っていないとも言えます。

以前の私には、この本の価値は理解できなかったと思います。数くの本を読み、セミナーやシンポジウムに参加するなどして、ようやく本書が非常に優れた辞書的な価値を持っていることを実感しました。
よほどの自信がない限り、まずはここに書かれていることは正しいと信じて、いかにそれを実践するかを考えるべきだと思います。難しいですが、難しいからこそ本書のような羅針盤が必要です。
手元に置いて、折に触れ参照したくなる珠玉の一冊です。

XDDPで有名な清水吉男氏も推薦されていますね。

[akiyama924さんの感想 · 2012年4月30日]

ソフトウェア工学の多数の論文のなかから、principleと呼べるものをDavisが厳選し、実務者にも読みやすく（Davisはもともとは実務者でした）エッセイ風にまとめたものです。

この本には「当たり前」と思うことばかり書いてあります。
けれど、実践できていないことも多いはず。

何故、実践できていないか？　どうしたらよいか？　を考えるきっかけになる良書です。

テスティングの原理も載っています。
　107　テスト項目と要求項目と関係づけよ
　108　テストを行う時期よりずっと前にテストを計画せよ
　109　自分のソフトウェアを自分でテストするな
　110　自分のソフトウェアのテスト計画を自分で作成するな
　111　テスティングは欠陥の存在をあらわにするだけだ
　112　エラーだらけのソフトウェアは価値がないことを保証するが、エラーがないこととそのソフトウェアの価値は無関係である
　113　エラーを見つけてこそテストがうまくいったといえる
　114　半分のエラーは15%のモジュールで発見される
　115　ブラックボックス及びホワイトボックス両方のテスティングを用いよ
　116　テストケースには期待される結果を含めよ
　117　無効な入力をテストせよ
　118　常にカフカ状態のテストをせよ
　119　ビッグバン説は当てはまらない
　120　MCabeの複雑性尺度を使え
　121　効果的な完了尺度を使え
　122　テスト・カバレッジを効果的に達成せよ
　123　単体テスティングが済む前に統合するな
　124　ソフトウェアに仕掛けを組み込め
　125　エラーの原因を分析せよ
　126　エラーを個人のものにするな

それから、「“硬派”のホームページ」に清水吉男さんによる解説がまとめられていますので合わせて読むと面白いと思います。

[kaizenさんの感想 · 2012年1月4日]

多くの経験を読んで、自分はなぜそうしないか、なぜそうできていないかの理由を考えるとよいかもしれない。
その仕事固有の制約条件があったり、その分野固有の制約条件があってできないことがあるかもしれない。
それを洗い出すきっかけとしても、いいかもしれない。

[nihonokamisanさんの感想 · 2011年2月19日]

様々なソフトウェア工学の原理を一冊にまとめた書籍で、
一般、要求分析、設計、コーディング、テスティング、
管理、製品保証、進化の各分野から選りすぐりの原理を紹介していく。
とりわけ以下のような原理が私的には頷けました。

・文書のない設計は設計とは言わない
・特殊なケースをあまりたくさん作るな
・人のことを第一に考えてプログラムを書け
・すぐコーディングを始めるな
・壊れていないのはら直すな
・保守は開発よりも多くのエラーを作り込む
・この変更は簡単だという信念が正しくない変更をもたらすことが多い

会社の机に置いておきたい一冊です。

[鷹下村塾さんの感想 · 2009年12月28日]

この本によると、最適な工期は「投入人月の立方根の2.4倍」らしい

[たかさんの感想 · 2006年8月7日]

現場の人間としては201の鉄則として網羅された各解説はある意味、身の回りに起きているだけに面白くも身につまされながら読める

[せーかくさんの感想 · 2004年11月16日]

これを買ったのは、多分7から8年前。まわりに（当時も今もソフトウェア開発の現場にいますが）すごく薦められて買いました。内容が、端的であるうえにかなり確信をついている内容が多く今でもこの本を読むとうなることがあります。