保守の単位は、
コードから文脈へ。

コーディングが速くなった話は、氷山の一角だ。水面下で起きているのは、保守フェーズそのものの構造変化である。

1-01 で、AI が最強の SIer になったという事実を据えた。コードを書くだけでなく、文脈を理解して設計までする、という事実だ。ここから最初に派生する帰結は、よく語られる「コーディングが速くなる」ではない。保守の構造が組み替わることだ。この章は、その組み替えを見る。

ソフトウェアの一生で、コーディングは最初の数ヶ月にすぎない。残りの長い年月は保守だ。そして保守は、ソフトウェアの費用の 4〜8 割、平均して 6 割 を食う (Robert L. Glass, "Frequently Forgotten Fundamental Facts about Software Engineering", IEEE Software 18(3), 2001)。四半世紀前に整理され、それより前から測られてきた事実である。

いまの保守は、すべてがコードの周りで回っている

AI の話題でよく取り上げられるのは、コードが速く書けることだ。これは事実だが、氷山の一角でしかない。ソフトウェア開発の支配的コストは、書くことではなく、書いた後にある。1980 年代から繰り返し測られてきたことだ。水面下に隠れている本体は、これだ。

• 既存コードの読解 ── 保守の中で最も支配的な活動
• 既存の挙動を壊さずに直す
• テストの追従 ── 後回しになる
• ドキュメントの追従 ── 通常は乖離したまま
• 仕様の暗黙化 ── 関係者がいなくなったら復元できない
• 技術的負債の蓄積 ── 毎年ゆっくり、確実に

旧来、保守の単位はコードだった。バグが出る。コードを読む。コードを直す。テストを書く。ドキュメントを直す。すべてがコードの周りで回る。中でも最大の単一コストは、既存コードの読解だ。

ここには数字がある。Glass は、保守の中で支配的な活動は「既存の製品を理解すること」であり、保守時間の約 3 割を占めると書いている(前掲)。実測もある。開発者 78 人の作業時間 3,148 時間を記録した調査では、作業時間の 約 6 割 がコードの理解に使われていた。しかも、経験の浅い開発者ほどその比率は高い (Xin Xia et al., "Measuring Program Comprehension: A Large-Scale Field Study with Professionals", IEEE Transactions on Software Engineering, 2018)。

退職した前任者の意図ごと読み解く作業は、時間をかけても完全には復元できない。レガシーを触れないことが、システム全体の延命を強いてきた。書き換えコストの大半が、読解コストだったからだ。

そもそも、なぜすべてがコードの周りで回るのか。設計書が、現実に追いつけなかったからだ。顧客は、細かい要望を言葉で SIer に伝えきれない。動くものを見て、初めて「ここはこうしたい」と気づく。SIer の側も、変更のたびに設計書を直すのは手間なので、設計書ではなくコードを直す。こうして設計書は更新されないまま取り残され、現実に追いついている資料はコードだけになる。「コードを読むのが一次資料」という常識は、ここから生まれた。

そして、この常識が「vibe coding」を生む。コードが一次資料なら、コードさえ書ければいい、という発想になる。動けばいい、出力さえ出れば正解だ、と。だが、これでは意味がない。設計も仕様も文脈も持たないコードは、たとえ動いても、何のために何をしているのかが分からない。書いた本人にも、次に読む者にも分からない。積み上がるのは、読めず、直せず、信頼できないコードの山だけだ。コードが書けること自体には、ほとんど価値がない。

AI が文脈を理解するから、コードでの保守は要らなくなる

ここで 1-01 の一点が効いてくる。設計の核心は文脈の理解であり、AI はそこに達した。AI は、システム全体の文脈を読み解ける。構造も、意図も、経緯もだ。

そして、理解した文脈を、AI は二つの形に書き起こせる。一つは、人間用のマニュアルだ。どう使い、どう運用するかを書く。もう一つは、機械用の設計書だ。構造と仕様を書く。AI 自身がコードを生成する拠り所になる。かつて、人間が面倒がって更新せず死なせた設計書を、AI が文脈から自動で書き、保つ。人間はマニュアルを読む。機械である AI は設計書を読んで、コードを生成し、再生成する。

その設計書は、どこに住むのか。保守の単位が文脈に移るなら、文脈の置き場が、そのまま保守の基盤になる。答えは自立編で据える ── 原稿と同じく文字で持ち、 git に入れる(2-06: コードを手元に・ 2-07: 文書を取り戻す)。文字なら、人も AI も同じものを読み、差分も履歴も残る。設計書が死ぬのは、文字でなく、履歴も残らない場所に置かれたときだ。

ここから、大きな帰結が一つ出る。*マニュアルを理解でき、それを現実に合わせられる人なら、開発も保守もできる*。コードを読む必要も、書く必要もない。難しいことを決める必要もない。マニュアルを読んで、自分の現実にあわせるだけだ。コーディングの経験は、前提ではなくなる。この点は、1-05 で「顧客自身が作る」として展開する。

チェックの側も同じだ。設計書のレビューも、コードのセキュリティ監査も、 Mythos/Fable クラスの AI ができる。攻撃の構造を組み立てられる力(1-01)は、裏返せば、弱点を見つけて塞ぐ力でもある。そしてその水準は、大手の SIer を上回る。レビューやセキュリティチェックを外注する理由は、もうない。委託そのものが成り立たなくなる構造は、転換編で扱う。

設計・仕様・文脈は、AI に渡す最初の仕様になる

保守の単位が設計・仕様・文脈に移るなら、書くべきものも決まる。何を使い、何を使わないか。どこに置き、どこまでを自分で持つか。どこから先は借りるか。その決定を、文字で持つ。これが、AI に渡す最初の仕様になる。

渡すのはコードではない。コードの書き方は AI が知っている。AI が知らないのは、この会社が何を選び、何を選ばなかったかだ。それだけが、人の側に残る。

この連載の自立編は、その形で書いてある。各章は手順の実演ではなく、決定の一覧だ。章をそのまま AI に渡せば、作り始められる。保守のときも同じ章に戻る。決定が変わったら、章ではなく決定を直し、AI に作り直させる。

まとめ

コードでの保守が要らなくなり、現場で保守ができる。保守の単位は、コードから設計・仕様・文脈に移った。最大の単一コストだったレガシーコードの読解は、消える。

この変化は、二つの問いを突きつける。個人としては、コードを書くこと自体を仕事の中心に置く役割、つまりコーダーはどうなるのか。組織としては、開発を請け負ってきた SIer は、まだ要るのか。

次の章では前者を扱う。コーダーという役割そのものの話だ。後者、SIer が不要になる構造は、転換編で扱う。

関連記事

• 1-01: AI は、世界で最も難しいコーディング問題を解く
• 1-03: ソフトウェアエンジニアの仕事を AI がするようになる
• 1-04: ビルダーという役割
• 2-04: 処理を書く ── Python と Flet で、自分の道具を持つ
• 構造分析08: 企業ITの税を引く