リスト：要求エンジニアリング を表示しています。（全 20 件）

本書はポイントが多すぎるので、何が重要なのか初心者にはとてもわかりにくいです。（黒田博司 / 2005-07-15）

この本は非常に多くのチェックポイントが列挙されているが、このチェックポイントの中には、「システムを構築する上で決めておきたい」が、現実的に適用することが難しいものが多い。
例えば、「どのユーザーの要求が最優先で扱われるべきですか」という質問をユーザーにせよとあるが、これをすらすらユーザーが答えられる場合は少ないと思われる。また、この序列を絶対化してしまうと、顧客のニーズを効率よく収集する妨げにもなりかねず、要件定義の本質から外れてしまう可能性もある。これは同程度の相反する要求を絞り込む場合に、有効なアプローチと言えるかもしれないし、あるいはシステムによっては、そうでもないかもしれない。
つまり、この本の冒頭にも書かれていることだが、このチェックポイントは絶対化＝一人歩きをしてはならないということだ。どれを取捨選択するかはシステム固有の問題であり、そこが要求定義担当者の腕の見せ所である。
結局のところ、要求定義はシステムによってそれぞれ異なるものであり、標準化できるような甘いものではないということだ。要求定義のアプローチは多様性にみちていて、共通して言えるのはその目的だけだと言っていいと思う。この本のチェックポイントの多さはその多様性を暗に示している。（yuun / 2008-05-03）

第1部の要求定義オリエンテーションはなるほどと思わせる記述が見られ、
実務の参考となります。
しかし、第2部のチェックリストが数が多過ぎ、かつ箇条書きの形で続き、
読み進めるのに若干苦労します。
著者の考えに賛同しかねる記述や技術的な間違いも多々あります。
また、誤字もあり、「従業員」の「したが業員」には苦笑するしかありません。
ワインバーグの本などを挙げた最後の参考文献リストの書籍を読む方が
よいかもしれません。
マネジメントや技術的な知識や経験が著者には圧倒的に足りない印象を
受けました。（mktarkn / 2007-02-10）

要求・要件定義または顧客と仕様検討の経験がある場合、共感を得られる箇所がいくつかある。一問一答形式ほど簡略ではないが、ヒアリング例題に対して、その意図と想定回答が示されており、読みやすい。
各所で解説される重要ポイントが重複しているため冗長に感じるが、いわゆる例題＆解説・回答形式なのでやむを得ないと思うし、それで良いと思う。
読み物としては５〜６時間で読み終わるが、いざ本番に挑むときのチェックリストとしても使えるので再利用価値がある。
私の場合は、本番後（顧客とのミーティング後）に振り返り、漏れがなかったかを再確認するためのチェックリストとして利用するつもり。
目次がチェックリストそのものになっているので、使い勝手をよく考えられた本であると感心する。
ただし427項目もあるので、実際には案件タイプに応じて集約したチェックリストを作成し、適用してみようと思う。
（nobuakim / 2008-04-16）

要求管理に関しては、多くが、抽象的な、実践とは離れた内容の本が多いと感じていました。
また、要求管理の手法は、明記されていても、対人作業として、実際にどうすればよいのか、と言うことについて、書かれている本はあまりありませんでした。
要求管理は、プログラミングと違い、どうしても、泥臭い人間同士の感情や思考を読み取る必要があります。
その感情の読み取り方、注意の仕方を、わかりやすく文章に落とし込んでいます。
いくらフォーマットで規定しても、目の付け方や見方によって、あっさり、「要求漏れ」となってしまいます。
そのプログラミングと違う、モノの見方をわかりやすく書いています。
要求管理者、または、システムを発注する方も読んでみて下さい。
双方とも、要求の漏れが、現状より減ると思います。（竹田翔丸 / 2005-01-27）

　どうも、IT関連の職種の方には、冗長であるとか、結論が最後に書いてあるとか、評判が良くないようですが、私は、記述も明解でかなりお勧めの本だと思います。筆者の経験した例も、他人ごととは思えないほど、身につまされます。
　この本に従い、全ての要求にその理由または意図を併記して一覧表にまとめたところ、一発で思ったとおりのシステムが出来上がってきて、とてもうれしく思いました。システムを「作る人」と「使う人」との間にある、埋め難い溝を少しでも埋めるための方法が書いてある貴重な本です。ユーザー側の方におすすめします。（アマゾン太郎 / 2006-10-30）

実は読みづらかった本。が、読み返してみると"仕様化"を横断する筆者独自の見解が面白い。
Specify（合意,特定、という意味で使われている）を中心に据えた仕様化の中身には、
さまざまなプロセス･エンジニアリングを経験した上でしか表現できない内容が。
ただ、Excel表記については、殊更それを強調する必要があるか？（個人的に、SEの現場で
Word型、というのは陳腐化して久しいと思うので）、と言えば、ううむ？、という印象も。。
WBSや、各メーカ独自のプロジェクト管理技法（契約フェーズ含む）、開発管理技法をある程度知ってから読んだほうが
面白さがわかる本、と思いました。
Agile他を一蹴する勇気（モチロン理由があります。）にも、1票！なので☆4つです。
はじめに→11章以降→1,3,6章･8,9章→その他、と読むとラクかもしれません。
PMBOK、CMMI、要求ワークフロー(オブジェクト指向)、ロジカル･シンキング等の知識があると
深読みできます。（keroko / 2007-10-05）

自分も仕様を作る立場ですので、非常に為になります。ソフトウェア開発がうまくいか
ないケースなど身につまされるケースもあり参考になります。
ただ、やはり文章が余りにも冗長で読みにくいです。クライアントの要求に漏れなく正
確に応える仕様書を書こうという本なのに、残念ながらこの著者は、クライアントであ
る読者の、読むという要求にあまり応えられていないってのは皮肉な話です。
（tamarl / 2006-05-05）

仕様は重要な割りに書籍が少ないので、買ってみたけど内容が冗長すぎる。いつまでたっても、自分の経験談の例がでてくる。
見た目も、中身のフォントもいいけど、オススメはあまりできない。
よっぽど顧客との相互理解に苦労したり、社内に対して要求仕様の重要さについて周知するときに苦労したのかもしれないが、書籍の全体に事例紹介するのはいきすぎ。
序盤のみそういう事例をだし、中盤〜後半は、手法のみにしぼって欲しかった。よむのがしんどくなる。内容もいいたいことはなんとなくわかるが、焦点がはっきりしないままだった（timeserver / 2006-02-11）

