以前の記事で「AIは地頭が良く自信過剰な新人」という比喩を使いました。個人としてAIとどう付き合うかを中心に書いてきましたが、組織レベルで考えると別の論点が見えてきます。
新人の比喩を組織に広げると、こんな問いが立ちます。
コードベース全体がAIで書かれたもので埋まったとき、その組織は健全に回るのか?
- 短期的には問題に見えにくい
- レビューだけでは成長しない
- レビューの観点も、書く経験から育つ
- AIレビューを信用する危険性
- シニアが育たない、維持されない
- ジュニアが育つ機会を失う
- 誰も全体を理解していない
- 責任を取れる人がいなくなる
- では、どうするか
- 組織として問うべきこと
- まとめ
短期的には問題に見えにくい
AIで書かれたコードだらけのコードベースは、短期的にはむしろ良く見えることがあります。
- 表面的な品質(命名、フォーマット、型)はAIが上手い
- 速度は出る
- テストも書かれている
- レビューも通る
「動いているし、品質も悪くない、ベロシティも上がっている」── 短期的な指標で見ると、何の問題もないように映る。むしろ良くなっているように見える。
ただ、ここにじわじわ進む問題が隠れている気がしています。
レビューだけでは成長しない
ここが一番大事な論点かもしれません。
「AIに書かせて、人間はレビューすればいい」という発想は、短期的には合理的に見えます。実装の手間が省けるし、レビューする側は判断力を使うので、能力が落ちないように思える。
でも、レビューと実装は別のスキルです。
実装は、悩みながら手を動かす作業です。「どう設計するか」「どこに依存を置くか」「どのライブラリを選ぶか」「このエッジケースはどうするか」── 数えきれない小さな判断の積み重ねが、コードに結晶化します。書く側は、その判断のプロセスを身体で経験する。だから、似た問題に当たったとき、過去の判断を引き出せる。
レビューは、完成品の良し悪しを判断する作業です。書く側が経たプロセスは、レビュアーには見えない。「結果として良いコードか」は判定できるけど、「そこに至るまでの試行錯誤」は経験しない。つまり、レビューだけしていると、判断のプロセスを経験する機会がない。
新人エンジニアにいきなりレビューだけ任せても育たないのと同じで、シニアエンジニアもレビューだけでは育たない、維持もできない気がしています。
数年このスタイルを続けると、レビュー自体の品質が落ちていく、育たない、という問題が起きます。コードを書く経験がないと、何を見るべきか、どこに罠があるかが分からないので、表面的なチェックしかできなくなる。
「動いていそう、テストも通っている、特に問題なさそう」で通してしまう。本当はそこに重大な問題があっても、観点がないので気付けない。
コードを書ける人と、コードの良し悪しを判断できる人は、重なる部分はあるけど別物。書く経験の少ない人のレビューは、判断の解像度が低い、というのが正確な言い方かもしれません。
レビューの観点も、書く経験から育つ
さらに踏み込むと、レビューのスキル自体も、書く経験がないと育たない気がしています。
レビューで「ここが問題」と指摘するには、何が問題かを知っている必要があります。問題を知るには：
- 自分で書いて失敗した経験
- 失敗したコードを後で苦労して直した経験
- 過去に似た問題で痛い目に遭った経験
- ライブラリのバージョンアップで壊れて慌てた経験
こういう書く側で得た経験が、レビューの観点を作ります。
書いていない人は、何が問題になるか分からない。だから、AIの書いたコードを見ても、「動いていそう、テストも通っている、特に問題なさそう」で通してしまう。観点が育たないので、見るべきところが見えない。
「観点はチェックリストにすればいい」と思うかもしれませんが、これは難しい。シニアの頭の中には、明示できないパターン認識が大量にあります。「なんとなくおかしい」という感覚は、言語化すると本質が落ちる。チェックリストの項目は通すけど、その奥にある問題に気付けない、ということが起きます。
経験は、文章にして渡すのが難しい。これは別の機会に書きましたが、レビューの観点も、その「渡しにくい経験」の塊なんだと思います。
AIレビューを信用する危険性
「人間のレビューが弱くなるなら、AIにレビューさせればいい」と思うかもしれません。実際、AIレビューは便利で、私もよく使います。ただ、AIレビューには構造的な限界があります。
- AIはコードベース全体の文脈や歴史を知らない(なぜこの設計になったか、過去にどんな失敗があったか)
- AIはドメイン固有の重要度を判断しにくい(どの処理が業務上クリティカルか)
- AIは「動いているか」は判定できるが、「長期的に保守できるか」の判断は弱い
- AIは自信過剰なので、見落としを「問題なし」と断言する
そして最大の問題は、AIレビューを信用しすぎると、レビューが二重に空洞化すること。
人間が深くレビューしない、AIレビューも本質を見ていない、結果として誰も深く読んでいないコードがマージされる。「AIが書いて、AIがレビューして、人間は最終承認だけ」という流れは、効率的に見えて、実質的に誰もコードを理解していない状態を作ります。
AIレビューは「人間のレビューを補助するもの」として使うのが健全で、「人間のレビューを置き換えるもの」として使うと、組織のスキルがさらに空洞化します。
シニアが育たない、維持されない
シニアエンジニアは、「難しい問題に向き合って、悩んで、失敗して、学ぶ」ことで育ちます。
- 設計を間違えてリリース直前に作り直した
- 性能問題でデータ構造を見直した
- 障害対応で原因究明に徹夜した
- 大規模リファクタで影響範囲に冷や汗をかいた
こういう身体を通した経験が、シニアの判断力を作ります。AIに任せて、本人は表面的にレビューするだけだと、これらの経験が積まれません。
5年後にシニアと呼ばれる立場になったとき、実は判断力が中堅レベルで止まっている、ということが起き得ます。本人にも自覚がないまま。
しかも、既にシニアの人も、AIに任せ続けると判断力が鈍るかもしれません。スキルは使わないと衰える。シニアが「私はもう書かなくてもいい」と思った瞬間に、シニアであることをやめる第一歩が始まる。
そして、業界全体で同じことが起きると、経験のあるシニアエンジニアの希少性が上がっていくかもしれません。育てる組織が減れば、市場全体で供給が細る。そうなると、自前で育てられない組織は、高い単価で外から探すしかなくなる。育成を諦めた瞬間に、人件費がむしろ上がる、という逆説的な状況が起こり得ます。
長期的には、ジュニアをシニアに育てられる組織のほうが、構造的に強くなるのかもしれません。AIで効率化が進む時代に、逆に「人を育てる力」が組織の競争優位になる。少し皮肉な話ですが。
ジュニアが育つ機会を失う
ジュニアの仕事だったタスクをAIが奪うと、ジュニアが「手を動かして覚える」段階を経られなくなります。
新卒でいきなりAIのレビューだけする立場になると、コードを書く筋力が付きません。書きながら悩む経験、間違える経験、修正する経験── これらは自分で書かないと得られない。
ジュニア時代に書く経験を積んでいないと、いざ「AIに頼れない複雑な問題」が来たときに、対応できません。ジュニアからシニアへの育成パイプラインが、構造的に断絶する。
「AIで書けるんだから、ジュニアは要らないのでは?」という発想は、短期的には合理的に見えます。でも10年後、シニアの供給が止まったときに困るのは、その組織自身です。シニアは突然湧いてくるものではなく、ジュニア時代の積み重ねで育つので。
誰も全体を理解していない
AIが書いたコードを、誰も深く読んでいない状態が続くと、「動いているけど、なぜ動いているか説明できる人がいない」状態になります。
これは、障害時、リファクタ時、移行時に致命的に困ります。
- 障害が起きたとき、原因を特定できる人がいない
- リファクタしようとしても、影響範囲が読めない
- 別の技術スタックに移行しようとしても、何を移すべきか分からない
「AIに聞けば分かる」と思うかもしれませんが、AIはコードベース全体の意図や歴史は知りません。「なぜこの設計にしたか」「過去にどんな失敗を経てこうなったか」は、人間の頭の中にしかない。それが消えると、コードベースはブラックボックス化します。
責任を取れる人がいなくなる
障害が起きたとき、規制対応が必要になったとき、訴訟になったとき── 責任を取るのは人間です。「AIが書いたので分かりません」では通用しません。
責任を取るには、コードを理解している必要がある。AIだらけで誰も理解していないと、責任を取れる人がいない状態になります。これは組織として、かなり脆い。
では、どうするか
「AIを使わない」が答えではないと思います。AIで効率は上がるし、それを捨てるのは別の意味で組織を弱らせる。考えるべきは、意図的に人間が手を動かす領域を残す設計だと思います。
任せる領域と、人間が手を動かす領域を分ける
AIに任せやすいのは、定型的な実装、ボイラープレート、ドキュメント生成、既存パターンの踏襲。人間が手を動かす価値があるのは、設計判断、難しいバグの調査、ドメインモデリング、セキュリティ。前者で時間を浮かせて、後者に投資する。
意図的に書く機会を作る
ジュニアにあえて手で書かせる、シニアにあえて深く設計させる、AI禁止のタスクを残す。効率を犠牲にしてでも、書く経験を維持する判断が必要かもしれません。レビューだけでは育たないし維持もできない、という前提に立てば、書く機会は意図的に作るしかない。
コードベースの「理解者」を意識的に育てる
各モジュールに、「これを深く理解している人間が少なくとも1人いる」状態を保つ。AIで書いてもいいが、誰かが読み込んで理解している必要がある。
メタな知識を蓄積する
「なぜこの設計にしたか」「なぜこのライブラリを選んだか」「過去にどんな失敗をしたか」── これはAIには持てない情報なので、人間がドキュメント化する。ADRのような形で。
組織として問うべきこと
少し堅い話になりますが、組織でAI活用を進める立場なら、こんな観点で見るといいかなと思います。
- 3年後、誰がこのコードベースの設計判断を下せるか
- 5年後のシニアエンジニアは、どこから育ってくるか
- AIなしでも事業が回る最低限の能力を組織に残せているか
- コードを「読める」人と「書ける」人の比率が崩れていないか
- シニアが、自分で書く機会を維持できているか
- 障害対応で、原因を特定できる人がいるか
これらに自信を持って答えられないなら、AIの使い方を見直すタイミングかもしれません。
まとめ
AIだらけのコードベースは、短期的には良く見える。でも、長期的にはシニアが育たない・維持されない、ジュニアが育つ機会を失う、誰も全体を理解していない、責任を取れる人がいないという問題が、じわじわ進む。
特に強調しておきたいのは、レビューだけでは成長しない、維持もできないということ。書く経験と、レビューする経験は別物で、片方だけでは判断力が育たない。さらに、レビューの観点自体も、書く経験から育つ。書いていない人のレビューは、解像度が低くなる。
AIレビューも便利ですが、人間のレビューを置き換えるものとして使うと、レビューが二重に空洞化します。「AIが書いて、AIがレビューして、人間は最終承認だけ」という流れは、誰も深く読んでいないコードを生む。
そして、業界全体で育てる組織が減ると、経験のある人材の希少性が上がり、自前で育てられない組織は高い単価で探すしかなくなる。皮肉なことに、AIで効率化が進む時代に、「人を育てる力」が組織の競争優位になりそうな気がしています。
これに気付くのは、たいてい手遅れになってから。「AIで効率が上がった」と喜んでいる時期に、別の問題が静かに進行している可能性があります。
対策は「AIを使わない」ではなく、「意図的に人間が書く領域を残す」設計。効率と能力維持のバランスを、組織として意識的に取りに行く必要があります。
これも、振り返ってみると特に新しい話ではないかもしれません。「自動化が進んでも、人間のスキルは維持しないと困る」というのは、製造業でも、金融でも、物流でも、ずっと言われてきたことです。AIだから特別、という話ではなくて、自動化と人間のスキルの関係を、また考え直す機会が来ているだけ。
道具がAIになっても、組織を健全に保つために考えるべきことは、エンジニアに限らず、あまり変わらないんじゃないかなと思います。
