「要求を仕様化する技術 表現する技術」読書メモ - 第1部第1章 要求仕様にまつわる問題
「改訂第2版 [入門+実践] 要求を仕様化する技術 表現する技術」（清水吉男著/技術評論社）
を読み始めました。読み切れるか大いに不安ですが、序盤からぐさぐさ刺さってきて周りの人に本当読ませたい。
第1部第1章ざっくりまとめ
- 問題プロジェクトあるある
- 実はバグの大半が要求仕様に関係している
- 開発者側に要求仕様書を書くスキルがないことが問題
ほんとこれな
残念なプロジェクト
今回のプロジェクトは納期も大きく遅れた上に、テストしてみると要求した機能も十分に達成していない、という状態はしばしば発生しています。特に、異常操作の対応や全体の操作性や応答性などの品質が悪く、とても完成したものとは認められないケースもあります。
いったん製品が市場に出ると、それが競争相手からターゲットにされるので、その状態で次々と新しい機能を組み込んだり短期間で機能を改良したりすることが求められます。それができなければ市場から退場させられるのです。
双方の機能が拮抗している状態では、的確なデリバリを実現できるだけで市場を獲得できることがあるのです。
それを支えるのは保守性などの品質要求を実現するための設計技術なのです。
設計や実装の工程で明らかになった「仕様」は要求仕様書に書き戻されることはない
仕様が曖昧な状態をカバーしてくれるような設計技術はありません。あるとすれば、設計中にそこで扱っている機能の仕様の曖昧さに"気づかせてくれる"程度です。そのときに気づいたことを仕様書に書き戻さなければ、他の仕様との衝突や不均衡には気づかないのです。
顧客にまともな要求仕様書を書く能力がない => 設計者が要求の仕様化技術を習得する必要がある
依頼者にはまともな要求仕様書をかけないと認識していながら、自分たち（設計者側）はそれをカバーする手段を持とうとせず、仕様変更で混乱する責任を依頼者のせいにしているように見えます。
（略）
確かに、設計者達は、効果的な要求仕様書の書き方を身につけていることはほとんどありません。少なくとも、そのような訓練を受けていないと思われます。
（略）
したがって、まずは設計者に要求の仕様化技術を習得してもらう必要があります。実際にそれを解釈しソースコードに変換するのは、ソフトウェアエンジニア（設計者）の方ですから。
品質要求を仕様化できない
機能要求に限らず品質要求も、仕様化されない要求は実現しないのです。
もともと、機能要求でもうまく仕様化できないために、多くのトラブルが発生しているのです。それは、要求を仕様化する技術が不足していることを意味しています。ましてや、品質要求なんて仕様化したことがないのです。
メモ
バグの過半数が要求仕様に関連するもの
- 仕様の記述モレ
- 読み手による仕様の誤解釈
- その仕様が自分に関係すると気付いていない
- テストの段階で検出される仕様間の衝突
- （（要求仕様の問題によって発生する）設計の遅れによって生じる）テスト不足
- （要求仕様が提示されない・または提示の遅れによる）テストの遅延・不足
memo: 自案件でも本当にそうか？は要分析。個人的印象では上記に該当するものは確かに多い。
バグの原因プロセスを分析する際、「設計プロセス」とする組織は多いが、設計エラーではなく仕様エラーとした方が解決しやすい場合がある
届けられたデータをチェックしないでそのまま使ったところ、たまたま不正データが入ったままのデータに遭遇したことでプログラムが暴走した
(略)
受け取ったデータをそのまま使用してはならないことを知らされていない状況では、設計エラーではなく、仕様エラーと分類
- 設計エラーとすると「設計者が気付く」か定期的に注意アナウンスするしかない（具体的な解決策がない）
- 仕様エラーの場合、気付くような書き方をする、という改善ができる
- 派生開発での変更モレはほとんどが設計エラーに分類されるが、これは「実装仕様の変更を変更仕様として書き出す」という考え方がないため
memo:
とはいえ、自然言語で書かれた要求仕様書に完璧はない。精々仕様モレなどの発生確率を許容範囲のレベルに下げるだけ、とのことですが。
顧客からの仕様変更 => 実は設計者が問い合わせたタイミングで発生することが多い
設計者がコーディングを進めていく中で仕様の曖昧な箇所に遭遇し、そこで依頼者に質問のメールや確認のメールを発したことが仕様変更のきっかけになっているのです。
- 依頼者は仕様と呼べるものを書けないことが多い
- 設計者も早い時期に仕様の不足をカバーできていない
- 仕様変更の多くは、設計者の問い合わせをきっかけに起きている
- しかも設計段階から実装段階にかけて多発しているために作業が混乱している
仕様戦争
- 終盤に発見された仕様の衝突は「（要求仕様の不備（=依頼者の責任）によって生じた）制限」として依頼者に提案される
- 依頼者は提案を受け入れる代わりに他の「追加仕様」をねじ込む
- 設計者側は提案タイミングが遅すぎることの気まずさから負荷の大きい追加仕様を受け入れざるをえない
- 「初期の段階で仕様不備に気づき、補足すること」はできない（設計者が要求仕様化スキルを持たないため）
要求を満たさない
今回のプロジェクトは納期も大きく遅れた上に、テストしてみると要求した機能も十分に達成していない、という状態はしばしば発生しています。特に、異常操作の対応や全体の操作性や応答性などの品質が悪く、とても完成したものとは認められないケースもあります。
この本でその最大理由として挙げられているのが、
- 「要求仕様書」が「仕様」といえるレベルに達していない
- 完成品として含まれるべき「品質要求」も記述されていない
- 関係者が、その不十分さに気づくためのスキルを持ち合わせていない
試作の弊害
- 「実現可能か分からない要求仕様」は細かい仕様に展開されず、試作で確認されることが多い
- しかし、安易な試作は仕様化・矛盾の検証などの不足につながる危険性がある
- 仮の要求仕様であっても、「それを実現する場合に必要な仕様」を決めることで「仕様衝突の検出」などできる
- 仕様には設計方法を誘導する力がある
派生開発のリスク
- 特に派生開発において、ソフトウェアの全体を理解して開発することは実質的に不可能
- 部分理解で対応せざるをえないにも関わらず、対応ミス・モレによる既存機能への悪影響は許されない
- また、他人のソースコードから元の要求・設計思想を理解するには新規開発より高い技術が求められる
- 一つの変更要求が複数の開発者に影響する場合、「関係することに気づかない（or伝えられない）」「（要求が曖昧な場合）人によって要求の解釈が違う」などが生じる可能性がある
memo:
1.8.3あたりの監視カメラの例は、この本ベースの勉強会するなら例題としてよさげ。
例えば
- 参加したばかりの派生開発プロジェクトでこの要求の対応見積もりを依頼された。どのようなことを考えるか？
- （隠れていた要求仕様を明らかにした後で）同様の事例を経験したことはあるか？
- このようなリスクがあることを踏まえて、見積もりをどのように扱うのがよいか？（対顧客・チーム内それぞれ）
とか。
設計フェーズの成果物が設計書ではなく要求仕様書になってしまう
- 本来の設計は（要求仕様をもとに）「データ構造・処理構造・制御構造」の3つの視点から（要求仕様の）実現方法を考えること
- 設計には「アーキテクチャ設計・タスク設計・関数設計」などの段階があり、それぞれで上記各視点を用いる
- 設計書とは設計の各段階で考えたこと、決めたこと（=仕様）が書かれたもの
- 各段階の仕様は「元となる要求仕様と対応する」が「元の仕様を補足するものではない」
- 設計の元になる要求仕様書が不完全な場合、設計の中で仕様が補われ、「設計書」としてまとめられる
memo:
設計には段階がある、というのはいわゆる外部設計・内部設計や詳細設計、などと読み替えてもよいのかも。
大事なのは 「設計書に書くべきなのは"元となる要求仕様の補足"ではなく"要求仕様に対応する（より低レイヤの）仕様"であり、そうなっていないなら元の要求仕様書に問題がある」 ということか
本には直接的に書かれていないけど、これによる問題は以下？
- 設計書内の要求仕様が要求仕様書にフィードバックされないので要求仕様として管理されない・仕様の衝突や誤解釈に気づかない・仕様が関係者に伝わらない
- 本来やるべき設計の時間が圧迫され、設計不備のリスクが増加
