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

要求・要件定義または顧客と仕様検討の経験がある場合、共感を得られる箇所がいくつかある。一問一答形式ほど簡略ではないが、ヒアリング例題に対して、その意図と想定回答が示されており、読みやすい。

各所で解説される重要ポイントが重複しているため冗長に感じるが、いわゆる例題＆解説・回答形式なのでやむを得ないと思うし、それで良いと思う。

読み物としては５〜６時間で読み終わるが、いざ本番に挑むときのチェックリストとしても使えるので再利用価値がある。
私の場合は、本番後（顧客とのミーティング後）に振り返り、漏れがなかったかを再確認するためのチェックリストとして利用するつもり。
目次がチェックリストそのものになっているので、使い勝手をよく考えられた本であると感心する。
ただし427項目もあるので、実際には案件タイプに応じて集約したチェックリストを作成し、適用してみようと思う。

第1部の要求定義オリエンテーションはなるほどと思わせる記述が見られ、
実務の参考となります。
しかし、第2部のチェックリストが数が多過ぎ、かつ箇条書きの形で続き、
読み進めるのに若干苦労します。
著者の考えに賛同しかねる記述や技術的な間違いも多々あります。
また、誤字もあり、「従業員」の「したが業員」には苦笑するしかありません。

ワインバーグの本などを挙げた最後の参考文献リストの書籍を読む方が
よいかもしれません。
マネジメントや技術的な知識や経験が著者には圧倒的に足りない印象を
受けました。

”新しい顧客”や”新しい業界”でのシステム開発は、前提知識や事前の情報が乏しいため要求定義をまとめることが困難です。

システム導入経験のある顧客と、そうでない顧客。
決定権のある顧客側の担当と、そうでない担当。
開発経験のある業界と、そうでない業界。
・・・・・・
状況による不安要素を数え上げたらきりがありません。

本書は、
・事前にこんなことを検討しておくといいよ
・ヒアリングでは状況（段階）に応じて、こんなことを聞くといいよ
という、項目の一覧と解説集です。

早速、お客様先で試してみましたが、聞くべきことの取捨選択が事前にできていたので、大変スムーズに初回のヒアリングを終えることが出来ました。
後は、議事録を求める際に、本書の項目と照らし合わせて不足分を追加質問・確認すれば良いと考えています。

要求定義段階で起きる”あいまいさ”の排除が、プロジェクト成功の大きな鍵であることは皆さん痛感していますよね。

大事なのはわかっているが、どのようにしたら良いか漠然としている
という方にぴったりな本です。

要求定義は非常に難しい作業です。前の経験がなかなか活きず、ここで苦労したから今度はしっかりやろうと思っていると、そこは大したひねりもなく、前は楽だったポイントに落とし穴があったり、網羅的にと考えると間違いなく時間不足になってしまったり・・・。

そうした中でチェックリストは非常に有効な手法だと思います。チェックリストに従って、どの辺りが今回のシステム開発の肝になりそうなのか探りを入れて、これはと思ったら網羅的に調査していく。そうした中で、このチェックポイントは非常に有効だと思います。今も実際にこのチェックポイントをベースに自分なりに取捨選択をし、一部書き直したものを使って要求定義をすすめていますが、この本に出会わなければ見落としていたであろう多くのポイントを早期に発見し、検討することが出来ました。

これはどこかでWiki化してみんなで更新していけるようになれば、尚更良いかと思います。