要求仕様の探検学 の商品レビュー

D.C.ゴーズ,G.M.ワインバーグ【著】,やな川志津子【訳】,黒田純一郎【監訳】

2022/11/15

要求仕様を定義する活動が大変多岐に渡ることがわかった。
具体的なやり方も記載されているが、現代(2022年)のベストプラクティスかどうかは不明。
金言はたくさん書かれているので、引用したり発表の参考にするのはいいかもしれない。

2019/01/20

同僚に借りて読んだ。

スイスの議会では"支配的"言語圏の人たちが自分の考えを"副次的"言語で表明することで、少数派の参画者に対する礼儀と信頼を表すという話が興味深かった。

パレート最適は夢想で、すべてのことにはトレードオフがあるというのも頷ける。

総じて、20年近く前に書かれたにもかかわらず、内容は古くないと感じる。

若干、日本語の訳出が・・・なところはあるのだけれど。。。

2018/10/20

『ライト、ついていますか』は問題を正しく定義するための一冊であり、『人月の神話』はプログラミ製品の開発は、その要件から根本的な複雑性を持つことの証明であった。本書はそれらから一歩進み、定義された問題を如何に解き進めるか、根本的な複雑性を如何に1つずつ解きほぐすかを示す一冊。
一言で言うならば"要件定義の進め方”てな本書であるが、要件定義が必要なのはなにもSEやコンサルに限ったことではない。会社で仕事をする以上、誰だって頼んだり頼まれたりすることはある。人は物事を頼むとき、自らが『必要としている』事を注文をするのではなく、『望んでいる』事を注文する。そこで意図を正しく汲み取り、ただ望まれた結果を返すのではなく、本当に必要としていたものを望むようにしむけるやり方は誰にだって役立つはずだ。
例えば要求の曖昧さの解決。例えば顧客の期待値コントロール。例えば選好と制約。設計書から曖昧さを排除すべきとは言われてきたが、曖昧さを計測したことはあっただろうか。期待値コントロールが重要だと言われてきたが、顧客の期待値を測ったことはあっただろうか。条件を選好と制約に分類し、その範囲を調整したことなんてなかった。全部が全部本書に書いてある通りのプロセスで進められるわけではないが、そのエッセンスを知らずにやってきた過去を振り返ると、恥ずかしかったり悔しかったり勿体なかったりで死にたくなる。

旋盤工だろうが書店員だろうが教師だろうがシステム屋だろうが、大抵の仕事というものは物理的か概念的に『まだこの世に存在しないもの』を創る仕事だ。材料を揃えて手だけ動かしてテキトーな何かを作ることは簡単だが、ピッタリと収まるべきところに収まる最適な何かを創るのはとてもとても難しい。要件を正しく見極めること。それこそがその差を埋める一歩になるだろう。やり方は本書にある。

2013/09/29

要件定義、つまりユーザーが欲しいと思うものをどうやって把握するかについて、特定の手法にとらわれることなく、一般的に通用する考え方を説いている。
人の記憶がいかにあいまいか、
質問の順番を誤ると全然違う結果になる、
制約と思っていたものが実は制約ではない、
などなど、要件定義をする人は絶対読んでおくべきだと感じた。

2013/06/25

(1994.05.20読了)(1993.11.02購入)
設計に先立つ品質の作り込み
（「BOOK」データベースより）amazon
どのように本音を引き出すか、相手の予断をどのように見つけ出すか、プレッシャのかからない会議をどう運営するか、あいまいさを追放するにはどうしたらよいか。ワインバーグのシステム開発における品質向上策。

☆関連図書(既読)
「システムづくりの人間学」G.M.ﾜｲﾝﾊﾞｰｸﾞ著、共立出版、1986.07.01
「ライト、ついてますか」ｺﾞｰｽ・G.M.ﾜｲﾝﾊﾞｰｸﾞ著、共立出版、1987.10.25
「コンサルタントの秘密」ﾜｲﾝﾊﾞｰｸﾞ著、共立出版、1990.12.25
「スーパーエンジニアへの道」ﾜｲﾝﾊﾞｰｸﾞ著、共立出版、1991.10.20

2012/05/01

設計に先立ち、Requirements をきちんと決めることが、いかに品質の作り込みに貢献するのかが分かる本です。

　　地図と実際の土地とが一致しないときは、つねに、実際の土地を信じよ

といった名言もたくさんのっているし、考えさせる事例（保証印ゴキブリ退治キットや、エレベータに対する要求）も良いです。

本書では、願望リストを属性と属性項目に区別することの大切さを書いています。
属性とは、エレベータでいえば“寿命”とか“色彩”といった関心を持っている次元の事で、属性項目とは“耐用年数より長く”とか“茶色、黒、赤、白”といった属性の細目の事です。

あらゆる属性が明らかにされたら、今度はそれらを機能に結び付けて分類したのち制約を定義してそれが満たされるかどうかつまりは、製品が受け入れられるかどうかをテストすると書いてあります。

ということは、このフェーズで属性（属性項目リスト）、と制約条件を使ってHAYST法で組合せ表を作って思考レビューをしてやったらいいんじゃないかと思いました。

きっと誰かがやって論文になっていると思うけど。

2012/01/12

古い本ですが今でも読む価値があると思います。要件定義に関する「変わらぬ本質」が書かれています。要件記述に含まれる形容詞、副詞にあいまいさが現われる、という指摘が勉強になりました。

2011/12/13

要求仕様について合意するための具体的な方策が体系的に列記されている。
ワインバーグの書籍では、一番何度も読み返して利用している本である。
実際に経験したこと、実際に思い当たることなどが、沢山書かれていて共感できる。
要求仕様を明確にせずに、後で手直しについて騒いでいる人達が、何故この本を読まないか不思議である。手直しが儲け頭なので、要求仕様を明確にするとお金にならないということなのでしょうか？

2011/10/28

要求仕様の探検学
●要件が示す図は、読み手への伝達という目的に合わせて表記法を選択することが重要
●誤りを発見したフェーズが要件定義、設計、コード化、試験、運用と進むに従って、修正に必要な費用は大きくなる
●感度のよい順序で質問をすることにより、完璧な解に近づけることができる
●利用者、利用する環境、解決したい問題など、文脈自由な質問をすることで、新しいプロジェクトや人間関係のぎこちなさを乗り越え、問題点を明示できる
●ユーザを包含する計画を立てたら、創造力と才略を駆使して必要とする全面的な参画を得ることが必要
●記憶するのが最も難しい部分は意味のない部分であり、要件定義において誤りを含みやすい部分となる
●属性を視覚イメージに変換した後、ランダムに組み合わせることで右脳でアイデアを生み出すことができる
●プロジェクトの名前は、不適当な理由を３つ挙げ、その問題を除いた別の名前を提案し、使える名前が出るまで繰り返す
●紛争が起きた場合には、それがまったく自然であることを皆に気づかせて冷静にさせる
●クライアントの恐怖や欲望の強さだけが、どの要件が制約で、選考で、飾りなのかを決める
●評価対象の属性をいくつか選択し、対極的な部分集合としてユーザ満足度調査を作成する
●問題に対する探求は、選択・仮定・押し付けにより曖昧さを減少させた解に近づけること。最終的に合意文書に変換して理解と承認を確認する