パパッと見るブックレビュー『【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術／清水 吉男』
はじめに
今日は『【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術』という本のブックレビューをしたいと思います。
パパッと見るブックレビューのコンセプト
レビューをパパッと見て、紹介した本が見た方の今の課題にマッチしているかどうかをパパッと判断できることをコンセプトとしています。
それではブックレビュースタートです。
そして月が変わりましたのでフォトギャラリーの画像を変更します。今月は『笹いと』さんのイラストを拝借します。ありがとうございます！
ブックレビュー『【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術』
本の紹介・読んだ目的など
【タイトル】【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術
【著者（敬称略）】清水 吉男
【発行日】2010/5/1
【発行所】技術評論社
［読んだ目的］
1、要件定義のポイントを知る
［何でこの本を知ったか］
Amazonで検索した
［ブクログでつけた★の数］
★★★★★
この本はこんな人にオススメ
要件定義（要求仕様決め）について知りたい人
開発をうまく進めたい人
開発で一歩先に進みたい人
著者：清水 吉男さんって？
Amazonから引用します。（出版当時のプロフィール）
清水 吉男（しみず よしお）
株式会社システムクリエイツ代表取締役。1968年からソフトウェアの世界に身を投じ、汎用機のソフト開発から途中で組み込みシステムの世界に転向。さらにコンサルティングに転じ、1990年にCMMと遭遇することで、自らの経験を元にして要求の仕様化技法(USDM)や派生開発専用の開発アプローチ(XDDP)などを確立して1995年にプロセス改善の世界に方向転換し今日に至る。派生開発の方法(XDDP、USDMなど)の普及を図るため、2010年に派生開発推進協議会を設立し代表として活動を開始
上記は当時のプロフィールで、清水さんは2017年にお亡くなりになっているようです（参考）。ご冥福をお祈りいたします。
私が読み取ったこの本のメッセージ
「 要求仕様をしっかりと決め、開発をスムーズに進め、開発業務を続けよう 」
私が感じたこの本のポイント
入り口の要求仕様がしっかり描けていないと設計・開発・試験工程で手戻りが発生し、余計に工数をかけることになり開発がスムーズにいかなくなる、よって要求仕様をしっかり書くことが重要
要求仕様とは要求+仕様。仕様だけでなく、その仕様の上位概念である要求を、最初に必ず書く。仕様をいきなり思いついても上位にさかのぼり要求を書く
要求は文章で書く。その中の動詞と目的語が仕様となる
要求仕様書は顧客、設計者・開発者、試験者が認識のずれなく特定（Specify）、合意できる文章
要求仕様はそのまま設計者が設計できる状態まで落とし込む。設計できる状態でないものは仕様ではない。
チャプター紹介
はじめに
第1部 要求仕様にまつわる問題
第2章 なぜ仕様のトラブルが起きるのか
第3章 要求仕様は不要か？
第4章 仕様化の効果
第5章 要件開発の重要性
第2部 要求仕様を書く
第6章 “要求”を書く
第7章 要求の階層化テクニック
第8章 要求を仕様化する
第9章 Excelによる仕様化の勧め
第10章 派生開発における要求仕様書
第11章 画面仕様書のあり方
第12章 ヒアリング時の注意
第3部 要件管理と計測
第13章 仕様化を支える要件管理
第14章 仕様化の出来栄えを測る
第15章 仕様化技術の応用
おわりに
読後ひと言感想（読んだ直後にブクログに投稿したもの）
目的：要件定義のポイントを知る
要旨
要求とはシステムで実現してほしいこと。機能要求、品質要求、その他制限の３つがある
要求の仕様化≒要件定義
多くのバグは要求の仕様化がしっかりされていないことに起因する
USDMとは、要求から使用を抜け漏れなく導き出す技術である
要求は文章で書く。正しい仕様の範囲を定義し、動詞と目的語から仕様を網羅で導き出す
要求からのブレイクダウンがポイント。仮に仕様を思いついたとしても、その仕様だけでを抜け漏れがある可能性があるので、上位概念である要求を考え、そこから導き出される仕様を網羅的に考える
要求仕様書とは、システムで実現してほしいことについて、テストフェーズ含めた関係者がその内容について認識ずれなく具体的にイメージ(特定)できる文章のこと。また設計者がそのまま設計に入れる＝必要な情報が全てある文章
要求に対して理由を必ずつける。各関係者が本意を確認し正しく判断するため
テンプレート：カテゴリー→要求(要求番号)→理由→説明、仕様分類名(グループ化)→仕様(仕様番号)。要求は二階層になる場合がある
良いと思った点3つ
改めて要求の仕様化の大切さを認識した。最初が肝心
いきなり仕様(具体)で進めるのではなく、上位の要求(抽象)を考えてから付随する仕様を考えるという手法になほどなど思った。ファクト→抽象化→転用の話とリンクした
実経験からの言葉で書かれているので説得力を感じることができた
私の読後トライ
USDMで要求仕様を書く（仕事で書いてみました！）
常に上位概念（要求は何か、本質は何か）を考える
その他メモ
なし
おわりに
いかがでしたでしょうか。パパッと自分の課題にあっているか判断できましたでしょうか。
以上、パパッと見るブックレビュー『【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術』でした！