あらすじ
好評既刊の改訂第2版。開発の根本であり工程すべてに関わってくる「要求の仕様化」について，その重要性からじっくりと解説。「要求」とは何か「仕様」とは何かという本質から説き，仕様書作りの考え方や表現方法を具体的に提示します。第1版では，要求を表現する際に「振る舞い」に注目し，分割・階層化により振る舞いの範囲を狭くして仕様漏れをなくしていく方法を提唱しました。第2版ではその方法論をさらに深め，上位要求の表現や分割・階層化したときの下位層の要求を表現する際に「動詞」を意識する視点を全面的に打ち出しています。
...続きを読む感情タグBEST3
Posted by ブクログ
久しぶりに再読。
過去に読んだ時よりも携わる業務の幅が広がったことでが、理解がより深まった。
忘れてるとこもあったので、定期的に読み返したい。
Posted by ブクログ
「入門+実践」要求を仕様化する技術・表現する技術
改訂第2版
仕様が書けていますか？
著：清水 吉男
出版社：技術評論社
良書、どろくさいシステム開発のなぜを考える書です。難易度が高いです。
本書の目的は、コンピュータシステムの構築の要求を適切に表現することで仕様を引き出す方法を語ってくれています。
本書を読めば、仕様変更率を５％以下に抑えることができ、仕様関係のバグも激減し、当初の納期通りにシステムができあがる、という、なんというありがたい書なのである。
要求の仕様化技術は、ソフトウエアエンジニアリングの技術の中の一部にすぎない
仕様化技術を生かすために、設計技術、見積技術、スケジューリング、進捗管理も重要である
さらに、要件開発は、２１世紀に入って、さらに高度な要求仕様の書き方や、要件の抽出、分析方法の研究もすすんでいる。
が結論です。
本書の構成は３部構成です。
①要求仕様にまつわる問題とはどんなものがあるのか
②問題に対して、どう要求仕様をかけばいいのか
③要件管理をどうするのか、なにを、計測すればいいのか
ソフトウエア開発とは、大勢の人間がかかわっているのでコミュニケーションの問題、個々のエンジニアが、みえない要求、仕様を、プログラム言語でコードにするので、対応する個々の人間のスキルや理解度に左右される、やっかいなものです。
あたまの痛い内容がたくさんでてきます。
・解釈の違いは伝言ゲームの中で発生する
・ウォータフォールの最大の欠点は、問題を発見するタイミングが遅くなることである
・テスト期間が短くなるのは、設計や実装に時間をとられているので、テストする時間が短くなるからである
・派生開発（追加開発）での潜在バグは、前任者が作りこんだバグがたまたま発見されたもの、なぜ作り込まれたのかは永遠にわからない
・設計や実装ベースであきらかになった、要求仕様や設計のミスは、要求仕様書に追記されることはない
・保守性という品質要求は、機能とはまったくことなるため、設計段階で、品質要求を行い、あらかじめ、組み込んで置かなければすり抜けてしまう
・要求仕様を丸投げした段階で、分割発注をおこなっても、まともなコードはかけない
・要求されない仕様は、実装されない
・仕様レビューは、１回しか見積工数として見られていないし、多くの指摘事項をもらうことを前提とはしていない
・仕様変更の流れ
①変更依頼の内容の不備をチェック
②内容の軽重や変更の範囲を検討
③範囲が広い場合は、関係者を集めて対応方法を検討
④現行仕様と矛盾しないか、他の機能仕様に影響がないかを検討
⑤手分けして、手戻り作業を行い
⑥修正作業と確認作業を行い
⑦対応完了の報告を行う
・要求仕様の粒度を小さくすると、「とてもそこまで書いている時間がありません」
⇒でも、仕様化されていないまま、設計はできない
⇒手戻りをするくらいであれば、粒度を小さくするほうが効果がたかく、おつりがくる
・顧客との関係を高める
仕様書のサンプルを用意して、成果物を例示して、なぜ必要なのか意味を説明する
・お互い「わかった」が一致していないケース、勘違いしています。
・文章が書けない人に他人の文章を理解させることは容易ではない
・理解するという行為は、時として、作成するよりも、難しい
・仕様モレよりも、要求モレを防ぐほうが難しい
・要求がきちんと文書化されることはほとんどありません
・仕様が分かりにくければ、理由と、説明をセットにしておく
・システムを適切なカテゴリに分割する、要求を分割して範囲を小さくする
・仕様書は、エクセルで書く
・派生開発（追加開発）の難しさ
①一般的に開発期間が短い
②自分で書いたコードではない、人の書いたコードを解析する必要がある
③要求仕様の文書がない、あっても不足している
④ほしい設計書がない
・言われたことを、メモしているだけではだめ
メモや議事録を、ドキュメント体系の中にうまく反映するための仕組みが必要
・仕様化されない要求は実現されない
目次
第2版の発行について
はじめに
第1部 要求仕様にまつわる問題
第1章 要求仕様にまつわる問題
1.1 どこで問題が発生しているか？
1.2 要求仕様のトラブルの実態
1.3 曖昧な仕様で作業に入っている
1.4 顧客からの仕様変更が頻発して……
1.5 要求した機能を満たしていない
1.6 納期の遅れとなって表面化する
1.7 品質要求に応えられないSE
1.8 派生開発での仕様トラブルはもっと複雑
1.9 設計書が省かれてしまう原因になっている
第2章 なぜ仕様のトラブルが起きるのか
2.1 問題が明らかにされたか？
2.2 仕様化の作業を放棄した
2.3 ドメインの知識がない
2.4 バグの経験だけでは役に立たない
2.5 レビューできた仕様書か
2.6 FIXした・しないでもめる理由
2.7 途中で仕様変更が混乱する理由
2.8 望みはある
第3章 要求仕様は不要か？
3.1 テスト仕様で代われるか？
3.2 仕様化しないほうが儲かる？
3.3 “不完全な要求仕様”の誤解
3.4 “コードなら書ける”の仕組み
3.5 GUI構築ツールで仕様を引き出せるか？
第4章 仕様化の効果
4.1 要求仕様書がすべての始まり
4.2 一気に解消する混乱
4.3 設計や実装のイメージができる
4.4 不用意な「試作」が減る
4.5 設計や実装時に仕様の確認ができる
4.6 レビューで感じる仕様化の効果
4.7 トータル工数が短くなる
4.8 設計に入る前に機能の難易が見える
4.9 顧客との良好な関係を築ける
4.10 ITゼネコンとの訣別
4.11 要件管理に取り組める
第5章 要件開発の重要性
5.1 文書にする理由
5.2 “わかる”の問題に対応する
5.3 なぜ“要求”仕様書というのか？
5.4 要求仕様書は誰が書くのか
5.5 顧客からの要求仕様書を洗練する
5.6 仕様モレと仕様間の衝突を早期に発見する
5.7 要件開発をスケジュール管理のなかで行う
5.8 要件開発と要件管理は車の両輪
5.9 要求工学における世界の動き
第2部 要求仕様を書く
第6章 “要求”を書く
6.1 要求の役割
6.2 要求の表現
6.3 要求には「理由」がある
6.4 必要なら「説明」を付ける
6.5 要求のカテゴリ化
6.6 要求のモレを防ぐことが重要
6.7 品質要求を確認する
6.8 品質要求の表現
第7章 要求の階層化テクニック
7.1 要求を階層化して範囲を狭める
7.2 「MECE」の活用
7.3 階層化しても「要求」に変わりはない
7.4 依頼者と分割の基準を共有する
7.5 階層は2層ぐらいで止める
第8章 要求を仕様化する
8.1 仕様とは
8.2 “Specify”の意味
8.3 仕様で衝突する
8.4 いつ仕様化すべきか？
8.5 検証可能性について
8.6 固有の番号を付ける
8.7 要求の階層のなかで仕様を捉える
8.8 さらに範囲を狭めるためのグループ化
8.9 シナリオ機能と単純機能の違い
8.10 仕様と要求の混在の問題
8.11 仕様から要求を立てる
8.12 “ペースト作文”の弊害
8.13 「否定表現」などの曖昧な表現を避ける
8.14 “FIX”から“賞味期限”へ
8.15 品質要求の仕様化
8.16 確定しない仕様の表現
8.17 設計情報の扱い
第9章 Excelによる仕様化の勧め
9.1 「Excel」のほうが細かな使い方ができる
9.2 要求書と要求仕様書を一体化
9.3 要求TM（トレーサビリティ・マトリクス）への展開
9.4 自在に「列」を設計する
9.5 WBSとの違い
9.6 Excelで書くときの注意
第10章 派生開発における要求仕様書
10.1 “部分理解”の世界である
10.2 要求仕様書の体系を持ち込む
10.3 旧状態を表現する
10.4 何が変更されるかを表現する
10.5 「差分」を書く
10.6 変更の種類
10.7 変更の要求
10.8 追加の要求
10.9 移植の要求
10.10 削除の要求
10.11 派生開発の品質要求
第11章 画面仕様書のあり方
11.1 画面仕様書の問題点
11.2 画面操作全体に対する要求はあるか？
11.3 個別の画面設計の指針としての仕様
11.4 画面遷移と画面仕様を連携させる
11.5 機能仕様との連携
第12章 ヒアリング時の注意
12.1 ヒアリングの目的
12.2 “システムの目的”を確認する
12.3 今回の要件定義の手順について同意を得る
12.4 仮説見積りに基づいた仕様作成期間
12.5 契約時には、仕様の項目数の見積りを付ける
12.6 要求仕様書の「体系」を示す
12.7 事前にヒアリングの範囲を知らせる
12.8 こちらの要求仕様のフォーマットに慣れてもらう
12.9 言われたことをメモしただけではダメ
12.10 品質要求をヒアリングする
12.11 未決項目を含んだ状態でのベースライン設定
12.12 顧客を仕様化作業に巻き込む
第3部 要件管理と計測
第13章 仕様化を支える要件管理
13.1 なぜ、仕様が変更されるのか？
13.2 関係者へのオリエンテーリング
13.3 要求仕様書をレビューする
13.4 ベースライン設定と合意
13.5 以後の仕様変更をコントロールする
13.6 未確定だった仕様が決まる
13.7 いつ仕様変更を実施するか
13.8 仕様変更を期間限定で募集する方法もある
第14章 仕様化の出来栄えを測る
14.1 何を計測するか
14.2 レビューでの指摘件数とバグ件数の関係
14.3 データは組み合わせると声を発する
14.4 バグから学ぶ要件開発の方法
第15章 仕様化技術の応用
15.1 リスク管理へ応用
15.2 課題への対応が見えずにうろうろする
15.3 作り替えても前と変わっていない
15.4 業務指示もその場で具体化しよう
15.5 会社の方針がそのまま降りてくる
おわりに
参考文献
ISBN：9784774142579
出版社：技術評論社
判型：A5
ページ数：384ページ
Posted by ブクログ
時間がない諸氏は、第二部の方法論から読むと良い。要求の書き方、仕様の抽出と書き下し方。まずはコア部分をマスターしたい。
本書で紹介されているUSDM方法論はJUASでも紹介されている。また、派生開発（一般に改修と呼ばれる）のプロセスを分けて考えているところも共感する。
開発プロセスをPDFダイアグラムで見える化するなど、CMMIの知見に基づいた具体的なSEの仕事改善案が散りばめられている。
Posted by ブクログ
システム構築が上手くいかなかったことが、「要求仕様書」が掛けていなかったことに起因していることが良く分かった。
読んでいるうちに、今回のプロジェクトのまずさを指摘されているようで苦虫をかみつぶした思い。
ただ、解決のための方法論も記載されている。慣れるまでは、負担になってしまいそうだが、愚直に取り組みたいと思わせる内容だった。
Posted by ブクログ
要求と仕様と理由を分けて記述し、それらをセットで紐づき構造にする。
軽視されがちな仕様変更時にも常に要求に立ち帰って影響範囲や制約逸脱を確認できる記述方式が望ましい。派生開発及び要求仕様記述の集大成として上記ノウハウを詰め込んだフォーマットとして、USDMと要求トレーサビリティマトリクスを提案されている。
Posted by ブクログ
清水さんの本を読んだのは、これで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をレビューして）テスト設計に持っていくのがよいわけです。
ということで、長文になりましたが、お勧めです（たぶん、初版の方をお読みの方が多いと思いますが）。
Posted by ブクログ
何を作るとよいかということをここでは「要求」という漢字2文字で表現しています。仕事によっては「制約」という場合もあります。
これらの制約を仕様として記述するのが不十分だと，
何を，どういう条件で試験すればいいかが分からないため，
結果として，何度も作り直しをしないといけないこともあります。
システム設計の基本的なところを，清水吉男さんの経験に基づいて、うまく整理しているところがよいでしょう。
参考文献も，海外でも流通している基本文献をあげているので，
国際的な展開に役立てることもできるでしょう。
2011年の11月には，上海で開催された世界ソフトウェア品質会議でも関連発表があったので，参考にするとよいでしょう。
また，2011年6月の派生開発カンファレンス2011での
藤倉 俊幸さんの
ユースケースとUSDMにセミフォーマル手法を適用した要求検証
が，本書の内容を発展させるよい鍵だと思いました。
Posted by ブクログ
プロセスフローダイアグラムの草案者の方。
「はじめに」から滲み出る強者の感じとか最高。
要求とあるが、要件定義フェーズのシステム化要求定義から設計フェーズの一部まで、を含むようなイメージで受け取った。
これはこれで超大事だが、要求そのものの明確化というよりは、要件化する上でのヌケモレ防止、という視点での動きなので、いわゆるDX系の曖昧な要求への対峙の仕方としては、直結しずらい感覚。
Posted by ブクログ
どのレベルまでが要件定義で、どこからが設計かはよく問題になるけど、“要求の仕様化”という見方でそのラインを考えたことはなかったなぁと実感。本の内容で中心になるUSDMは普段使ってるけど、やっぱり急いで次工程に進んでいるのが現状なので、そのあり方について考えさせられる内容でした。。。
Posted by ブクログ
一通り読み終えた。
わかりやすいとは言えないが納得する内容。
今までよりもちょっとだけ前プロセスでの品質作り込みに意識がいきそう。
もう一度６〜８章を読み直して要求の定義と要求の仕様化についてまとめてみようと思う。
Posted by ブクログ
要求仕様化に限らず、「設計」という行為に携わる人間は、全員が読むべき本。要件分析のやり方に悩むエンジニアは多いが、必ず何らか助けになるはず。
内容は難解ではないが、幅が広いのと実務に合わせてイメージするのが少し難しいので、何度か繰り返して読むのが効果的だろうと思う。
Posted by ブクログ
要求をとらえること、要求という包みの中に、仕様を入れていくこと。そして、そのような要求や仕様がどのような理由によって裏付けられているかを記すこと。
似たような内容の繰り返しが多いが、だからこそ重要なポイントがわかりやすい。
ただ、誤字脱字が多すぎる。要求や仕様を「文書」で書き残すことの大切さを唱える本だけに、これは非常に残念。
しかし、この点に関して目をつぶれば、システム開発に関わる人たちにとって重要な示唆を与えてくれる本だと思う。
Posted by ブクログ
・良書。
・ユーザから提示された仕様に対して、常に要求をひもづける事で、機能要件だけでなく、非機能要件までも洗い出すいう考えは、今までなんとなく感覚的にやっていたが、それだと品質が安定しない（属人的スキルだと、人が変わると品質も変わるし、同じ人でも、時期によって品質が変わる）と感じていた。当書で薦める手法（USDM）は、EXCEL書式の要求仕様を作製する事で、USDMの書式がある程度ガイドの役目を果たし、自分が作業する際も見落としが減るし、またチーム・レビューをする際にも、レビュアーが見やすい書式を使用する事で、気付きの機会を増やし、上流工程でのなるべくバグ洗い出そうという手法の様に思えた。
Posted by ブクログ
仕事のために勉強のため読みました。
自分の場合は仕様書を特に作成せず、打ち合わせを何回も重ねて仕様を固めて来ました。正直この本に書いている様に書くのはなかなか大変だなと思いましたが、話し合いの中で、書くと話すと言う意味では変わってしまう部分はありますが、とても参考になりました。
かなりボリュームはありますが、システム開発に携わる人は一度読んでおくといいと思います。
Posted by ブクログ
何かこう独りよがり感はある．例えば仕様書作成のツールとして「WordではなくてExcel」を勧めるのだが，内容を読むと表形式で書けるなら何でもいい感じで，つまりMS以外の選択肢を知らないで書いてるんじゃないかという．ただ，内容としてはまあ正しそう．Agileディスってるけど，安易に飛びつく層に対しての説得力はあると思う．
Posted by ブクログ
著者のセミナーに出席後購入。
述べてる手法は素晴しいんだけど、話があっち飛びこっち飛びするせいで、文章全体にまとまり感が無く読み易いとは言い難い。
