はじめに

• 仕様にまつわるトラブルの頻発
• 要求仕様の不完全性
• Agileへの逃避の問題
• 適切に表現されなければ漏れる
• 派生開発での考え違い
• CMMとの遭遇
• CMMで見落とされたこと
• 仕様を誰が書くか
• 筆者自身の経験から編み出した方法
• この本にかける思い
• 構成について
• 謝辞

第1部　要求仕様にまつわる問題

• 第1章　要求仕様にまつわる問題
  • 1.1　どこで問題が発生しているか？
  • 1.2　要求仕様のトラブルの実態
  • 　1.2.1　仕様モレ
  • 　.2.2　解釈の違い
  • 　1.2.3　仕様の衝突（矛盾）
  • 　1.2.4　テスト不足
  • 　1.2.5　市場からの反撃も
• 1.3　曖昧な仕様で作業に入っている
  • 　1.3.1　構造が傷ついていく
  • 　1.3.2　“潜在バグ”の意味
  • 　1.3.3　仕様書の良否の判断ができない
  • 1.4　顧客からの仕様変更が頻発して……
  • 　1.4.1　現状はどうなっているか
  • 　1.4.2　最後になって機能に制限がつく
  • 1.5　要求した機能を満たしていない
  • 　1.5.1　専門のテストエンジニアがいない
  • 1.6　納期の遅れとなって表面化する
  • 　1.6.1　何度も作り直している
  • 　1.6.2　試作の発想が消えない
  • 1.7　品質要求に応えられないSE
  • 　1.7.1　保守性要求に居直るソフト会社
  • 　1.7.2　タイトルだけの要求仕様書の危険性
  • 　1.7.3　品質要求を見たことがない
  • 　1.7.4　品質要求を仕様化できない
  • 　1.7.5　設計技術にバリエーションがない
  • 1.8　派生開発での仕様トラブルはもっと複雑
  • 　1.8.1　ソースから仕様を理解できるか
  • 　1.8.2　変更要求（仕様）が表現されていない
  • 　1.8.3　変更要求がブレークダウンされない
  • 　1.8.4　でき上がりの仕様が書かれている
  • 　1.8.5　どこが修正されたのかわからない
  • 　1.8.6　異なる変更要求の修正が同じ箇所にぶつかる
  • 　1.8.7　一つの変更要求に複数の人が絡む
  • 　1.8.8　各自の修正を集めて動かしてみると？？
  • 1.9　設計書が省かれてしまう原因になっている
  • 　1.9.1　設計レベルの仕様と混同
• 第2章　なぜ仕様のトラブルが起きるのか
  • 2.1　問題が明らかにされたか？
  • 2.2　仕様化の作業を放棄した
  • 　2.2.1　それって仕様か？
  • 　2.2.2　要求が表現されていない
  • 　2.2.3　説明なのか仕様なのかわからない
  • 　2.2.4　概要に隠れる仕様
  • 　2.2.5　画面仕様も項目だけしかない
  • 　2.2.6　仕様化に必要な時間を投入していない
  • 2.3　ドメインの知識がない
  • 2.4　バグの経験だけでは役に立たない
  • 2.5　レビューできた仕様書か
  • 　2.5.1　どこに何が書いているのかわからない
  • 　2.5.2　“仕様”になっていない
  • 　2.5.3　まとめてのレビューになっている
  • 2.6　FIXした・しないでもめる理由
  • 2.7　途中で仕様変更が混乱する理由
  • 2.8　望みはある
• 第3章　要求仕様は不要か？
  • 3.1　テスト仕様で代われるか？
  • 3.2　仕様化しないほうが儲かる？
  • 3.3　“不完全な要求仕様”の誤解
  • 　3.3.1　はじめから要求を正しく把握することは困難か？
  • 　3.3.2　初期に時間をかけて“完全な”仕様化に取り組む価値はない？
  • 　3.3.3　予測するよりも“適応”するほうが重要か？
  • 3.4　“コードなら書ける”の仕組み
  • 　3.4.1　仕様を書くよりもコードを書くほうが早いか？
  • 　3.4.2　設計しながら仕様を探り出す？
  • 3.5　GUI構築ツールで仕様を引き出せるか？
