10年後、システムを読める人は何人残るか——AIコーディング時代の盲点
2026.06.12執筆者：DigKnow株式会社 CTO 桑原 脩
10年前にローンチされたシステムが、いまも会社の売上の中心にある——そんな現場は、思っているより多いはずです。そして、そのシステムを書いた当時のメンバーは、いま何人残っているでしょうか。多くの会社で、答えは「片手で足ります」になります。10年後、同じことが、いま動いているコードに起きないと言えるでしょうか。読める人は、確実に減っていきます。
「読める人の数」は、ふつう棚卸しされない
会社のバランスシートには、システム資産が金額で載っています。減価償却も計算されています。一方で、「そのシステムを読める人間の数」は、どこの会社の決算資料にも載っていません。
ところが、システムを動かし続けるためのコストの本質は、サーバー代やライセンス料よりも、読める人を確保し続ける費用のほうにあります。新機能追加でも障害対応でもセキュリティパッチでも、まず必要になるのは「このコードを読み解いてリスクを判定できる人」だからです。
この人数を、自社のシステムごとに棚卸しした経験はあるでしょうか。コードの行数は数えられます。テストカバレッジも測れます。でも「このコードを読める人の数」は、誰も数えていません。数えられていないからこそ、減っていることにも気づかれないのです。
10年というスパンで考えると、この見えないバランスシートが効いてきます。
10年でエンジニアは何人入れ替わるか——属人化問題
エンジニアの平均在籍年数は業界で幅がありますが、感覚値で言えば3〜5年というレンジに収まることが多いように思います。10年スパンで考えると、ほとんどのチームでメンバーは一巡します。場合によっては二巡します。
ここで素朴な計算をしてみます。あるシステムをいま5人のエンジニアが理解しているとして、10年後、同じ深さで理解している人は何人残っているでしょうか。
– 5人のうち、10年後も同じ会社に在籍している人：おそらく1〜2人
– そのうち、同じシステムを継続して触り続けている人：さらにその一部
– 退職した人の代わりに入った人で、同じ深さに到達している人：これが本題
最後の項目が見落とされやすい部分です。新しく入った人が「読める」ようになるには、既存メンバーから引き継ぐか、ドキュメントから読み取るか、コードから自力で再構築するか——このいずれかが必要になります。引き継ぎは、引き継ぎ元が在籍しているうちにしかできません。ドキュメントは、書かれていなければ機能しません。自力再構築は時間がかかりますし、設計意図までは復元できません。
つまり、10年後の理解者の数は、過去10年でどれだけ「知識の伝達経路」を確保してきたかで決まるということです。経路を作っていないチームでは、メンバー交代のたびに理解の総量が静かに減っていきます。これが属人化の時間軸での姿です。
「読める」は、コードを字面で追えることではない
ここで一度、「読める」という言葉の中身を分解しておきます。エンジニアが「このコードが読めない」と言うとき、それはたいてい、シンタックスがわからないという意味ではありません。`if`文も`for`ループも誰でも読めます。読めないのは、その先です。
– なぜこの分岐が存在するのか（仕様か、過去の障害対応か、特定顧客向けか）
– なぜこのテーブルにこのカラムがあるのか（廃止予定か、まだ使われているか）
– なぜこの処理がこの順序で書かれているのか（依存関係か、パフォーマンスチューニングか）
– なぜこのライブラリが選ばれているのか（互換性か、当時の選択か、消極的理由か）
こうした「なぜ」がわからないコードを変更すると、副作用が読めません。手を入れられないコードは、機能追加もできず、リスクを抱えたまま放置されます。
「読める」とは、変更しても安全だと判断できる状態のことです。字面を追えることではなく、変更の影響範囲を見通せることを指します。この意味での「読める人」は、コードに加えて「コードに書かれていない情報」を持っている人のことです。そして、コードに書かれていない情報は、書き留めておかなければ消えます。人の頭のなかにしかない情報は、その人が辞めた瞬間にゼロになります。
AIコーディングは、この時計を早回しする
ここまでの話は、AIコーディングがなくても起きていた問題です。エンジニアが入れ替わり、コードが読まれなくなり、システムがブラックボックス化していくのは、業界で長く続いてきた現象です。
AIコーディングが効いてくるのは、この時計の進む速さです。AIが介在することで、コードを書く速度は確実に上がります。しかし、書かれたコードのうち、人間が「なぜそうなっているか」を完全に把握している比率は、確実に下がっているように感じます。AIが提案した実装をそのままマージしたコードは、書き手のなかにも「字面以上の理解」が残りにくい。
つまり、書かれた瞬間から「読める人がゼロ」のコードが、現場に増えていきます。これは10年後の話ではなく、今この瞬間に進行している話です。
レビューを通っても、テストが通っても、その時点では問題なく動きます。問題になるのは、半年後、一年後、誰かが障害対応で開いたとき、あるいは仕様変更で手を入れる必要が出たときです。書かれたときに理解されていなかったコードは、後から理解しようとしても、たいてい誰の頭のなかにも答えがありません。
10年後の話が、いまの開発速度の問題と地続きになっていきます。AIへの依存度が高まるほど、書いた本人すら10年後に説明できないコードの比率が上がっていく。AIが進化するほど、人間が理解できないコードが増えていくという逆説については、今後の記事で改めて掘り下げていく予定です。
「読める人」維持の三つの選択肢——技術的負債対策
10年後に「読める人」を確保するために、現実的に取りうる選択肢は、大きく三つに分かれます。
① 人を留める：個人依存戦略の限界
特定のシステムを理解している人を、長期にわたって会社に留め続けるアプローチです。報酬・キャリアパス・関係性を整え、退職リスクを下げる。これは有効ですが、人事的な打ち手には限界があり、特定個人の人生の都合にも依存します。一人の退職で全体の理解が崩れるリスクは、消えません。
② 知識を分散する：横展開のコスト問題
ペアプロ、モブプロ、コードレビュー、設計議事録の共有——特定の人物に集中している知識を、複数人に薄く広げます。ただ、コストが高い。AIコーディングで実装速度が上がったぶん、議論の時間を増やすのは現実問題として難しい場合が多いでしょう。
③ 構造化して残す：ドキュメントという古典的な打ち手
設計判断、仕様の意図、過去の選択理由——コードの外に書き出して、人の出入りに依存しない形で保管します。「ドキュメントを書く」という昔から言われてきた話ですが、業務の合間に手書きで維持し続けるのが難しいことは、業界が経験してきた通りです。
この三つは、どれか一つを選ぶというより、比率を組み合わせて運用するものです。10年というスパンで考えると、①と②だけに頼る組織は、人の入れ替わりに対して脆くなります。③の比率をどこかで上げる必要が、いずれ訪れるはずです。問題は、その③をどう持続可能な形で運用するか、という話に行き着きます。この点については、今後の記事で順を追って掘り下げていきます。
まとめ
10年後、自社のシステムを読める人が何人残っているかは、ふつう棚卸しされません。ですが、システムを動かし続けるための本当のコストは、そこに眠っています。エンジニアは10年で一巡し、コードに書かれていない情報は退職とともに消えていきます。AIコーディングはこの時計を早回しし、書かれた瞬間から「読める人がゼロ」のコードを増やしていきます。読める人を維持する打ち手は、留めるか、分散するか、構造化して残すか——③の比率を上げる必要が、いずれ訪れるはずです。