著者の言いたいことは「なるほど」っと思いました。
ただ書籍としてはいかがなものか？？？
記述にダブりが多いこともあり、もし第2版があるようでしたら、
この本で書かれている要求仕様の書き方にのっとり、要求仕様の
書き方のルールをまとめてもらえると非常に分かりやすく、実利用しやすいかと思いました。
すなわち、ルールを仕様として、そのルールの目的や意味を要求＋理由として、要求仕様を書いて頂きたいと。
それであれば、散文形式より、著者の提案形式の方が、はるかに見通しが優れていることも分かるし...　:-)
（しらしら / 2005-12-02）

日本のシステム開発の現場では、「ゼロからの新規開発」より、「動いているシステムの変更・機能追加」の仕事が多いはずです。
その一方で、従来よく知られている開発方法論・開発プロセス論は、新規開発に偏った構成になっています。また、新入社員などがシステム開発を学ぶ場合を見ても、新規開発のための方法論、プロセスが学習されていました。
本書は、こうした「仕事の現状」と「開発方法論」との間の乖離を埋める目的で、変更・機能追加を扱う「派生開発」のためのプロセス、方法論を論じています。
派生開発で陥りやすい失敗が示された後、派生開発の特徴が論じられます。これらは、著者の現場での豊富な経験に基づいて書かれており、真実味があります。
その上で派生開発の方法論（プロセスや成果物）が述べられています。他の方法論・プロセス論と同様、各現場でカスタマイズが必要なのは言うまでもありません。ですが、一般原則として述べられる内容に、私は「なるほど！」と感じることが多かったですね。
「１，２ヶ月の短納期で、機能の変更・削除・追加を行うミニプロジェクト」に追われている、多くのエンジニアにお勧めします。
（izagon / 2008-01-21）

非常に具体的かつ実際的な内容。
組込系のシステム開発の例が多いが、あらゆるシステム開発プロジェクトに応用できる内容だと思う。
手戻りが多く予定の工数を大幅に超過してしまうのも、品質が悪く結局使えないシステムになってしまうのも、多くのSEが日々の無駄な作業に追われて疲弊しスキルアップに励む余地が無くなってしまうのも、極論すれば全て「要求仕様書」の“書き方”の拙さに起因していることが反論の余地の無いほどズバリと指摘されている。
その上で、具体的にどこをどのように改善すれば良いのか、非常に具体的な仕方で示されているので思わず「ああ、なるほど！」とうなずいてしまう。
しかも、決して筆者の独りよがりな方法論を押し付けるというのではなく、コンサルティングの現場での多くの経験を通し、実際に適用するに当たってどこが難しいのか、どこから取
掛かれば良いかなども指摘されていて、よしがんばろう！という気持ちにさせてくれる。
これまでいくつか「派生開発」プロジェクトに関わったが、その失敗や困難の背景に本書で指摘されている多くの原因があったと気づかされた。
筆者の語り口について“説明が冗長で分かりにくい”という印象を持つ方もいらっしゃるようだが、問題の本質をしっかりと突いているので、ポイントを抑えながら読めば苦にはならないと思う。（p!chan-papa / 2008-03-08）

「レガシーコード改善ガイド」の時と同じく、日々の保守開発業務を改善したいと思い、この本を手に取りました。
「レガシーコード改善ガイド」は「オブジェクト指向 + 自動化テスト」が基本なので若干理想論っぽいところがありますが、この本はもっと実践的というか、「現場によくある風景」を強く反映している点が評価できると思います。
本の冒頭に書かれていた、
・現場の大半は派生開発(保守開発)である。新規開発なんて滅多にない。
・ところが世の中に出回っている有名な開発プロセスはほとんどが新規開発をターゲットとしている。
という記述にも「まさにその通り！」といった感じで大きく頷いてしまいました。
さて、筆者の提唱する派生開発のためのXDDPというプロセスですが、私なりにまとめてみると以下のようになります。
・要求(顧客の意図や目的)と仕様(要求を実現するための方法、機能)を明確に分ける。
・要求/仕様(What)と変更箇所(Where)、変更方法(How)をそれぞれ文書化する。
・文書は基本的に自然言語で書く。ソースコードを貼り付けて説明するのはNG。(影響範囲をレビューする際に視野が狭くなるため)
・文書を他の開発メンバーとレビューし、認識ミスや変更箇所のモレ、重複、デグレードの危険性等がないか確認する。
・Howの文書にしたがってソースを変更する。
・Howの文書にしたがってソースが変更されていることを他のメンバーが確認する。
・What/Where/Howの文書の内容を必要に応じて公式文書(新規開発時から存在する機能仕様書等)に更新する。
いくつかは新しい発見がありましたが、基本的な流れは私も実際に実践している方法に近かったです。(「ここだ！と思った箇所をすぐ修正」はやっぱり危険ですよね)
とはいえ、本の中では作業フローや成果物を詳しく説明してあるので、この本の内容をベースに社内の業務プロセスを改善していけそうだと感じました。
ちなみにこの本ではほとんど触れられていませんが、私の場合、業務において以下のような点で苦労することもよくあります。
・前回の開発からかなり時間が経過しているため、開発環境やテスト環境(テストデータの用意を含む)が再現できない。
・デグレードしていないことを証明するためのテストケースが分からない。(現行バージョンの仕様が不明確)
この部分についても何かアイデアがあればさらに嬉しかったです。
本の内容自体は非常に実用的だと思うので星5つですが、最後に少し気になった点を挙げておきます。
・あちこちで「USDM」という筆者の提唱している要求仕様化技法の話が出てくる。しかし、この手法はポピュラーなものとはいえず、別途筆者の本を購入しないと確認できない。簡単にでも説明してほしかった。(「これは商売か？」と勘ぐってしまった)
・文章が若干まわりくどい。似たような話が何度も出てくる。もっと内容を整理して再構成すれば短時間で読めるのに、と思った。
・本のレイアウト(見た目)が若干うるさい。ページ中の余白をもっと増やしたり、変な装飾(?)をもっと減らせばすっきりして読みやすいのに、と思った。（伊藤淳一 / 2009-11-24）

