■60万インプレッションのバズ

先日投稿した下記、Xのポストが60万impとかなりバズりました。

ジュニアエンジニアが生成AIで大量の低クオリティなものを作ってしまうがために、シニアエンジニア（年齢ではなくハイスキルな先輩エンジニア）が、チェックで工数を取られてしまうという問題について何社でも聞いたので、その話をポストしたものです。

これは生成AI駆動開発やってる人、つまりITのエンジニアだけの話だと思っていたのですが、想定以上に色々な領域の方から共感をいただきました。

■量が求められるときと、質が求められるとき

深津さんのこのポストを見て、ふとそうじゃないケースもあるよな、と思ってポストしたものです。元のポストを一方的に否定する意図は特にありませんでした。

自分でやるより多少クオリティが落ちても、スピードが上がったり量がこなせたほうが良い内容のタスクはそれなりにあると思います。例えば下記のようなものです。

1. かしこまったメールの返信文章

2. 初期的なリサーチ業務

3. キャッチ文章やタイトル案検討

4. アイデア出し

5. プロトづくりのVibeCoding

生成AIによって、こういったタイプのタスクをサクッとできるようになったのは、もとのポストに書かれているとおりです。100点（自分の上限値）である必要がないタスクを見極め、生成AIを使って生産性を上げていこうというのは賛成です。

■粗悪品の粗製乱造はたちが悪い

課題となるケースとして感じたのは、経験が浅いジュニアエンジニアが、深く考えず生成AIを安易に使い、粗悪な品質のコードを量産してしまう場合です。

私が代表を務めるpaizaは、ITエンジニア特化の転職・就職サービスを提供しており、現在4,600社ほどにご利用いただいているので、直近生成AIの利用状況は数十社に話を聞きに行きました。

それらヒアリングした結果として、積極的に生成AIを使っている会社では「シニアエンジニアは生成AIを上手く使えるが、ジュニアエンジニアが生成AI任せで低品質なコードをどんどん量産し、シニアがチェックで死に、全体としての生産性が落ちる。」という声が上がってきていました。

生成AIはできないことをできるようにするツールではなく、できることをより早くできるようにするツールです。（なぜならば、自分ができないことは指示出しもままならず、正しくできたかどうかの判断もつかないため、使いこなすことができないからです）。

ジュニアエンジニアが生成AIを使うと、非機能要件（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ等）を考慮できていなかったり、トレードオフとなる意思決定事項の調整ができていないなど、低品質な粗悪コードになりがちです。

生成AIは生産速度は恐ろしく早いのが厄介です。企画側等の依頼者が機能要件としては伝えてこない非機能要件を、ジュニアが考慮せずプロンプトを書くと、もちろん機能要件だけのプロンプトとなり、非機能要件の考慮漏れや、トレードオフ事項の調整がされてないコードが恐ろしい速度で量産されてしまいます。

あえて、この考慮漏れ、調整漏れの多い低品質なコードを「クソコード」というのであれば、まさに「クソコード量産機」になってしまうのです。

そしてそのクソコードをとにかくひたすらチェックするのがシニアエンジニアとなり、彼らの生産性を奪ってしまうことになります。

まだこういった事態は一部なのかなと思っていたのですが、想像以上に共感の引用リプライをいただきました。

■他業界でも似た話がある

翻訳業界でも同じ話があるようです。

法律分野も同様なようです。

学校の先生も大変そうだ…

こちらは例だけど、コンテストにAI使って大量の作品送られると、チェックする側が詰む、というのは構造としては同じですね。

■まとめ

ジュニアはどうすべきなのでしょうか。依頼をそのまま生成AIに渡してノールックで完成とするのではなく、下記のように生成AIに相談しながら品質を上げていく、というのが良いのだと思います。

同じ時間軸の中でも品質の低いものを量産する時間の使い方ではなく、一球入魂で生成AI使って学びながら一つの成果物の品質を高める時間の使い方をするのが重要なのだと思います。

最後までお読みいただきありがとうございました。

ちなみに、paizaはITエンジニア向け国内最大の転職・就職・学習プラットフォームです（paiza.jp）。生成AI講座も無料で学べるので、よかったら使ってみてください。

なぜAIに丸投げできないのか？レビューをAIに依頼できないのかについてはこちらの記事で書いているので興味があれば御覧ください。