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