　筆者の カール・Ｅ・ウィーガーズ (Karl E. Wiegers) 博士 はEastman Kodak社で写真技術に関する研究やソフトウェア開発に18年間かかわり，現在は， Process Impact 社 を主宰して，ソフトウェア開発に関するコンサルテーション，講演，執筆などを行っている．
　本書は，1996年に出版され，ソフトウェア開発者向けの専門雑誌 Software Development Magazine 誌 の Productivity Award を受賞した話題作である．1996年の出版と聞くと内容が古いという印象があるかもしらないが，決してそんなことはない．流行の技術には殆ど左右されない本質的な内容である．
　私自身の経験では，この手の本では，「80%以上賛成」できるものは非常に少ないが，この本書は，その少ない例の一つだと言える．
　目新しい技術や，魔法のような手法ではなく，確実に効果があると知られているものについて，判り易い文章と豊富な参考資料とともに，うまくまとめている．
　原題は「Creating a Software Engineering Culture」であり，ソフトウェア工学のお作法を，単に技術としてではなく，文化ととらえている点が，本書と他のソフトウェア工学の本との大きな違いである．さらに，品質と，継続的な学習を重視している点が，とても良い．
　プロとしてソフトウェア開発に関わるすべての人，これからソフトウェアの道を歩もうとする人に，強くお勧めする．ソフトウェア開発技術者必読の一冊．（Dr. Jason / 2005-10-01）

物騒なタイトルを書いてしまったが、各章の最後に「文化を生かすもの」と「文化を殺すもの」の項目が記述してある。特に殺すものを読むと、自分の今までの経験の中でいくつかは当てはまるものを発見し苦笑いする人も多いのではないだろうか？そうした目でもう一度本文を読み直すと理解が深まると思う。
また、やはり各章末の「参考文献」と「補足資料」も役に立つ（日本語訳のない文献が多いのが残念だが、この書についている数行のコメントでもかなり雰囲気はつかめる）（キミノリ / 2006-03-23）

　営業の生産性を高め、人材育成をし、成果を上げるためには、
精神論だけでは十分ではなく（精神論も重要であるが）、営業
プロセスを確立し、型を作ることがまず必要であると思う。
　本書は、がむしゃらに経験をつんていろいろなことを経験した
あと、知識を整理し、営業活動をプロセス分解するというレベル
にあがる際に参考になる。理論展開が明快で、しっかりしており、
営業を科学するさいのお手本として使えるレベルの内容だと思う。
　（ny / 2004-12-10）

　日本の生産の現場の効率化、生産性向上のレベルは相当進んで
いる。一方、いわゆるホワイトカラーの生産性は国際的に見ても
受け入れがたいほど未開拓な状況らしい。
　営業の現場の生産性を挙げるために、精神論だけでは限界がある。
セールスプロセスを定義し、管理し、組織的な対応をするという
ことがおそらく唯一の正攻法だと思う。
　ここで問題なのが、ではセールスプロセスって具体的に何？
という問題。本書は、この問いにかなり詳細に答えている。
さらに、ウェブサイトからダウンロードできるワークシートは
細かすぎて作成できないと思うかもしれないが、これも机上の
空論ではないよく考えられたシートであることがわかる。
　アメリカと違って、日本の「現場」はそこそこレベルが高い
ので、マニュアル文化になじまないという面があるが、一度こういった
セールスプロセスのマニュアルを試してみてはいかがであろう。
「急がば回れ」だということが理解できるように思う。（ny / 2004-12-14）

　本書ではソリューション営業に必要な情報収集からプレゼンテーションまでの戦術を詳細に解説しています。そして、ここでのポイントは顧客を神様にしないで販売する戦術です。この戦術には買い手と売り手の上下関係はありません。顧客の機嫌をとるような行為も否定しています。
　この戦術が日本の文化に受け入れられるかどうか判りませんが、理屈は通っています。買い手側が支払う対価以上のものを売り手側が供給することによって、買い手と売り手の上下関係は逆転するとう理論です。自分が販売する商品（提案）に対価以上の価値があれば、下手に出る必要はないということです。
　勿論、営業は売ることが先決です。売れるのであれば顧客を神様にもします。しかし、この状態には限界があります。真のパートナーには、なれないでしょう。
　この強気の戦術は幾つかのリスクも持ち合わせていますが、強固なパートナーの関係を構築していく上で有用な戦術だと思います。（イッパン人 / 2006-01-29）

顧客と対等の関係を築く営業法について、
理論的に記されています。
初回訪問から、交渉術、クレーム処理まで
提案営業のプロセスを
解説してあり、
役に立ちます。
特に提案するための情報収集の項は
一読の価値ありです。（かけふ / 2005-09-19）

最近法人営業に配属になったものの、自分は元々ベタベタした精神論が苦手なタイプで、どのように営業スタイルを作ればいいのか日々違和感を持ちながら仕事をしている状況が続いていた。
こうしたなかで本書を手にして、ある意味本当に「救われた」気がした、というのが第一の印象である。
本書では従来型の「精神論型営業」を切り捨て、分析に基づいたビジネスパートナーとしての関係性を構築する「ロジック型」の営業を勧める。これが自分には合った。
もちろん、本書で述べられている問題解決や顧客分析、ミーティングの構造化、win-win な関係構築などは他のところでも充分言われていることだし、ビジネスを勉強している人にとってはある意味「聞き飽きた」言葉であることも事実だろう。
しかし、これがこと「営業」ということになると、案外「営業という仕事の特殊性」という考え方に阻まれて実際の業務には充分落とし込まれていないのが現実ではないだろうか。
本書では単に上記の抽象的な概念だけを滔々と述べるのではなく、日々の業務にどうやって落とし込んで実行すればよいかを客観的かつ簡潔に述べてあるので、非常に分かりやすく、腑に落ちるものとなっている。
私はこの本を読んでから、毎日の仕事に取り組むスタンスそのものが変わりました。
従来の「精神論型営業」に違和感を持っている人や、これから営業（特に法人）を始める人に強くオススメします。（tendawn / 2005-08-29）

