AI のおかげで、マージされる PR は去年の倍になった。タスク管理ツールのチケットは、次々に「完了」へ移っていく。もはやチケットを切るのも追いつかず、チケットのない変更がそのままマージされていくチームも多いだろう。では、ユーザーが得たものや事業の数字は、果たして倍になっただろうか。
倍になっていないなら、数えているものが違う。クローズしたチケット、マージした PR、消化したストーリーポイント、リードタイム。どれも「いつ、何件終わったか」を示すアウトプットであり、点である。しかしアウトカムは、リリースしたあと、使われ続けるあいだに少しずつ積み上がっていく。点ではなく、時間とともに広がる面積である。
エンジニアの仕事は、アウトプットを増やすことでも、速度を上げることでもない。抱え続けるコード1行ごとに、どれだけの面積を生めるか。その効率を上げることである。
リリースした日、あなたのコードの価値はゼロである。
ユーザーが使い始めてはじめて、価値はあるペースで流れ出す。守れた売上、減った誰かの手間、避けられたリスク、依存してくれるプロジェクト。そのペースに、役に立ち続けた時間を掛けたものが面積になる。出荷が遅い、使われない、たびたび止まる。どれかひとつでもあれば、コミットログがどれほど賑やかでも面積は小さい。
費用対効果も生産性も、分子にあるのは面積である。速く出しても使われなければ、分子はゼロのまま分母の費用だけが増える。安く価値を買ったのではない。使われない機能に、お金と時間を払っただけである。
面積を本当に広げる仕事は、次の5つのどれかに当たる。
- 早くリリースする — 始まりを前倒しし、価値が流れる時間を長くする。
- 価値を厚くする — 単位時間あたりの成果を上げる。ユーザーの課題を、よりはっきり解く。
- いま価値を落とさない — 障害、壊れた導線、気づかれにくい不具合。面積に空く穴を塞ぐ。
- あとで価値を失わない — サポート終了、強制アップグレード、抜けられない基盤。未来の面積が消えるのを防ぐ。
- 続けられる状態にする — 次の変更が高くつかないよう、変えやすさを保つ。
新機能はたいてい 1 と 2 に、保守や信頼性の仕事は 3 から 5 に効く。狙う面積は同じで、触る辺が違うだけである。
ただ、どの打ち手を選んでも、手元にはコードが残る。
ビルのオーナーを思い浮かべてほしい。ワンフロア増築すれば、家賃収入が増える。同時に、建築費、入居者の募集、修繕、住人対応、退去対応、固定資産税がついてくる。空室のままでも、修繕費と税は毎年やってくる。コードも同じである。届いている機能が家賃を生み、残した1行には、レビュー、テスト、移行、オンコールがつきまとい、次に読む人の頭にも負担がかかる。OSS なら、Issue への返事と互換性の約束も加わる。どれも、その行が価値を生んでいるかどうかに関係なく。
総コード量が増えるほど、保守の割合も増える。人数を変えずに対象だけ広げれば、新しい価値に回せる余力は細っていく。維持するものを減らさずに前へ進み続けるには、人が増え続けるしかない。保守を AI で人間より安く代替できても、今度はその AI を保守するコストが加わる。
道はひとつしかない。維持するものを減らすことである。
だから削除と整理は、暇なときの掃除ではない。エンジニアリングの本業である。価値を落とさずに削ぎ落とせることこそ、卓越したエンジニアの証である。
使われない機能やオプション、終わった実験の残骸、誰も使わない互換のための継ぎ足し。これが 業務上の負債 である。空室と同じで、コストだけがあり、面積がない。消すべきである。消すのは面積のないコードであり、読めない短さに潰すことではない。同じミスを封じる抽象なら、行が増えても価値は上がる。
残るのはしばしば 実装上の負債 である。まだ価値を生んでいるが、安全に変えにくいコード。こちらは消さずに、いま生んでいる面積を壊さないよう直し、まとめる。目的は見た目のきれいさではない。次の面積を安く作れるようにすることである。先送りしても、結局は払う。利子付きで、しかもたいていは障害や強制移行のさなかに。
ソフトウェアファクトリーを組み、大量の AI が構築と保守を回すようになっても、工場を管理するのは人間である。
管理画面には、今日もマージされた PR の数が並んでいる。ある日、AI では直せない障害が起き、あなたは初めて工場の中を覗く。中はゴミだらけで、かろうじて出荷できている。
どうするだろうか。
まず、消すはずだ。面積のないコードを探し、残す1行ごとに、何の価値を生んでいるかを問うはずだ。その問いは、工場が止まる前から始められる。今日の差分からでいい。
AI の時代は、コードを増やす誘惑が強い。そこで踏ん張る。
コード1行あたりの業務価値を最大化する。
