こんにちは、東（@teast330985）です。
もうすぐ2025年が終わるので、今年1年間の反省を書こうと思います。
今年はAIによるエンジニア産業革命がとんでもなかったので、それについていくのに苦労しました。目新しいことはないかもですが、自分の目線で反省をまとめておき、今後の自分とこれを開いてくださったみなさんの役に立てられたらと思います。
反省1:大量にコードを生み出すからこそ、「コード == 負債」の認識をより一層強めるべき
やこちらの記事のもとになっている に書かれている「コードは負債」という考え方は私も強く共感します。
ソフトウェアとして動くプログラムコードが生み出す正の資産と同じくらいに、バグやメンテコストといった負の資産についても意識すべきという話です。
技術的にもビジネス的にも負の複利を生み出すリスクは常に考えて置く必要があります。つまり、コードがあればあるだけ良いというわけではないということですね。
生成AI、特に自立型のエージェントなどを使うことで、単位時間あたりに一人が生み出すコードの変更行数は何倍にも膨れ上がりました。
一方でそれらを単純な生産性の向上と捉えて良いこととみなすのは危険だと思います。
生成AIは優秀な部下ですが、確率モデルなので嘘をつき、無責任で論点をずらしてくるものであるという前提で関わる必要があります。テストにおいても、生成AIが作ってくれるテストデータは便利でありがたい一方でなんの整合性の根拠もないわけです。
そんな部下が大量に生み出すPRを受け入れたとして、その負債の責任を請け負うのは私たち人間だけと思うと、恐ろしいです。
いわゆるバイブコーディングというものはこのリスクが多分にあります。私も業務の中で、社内の限られた人間しか使わない部分の実装に対して、時短のためにほぼバイブコーディングで実装した経験があります。口頭で指示した内容に対して、一気にそれっぽい実装をしてくれるので非常に感動しますが、その感動に埋もれた多くの手戻りコストに気づかず痛い思いをしました。
スピードを重視した結果、そこから生み出される負債の解消と合わせるとかえって時間がかかってしまったというケースを起こさないためにも、リスクを十分に理解して意思決定を行うことが重要と思います。
反省2:思考するフェーズと実装するフェーズは明確に分けるべき
反省1に関連している話ですが、AIの使い所と使い方をしっかり分けておこうという反省がありました。これは初学者の人や、新規参画したプロジェクトのドメイン知識が十分でない人が特に気をつけるべき内容かと思います。
時短のためにAIに一度にまとめてやってもらったら逆に時間がかかったという事象
よくある失敗パターンは「機能Bを作って。機能Bは〜〜が〜〜のときに〜〜ということができて〜〜」みたいな、出来上がる機能をユーザーストーリーベースで伝えて実装を依頼するパターンです。
コーディングエージェントは、機能Aの実装を見て、TODOリストをまとめて、実装に取り掛かってくれます。
しかし、背景の共有から設計、実装までをまとめるような依頼だとどうしても出来上がるものは変な実装になってしまいがちです。変な実装と気づけてそれを直せるならまだ良いものの、初学者や新規参画者は設計の妥当性の良し悪しが掴めていなかったりするので、よくわからんとなってしまいます。
知識どうこうだけでなく、方針も曖昧なので承認否認もできず、レビューコメントも難しかったりします。
生成AIの使い所が悪いと、このような事象に陥ります。私もなりました。
思考と実践の型を持った上で、AIに補助してもらう。
ここにも書かれているようにジュニアとシニアでAI活用の溝があるのは、進め方にあると思います。
シニアエンジニアは、技術的に経験のない新規機能を実装するときやバグ修正などの場においては、本格的に手を動かす前に以下のようなサイクルで問題をクリアにしていきます。
- 仮説をいくつか立てる
- 調査や小さなプロトタイプで仮説の妥当性を検証する
- 結果を考察し、新たに仮説を立て直す
既存のものから横展開的に実装できるものであっても同じだと思います。
機能の要件やテストパターン、アーキテクチャ的にどこにどういう名前の関数が置かれるか、などの計画を立てて、それらの具体的な方針をもとに実装に移ります。
特に計画もなくいきなりコードを書き始めると、最後の最後に考慮漏れがみつかり、手戻りを発生させてしまいます。
こういったベースの型を持った上で、それぞれのフェーズでどのように生成AIを使えばいいかを切り分けることでカオスを減らせます。
調査時であれば、DeepResearchを使ったりDeepWikiを使って見立てを立ててから、一次ソースを読みに行くという流れが適切でしょうし、検証時に利用する使い捨てのスクリプトの実装であればシンプルな機能であることが多いので割とそのままAIに投げてもいい感じに作ってくれたりします。
バグ修正の際も「〜〜というバグが出たから直して」ではなく、ある程度の仮説を自分で立てた上で、「〜〜のバグはどういう時に発生する？」「〜〜のエラーメッセージを解説して」と問題を少しずつ解消していく方が最短距離で解決できることが多いです。
アーキテクチャデザインやコーディング規約をコンテキストに持たせた別のAIエージェントにコードレビューだけを依頼するというのも使い分けのポイントですね。
また、あくまでもAIは補助ツールであり、大事なのは私たちの目の脳であることが重要です。AIに調査をまとめて方針を出力してもらったりすると結構小難しく書かれていたりするのでそれだけで満足してしまいがちですが、それ単体には価値はありません。
内容の全てに人間が同意して承認しないと話は始まりません。結局は脳みその中に方針がしっかり入っていることが大事であり、AIが出力するプランのテキストはただの思考の材料です。。AI -> 脳 のフィルターをしっかり働かせることが大事と学びました。
反省3:自分の脳内を外部に解放すべき
そもそも私たちはAIに全てを伝えられていない。
AIに仕事を依頼するためにはコンテキストとして与える情報が重要ですが、可視化される事実だけでは私たちがどこまで理解できているのかをAIは理解できていません。
そこのズレがあることで、期待する実装や回答をしてくれないことがいくつかありました。
なぜそうなったのかを振り返ると、私自身がなにを分かっていて、なにを分かっていないかが曖昧だったからだと反省しています。
AIと私たちのズレをなくすために、私たち自身が対象に対して
- 無知
- 未知
- 既知
をAIに頼らず整理しておき、それぞれに対して適切に情報を取得していくのが大切です。
脳みそ as a RAG
脳もRAGのようなもので、日々の活動の中得た知識や経験が自身のフィルターを経由して解釈やノウハウとなり、私たちはそれをリトリーバルし生産活動に役立てています。
それはAIだけでなく、周りにいる人達にとっても有益な判断材料になります。
自分の脳みそを活用するために、今年からObsidianでメモをするようになりました。日々の業務のメモや、一言日記など、大事なことからしょうもないことまで記載することを心がけています。まだ上手く使いこなせていない部分もありますが、いつかこれらが花開くことを目指してこれからも継続していこうと思います。
さいごに : AIが私たちに届ける感動には要注意
以上、今年1年間で私や私の周囲で実際に経験した反省点です。本当はもっとありますが、抜粋しました。
AIは「そんなこともできるの！？」と多くの感動を私たちに与えてくれますが、果たしてそれが私たちの意図しているものであるか、私たちが出力すべき成果に見合っているかどうかは別の話だと思います。
我々自身の考え方や情報の整理力が試されます。
負けるな人間！良いお年を。
Discussion