著者の豊富なコンサルタント経験、ビジネススクール講師としての過去のキャリアが凝縮した、
ビジネスパーソンのためのコミュニケーション論の集大成とも言える本である。
かつて花盛りだったロジカルシンキングの限界は、インタラクティブ性の弱さにあり、
実はインプットされたものをどう組み立てるかが重要であったと言うところからスタートする本書は、
いわゆる一般的な論理的思考の本とは一線を画す。
すなわち、
まず相手の話を対人スキルで受け取り、
　　そこから内的な思考力で再構成して組み立て、
　　展開して相手に伝え返す・・・
本当に優れたコンサルタントが実践していることが、分かりやすく解説されている格好だ。
著者の既刊に出てくるフレームワークもアップデートされつつ最新の事例を加えている。
さらにＭＢＴＩやＮＬＰなど著者の幅広い学問への知見がふんだんに散りばめられている。
コミュニケーション能力の全てを網羅的に強化するヒントを得たい全ての人に、薦められる好著である。（いたる / 2006-12-05）

著者の思考力、対人力に関する本は、毎回多くの気づきを得ることが多いので、
今回も期待したのですが、どちらかというと、最近の著書の集大成という感じ
で、重複する部分が多く、今回は、正直それほど大きな示唆を得ることができ
ませんでした。
ただし、初めて触れる人であれば、学ぶ部分多く、間違いなくお薦めと思います。
また、著者のセミナー等開催されているようなので、参加してみたいようにも
思いました。
なお、個人的に気になったのは、自説を説くときに、それが出来ていない人を
批判・皮肉を込めて引き合いに出す部分が非常に多いこと（政治家、大企業、等々）
そこまでしなくても、著者の力があれば、十分伝えることができると思うのだが
いかがだろうか？あまりに多く、正直冷めてしまいました。（COR / 2007-01-09）

本書はここ数年で数多く出版されてきた「論理思考モノ」関連の書籍の中でも、ビジネスでの実践に十分に耐えうる良書です。ビジネスコミュニケーションの決定版だと思います。
これまで著者の本を数冊読んできましたが、それを統合し、進化させた内容です。
冒頭に「ロジカルリスニングとは、相手の話を聞きながら、相手の頭の中で組み立てられたことと意図を理解する技術である。」とあります。
よく「相手の話をよく聞きなさい」といいますが、これはとても難しく、奥深いことだと感じています。
とりわけビジネスでは、合理性だけでうまくいくことはなく、人間の持つ情理を理解することも大事です。この合理と情理は相反することが多いのですが、自分の肌で感じ、頭で考えながら、相手の真意を掴んでいくしかないと思っています。
難しいのはこうしたことをコミュニケーションが苦手な部下や後輩に指導しなければならないことです。ずっと暗黙知を形式知化できないようなもどかしさを感じていました。
本書を読んで、こうしたことにも多くのヒントが得られました。ビジネスパーソンには欠かせぬ1冊だと思います。（ミドルマネジャー / 2006-12-09）

　ロジカル・リスニングとは、人の話を単に”ロジカル”に「聞く」ことではない。
相手の話を注意深く「聴き」、それらを論理的に理解し、場面に応じた適切な言葉を選んで相手に「訊き」、効果的に対話をすすめていくことであり、ビジネスに「効く」スキルである。
　この本は、”プレゼンの技術”、”相手を説得する話し方”、といったビジネス書の中に並んでいるので、受け身的な内容なのかと思われる向きもいるかもしれないが、決してそんなことはない。本質的に相手の信頼を得て、内容の濃い対話を引き出し広げていくための、むしろ効果的な「攻め」のスキルではないかと思う。
　効果的な対話を行うための、アタマの使いドコロが満載。
　
　
（桃色鯨 / 2006-12-19）

まず疑問に思ったことは、
この本は一体誰をターゲットにして著わしているのでしょうか？
実践的な内容はどこにあるのでしょうか？
ということです。
そして、文章を読んでいて思ったことは、今まで読んだ「本」に比べて
頭の中で想像がしにくい文章の書き方です。
加えて横文字が非常に多いですが、英語が苦手な人はどのように
読解すればいいのでしょうか。知らなければ出直してこいと言わんばかりです。
このような本が理解できる人ならば、そもそもこの本を読まなくても
十分な理解力があるのではないだろうかと疑問を抱きます。
また、私が以前読んでいたクリティカルシンキング系の本には、
本のほとんどが問題を通して解答例、見抜くポイントなどを徹底的に
説明していました。しかし、この本は時々ＳＰＩで出るような
理論力系の例題をちょこちょこっと出しておしまいです。
さらに最初の100ページくらいは、どのクリティカル・ロジカル系の
本でもお目にかかるような単なる前置き的な説明で埋めています。
そして全体としても特に「へー」と思うような内容は一切ありませんでした。
これなら、もっと平易で誰でもわかる本を買ったほうが勉強になると思います。
（Maril / 2008-06-24）

仕事上の必要があって、ファシリテーションに関する書籍を漁ったなかの１冊。
著者の堀氏は日本ファシリテーション協会の会長で、著作も多い。
本書は、ファシリテーションの個別スキルであるファシリテーション・グラフィック、
すなわち「板書」について解説したものである。
会議で板書をするのはいちばん下っ端の若い人ということが多いが、
実はそれは大変な間違いで、板書をする人こそが会議において最も影響力を持ちうる、
と本書はいう。
なぜなら、板書をする人が個々の意見をどのように要約するか、整理するかで、
議論の組み立てを舵取りできるから(p2)である。
従って「板書」はファシリテータの最重要スキルのひとつということになるのだが、
実際にはリアルタイムで進行する議論を構造化したりグループ化したりするのは
容易なことではない。
本書では、「朝まで生テレビ！」を聴きながら板書する、という訓練方法を紹介しているが、
想像するだけでへこたれそうである。
ともあれ、これまで板書を会議スキルとして正面から扱った本はなかったように思う。
書かれている内容については、さほどびっくりするようなことはないが、
きれいに板書されたカラーのサンプルは大変参考になる。
なお本書を読む前に、ファシリテーションの全体像は類書で押さえておきたい。
以下をお勧めする。
　　『ファシリテーション』山崎将志,2007,ファーストプレス
　　『今すぐできる！ファシリテーション』堀公俊,2006,PHPビジネス新書（丁三 / 2007-06-04）

