■ 1. 記事の概要
- タイトルは「おい、要件を動くものにしろ」であり AI時代における要件工学シリーズ第2部にあたる
- 要件は文書として残すものではなく 型システム・テスト・CI/CDパイプライン・コードスキーマ・自動レビューに埋め込まれた「動くもの」として存在すべきであると主張する
- ドキュメントは書かれた瞬間から腐敗が始まるが コードに埋め込まれた要件は毎日読まれ検証され続ける
■ 2. 要件・仕様・契約の定義整理とスペック駆動開発の分類
- 三つの概念の定義:
- 要件:ビジネスが達成したいこと
- 仕様:システムがその要件をどのように実装するか
- 契約:コンポーネント間の保証
- スペック駆動開発の3分類:
- スペックファースト:仕様は実装後に破棄される
- スペックアンカード:仕様は実装と並走して更新される
- スペックアズソース:コードは仕様を唯一の真実の源として導出される
- 著者はハイブリッドアプローチを推奨し 仕様が価値を生む箇所にのみ適用することを提唱する
■ 3. AIコードのレビューが困難な理由と信頼構築の方向性
- AI生成コードのレビューには通常の3倍の時間がかかる
- 原因は読む時間の増加ではなく「共有コンテキストの欠如」にある
- 人間のレビュアーが依存する暗黙のチーム知識をAIは持たない
- 解決策はより良いプロンプトではなく より良いコンテキストの提供にある
- 信頼構築のための4方向:
- ドメイン知識を明示的に構造化する
- 責任の境界を明確にする
- 実装前に要件合意を明示的に確保するようプロセスを再設計する
- AIへの指示をチームの共有資産へ移行する
■ 4. 要件の5層分散
- 原則:1つの要件は1箇所に配置し 検証されるタイミングによって配置先を決定する
- 各層の配置:
- プロジェクトレベル:CLAUDE.mdに記述する
- ドメイン固有:ドキュメントとスキルに記述する
- 機能固有:コミットメッセージ・PRテンプレート・テストコメントに記述する
- 手続き的:CIワークフローとリンティングルールに記述する
- 振る舞い:実行可能なテストスイートに記述する
■ 5. 主観的レビューの削減とアーキテクチャの役割
- 著者は「客観的／主観的 × 予防的／回復的」の2×2マトリクスを提示する
- AI時代のボトルネックは「主観的×予防的」の象限であり 自動化できない人間の判断を要する
- アーキテクチャによりこの象限を最小化する手法:
- 境界付きコンテキスト:意思決定の境界を明確にする
- 常に有効なドメインモデル:型によって不正な状態を表現不可能にする
- タイプファースト開発:型を優先して設計する
- 可変コードと不変コードの分離
- イベントソーシングによる説明責任の確保
■ 6. 受け入れ基準の実行可能化
- 曖昧な記述（例:「速くなければならない」）を具体的な形式に変換する
- 要件は「いつ・誰が・どこで・何を・どのように・どのくらい」の6要素で記述する
- 具体例:「ユーザーがクリックしたとき APIは200ms以内に応答する」という形式にする
- 「してはならないこと」と「明示的にスコープ外のこと」も記述する
■ 7. 非機能要件とトレードオフの管理
- 非機能要件（性能・セキュリティ・保守性など）は相互に干渉する
- セキュリティ強化は性能を低下させるなど 全てを同時に最大化することはできない
- 「上位3つ」の優先順位を特定し 何がハード目標（二値的合否）で何がソフト目標（程度による）かを認識する
- プロジェクトのフェーズが変化するにつれて優先順位を定期的に見直す
■ 8. 著者のスタンスと実践的原則
- 著者は「仕様書よりも検証を重視する」立場をとる
- 厚い要件ドキュメントよりも 厚いテストとガードレールを重視する
- 実践的原則:
- 要件は読まれる場所に記述する:別途ドキュメントではなくコードのコンテキストに記述する
- 測定可能なものは全て自動化し 本物の判断が必要なものにのみ人間のレビューを用いる
- 要件の進化を認識し「上位3つ」の優先順位をプロジェクト成熟に合わせて見直す
- 要件はカテゴリではなく検証タイミングによって配置する
- 書き込み操作と読み込み操作を分離しレビューの強度に差をつける
■ 1. 総評
- 記事の主張密度と文章量の比率が逆転している
- 核心的な主張は早期に確立されており 以降は同じ主張の繰り返しまたは傍証の積み上げに費やされている
- 記事全体は必要な分量の2倍に相当する
■ 2. 論理的に機能している部分
- 中心テーゼの明確さ:
- 「ドキュメントに置かれた要件は腐る 動くもの（テスト・型・CI・CLAUDE.md）に分散させた要件だけが毎回検証される」という主張が一貫している
- 撤回条件の明示:
- この種の実践知系記事では珍しく誠実であり 論述の信頼性を高めている
- 要件/仕様/契約の3区分:
- 実用的で読者に整理をもたらす
- 仕様駆動開発の文脈でこれを明示したことに価値がある
■ 3. 論理的に脆弱な部分
- 「動くものは腐らない」という前提の誤り:
- 著者自身が結論部でテスト・lintルール・CLAUDE.mdも古びると認めている
- 「腐らない」ではなく「腐ったとき気づきやすいかどうか」という違いを論じるべき
- 強い主張を採用したまま自己矛盾を抱えている
- 「3倍のレビュー時間」の根拠の脆弱さ:
- N=1の自己計測にすぎない
- この数値から「AIで書いたコードは構造的に信頼できない」という一般命題を導いており 観測規模と主張のスケールが不釣り合い
- 「5つの場所に散らす」処方箋の構造的問題:
- 処方箋を先に提示した後 その問題点として自らの失敗事例が続く
- 読者を混乱させる順序であり 「1つの要件は1つの場所」を前提として先に述べ 5つは「置き場の種類」として整理し直す必要がある
- 「AIのエラーは新種ではない」という主張の検証不可能性:
- 撤回条件として「AI固有で以前には観測されなかったエラーを列挙できたら撤回する」と記載している
- 「AI以前に存在しなかった新種エラー」の同定自体が主観的かつ困難であり 撤回条件が実質的に機能しない
- 4象限モデルの「主観×予防がボトルネック」の論証不足:
- 「他の象限が自動化・高速化したから相対的に目立つ」という相対論的推論のみで 「最大」と断言するには不十分
■ 4. 主張の冗長パターン
- パターンA（テーゼの繰り返し）:
- 「動くものに要件を散らす」「ドキュメントは腐る」「機械に判定させる」が複数の節でほぼ同一命題として再登場する
- パターンB（撤回条件の儀式化）:
- 5〜6回登場することでテンプレート的な免責事項に見えてくる
- 主要な主張に1〜2回絞った方が誠実さが際立つ
- パターンC（非機能要件節の逸脱）:
- 「トレードオフ」「Top 3」「時間軸の変化」「AIシステムの新しい品質要件」は中心テーゼとの接続が薄い
- 結論に辿り着くまでの道のりが長すぎる
- パターンD（個人エピソードの過剰使用）:
- マイナス在庫の失敗・深夜の差し戻し・空調管理システム・保持期間インシデント等 主張の補強よりページ数の補充として機能している場面が多い
■ 5. 構造的批判
- 記事は実質的に5本の異なる記事を1本に詰め込んでいる:
- 仕様駆動開発の用語整理と分類
- AIコードレビューの構造的困難
- 要件を実行可能な形へ変換する技法
- 認知負荷を減らすアーキテクチャパターン
- 非機能要件のトレードオフ管理
- タイトル「おい 要件を動くものにしろ」に対して読者が期待するのは「要件を実行可能な形へ変換する技法」のみ
- 仕様駆動開発の用語整理とAIコードレビューの困難は導入として機能するが アーキテクチャパターンと非機能要件管理は本記事の射程を超えている
- 4象限モデル以降は別稿にすべきであり そうすることで本論が締まる
■ 6. 結論的評価
- 中心テーゼの明確さ: 高い
- 論理の整合性: 中程度（自己矛盾あり）
- 証拠の質: 低め（個人観測が中心）
- 冗長さ: 問題あり（2倍の分量）
- 実務上の有用性: 高い（具体的な処方箋は有用）
- 「ドキュメントより実行可能なもので要件を保つ」という主張は正しく実践的な価値も高い
- 主張の強さに対して論証が追いついていない
- 分量を半分にして核心（要件を動くものへ変換する技法）に絞れば 説得力は現状より増す