【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？

清水吉男

好評既刊の改訂第2版。開発の根本であり工程すべてに関わってくる「要求の仕様化」について，その重要性からじっくりと解説。「要求」とは何か「仕様」とは何かという本質から説き，仕様書作りの考え方や表現方法を具体的に提示します。第1版では，要求を表現する際に「振る舞い」に注目し，分割・階層化により振る舞いの範囲を狭くして仕様漏れをなくしていく方法を提唱しました。第2版ではその方法論をさらに深め，上位要求の表現や分割・階層化したときの下位層の要求を表現する際に「動詞」を意識する視点を全面的に打ち出しています。

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 言語・プログラミング
• 出版社: 技術評論社
• ページ数: 384ページ
• 電子版発売日: 2017年11月17日
• コンテンツ形式: EPUB
• サイズ(目安): 28MB

[ブクログ · ★★★★★]

前半は仕様関連の課題と原因の説明で、共感しかなかったです。。
後半は具体的な書き方についてで、大変参考になりました。

[ブクログ · ★★★★★]

要求仕様書のあるべき姿を考えさせてくれる本。この本の通りに実践するのはなかなか大変だが、やる価値はあると思う。

[ブクログ · ★★★★★]

時間がない諸氏は、第二部の方法論から読むと良い。要求の書き方、仕様の抽出と書き下し方。まずはコア部分をマスターしたい。

本書で紹介されているUSDM方法論はJUASでも紹介されている。また、派生開発（一般に改修と呼ばれる）のプロセスを分けて考えているところも共感する。

開発プロセスをPDFダイアグラムで見える化するなど、CMMIの知見に基づいた具体的なSEの仕事改善案が散りばめられている。

[ブクログ · ★★★★★]

システム構築が上手くいかなかったことが、「要求仕様書」が掛けていなかったことに起因していることが良く分かった。
読んでいるうちに、今回のプロジェクトのまずさを指摘されているようで苦虫をかみつぶした思い。
ただ、解決のための方法論も記載されている。慣れるまでは、負担になってしまいそうだが、愚直に取り組みたいと思わせる内容だった。

[ブクログ · ★★★★★]

清水さんの本を読んだのは、これで3冊目です。

冗長とか読みにくいとかいう感想は一緒です。でも、まずは、それを書いておかないとね。

そのように、本としては、いまいちな本書がこんなに読まれているのは、そこに卓越したオリジナリティと実用性があるからだと思います。

★★★

本書では、清水さんのUSDM（Universal Specification Describing Manner）について書かれています。
改訂版なので16ページ増えています。

USDMは、要求仕様書の書き方です。仕様書というからには、
「仕様書」は「Specification」の日本語ですが、どのような状態かわからないままこの言葉を使っていると思います。英和辞書を引いても「仕様」「詳細」「明細」といった意味が書かれているだけでほとんど役に立ちません。「USDM」では「Specification」を、関係者がその内容について“特定できた（Specify）状態"、すなわち同じもの（こと）をイメージしている状態と定義します。
が満たされている必要があると筆者は主張します。

そのために、
　・ 要求には特定しやすいように番号を振る
　・ 仕様にも同様に番号を振る
　・ 要求と理由と説明と仕様は区別して書く
　・ 複数の要求はカテゴリにまとめる
　・ 要求自体の階層化は2段までとする
といった具体的なテクニックが書かれ、さらにチェックマーク欄などを加えた具体的フォーマットが示されています。

★★★

USDMの価値は、要求に対して理由を紐づけることで要求の依頼者の真意とのズレを無くし、さらに仕様を要求と離れないように、しっかりと関連付けて明確にしていることにあると思います。

そして、それをExcelという追加修正しやすいツールで記載しているところが実用性を上げています。

★★★

本書を読む前に、Twitterで@mkoszkさんが
USDMで用いている要求は一般に使われている要求とは違う。USDMにおける要求は、「範囲」を表すようにしている。それは、状態や条件の場合分けがあり、連続する振る舞いを表現するため、一般に要求と思われているものよりも文章が長くなり、複数の動詞が含まれることになる。#USDM
posted at 01:22:35

という理解でよいのかしら？ #USDM
posted at 01:22:50

USDM本が改訂される理由は、「仕様は要求に含まれる”動詞”およびその”目的語”にある」ということを全面に押し出すためと書かれている。 #USDM
posted at 01:32:09

この理解がまだ不十分なのだが、今のところの理解を書いておこう。複数の動詞が含まれる要求を分解して、一つ一つの動詞にするだけではなく、その動詞が書かれた背景や情景、シーンや状態を見極め、書かれていない”動詞”を抽出するというものだ。 #USDM
posted at 01:34:52