議論を描くということに関して、これほどまでに丁寧で分かり易い上に
内容ギッシリの本が他にあるだろうか？と思うぐらい素晴らしい本です。
ファシリテーション・グラフィックというのは、
ホワイトボードや模造紙等に、文字や図形を使って分かり易く表現し、「議論を描く」ことを言います。
グラフィックというと、何か難しいものを想像される方が少なくないと思いますが、
決してそんなことは無く、アンダーラインや枠囲みなど、
書くことに慣れていない人でも、すぐさま使えるテクニックが沢山あります。
でも、この本で一番優れているのはテクニックの部分では無いのです。
テクニックも満載なのですが、一番優れているのは
「私も描いてみたい」
と思わせる手書きのサンプル(図)が沢山あることです。
一番大切な「やってみたい」を感じることが出来る本なんです！
まずは綺麗に描けなくても良いのです。
本書で述べられているように、
『「上手下手」よりも「描くか描かないか」の方がはるかに重要』なのです。
ですので、この本を読んで「上手く描けるか分からないけど、まず描いてみよう」
と思ってもらえる方が沢山出てきてくれると私も嬉しいです。
私も会社で実践していきます。一緒に頑張りましょう！（ノグチョ / 2007-03-01）

帯のタイトルは「議論を描けば会議が変わる！」である。
巻頭の８頁のカラーページにより各章のポイントをビジュアルで提示。
それ以降のページも２色表示で、「図・絵・写真」が豊富で紙質も良い。
文章もこなれていて非常に読みやすく、楽しく通読できました。
「ビジュアル表示のコツ」を書いた書であるから、
当たり前と言ってしまえばそれまでだが、「看板に偽りなし」といった所。
「色」の使い方について、色相環や補色などの説明はなく、
「著者の好みで言ってる？」と思われ、突っ込みたくなる部分もありますが、
それを補ってあまりある「ビジュアル化」の「コツ」「工夫」を紹介しています。
初心者は最初から読み進めることで、視覚化のコツが分かります。
上級者は「第４章」の「研究編」からの、実際のミーティングを想定して、
白紙に徐々に書き込んでいく過程を解剖した解説が参考になります。
ファシリテーター、プレゼンテーターの「虎の巻」となる１冊ですね。
ちなにに、著者お薦めの、三菱「PROCKEY」は私も愛用の１本。
本書だけでなく、このペンも、私のお薦めです。
（手帳の達人 / 2007-01-24）

ファシリテーションの中核スキルであるグラフィックスについて、網羅的に解説した本です。
議論を見えるように描き出すことで、議論を活性化し、質を高め、話し合いの成果と参加者の納得感を高めることができます。
とにかくお薦めは第４章。打ち合わせやワークショップの例をもとに、実際に議論をどのように描き出すかを詳細に説明してくれています。
どのような会議で、どこ（ノート、ホワイトボード、模造紙）に描くのか、どのような描き方をするのか、などが懇切丁寧に描き出されています。
読んでいるうちに　頭が活性化してきて、自分でも描いてみたくなる気にしてくれます。
第２章で出てくるイラストも　非常に印象的、かつ簡単に描けるもので、なかなか役立ってくれています。
まずはファシリテーションの入門書（堀氏の『問題解決ファシリテーターがお薦め）を学んだうえで、是非お読み下さい。
理屈だけでなく実践につながる書です。（plateau / 2007-04-06）

これまでホワイトボードやノートの使い方を単に
記録する」「意見をまとめる」といった言葉を羅列した使い方から
グラフィカルに表現し印象を強く、また分かりやすく会議(議論)を進める方法を解いている。
一見すると、ブレインストーミングの発展系かとも思われたが、
本書は文字の大きさや、色、図形を工夫し使用することが議論のポイントを
いかに効果的に理解させやすいかを、いろんなケーススタディを用いて解説している。
これまで議論がなぜまとまらないのか、会議をまとめるということは
多くのことをダラダラと記録するのではなく、いかに分かりやすく理解させるのか
ということが本書を読むと良く分かる。
また、上手く会議をまとめるにはファリシリテーターの役割がどれだけ重要かというのもわかる。
いろんな角度からの思考力のまとめ方など
子供の教育からいろいろなプロジェクトまで、実践的に役に立つヒントが多い実用書。（neeson / 2007-01-10）

　SEが中堅へステップアップするためには最適の本です。上流工程の整理方法について、今まで理論や方法論を解説した本を何冊も読みましたが、これだけ「現場」に近い感覚で即戦力になる本は皆無でした。作者は独自のノウハウを織り込みながらわかりやすく解説していきます。私の２０年のＳＥ経験からみてこの手法は充分納得出来るものでした。若い方だけでなく、中堅以上の方にもお奨めします。
　簡単にこの本の手法を説明します。上流工程の方法論として、処理を最初に考える方法(Process Oriented Approach:POA)と、データを主体に考える方法(Data Oriented Approach:DOA)が一般的です。この本ではDOAを主体としながらも独自の方法論をとっています。
　処理を「機能」と「業務」にわけて、業務とデータを同時に分析し、その後機能を分析するのです。新DOAと言えるかも知れません。業務はデータ・フロー・ダイヤグラム(DFD)で整理し、データはER(Entity-Relationship)図で書きます。このDFDもER図も「渡辺式」と言うべき独自の作図法です。DFDは「タイミングを表せない」という欠点をなくし、ER図は「実データ（タプル）を描けない」という欠点を完全に取り除いてあります。最後に機能分析ですが、ここでも驚くべき手法を提案することで、若手でも簡単に機能分析が出来る仕掛けを用意してあります。
　大変読みやすい本ですので、実用書と思えるかも知れませんが、バックボーンの理論もしっかりしています。著者はデータモデリングの本を既に２冊書かれた方です。この本がSEのバイブルになることで、不幸せなシステム開発が１つでも減って欲しいと思います。（hat / 2004-05-05）

上流工程には唯一無二の方法論は存在しないながらも、何らかの道しるべが欲しいという方には一読の価値はあると思う。具体的な業務フロー、データモデル等の書き方も参考になる。また、最後にまとめとしてセッションを会話ベースでシミュレーションしているのがリアルで理解を助けてくれる。自らの方法論を構築するためのベースとしての知識は網羅されている。（ / ）

