[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

著者 : 清水吉男

• 技術評論社 (2010年5月1日発売)

感想・レビュー・書評

[sai10reiさんの感想 · 2012年11月25日]

要求と仕様と理由を分けて記述し、それらをセットで紐づき構造にする。
軽視されがちな仕様変更時にも常に要求に立ち帰って影響範囲や制約逸脱を確認できる記述方式が望ましい。派生開発及び要求仕様記述の集大成として上記ノウハウを詰め込んだフォーマットとして、USDMと要求トレーサビリティマトリクスを提案されている。

[jin1977さんの感想 · 2012年7月24日]

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

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

[keepiruさんの感想 · 2012年5月13日]

著者のセミナーに出席後購入。
述べてる手法は素晴しいんだけど、話があっち飛びこっち飛びするせいで、文章全体にまとまり感が無く読み易いとは言い難い。

[狐舞さんの感想 · 2012年5月6日]

　仕様を作成する方法について、著者のこれまでの経験に基づいて述べられているので一定の説得力があった。しかし、自身の経験と考えに過信ともいえる自信をもっており、経験したことのない方法論や嫌いな方法論、一方的に使えない方法であるとして切り捨てている姿勢には疑問が残る。また誤解されて広まった内容を鵜呑みにしている。もちろん参考になる部分は多かったが、とにかく気に入らないものは排除するという筆者の姿勢がそれに疑念を抱かせる要因となってしまっていた。

[akiyama924さんの感想 · 2012年4月30日]

清水さんの本を読んだのは、これで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をレビューして）テスト設計に持っていくのがよいわけです。

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

[kaizenさんの感想 · 2011年12月30日]

何を作るとよいかということをここでは「要求」という漢字2文字で表現しています。仕事によっては「制約」という場合もあります。

これらの制約を仕様として記述するのが不十分だと，
何を，どういう条件で試験すればいいかが分からないため，
結果として，何度も作り直しをしないといけないこともあります。

システム設計の基本的なところを，清水吉男さんの経験に基づいて、うまく整理しているところがよいでしょう。

参考文献も，海外でも流通している基本文献をあげているので，
国際的な展開に役立てることもできるでしょう。

2011年の11月には，上海で開催された世界ソフトウェア品質会議でも関連発表があったので，参考にするとよいでしょう。

また，2011年6月の派生開発カンファレンス2011での
藤倉 俊幸さんの
ユースケースとUSDMにセミフォーマル手法を適用した要求検証
が，本書の内容を発展させるよい鍵だと思いました。

[Jun Maekawaさんの感想 · 2011年12月8日]

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

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

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

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

[hino4649さんの感想 · 2011年9月8日]

・良書。
・ユーザから提示された仕様に対して、常に要求をひもづける事で、機能要件だけでなく、非機能要件までも洗い出すいう考えは、今までなんとなく感覚的にやっていたが、それだと品質が安定しない（属人的スキルだと、人が変わると品質も変わるし、同じ人でも、時期によって品質が変わる）と感じていた。当書で薦める手法（USDM）は、EXCEL書式の要求仕様を作製する事で、USDMの書式がある程度ガイドの役目を果たし、自分が作業する際も見落としが減るし、またチーム・レビューをする際にも、レビュアーが見やすい書式を使用する事で、気付きの機会を増やし、上流工程でのなるべくバグ洗い出そうという手法の様に思えた。

[yoheyjp0905さんの感想 · 2011年6月19日]

仕事のために勉強のため読みました。

自分の場合は仕様書を特に作成せず、打ち合わせを何回も重ねて仕様を固めて来ました。正直この本に書いている様に書くのはなかなか大変だなと思いましたが、話し合いの中で、書くと話すと言う意味では変わってしまう部分はありますが、とても参考になりました。

かなりボリュームはありますが、システム開発に携わる人は一度読んでおくといいと思います。

[深海いわしさんの感想 · 2010年10月15日]

仕様仕様って言われても何のことやらさっぱりだったのでお勉強。読んでもわからなかったのは悪い例そのまんまな仕様書だったからっぽいことがわかってちょっとほっとしました。