この考え方はHAYST法におけるFV表の”目的機能"を導き出す方法と似ている気がしている。USDMで抽出された"動詞"とFV表に書かれた”目的機能"は、表現された結果は違うものだけれども、その過程が似ている気がしている。 #USDM
posted at 01:38:46

FV表の目的機能は、システム機能では無い。どちらかというと要求に近いと思われる。そのため、USDMと似ている気がしているだけで、やっぱり違うのかもしれない。
posted at 01:48:51
書かれていたので、今回、FV表との違いを意識して読みました。

その結果分かったことは、
@mkoszk 半分位読んだのですが、USDMの要求仕様とFV表の目的機能とは重なるところは多いのですが違うものでした。目的機能の方は「欲しいかどうか」は重視しません。
posted at 12:31:43

@mkoszk 半分しか読んでいないのでUSDMの方は確信はないのですが、FV表の方は基本機能を考えてから目的機能に戻ります。そうすることで今回の商品にはあるいは過剰品質かもしれないけど再利用や保守で必要となる機能を見つめます。
posted at 12:54:33

「理由」と「目的」は似ているけど違うものです。そこがUSDMとFV表との本質的な違い。理由は「何故？」と掘り下げる思考で、目的は「本来はどうなの？」と登っていくもの。開発用には掘り下げる方が良いし、テストでは視野が広がるので本質に目を向けるのが良いだろう。
posted at 18:18:26
です。

FV表のFは智美塾合宿の結果Fg（ゴールを意識した機能）ということが分かってきたのですが、「機能」から「目的」を問う方向なのです。

つまり、FV表の「目的機能」は、「その機能は何のためにあるの？」「その機能が果たすべき目的は何なの？」「そもそも、どうして作ろうと考えたの？」という解決空間を拡げる上部へ展開していく方向です。

一方で、USDMの「理由」は、「その要求がでてきた理由や背景はなんだっけ？」「何故、依頼者はこんな要求を出してきたんだっけ？」というように要求の依頼者の真意と要求仕様書を記述する開発者やレビューアとの認識のズレをふせぐための「要求の掘り下げ」です。

これは、どちらが良いという話ではなく、要求を仕様化していくためには、それはさまざまな選択肢の中から仕様を確定していく行為ですから、清水さんの「理由｣の方向で分析するのがよいのです。

そして、できた機能に対してテストする時には、書かれた要求や仕様が間違っていることもあるわけですから、「目的」展開を行ってゴールの認識を共有して（Fをレビューして）テスト設計に持っていくのがよいわけです。

ということで、長文になりましたが、お勧めです（たぶん、初版の方をお読みの方が多いと思いますが）。

[ブクログ · ★★★★☆]

要求をしっかり仕様として落とし込み文章化することの大切さを再認識。あり様、書き方が具体的に書かれているのでとても参考になりました。

[ブクログ · ★★★★☆]

どのレベルまでが要件定義で、どこからが設計かはよく問題になるけど、“要求の仕様化”という見方でそのラインを考えたことはなかったなぁと実感。本の内容で中心になるUSDMは普段使ってるけど、やっぱり急いで次工程に進んでいるのが現状なので、そのあり方について考えさせられる内容でした。。。

[ブクログ · ★★★★☆]

一通り読み終えた。
わかりやすいとは言えないが納得する内容。
今までよりもちょっとだけ前プロセスでの品質作り込みに意識がいきそう。

もう一度６〜８章を読み直して要求の定義と要求の仕様化についてまとめてみようと思う。

[ブクログ · ★★★★☆]

要求仕様化に限らず、「設計」という行為に携わる人間は、全員が読むべき本。要件分析のやり方に悩むエンジニアは多いが、必ず何らか助けになるはず。
内容は難解ではないが、幅が広いのと実務に合わせてイメージするのが少し難しいので、何度か繰り返して読むのが効果的だろうと思う。

[ブクログ · ★★★★☆]

要求をとらえること、要求という包みの中に、仕様を入れていくこと。そして、そのような要求や仕様がどのような理由によって裏付けられているかを記すこと。

似たような内容の繰り返しが多いが、だからこそ重要なポイントがわかりやすい。

ただ、誤字脱字が多すぎる。要求や仕様を「文書」で書き残すことの大切さを唱える本だけに、これは非常に残念。

しかし、この点に関して目をつぶれば、システム開発に関わる人たちにとって重要な示唆を与えてくれる本だと思う。