ソフトウエア開発 55の真実と10のウソ（Robert L. Glass）

書籍情報

• 著者:Robert L. Glass（著）, 山浦恒央(訳)
• 発行日:2004-04-12
• ISBN:9784822281908

書籍目次

• まえがき
• 著者の追記
• 謝辞
• 第I部 55の真実
  • 第1章 プロジェクト管理
    • [人員]
    • 真実1:ソフトウエアの開発で最も重要なことは、プログラマが使うツールや技法ではなく、プログラマ自身の質である。
    • 真実2:プログラマ個人を分析した研究によると、最も優秀なプログラマは最悪に比べ、28倍優れている。給与が能力を反映していないとすると、優秀なプログラマは、最高の掘り出し物と言える。
    • 真実3:遅れているプロジェクトに人を追加すると、もっと遅れる。
    • 真実4:作業する環境は、プログラムの生産性や品質にきわめて大きく影響する。
    • [ツールと技法]
    • 真実5:開発ツールの大袈裟な宣伝文句は、ソフトウエアの開発プロジェクトにとって、たちの悪い伝染病のようなものだ。ツールや技法の大部分は、生産性や品質を5～35％程度、改善するにすぎないが、「革命的な効果」がると吹聴する場合がほとんどである。
    • 真実6:新しいツールや技法を学習すると、最初は生産性や品質が下がる。実際に効果が出るのは、ツールや技法が完全に身についてからだ。従って、ツールや技法の導入が効果的なのは、(a) 効果が現実的である、(b) 気長に効果が出るのを待てる場合に限る。
    • 真実7:ソフトウエア技術者は、ツールの話が大好きである。いくつもツールを買い、評価もするが、開発で実際に使う人は、ほとんどいない。
    • [見積もり]
    • 真実8:プロジェクトが大失敗する原因には二つある。一つは見積もりミスだ（もう一つは真実23を参照）
    • 真実9:ソフトウエア開発の見積もりは、プロジェクトの開発時に実施する場合が非常に多い。これだと、要求定義が固まる前に見積もることになり、どんな問題がどこにあるかを理解する以前に予測するので、意味がない。従って、見積もり時期として適切ではない。
    • 真実10:見積もりは、上層部かマーケティングが実施する場合がほとんどだ。実際にプログラムを開発したり、開発プロジェクトの直接のマネジャが見積もることはない。結局、適切な人が見積もっていないのだ。
    • 真実11:プロジェクトが進むに従って、見積もりを調整することは、まずない。従って、不適切な時期に不適切な人間が実施した見積もりをが修正することは、ほとんどない。
    • 真実12:見積もり精度がいい加減だと、実際のプロジェクトが見積もり通りに進まなくても、まったく気にならないはずだが、現実には、みんな気にする。
    • 真実13:管理者とプログラマの間には、大きな断絶がある。ある研究によると、重大な見積もりミスを起こし、管理者は大失敗プロジェクトと考えているのに、開発担当のエンジニアは、これまで従事した中で、最も成功したプロジェクトと考えているものがあったらしい。
    • 真実14:実現可能性の分析（feasibility study）の結果は、いつもYESである。
    • [再利用]
    • 真実15:小規模な再利用（例えば、ライブラリやサブルーチン）は、50年前に始まり、既に解決済みの問題である。
    • 真実16:大規模な再利用（コンポーネント単位）は、誰もがその重要性を認識し、なくてはならないと感じているが、今なお未解決である。
    • 真実17:大規模な再利用は、類似システム間ではうまくいく可能性が高い。応用分野の類似性に依存するため、大規模流用の適用範囲は狭くなる。
    • 真実18:再利用には、二つの「3の法則」がある。（a）再利用可能なコンポーネントを作るのは、単一のプログラムで使うモジュールを開発する場合に比べ、3倍難しい。（b）再利用可能なコンポーネントは、ライブラリに取り込む前に、3つの異なるプログラムでテストする必要がある。
    • 真実19:プログラムを再利用する場合、流用母体の変更は、バグの原因になる。20～25％も変更する必要があるなら、最初から作ったほうが、効率が上がるし、品質もよい。
    • 真実20:デザインパターン方式の再利用は、ソースコードの再利用における問題を解決する一手段である。
    • [複雑性]
    • 真実21:対象となる問題の複雑度が25％増加するたびに、ソフトウエアによる解法の複雑度は、100％上昇する。これは、改善しなければならない数字ではなく（複雑性を下げるのは非常に望ましいが）、こうなるのが普通。
    • 真実22:ソフトウエアの開発は、80％が知的な作業である。また、かなりの部分が、創造的な仕事であり、事務作業はほとんどない。
  • 第2章 ソフトウエア・ライフサイクル
    • [要求仕様]
    • 真実23:プロジェクトが途中打ち切りになる二つの原因のうち、一つは、仕様を確定できないことだ（もう一つは、真実8を参照）。
    • 真実24:仕様不良の修正コストは、製品出荷後はもっとも高いが、開発の初期であればもっとも安い。
    • 真実25:仕様の抜けは、仕様関係の不良の中で修正がもっとも難しい。
    • [設計]
    • 真実26:仕様定義フェーズから設計フェーズに移る時、膨大な数の「派生仕様（derived requirements:仕様を具体的な設計方式にブレイクダウンする場合、設計方式に対する要求仕様）」が生じる。これは、問題解決プロセスが複雑なために発生する もので、この設計仕様の量は、元の仕様の50倍になることもある。
    • 真実27:ソフトウエアの開発において、ベストの解法が一つしかないことは、まずありえない。
    • 真実28:ソフトウエアの設計は、複雑で反復が必要なプロセスである。従って、最初に考えついた設計方式が間違っている可能性は高く、最適解ではない。
    • [コーディング]
    • 真実29:問題を「基本モジュール」レベルまで詳細化できた時点で、設計フェーズからコーディング・フェーズへ移る。コーディングをする人と設計者が同一人物でない場合、「基本モジュール」の認識にズレが生じ、トラブルの元となる。
    • 真実30:COBOLは非常に悪い言語だ。しかし他の（ビジネス・データ処理用）言語は、もっとひどい。
    • [不良除去]
    • 真実31:ソフトウエア開発のライフサイクルで、不良除去に最も時間がかかる。
    • [テスト]
    • 真実32:十分テストをしたとプログラマが自信を持つソフトウエアでも、全パスの55～60％程度しか網羅していない。パス・カバレッジ・アナライザのような自動化ツールを使うと、網羅率が85～90％に上がる。しかし、100％のパスを網羅するのは不可能だ。
    • 真実33:100％のテスト網羅が可能でも、完全テストとはいえない。バグの約35％は、パスの抜けが原因であり、40％はパスの特定の組み合わせを実行したときに起きる。このバグは、パスを100％カバーしても検出できない。
    • 真実34:ツールを使わないと、不良除去はうまくいかない。デバッガはみんな使うが、カバレージ・アナライザはほとんど使わない。
    • 真実35:テストの自動化は、非常に難しい。テスト・プロセスの中には、自動でできるし、自動化しなければならないものもあるが、大部分は自動化が不可能な作業である。
    • 真実36:プログラマがソースコードの中に組み込むデバッグ用の命令語(コンパイラのパラメータにより、オブジェクト・コードに吐き出すかどうかを制御できることが望ましい)は、テスト・ツールを補って余りある。
    • [レビューとインスペクション]
    • 真実37:インスペクションを厳しく実施すると、プログラムをマシンで実行する前に、90％ものバグを叩き出せる。
    • 真実38:厳密なインスペクションは、大きな効果を上げるが、テストの代わりにはならない。
    • 真実39:出荷後レビュー（遡及的レビュー[retrospectives]と呼ぶ場合もある）は、顧客満足度の測定、および、プロセス改善の両方の観点から重要だが、実施している企業はほとんどない。
    • 真実40:ピア・レビューには、技術的問題と社会学的問題がある。レビュー相手のことを十分考慮しないと悲惨な結果になる。
    • [保守]
    • 真実41:保守には、ソフトウエアのコストの40～80％(平均60％)がかかる。従って、ソフトウエア・ライフサイクルの最重要フェーズである。
    • 真実42:保守の60％は機能拡張であり、バグ修正は17％にすぎない。このため、ソフトウエアの保守は、不良修正ではなく、古いソフトウエアに新しい機能を追加する作業である。
    • 真実43:保守は解法であり、問題ではない。
    • 真実44:ソフトウエアの開発作業と保守作業を分析すると、大部分は共通している。例外は、保守の場合、｢既存プログラムの理解｣が新たに加わることである。この作業には、保守の全作業時間の約30％が必要で、保守の中心となる作業だ。従って、開発に比べると、保守は難しい。
    • 真実45:優れたソフトウエア・エンジニアリングに沿ってプログラムを開発すると、保守は減らず、かえって増える。
  • 第3章 品質
    • [品質]
    • 真実46:品質とは、属性を集めたものである。
    • 真実47:ソフトウエアの品質とは、ユーザを満足させることではない。仕様を満足させることでもなければ、コストとスケジュールを満足させることでも、信頼性でもない。
    • [信頼性]
    • 真実48:誰もが共通に作り込む種類のバグが存在する。
    • 真実49:バグは固まって存在する。
    • 真実50:不良除去に、唯一無二のベストな方法はない。
    • 真実51:プログラムの中の残存バグは、簡単には摘出できない。従って不良除去では、重大なバグを最少に抑えたり、なくすことを目標とすべきである。
    • [効率]
    • 真実52:プログラムの処理効率には、よいコーディングよりも、よい設計が大きく影響する。
    • 法則53:高級言語(HOL:High Order Language)は、適切な最適化コンパイラがあれば、アセンブラ言語で記述した場合の90％の効率で処理できる。最新の複雑なハードウェアを使えば、アセンブラのプログラムより速くなる。
    • 法則54:プログラムの大きさと処理時間には、トレードオフがある。片方をよくすると、他方が悪くなる。
  • 第4章 研究
    • 真実55:大部分の研究者は、技法を「分析」するのではなく、「擁護」する。その結果、(a) 研究対象の技法は、実際には、自分が信じるほどの効果はなく、(b) 技法の本当の価値を検証する評価研究が不足している。
• 第II部 5+5のウソ
  • 第5章 管理について
    • ウソ1:計測できないものは管理できない。
    • ウソ2:ソフトウエア製品の品質は管理できる。
    • [人員]
    • ウソ3:プログラミングからエゴを取ることは可能だし、そうでなければならない。
    • [ツールと技法]
    • ウソ4:ツールや技法は、どんな状況でも適用できる。
    • ウソ5:ソフトウエアには、もっと開発方法論が必要である。
    • [見積もり]
    • ウソ6:コストやスケジュールを予測する場合、まずソースコードの行数を見積もる。
  • 第6章 ライフサイクル
    • [テスト]
    • ウソ7:ランダム・テストにより、テストを最適化できる。
    • [レビュー]
    • ウソ8:「多くの目にさらされれば、バグは枯れる」
    • [保守]
    • ウソ9:将来の保守に要するコストや、いつ現在のソフトウエアを入れ替えるかの決定は、過去のコストのデータを見ればわかる。
  • 第7章 教育
    • ウソ10:プログラムをどう書くかを見せれば、プログラムの方法を教えられる。
• 結論
• 著者プロフィール
• 訳者あとがき
• 索引
• 訳者紹介