• 第4章　仕様化の効果
  • 4.1　要求仕様がすべての始まり
  • 4.2　一気に解消する混乱
  • 　4.2.1　仕様の変更率が1／5に減った
  • 　4.2.2　仕様変更時に影響する仕様を確認できる
  • 4.3　設計や実装のイメージができる
  • 4.4　不用意な「試作」が減る
  • 4.5　設計や実装時に仕様の確認ができる
  • 4.6　レビューで感じる仕様化の効果
  • 4.7　トータル工数が短くなる
  • 4.8　設計に入る前に機能の難易が見える
  • 　4.8.1　早期にトレードオフの交渉ができる効果
  • 　4.8.2　仕様化でウォーターフォールの誤解を解く
  • 　4.8.3　インクリメンタル開発への切り替え
  • 4.9　顧客との良好な関係を築ける
  • 　4.9.1　“別に料金を払う”といってきた
  • 4.10　ITゼネコンとの訣別
  • 　4.10.1　分割発注への道
  • 4.11　要件管理に取り組める
• 第5章　要件開発の重要性
  • 5.1　文書にする理由
  • 5.2　“わかる”の問題に対応する
  • 5.3　なぜ“要求”仕様書というのか？
  • 　5.3.1　作ることを誘導できなければ意味がない
  • 　5.3.2　「作るための文書」であることの好都合
  • 　5.3.3　新規開発と派生開発の「要求」の違いをあらわす
  • 　5.3.4　派生開発では「差分」の分だけが“要求”
  • 　5.3.5　機能仕様書との関係
  • 5.4　要求仕様は誰が書くのか
  • 5.5　顧客からの要求仕様書を洗練する
  • 5.6　仕様モレと仕様間の衝突を早期に発見する
  • 5.7　要件開発をスケジュール管理のなかで行う
  • 5.8　要件開発と要件管理は車の両輪
  • 5.9　要求工学における世界の動き

第2部　要求仕様を書く

• 第6章　“要求”を書く
  • 6.1　要求の役割
  • 　6.1.1　要求には「範囲」がある
  • 6.2　要求の表現
  • 　6.2.1　要求の表現の難しさ
  • 　6.2.2　「範囲」をあらわしているか
  • 6.3　要求には「理由」がある
  • 　6.3.1　なぜ「理由」にこだわるか
  • 　6.3.2　要求と理由でセット
  • 　6.3.3　慣れないうちは理由に要求が混じる
  • 6.4　必要なら「説明」を付ける
  • 　6.4.1　要求の理解を助けるもの
  • 　6.4.2　用語集への展開
  • 6.5　要求のカテゴリ化
  • 　6.5.1　コンテキスト図でシステムの境界を明確にする
  • 　6.5.2　システムの世界を分割する
  • 6.6　要求のモレを防ぐことが重要
  • 6.7　品質要求を確認する
  • 6.8　品質要求の表現
  • 　6.8.1　機能に付随する品質要求
  • 　6.8.2　製品・システム全体に属する品質要求
• 第7章　要求の階層化テクニック
  • 7.1　要求を階層化して範囲を狭める
  • 　7.1.1　分割の基準
  • 　7.1.2　時系列分割
  • 　7.1.3　構成分割
  • 　7.1.4　状態分割
  • 　7.1.5　共通分割
  • 7.2　「MECE」の活用
  • 7.3　階層化しても「要求」に変わりはない
  • 7.4　依頼者と分割の基準を共有する
  • 7.5　階層は2層ぐらいで止める