非常に手堅い、堅実な本です。若いエンジニア、特に「Webアプリケーションの開発からキャリアをスタートし、基幹系業務システムの経験が薄い」エンジニアに強く勧めたいです。
著者は、業務システム（ビジネスシステム）の上流工程について、輸入された理論や知識、図法を形だけ適用するのではなく、現実の経験に照らして整理しています。
その態度は、まさに「工学的」で、非常に勉強になります。デスマーチ的な日々に埋没しがちな私は、尊敬しないではおれません。システム開発を成功させ、顧客に利益をもたらすためには、こういう工学的な態度を持っているべきだな、と。
他のレビューではあまり触れられていないようですが、本書の後半に列挙されている「上流工程で適用できるパターン」の考え方は、特筆に値すると思います。
最近では、「パターン」といえば「デザインパターン」であり、設計以降で利用されるものとしてとらえられていますが、著者は上流工程でのパターンとして、「業務フローのパターン」「データモデルのパターン」「機能モデルのパタ－ン」「サブシステム分割のパターン」の４種を挙げ、抽出を試みています。
若干、一般化が進みすぎているという感はありますが、業務に関して一般的な知識を得ることができ、とても有意義です。
あえて難点を挙げるとすれば、DFD、ERともに著者によるアレンジが加えられていることでしょうか。
アレンジ自体は、著者の優れたアイデアであり、書かれていることはよく理解できます。しかし、実務で使おうとすると、ER描画ツールが対応していないのです。また、他のエンジニアに、記法から説明しなければならないのです。この点は、やむを得ないところですが、読者の側に若干の注意が必要なところになります。
とはいえ、全般に読み応えのある、よい本です。経験則や、現場のやりかたに慣れて、より良い方法を考えるのをやめてしまいがちですが、この本はそうした惰性を断ち切るチカラになるでしょう。多くの人に読んでもらいたいと思います。（izagon / 2005-05-19）

私は、筆者が上流工程を設計されたシステムを今でも担当しています。筆者が設計されたＤＢの素晴らしさは、７年経った今でも色あせることはありません。筆者に５年ほど前に上流工程について講習をうけたことがあります。そのころ私は、ＳＥとしての経験も浅く正直筆者の話に感銘はうけましたが実践するまではいたりませんでした。それからの５年間で私自身いくつかのシステムを立ち上げましたが、その中で筆者より教わったことを断片ながら応用しシステムの立ち上げに役立てることができました。今回この本を購入し読み進んでいく中で、私が最近感じているシステム開発の難しさ、それに関する解答を見出すことができました。すばらしい本です。（kanzaburo / 2005-05-08）

今までＳＥとしての訓練を受けたこともないまま
次の開発で要件定義を書く担当になり、途方にくれつつ
参考になる本を探して、最初に見つかったのがこの本。
読んでから業務に取組み始めると・・
◆基本設計／詳細設計という言葉がプロセス、データモデル
　といった領域を無視したように語られているのがこの本を
　読んだ後だと不安
◆他の本も参考にしてますが、この本のデータ、プロセス、
　システム機能といった区分が一番しっくりいく
結局はこの本が座右の書になりそうです。（趙子竜 / 2004-01-20）

　著者の４冊目の本です。過去の本と同様に読みやすく流れるような文章ですが、今回はあえて流れを止める「練習問題」が数多く入っています。
　こういう方法論の解説本というのは、読んでいる時には理解出来たような気になりますがいざ本当に使ってみようとすると、どこから手をつけて良いかがわからない事が多いです。
　「知っている」→「理解している」→「説明出来る」→「使える」
という段階があるとすると最後のギャップは想像以上に大きいものです。その「使える」までのギャップを埋めようというチャレンジ精神あふれた、恐らく日本で初めての本です。
　世の中に方法論はたくさんありますが、完成例を公開したものは極めて少ないです。完成例が示されないなら単なる座学（理屈）でしかないかも知れません。すぐにでも実務で使えそうな４つのサンプルを解説することで、著者の三要素分析法は「実学」だと声高に主張されているように感じました。
　「練習帳」ですから、ぜひ実際に手を動かして回答を書いてみてください。回答を読んだだけでは気付かなかった疑問が色々と出てくるはずです。そうなれば読者のモデリング技術は一段上がったと言っていいでしょう。
（hat / 2006-08-28）

　業務と機能とデータそれぞれのモデリングという説明は了解できたが、業務モデルがDFD（データフローダイアグラム）によるPOA（プロセス中心アプローチ）に基づいたもの。草創期からソフトハウスで活躍した筆者ゆえ、今となってはやや手法は古いし、一般向きではないように思う。
　システム開発はプログラム開発ではなく業務開発であり、マニュアルが個別の機能を説明したものでは落第という指摘などプロとしての箴言は役には立つ。（miemie / 2008-04-16）

SEとコンサルタントだけでなく、企業側でシステム導入担当している方に、是非、読んで欲しい。
自分の知らないところで、SEとコンサルタントという「外部」の人間の間の軋轢で、自分が担当しているプロジェクトがリスクに直面する可能性があるということを知っておくだけでも、システム導入を進める上で意味がある。
さらには、この本の内容を逆手にとって、SEとコンサルタントの関係を上手にマネジメントすることで、より以上のパフォーマンスを引き出すことも。（やっさん / 2005-08-02）

今、まさにSEとコンサルタントを相手にしてプロジェクトを進めているあなた！
あなたの知らないところで、そのプロジェクトにほころびが発生しているかもしれません。まるで、ダムに開いた小さな蟻の穴の様に・・・。
情報システム開発の最前線にいるSEに向けて書かれた本のようでいて、実は顧客企業で「社運を担う情報システム開発プロジェクトを担当している方」こそ、読むべき一冊。この本を読めば「コンサルタント」にも「SE」にも振り回されずに、「自社が求める」システム開発を進められる（と思います）。
今、まさにシステム導入を検討している方、コンサルタントとSEの関係を探るリトマス試験紙として使ってみてはいかが？（akkun@東京 / 2005-08-01）

コンサルの後工程のＳＥの苦労が非常に大変だということが良くも悪くも分かる本。
”SEはITのプロなんだから、仕様の曖昧なところも上手く調整して、コンサルが
　立てた計画と予算どおりやれるように、ちゃんと考えて下さい”
というメッセージの本なので、ＳＥの人はきっと読む途中で怒り心頭になることでしょう。
読むとストレスがたまりますが、これじゃあ上手く行くはずがないということも
痛感するので、本のタイトルに偽りは無いと思います。（上流ＳＥのはしくれ / 2007-08-15）

