根拠で進める開発仕事術：検索戦略・検証・引用の実務

第3章：仕様読解（前提/用語/例外/互換性）

この章で学ぶこと

  • 仕様を“前提/定義/例外/互換性”に分解して読む
  • 未解決事項を残したまま意思決定しない
  • 仕様メモをテンプレで標準化する

成果物（または判断基準）

本文

仕様は文章量が多く、読み飛ばしが発生しやすい。テンプレで“読む観点”を固定する。

手順（最小）

  1. 対象バージョンと適用範囲を固定する（「どこからどこまで読むか」を決める）
  2. 用語定義と規範的キーワード（MUST/SHOULD/MAY）を先に確認する
  3. 例外（エラー/境界条件）と互換性（変更点/移行条件）を抜き出す
  4. 未解決事項（曖昧/未記載/矛盾）を明示し、結論に混ぜない
  5. 仕様読解メモとして残し、必要に応じて検証計画へ接続する

仕様読解で拾うべき項目

  • 前提（適用範囲、対象バージョン）
  • 用語（定義があるか）
  • MUST/SHOULD/MAY（強制度）
  • 例外（エラー、境界条件）
  • 互換性（既存挙動との違い）
  • 未解決（既知の制約/残課題）

MUST/SHOULD/MAY（要件レベル）の扱い

仕様やRFCの MUST/SHOULD/MAY は「規範的キーワード」であり、単なる強調ではない。推奨（SHOULD）を必須（MUST）と誤読すると、過剰対応や誤実装に直結する。

  • MUST: 必須（満たさない実装は仕様違反）
  • SHOULD: 強い推奨（正当な理由がある場合のみ例外を許容）
  • MAY: 任意（実装/運用の裁量）

用語の定義は RFC 2119 および RFC 8174 を一次情報として参照する（付録: 参考文献）。

注意点

  • 訳文・要約は補助として扱い、最終判断は一次情報（原文）で要確認とする
  • 仕様と実装が食い違う場合がある。仕様違反（バグ）なのか、仕様の改訂や例外条件なのかを切り分けて記録する

具体例（悪い例→良い例）

悪い例

仕様の結論: たぶんこういう意味
根拠: 斜め読みした印象

良い例

前提: v2.3 以降に適用
用語: "Session" は 5分間の不活動で失効
例外: ネットワーク断のときは再試行するが、最大 3 回
未解決: 互換モードの扱いは別節に記載（要確認）

チェックリスト

  • 前提（適用範囲/バージョン）を抜き出した
  • 用語定義を確認した
  • 例外/境界条件を抜き出した
  • 未解決事項を明記した

まとめ

  • 仕様は「前提/用語/要件レベル/例外/互換性/未解決事項」に分解して読む
  • MUST/SHOULD/MAY は規範的キーワードとして扱い、誤読を避ける（RFC 2119/8174）

次章への接続

Edit this page on GitHub