• 第8章　要求を仕様化する
  • 8.1　仕様とは
  • 8.2　“Specify”の意味
  • 　8.2.1　均一である必要はない
  • 　8.2.2　ベテランを投入する意味
  • 8.3　仕様で衝突する
  • 8.4　いつ仕様化すべきか？
  • 8.5　検証可能性について
  • 　8.5.1　テストエンジニアによるレビュー
  • 8.6　固有の番号を付ける
  • 　8.6.1　番号の確定は少しあとに回そう
  • 　8.6.2　番号化における注意
  • 　8.6.3　要件の実現性追跡に重要な手掛かり
  • 　8.6.4　テストケース仕様とつなぐ
  • 8.7　要求の階層のなかで仕様を捉える
  • 　8.7.1　「範囲」が見えることで仕様が引き出せる
  • 8.8　さらに範囲を狭めるためのグループ化
  • 　8.8.1　要求の分割基準を準用
  • 　8.8.2　グループ分けのパターン化
  • 　8.8.3　要求の代役としてのグループ
  • 8.9　シナリオ機能と単純機能の違い
  • 　8.9.1　ユースケースだけでは仕様を拾いきれない
  • 　8.9.2　“フローチャート”の落とし穴
  • 8.10　仕様と要求の混在の問題
  • 8.11　仕様から要求を立てる
  • 　8.11.1　要求を立てる意味
  • 　8.11.2　ふさわしい要求に収容する効果
  • 　8.11.3　仕様を「裸」にしない
  • 8.12　“ペースト作文”の弊害
  • 8.13　「否定表現」などの曖昧な表現を避ける
  • 8.14　“FIX”から“賞味期限”へ
  • 　8.14.1　なぜFIX を要求するのか？
  • 　8.14.2　FIXに潜む落とし穴
  • 　8.14.3　その仕様は何に依存しているのか？
  • 8.15　品質要求の仕様化
  • 　8.15.1　機能に付随する品質要求の仕様化
  • 　8.15.2　保守性などの要求の仕様化
  • 　8.15.3　品質要求はテストでも確認する
  • 8.16　確定しない仕様の表現
  • 　8.16.1　「T.B.D」では合意できない
  • 　8.16.2　あとは要件管理でカバーする
  • 　8.16.3　依頼者と事前の合意が必要
  • 8.17　設計情報の扱い
• 第9章　Excelによる仕様化の勧め
  • 9.1　「Excel」のほうが細かな使い方ができる
  • 9.2　要求書と要求仕様書を一体化
  • 　9.2.1　最初に「要求書」を展開する
  • 9.3　要求TM（トレーサビリティ・マトリクス）への展開
  • 　9.3.1　仕様変更時に効果を発揮する
  • 9.4　自在に「列」を設計する
  • 9.5　WBSとの違い
  • 9.6　Excelで書くときの注意
• 第10章　派生開発における要求仕様書
  • 10.1　“部分理解”の世界である
  • 　10.1.1　人の書いたソースを理解できるか？
  • 10.2　要求仕様書の体系を持ち込む
  • 　10.2.1　“仕様”で出される変更要求
  • 　10.2.2　「変更要求」を立てることの効果
  • 10.3　旧状態を表現する
  • 10.4　何が変更されるかを表現する
  • 10.5　「差分」を書く
  • 10.6　変更の種類
  • 10.7　変更の要求
  • 　10.7.1　ソースの変更を変更仕様として記述する
  • 　10.7.2　スペックアウトしながら変更要求仕様を拾い出す
• 10.8　追加の要求
  • 　10.8.1　機能追加も実装レベルの仕様変更が不可欠
  • 　10.8.2　変更要求と追加要求に分ける
  • 10.9　移植の要求
  • 　10.9.1　移植は追加よりも難しいことがある
  • 　10.9.2　移植元の変更も変更要求仕様で扱う
  • 10.10　削除の要求
  • 10.11　派生開発の品質要求
• 第11章　画面仕様書のあり方
  • 11.1　画面仕様書の問題点
  • 11.2　画面操作全体に対する要求はあるか？
  • 11.3　個別の画面設計の指針としての仕様
  • 11.4　画面遷移と画面仕様を連携させる
  • 11.5　機能仕様との連携
  • 　11.5.1　重複は避けよう
• 第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.5.1　CCBは判断と指示を出すだけ
  • 　13.5.2　変更率5％以下の効果
  • 　13.5.3　最初のサイズ見積りが説得力となる
  • 13.6　未定義だった仕様が決まる
  • 13.7　いつ仕様変更を実施するか
  • 13.8　仕様変更を期間限定で募集する方法もある
• 第14章　仕様化の出来栄えを測る
  • 14.1　何を計測するか
  • 14.2　レビューでの指摘件数とバグ件数の関係
  • 　14.2.1　獲得時間の集計
  • 14.3　データは組み合わせると声を発する
  • 14.4　バグから学ぶ要件開発の方法
• 第15章　仕様化技術の応用
  • 15.1　リスク管理へ応用
  • 　15.1.1　「リスク」の表現に問題がある
  • 　15.1.2　要求と要求仕様の関係と類似
  • 　15.1.3　リスクと要因で「範囲」を示す
  • 15.2　課題への対応が見えずにうろうろする
  • 15.3　作り替えても前と変わっていない
  • 15.4　業務指示もその場で具体化しよう
  • 15.5　会社の方針がそのまま降りてくる