まさに題名はその通りの世界をしめしています。すれ違うのです。
しかし、目的はひとつのはずで、いかにSEがコンサルタントと渡り合い、
折り合いを付けていくのかがじっくり書かれています。
ねばちこい文体は、実務の経験に裏打ちされた証拠ではないでしょうか。
もちろんプロジェクトの対立点はもっとたくさんあり、ユーザー、オーナー、
パッケージ屋、ハードベンダー、ネットワーク屋とたくさんの関係性の
澱があります。ひとつの対立点を解き明かす点では秀逸な本でしょう。
お勧めです。（みかんの花さくころ / 2008-12-17）

コンサルタントを理解するとしても一般論的な
話しかないようだ。コンサルに近いＳＥが
すぐに仕事の役に立つような内容を期待しても
残念ながら概略のお話しかない。（masabun / 2005-09-15）

まだまだ開発現場に
オブジェクト指向開発が浸透してるわけでもない昨今
組込み系と構造化モデリングの組み合わせは
現場に即したものではないでしょうか。
オブジェクト指向設計を学ぶ前段階としても
意義のある著作だと思う
欲をいえば
モデリングツールであるDFDとかCFDそのものを
もうちょっと突っ込んで詳しく解説してほしかった
続編を望む（あ / 2006-05-01）

うまく構造化できるということは、うまくモデルが作れたというのと同義だと思っていました。そのため、要求分析、設計、ソースコード作成は一体として構造化へまっしぐらだという感じです。
対象となるシステムによって、構造化の仕方が違うかもしれません。
経験が豊富ではないので、本書も一つの事例として参考にさせていただきます。
ありがとうございます。
（kaizen / 2008-03-21）

組込み系はOO開発と手続き型（機能型）開発の２種類あります。
一般にエンジンボードといわれているところは手続き型のC言語で記述しているところも多々あり、現場ではまだまだ使われているのではないでしょうか？
sessameが著書のオブジェクト指向もありますが、オブジェクト指向のベースの一部は構造化からきていることもあって合わせて読むと理解が大変深まります。
オブジェクト指向編では何故構造化が悪いのか、悪いというか陥りやすいアンチパターンについて書いてあり、手続き型の開発からオブジェクト指向開発に移行する際にもためになるでしょう。
（むにゃ / 2007-01-17）

　構造化は、コーディングでは常用されていて重要だと思う。大学初年の教科書にぴったりだと思う。
プログラミングの知識として必要だと思う。ただ、オブジェクト指向なのが、ちょっと気にかかる。
欲を言えば、純粋に構造化だけで書いて欲しかった。と申しますのは、オブジェクト指向にしてしまうと、継承の問題がからみ、実際にコーディングが終わると反省会で良くなかったねとなるからです。
現場では、オブジェクト指向より明示的メソッド（全部自分で書く事になるけど）の方が良く使われます。
でも、良本です。
（組み込み太郎 / 2008-02-03）

既存のコードを修正できないでいることがよくあるとお聞きしています。
自分でも、自分の作ったプログラムのバグが取れずに、ある方法で動かすと現象がでないので、そのままにしているものがあります。
どうにもなんともならなくなる前に、一度、作り直す機会があるとよいかもしれません。
CPUが変わるとき、OSが変わるとき、メモリの大きさが変わるとき、クロックが変わるとき、どんなときがよいかはわかりません。
何かが変わるときに、一緒に変えると、何が原因かがわからないので嫌だという話はお聞きしたことがあります。
その気持ちもわかるので、既存のソースを直すのは、実験的な作業だけにとどめたい気持ちもあります。
そんなぐだぐだした状態に喝を入れるヒントがみつかれば儲け物かもしれません。（kaizen / 2008-03-21）

デザイナーとは、ディレクターとは、いったい何をどこまで追求すればいいのだろう？開発と制作の境界線は？静的ページの情報ページとウェブアプリケーションのインターフェースデザインは誰が決めて誰が作るの？
といったようなウェブの構築に関する様々な疑問に対して、自分独自のノウハウをつちかっている中で、この本はその考えをすっきりとまとめてくれました。知っていて分かっていたけど、どう言葉にしていけばいいのか、なんとなく分かっていたウェブの構築のプロセスや、デザインについて、開発者の立場から、制作の現場から、また戦略の立場から、どの立場の人にも、読みやすく書かれています。
英語版、Jesse James Garrett のウェブサイトとあわせてみると、理解が深まります。（fumination / 2005-03-12）

ハッキリ言って、訳が最悪です。
書かれている文章の意味が理解できないために、分からない言葉は、全てカタカナで表記したか、もしくは、一般会話の中でも、カタカナ言葉を多用するのがカッコイイと思っている、鼻持ちならない奴が、訳をしたとしか、思えません。
（ウェブ戦略としての「ユーザーエクスペリエンス」）という書名とは裏腹に、書籍としてのユーザーエクスペリエンスについては、考えられていない、という笑える本です。
内容を理解した上で日本語訳ができる人による本だったら、間違いなく星５つです。（ / ）

ユーザビリティとウェブ開発の実践をテーマとした、ウェブデザインの中・上級解説書です。
本書は、目先の具体的な問題に対処する指針を与えません。説明の都合上、僅かに具体例を示した箇所はありますけれども、基本的には抽象的な概念を整理して示すことに主眼が置かれています。そう、本書はデザイナーの抱える膨大な量の問題を腑分けし、きちんとプロセスの中に位置づけていく方法を示す、メタ・ユーザビリティ解説書なのです（私の読み違えでなければ）。
著者は様々な問題とその解決のために持ち出される概念を「戦略、要件、構造、骨格、表層の5段階」に配置し、できる限り一貫した流れの中でプロジェクトを進めていくための考え方を提示しています。このような発想と分類法は、幅広く応用が利きますが、「理屈は理解しても実行が伴わない」のもよくある話。だから、やれば勝つ……のだろうな、と思いつつ読了しました。（徳保隆夫 / 2005-03-17）

