--- note: コードから復元できる層とできない層。要求だけが原理的に復元できない理由 created: 2026-08-08T22:30:29+09:00 --- # コードから何が読めるか 引き継いだシステムに、コードしか残っていないことがある。 前任者は退職し、設計書は初版のまま、要件定義書は見つからない。動いているコードだけがある。 このとき「コードを読めば全部わかる」と言われることがある。半分は正しい。 だが**層によって復元できる度合いは決定的に違い、要求だけは原理的に復元できない**。 その線引きを明らかにするのがこの文書の目的である。 これは4層モデルを逆向きに辿る話にあたる。 他の文書が「上から下へ書く」ことを扱うのに対し、ここでは「下から上へ読む」ことを扱う。 ## 復元可能性は層によって違う | 層 | 復元可能性 | 残っているもの | 消えているもの | |---|---|---|---| | 設計 | ほぼ完全 | 構造・技術選択・データモデル | 検討して採らなかった案とその理由 | | 仕様 | 高い | 入力・出力・条件・例外（分岐とバリデーションとして） | どれが意図的な決定で、どれが暗黙の既定値か | | 要件 | 部分的 | 何ができるか | 何ができるべきか。実装されなかった要件 | | 要求 | 復元不能 | なし | 目的・成功基準・スコープ外の判断・代替案 | 下の層ほどコードとの距離が近く、上の層ほど遠い。 これは「開発プロセスの全体像」で述べた抽象から具体への段階的詳細化を、逆から見たものである。 注意すべきは、この表の右列——**消えているもの**が、いずれも「判断」だという点である。 コードに残るのは判断の**結果**であり、判断そのものではない。 ## なぜ要求だけ復元できないのか 理由は2つある。 ### 写像が多対一である 上位層から下位層への対応は一対一ではない。 まったく異なる要求から、同じコードが生まれうる。 例えば「関連文書をキーワードで検索できる」という実装は、次のどの要求からも導かれる。 - 調査にかかる時間を短縮したい - 担当者が異動しても業務が回るようにしたい - 問い合わせに対して根拠を示せるようにしたい コードはこの3つを区別しない。区別する必要がないからこそ、実装として成立している。 多対一の写像に逆写像は定義できない。これは情報が失われているという以前に、**構造上の帰結**である。 ### 要求はシステムの話をしない層である 「開発プロセスの全体像」で述べたとおり、要求は唯一システムの話をしない層である。 主語がユーザーや発注者であり、対象がビジネスと業務である以上、 その内容はシステムの内部——すなわちコードには最初から現れない。 コードの中を探しても見つからないのは当然で、そこに書かれるべきものではなかった。 ## 意図と事故は同じ形をしている 復元をさらに難しくするのは、**判断の結果と偶然の産物が、コード上で区別できない**ことである。 `LIMIT 20` という記述を見つけたとする。この値の由来は少なくとも3通りある。 1. 業務上の判断。画面で一覧できる件数として決めた 2. 性能上の妥協。件数を増やすと応答が遅くなるため下げた 3. 由来なし。最初に書いた誰かの既定値がそのまま残った コードからはどれか判定できない。にもかかわらず、読み手は多くの場合1だと解釈する。 コードを読むという行為には、**そこに理由があったと仮定する**バイアスが伴う。 さらに厄介なのは、「層の越境パターン集」で挙げた上向きの越境が起きていた場合である。 設計上の制約が要求の目標を静かに書き換えていたとき（同 #10）、 コードには**要求が未達であるという事実まで含めて、整合した状態**が残る。 このコードから逆算すると、達成できなかった状態が「そういう要求だった」として読み取られる。 復元は失敗しない。誤ったものを、矛盾なく復元してしまう。 ## 手がかりと、その限界 読み取れるものがないわけではない。ただし、どの層に届くかを意識して使う必要がある。 | 手がかり | 読めること | 届く層 | |---|---|---| | テストコード | 想定された入力・出力・例外。当時「正しい」とされた振る舞い | 仕様 | | 分岐とバリデーション | 条件と制約。ただし網羅されているとは限らない | 仕様 | | 例外処理の偏り | 特定箇所だけ手厚い防御は、過去に障害が起きた痕跡 | 仕様〜要件 | | 権限・ロールの構造 | 誰が使うシステムか。ステークホルダーの構成 | 要件 | | 命名の揺れ | 立場の異なる関係者の言葉が混在した跡（同 #15） | 要件 | | コミット履歴・課題管理 | 変更の理由。**唯一、要求に届きうる情報源** | 要求 | このうち上5つは、どれほど丁寧に読んでも要件までしか届かない。 要求に届く可能性があるのはコード外の記録——履歴や議論の場——だけである。 マジックナンバーの扱いには補足が要る。 `LIMIT 20` から読み取るべきは値の意味ではなく、**そこに判断があったという事実**である。 値の意味は推測するのではなく、確認すべき項目として記録する。 ## 逆算の罠 コードから要求を推測し、それを要求定義書として書き起こすことには固有の危険がある。 書き起こした瞬間、それは**現状追認の装置**になる。 実装の都合で決まった値が、要求という最上位の権威をまとって固定される。 以降の変更は、その「要求」との整合性を基準に判断される。 これは上向きの越境（同 #9・#10）を、文書化によって恒久化する行為にあたる。 越境はもともと記録されないことが問題だったが、 逆算による文書化は、越境を**正式な決定として記録してしまう**点でより悪い。 生成AIに読ませる場合、この危険は増幅される。 コードを渡して要求を尋ねれば、必ずそれらしい要求が返ってくる。 形式は整い、文体は自信に満ち、検証の手がかりだけがない。 判断の基準はここでも同じである。 **その要求を「正しい」と検証できるのは発注者やユーザーであり、コードではない。** コードは要求の検証者になれない。検証者のいない文書は、合意ではなく推測の固定である。 ## 実務的な着地 引き継いだシステムに文書がないとき、次の方針をとる。 - **復元するのは仕様まで**。コストに見合い、テストコードという裏取りの手段もある。設計はコード自体が最新の記述なので、改めて書くのは変更の理由に限る - **要件は列挙にとどめる**。「何ができるか」は書けるが、「何ができるべきだったか」は書けない。実装されなかった要件は観測できないため、一覧は常に不完全である - **要求は人に聞く**。関係者が残っていれば聞き、いなければ「不明」と書く。**空欄のほうが、推測で埋めた欄より価値がある**。空欄は問いとして残るが、埋まった欄は問われなくなる - **推測を書くなら出所を明記する**。「観測された振る舞いからの仮説」と書き、検証者を人に戻す。仮説と合意事項を同じ体裁で並べない ## まとめ - コードに残るのは判断の**結果**であり、判断そのものではない - 復元可能性は層に依存する。設計と仕様は高く、要件は部分的、要求は原理的に不能 - 上位から下位への写像は多対一であり、逆写像は存在しない - 意図と事故はコード上で同じ形をしており、読み手は理由があったと仮定しやすい - 逆算した要求の文書化は、越境を正式な決定として固定する - 迷ったら問う。**この判断は誰が検証するのか**。コードは検証者ではない 文書は工程の副産物ではなく、判断が行われた証拠である。 コードしか残っていない状況とは、判断の結果だけが残り、証拠が失われた状況にほかならない。