「ソフトウェアインスペクション」 とその関連商品

インスペクションとは上流工程からの成果物(機能仕様書、テスト仕様書など）に対して一定の判定基準を元に内容を精査するプロセスのことです。
ソフトウェア開発プロセスの品質改善とプロセス自体の改善を目指したものであり、そのために本書ではデータの収集と分析を非常に重んじています。
どちらかといえば形式的なところを重んじていますが、それによる問題も同時に取り上げています。
正直な感想としては、内容に重量級のボリュームがあり、すぐに実践できるかというと、「それは無理」と感じます。
何度か実経験を踏んだ上で、さらに何をどうしたらよいか考える再に、非常に示唆に富んだ提言がかかれていると思いました。
実際の成功例・失敗例などもリアルに書かれているので、インスペクションは成功すれば成果はすごいが、そんなに容易でもないということを分からせてくれます。
分量的な面から言っても、あまりイントロダクションとしてはふさわしくないです。
インスペクション初心者には Karl E. Wiegers の「ピアレビュー」と併読することを勧めます。
「ピアレビュー」は大変良い書物ですし、内容の割には薄い本なので初心者にはもってこいなのです。
その上で本書を読むことにより、インスペクションを実施していくための理論的基礎の強化ができると思います。 (taka-m/2005-11-08)

検査といわれればするのに、インスペクションといわれた途端にやる気がなくなる現場がある。なぜかはわからない。自己査定は許容水準だった。自分では、この点よりよくするつもりはありません。これ以上やると無駄が増え、改善を阻害しそうだと感じるからです。大規模組織で、大規模開発の場合と、小規模組織で、小規模開発の場合での違いがあるかどうかが課題だと考えています。

以下は自己査定の回答例です。
(1)　通常する
（２）通常する
（３）ときどき
（４）通常する
（５）ときどき
（６）ときどき
（７）通常する
（８）ときどき
（９）通常する
（１０）まったくしていない
（１１）通常する
（１２）通常する
（１３）通常する
（１４）通常する
（１５）ときどきする (kaizen/2008-07-09)

驚くことに日本のソフトウェア業界にはレビューの価値を評価できずに、省略しても構わないとする文化が少なからずともあります。本書はしつこいくらいにレビューの必要性を説き、中でもインスペクションの有効性を強調しています。
私自身、ソフトウェア業界に従事して20年近くになりますが、レビューの必要性を痛感する一方です。会社にレビュー文化をいかに根付かせるか悩んでいる方にはうってつけの書籍ではないでしょうか。私は、自分の会社でこの本を配布し、レビューをソフトウェアシステム構築の重要なタスクのひとつであるということを認識させることに成功しました。 (川久保智晴/2004-06-26)

レビューという言葉はコード・レビューの意味で使われることが多いようですが、最初の検討フェーズから各ステップでレビューを実施すれば大きな効果が得られると思います。
この本ではピアレビューをＣＭＭＩレベル３での実施アイテムとして提示していますが、企業としてのレベル３取得の動きとは関係なく実施できると思います。内容はなかなか実践的なので、読者自身が工夫することで自分のプロジェクトに応用できそうです。 (横丁のおじさん/2004-05-02)

内容は、レビュの重要性、効果が少々で、あとは、レビュを組織的に行うには？の説明です。
レビュ、インスペクション、ウォークスルーの違い、インスペクションの各種手法、インスペクションの準備、成果物、評価、陥りやすい失敗とその対策、効果を上げる方法等です。
インスペクションが中心に記述されています。ウォークスルー等については、違いが記載されている程度です。
手法そのものよりも、成果物や人の教育、体制、改善など、組織に導入するという点に重きが置かれている印象でした。
初心者にも、分かりやすく書いてありました。
また、厳密なインスペクションの実施に興味がある方には、参考になることがあると思います。 (lemonerika/2005-09-02)

ピアレビューとは「同僚による査読」であり、品質向上のためのツールのひとつ。この本はタイトル通りこの「ピアレビュー」をテーマにした1冊。その中でも「インスペクション」と呼ばれる公式レビューについての解説が厚い（第4章〜第9章）。公式レビューは、概要説明、準備、インスペクションミーティング、修正、フォローアップという5段階を踏み、モデレータや記録者、読み手という役割が必要となるが、それに見合う欠陥検出効果が見込めるという。実際には、プロジェクト計画において品質目標、規模などを考慮して公式レビューを取り入れるのかどうかを見極めることになるので、必ずしも公式レビューである必要はない。とはいえ、こういう手法を知っておくのはいいことだ。

第4章でも言及されているが、インスペクション（準備をしてミーティングによって欠陥を指摘する）がどれほどの効力があるかについては議論の余地があるようです。この本以外の書籍についてもあわせて読むことを薦めたい。たとえばソフトウェア・テストPRESS　vol.2でインスペクションについての記事が載っている。 (softest/2008-08-12)

この本はピアレビューを行う際の観点についての記載はないです。
残念。
みんなが悩んでいるところは、どうすればレビューで不具合を漏れなくガードできるかなんじゃないかな？こういった具体的なネタは会社固有のノウハウでなかなか外には出てこないのでしょうね。
プロセスについてはCMMIやPMBOK本のほうがいいかな！？ (樹/2008-10-03)

2000年までの6300件のデータをもとに、多くのグラフを用いて説明されており、非常に説得力があります。
概念的には、機能総量＝プロセス生産性×工数×開発時間で表すことができます。この関係からわかるように、工数と開発時間はトレードオフ関係にあり、開発時間を延ばせば工数が減ることになります。
従来の見積もりでは単に人月であり、開発時間を考慮していないため、正確に見積もれないことがわかります。（100人月：100人なら１ヶ月？１人なら100ヶ月？）
どんなに頑張っても（コスト・人を投入しても）これ以上早くは開発できないという最短開発期間が存在するというのも、目から鱗でした。無理ムリのスケジュールでの開発は、破綻することになります。

計測されたデータの分析結果が主になっているので、いざ実際に計測しようとすると、他の書籍などを調べる必要があるかとは思います。

5章と11章だけでも読む価値があるかと思います。 (tkcjun/2005-12-03)

ソフトウエア開発の現場では、今でもいろんな混乱がある。
■工期短縮のためには工数増が必要であるのも拘わらず、プロジェクト開始後に要件決定の遅れや納期の短縮要求をズルズルと受け入れてしまう。
■トップがその年に決めた目標(たとえば生産性向上５％)を達成するために、他の重要なメトリックスを悪化させてしまう。

この本の中では、ソフトウェア開発の分野では中核となるメトリックスは５つある（規模、工数、工期、品質、生産性）といい、６３００の実績データの分析、メトリックスの導入、注意事項について解説している。

全体を通して痛感するのは、何を測るか、それをどのようにフィードバックするか、こういうことを継続して考えていかないと５つのメトリックスを同時に改善していくことはできないということ。本書の中で引用されている、絶対温度で有名なケルビンの「計測できればコントロールできる」という言葉が強く印象に残ります。日本でも、ソフトウェア開発分野のプロセスエンジニアという職種が定着することが必要とも感じました。 (yu-ji/2006-09-13)

ソフトウェアのプロマネ本の1つです。
ソフトウェアの開発を管理する上で、気を配らなければならないことが書いてあります。作者の長いソフトウェア業界での経験が凝縮されていて、その点は参考になります。
しかし、少し内容がふるいのが気になります。1980年代の前半の話などがよく引用されて出てきます。さすがに20年前の話をされても困ります。
で、トータルすると星３つ。 (ユングベリ/2008-12-21)

著者のお二人は日立製作所で実務を経験され、保田氏は現在つくば国際大学で教べんをとり、奈良氏はソフトウェア開発のコンサルタント業をされている。

第1章ではソフトウェアの品質・品質保証について書かれており、ソフトウェア品質の考え方をモデル化した説明、ソフトウェアの4つ（あるいは5つ）の特質、欧米と日本の品質の考え方の違いなどが丁寧に解説されている。不良低減のための方針を表した図は、なるほど、と自明ではあるものの「作り込み不良低減」「不良の早期摘出」という2つのベクトルがとても印象的。

第2章では品質保証部門ではなく開発部門の視点に立ち、前述の「作り込み不良低減」の努力について解説している。DR（デザインレビュー）については問題点があげられており、限られた時間で、できるだけメンバーに多くの指摘をしてもらう、DR終了後の徹底的なフォローが必要、といった指摘があった。自身のレビューを振り返るいいネタになりそうだ。

第3章は出荷後の品質保証活動について、第4章ではいわゆる静的・動的テストに関するテスト戦略・技法などについて網羅的に解説されている。ここでは技法紹介に加えて、「評価」についても言及されている。「測る」ことの重要性を再認識させられる。

第5章、第6章では人材育成・求められる品質保証というテーマが、より広域的な視野で語られ、本書は締めくくられている。

品質を「作る」「測る」「管理する」すべてのエンジニアにとって良い本。
(softest/2008-07-29)

日本のシステム開発の現場では、「ゼロからの新規開発」より、「動いているシステムの変更・機能追加」の仕事が多いはずです。

その一方で、従来よく知られている開発方法論・開発プロセス論は、新規開発に偏った構成になっています。また、新入社員などがシステム開発を学ぶ場合を見ても、新規開発のための方法論、プロセスが学習されていました。

本書は、こうした「仕事の現状」と「開発方法論」との間の乖離を埋める目的で、変更・機能追加を扱う「派生開発」のためのプロセス、方法論を論じています。

派生開発で陥りやすい失敗が示された後、派生開発の特徴が論じられます。これらは、著者の現場での豊富な経験に基づいて書かれており、真実味があります。

その上で派生開発の方法論（プロセスや成果物）が述べられています。他の方法論・プロセス論と同様、各現場でカスタマイズが必要なのは言うまでもありません。ですが、一般原則として述べられる内容に、私は「なるほど！」と感じることが多かったですね。

「１，２ヶ月の短納期で、機能の変更・削除・追加を行うミニプロジェクト」に追われている、多くのエンジニアにお勧めします。
(izagon/2008-01-21)

非常に具体的かつ実際的な内容。
組込系のシステム開発の例が多いが、あらゆるシステム開発プロジェクトに応用できる内容だと思う。

手戻りが多く予定の工数を大幅に超過してしまうのも、品質が悪く結局使えないシステムになってしまうのも、多くのSEが日々の無駄な作業に追われて疲弊しスキルアップに励む余地が無くなってしまうのも、極論すれば全て「要求仕様書」の“書き方”の拙さに起因していることが反論の余地の無いほどズバリと指摘されている。

その上で、具体的にどこをどのように改善すれば良いのか、非常に具体的な仕方で示されているので思わず「ああ、なるほど！」とうなずいてしまう。

しかも、決して筆者の独りよがりな方法論を押し付けるというのではなく、コンサルティングの現場での多くの経験を通し、実際に適用するに当たってどこが難しいのか、どこから取
掛かれば良いかなども指摘されていて、よしがんばろう！という気持ちにさせてくれる。

これまでいくつか「派生開発」プロジェクトに関わったが、その失敗や困難の背景に本書で指摘されている多くの原因があったと気づかされた。

筆者の語り口について“説明が冗長で分かりにくい”という印象を持つ方もいらっしゃるようだが、問題の本質をしっかりと突いているので、ポイントを抑えながら読めば苦にはならないと思う。 (p!chan-papa/2008-03-08)

ソフトウェア品質を管理という視点だけでなく、品質そのものの視点を提供している点において、管理指向から脱却する一歩になるかもしれない。
測定、見直し、試験、分析・評価、運用・保守という基本的な事項を体系的に記述している。
どういう作り方をするのがよいか、よい設計のソフトウェアを作るにはどうしたらいいか、品質の肝は設計（デザイン）だと思う。
プログラマに設計したものをコーディングするコーダという役割を与えているか、設計を試行錯誤するためにプログラムを書いている人かの立場の違いがあるかもしれない。

著者、レビュアーは、錚々たる方々なので、安心してみることができる。
参考文献には、プログラマが書いた本、プログラマの知見を整理したものもあると思われるので、プログラムを組んでいる人達がこの本をうまく利用して、プログラマにとってのソフトウェア品質知識とは何かを、それぞれが構築することが重要だと思う。

例えば、Safetyは、ISO/IEC Directivesに安全に関する資料があり、ISO/IEC Guide 51,50 で基本的な記述があり、ISO 12100に機械に関する安全設計に関する知見がある。これらを抜きに安全に関する記述するとよいだろう。

プログラムは設計であるという基本に帰って、ハードウェアの設計に対応したソフトウェアの設計という視点を強化するきっかけを読者が掴んで、それぞれに必要な体系を持つとよいのではないだろうか。

ps.
日経品質管理文献賞を受賞したとのことです。おめでとうございます。 (kaizen/2008-02-16)

学校でも、社会人になっても、ソフトウェアの品質について詳しく教わる機会はとても少ない。テストをすれば品質が上がるの？ソフトウェアなんて簡単に変更できるから大丈夫。とりあえず動くものを作れ！など、わけのわからないプレッシャーだけでモノを作ることが多い。その中、ソフトウェアの品質という点に焦点を当てた本がこれだ。辞書として、教科書として、全体を知りたい時にひいてみてもいいし、頭から読んでみるのもいいだろう。（私は読んだ）
体系的にまとまった、他に類を見ない本だと思う。願わくば、ソフトウェアの作り方にも言及するとされている第2版が速く出ることを望みたい。そのときは、もうすこし記述を詳しく書いて欲しいです。
(レビュー人/2007-12-19)

本書はソフトウェア品質に関する知識を1冊にまとめたものです。本書ではソフトウェア品質に関する知識領域を「ソフトウェア品質の基本概念」「ソフトウェア品質マネジメント」「ソフトウェア品質技術」の3つのカテゴリに大別して解説しています。本書の特徴は網羅している範囲が広い点で、ソフトウェア品質に関する知識は一通り押えています。その代り個別の記述内容はアッサリしていて、より詳しい知識を得るためにはより専門的な著作を調べる必要があります。
ソフトウェア品質に関する辞書的な使い方をするには有益な著作といえましょう。
(もりつち/2008-08-17)

ソフトウェアのテストに興味がある方、実際にソフトウェアをテストされている方にお薦めします。

このシリーズは大好きで、毎回発売されるのを楽しみにしています。

今回の特集は、見積もり、日本のテスト力、探索的テストでした。各記事は、現役のエンジニアが執筆しており、説得力がありました。また、最近の動向も分かりました。
本書はマガジンですので、もちろんすべての内容を把握できる訳ではありません。しかし、概要を把握した上で、興味を持った内容を勉強する足がかりになると思います。

個人的に、今回もっとも参考になったのは、「ビジネス ロジックに対する単体テストのすすめ」という、たった 4 ページの記事でした。ソース コード (Java です)をダウンロードして試してみたのですが、使えそうなので実際のプロジェクトで活用しようと思っています。
こういった Tips を見つけると、ちょっと嬉しくなります。 (みっちぃ/2008-12-01)