webサービス（サイト）のプロジェクトのワークフロー及びガイドラインとして
下記の5つの段階を踏んでいくべきであると定義していて、
1の段階での誤りが上のレイヤー（ここでいう5の「表層」）にいくほど、
その傷が広がるというのはなるほどその通り。
　1.戦略（Strategy）：ユーザーニーズ／サイトの目的
　2.要件（Scope）：コンテンツ要求／機能要件
　3.構造（Structure）：インフォメーション・アーキテクチャ／インタラクション･デザイン
　4.骨格（Skelton）：インフォメーション・デザイン／ナビゲーション・デザイン／インターフェイス・デザイン
　5.表面（Surface）：視覚的デザイン
各段階での思考のプロセスや考え方などもしっかり抑えられていて
個人的には最も職域でマッチする4「骨格」と5「表層」はかなりマーキングしまして、
今後の自分の指針にもなりそう。
コードやグラフィックなどの技術論ではなく最終的なアウトプットを見据えた
情報の構造化と一貫性の導入という点ではwebデザインという
領域以外にも汎用的に使えそうな考え方だと。
デザインガイドラインの策定時やコンテンツ仕様の決定時、
自分の立ち戻り先の確認用の書籍としても非常に役立ちそうな良書。
UXの概念を常にどのレイヤーにも導入することによりローンチ後の
サービスの質が大きく変わるということですね。
（ndd / 2009-10-08）

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

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

ピアレビューとは「同僚による査読」であり、品質向上のためのツールのひとつ。この本はタイトル通りこの「ピアレビュー」をテーマにした1冊。その中でも「インスペクション」と呼ばれる公式レビューについての解説が厚い（第4章〜第9章）。公式レビューは、概要説明、準備、インスペクションミーティング、修正、フォローアップという5段階を踏み、モデレータや記録者、読み手という役割が必要となるが、それに見合う欠陥検出効果が見込めるという。実際には、プロジェクト計画において品質目標、規模などを考慮して公式レビューを取り入れるのかどうかを見極めることになるので、必ずしも公式レビューである必要はない。とはいえ、こういう手法を知っておくのはいいことだ。
第4章でも言及されているが、インスペクション（準備をしてミーティングによって欠陥を指摘する）がどれほどの効力があるかについては議論の余地があるようです。この本以外の書籍についてもあわせて読むことを薦めたい。たとえばソフトウェア・テストPRESS　vol.2でインスペクションについての記事が載っている。（softest / 2008-08-12）

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

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

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

検査といわれればするのに、インスペクションといわれた途端にやる気がなくなる現場がある。なぜかはわからない。自己査定は許容水準だった。自分では、この点よりよくするつもりはありません。これ以上やると無駄が増え、改善を阻害しそうだと感じるからです。大規模組織で、大規模開発の場合と、小規模組織で、小規模開発の場合での違いがあるかどうかが課題だと考えています。
以下は自己査定の回答例です。
(1)　通常する
（２）通常する
（３）ときどき
（４）通常する
（５）ときどき
（６）ときどき
（７）通常する
（８）ときどき
（９）通常する
（１０）まったくしていない
（１１）通常する
（１２）通常する
（１３）通常する
（１４）通常する
（１５）ときどきする（kaizen / 2008-07-09）

内容を見ると非常にわかりやすく、それぞれの鉄則が胸に突き刺さることが多い。それぞれの鉄則１つ１つにつき１冊の本ができるようなネタが多い。
まえがきの段階で、用語（兆候・品質・ブラックボックステストなど）の説明をさらっと終わらせ、実践的なことが書かれている。また、テストの技法・手続きだけでなく、後半には、テストチームのマネジメントやテストプロジェクトのマネジメント、ソフトウェアテストにおけるキャリアまで書かれている。
いままで出版されてきたテスト・試験の本とは異なり、体系的に書かれてはいないが本当に必要な技術・思想などが満ち溢れている。
テストとは、ここまで考えてやることなのか、テスト道を究めたいひとにはぜひ読んでいただきたいし、それ以外にもソフト㡊ウエア開発に携わっている方々にも読んで欲しい。（izuminoa / 2003-05-07）

テストに関するノウハウについて書かれていて、とても貴重な本である。原書は米国でテストの実用書としてよく売れている本であり、「テストとはこうあるべき！」というよりも、実際にテストをする技術者の視点でテストの勘所が書かれており非常に参考になる。特に、著者たちのベストプラクティスやＣＭＭなどに対する見解は、規則重視の品質管理に対するアンチテーゼとなるだろう。テスターだけでなく、多くのソフトウェア開発者、ＳＥ、マネージャに読んで貰いたい。（ / ）

２　常に目的を意識せよ
４　顧客の価値と向き合うこと
５　重大なバグを素早くみつけよう
７　口にださなくても、いろいろ疑問を持とう
８　プログラムの失敗を成功の母とせよ
１０　テスト完了と聞いたら注意すべし
最初の１０項目で６項目共感した。
全体の６割が共感出来る可能性が高いと思うか、最初に確実な事項を書いているので、残りは半分以上が共感できないだろうと予測するかは、性格によるか、統計に馴染んでいるかの違いだろうか。（kaizen / 2008-07-08）

テストの現場は過酷である。プログラムや設計と違い、ロクにマニュアル本もなく、経験則が全ての世界。この本は、そんな現場にこそ導入すべき必携ツールと成る一冊といえよう。
これまでの経験則から導き出されたテスト戦略の構築法、バグ出しや試験管理のための実際の技法、さらにはテスターのキャリアアップ指針まで、まさにテスターの道標となるべき内容が盛り込まれている。手探りで進めているそこのテスターのあなたに今必要なもの、それはこの本だと断言しよう。（Ash@VRS / 2003-04-26）

『基本から学ぶソフトウェアテスト…』に続いて凄い本が現れた。
『基本から～』は、文字通り「テスターってなに?」というところから入る本だったのに対して、『293の鉄則』は一言で言えば実践ノウハウ集。
もし、テストやテスターという言葉に馴染みがなければまずは『基本から～』を先に読まれることをお薦めする。
すでに様々なプロジェクトが進行し、ソフトウェアの品質の低さに辟易しているとしたら、職種を問わず、まずこの本を手に取るべきだ。ざっと目を通すだけで、自分たちの問題点や誤った常識が次から次へと見つかるに違いない。
個々のトピックがまさに鉄則、一つとして譲れない項目ばかり。よくある「100の○○」系の本のような薄っぺらな穴埋め項目がないのはその半端な数からもわかる。
夢のような理論/理屈で読者をケムに巻くのではなく、「現実は甘くない、こう対処せよ」という実例や解決方法がぎゅぎゅっと濃縮されている。
とにかく、ソフトウェアの品質管理や検証/テスト部隊には一冊(どころか人数分備えておくべき必読書なのは間違いない。（kaorun / 2003-04-28）