AI時代のエンジニアは「編集者」になる
はじめに
AIの登場によって、開発体験が大きく変わったと感じています。
思い描いたものがすぐ動くものになる。
動いたものに対して「ここが違う」と指摘できる。
そしてどんどん良いものが生まれていく。
このフィードバックループの速さは、以前では考えられなかったものです。
一方で、こんな疑問も浮かびます。
「実装のコストが劇的に下がった今、エンジニアの価値はどこにあるのか？」
この問いについて考えていく中で、ひとつのアナロジーにたどり着きました。
それが「編集者」という存在です。
本記事では、出版業界における編集者の役割を参考にしながら、AI時代のエンジニア像について考えてみたいと思います。
編集者とは何をする人か
漫画やドラマで描かれる編集者のイメージはさまざまですが、その本質的な役割を整理するとこうなります。
- 自分では書かないが「何が良いか」を判断できる
- 方向性を示し、的確なフィードバックを返す
- 最終的な品質に責任を持つ
- 作り手の潜在能力を引き出す
編集者は、作家と編集部の間に立つ存在です。
作品をより良くするために意見し、時には厳しいフィードバックも返します。
しかし、その根底にあるのは作品と作り手への深い理解と愛情です。
これをエンジニアに当てはめてみると、どうでしょうか。
AIがコードを生成する時代において、エンジニアは
- AIに「何を作るか」を指示し、方向性を決める
- 生成されたコードの品質を判断する
- 的確なフィードバック（プロンプト）を返して改善させる
- 最終的な品質に責任を持つ
まさに「編集者」的な役割ではないでしょうか。
編集者はどうやって編集者になるのか
では、編集者はどのようなステップを経て編集者になるのでしょうか。
1. 大量に読む
良いものと悪いものを大量に浴びることで、品質を見分ける目が養われます。
何が面白いか、何が読みにくいか、感覚として蓄積していきます。
2. 自分でも書いてみる
多くの編集者は、学生時代に文章を書いたり、入社後も企画書やコピーを書いたりしています。
書く苦しみを知っているからこそ、書き手の気持ちがわかり、的確なフィードバックができるようになります。
3. 先輩について現場で学ぶ
実際の原稿に赤入れする先輩の横で、どこに目をつけるか、どう伝えるかを見て盗みます。
この徒弟制的な学びが大きいです。
4. 作り手との信頼関係を築く
編集者の仕事は半分以上がコミュニケーションです。
相手の意図を汲み、やる気を引き出し、時に厳しいことも言える関係性を作ります。
ここで重要なのは、多くの編集者はライター経験を経て編集者になっているという点です。
書く経験があるからこそ、何が難しいか、どこに落とし穴があるか、どういうフィードバックが的確かがわかります。
「書いたことがない編集者」というのは、実はかなり稀な存在なのです。
ジュニアエンジニアはどう「編集者」になっていくのか
では、ジュニアエンジニアはどのようなステップを経て「編集者」になっていくのでしょうか。
編集者のキャリアパスを参考に、具体的な成長ステップを考えてみます。
フェーズ1：まず「書く」経験を積む
編集者の世界では
- 大量に本を読み、良いもの・悪いものを浴びる
- 自分でも文章を書いてみる
- 書く苦しみを知ることで、作家の気持ちがわかるようになる
エンジニアに当てはめると
- 大量のコードを読む（OSSやチームのコードベース）
- 自分の手で実装する経験を積む
- 「なぜこの設計なのか」を考えながら写経する
- AIを使う場合も、生成されたコードを必ず読んで理解する
この段階でAIとどう付き合うか
AIに頼りすぎず、まず自分で考えてから使うことが重要です。
AIの出力を「答え」ではなく「参考例」として扱い、生成されたコードを手で修正しながら学ぶ姿勢が大切になります。
このフェーズを飛ばしたくなる気持ちはわかります。
AIがあれば、自分で書かなくても動くものは作れてしまうからです。
しかし、このフェーズを飛ばすと、後のフェーズで必ず壁にぶつかります。
フェーズ2：「赤入れ」を受ける側として学ぶ
編集者の世界では
- 先輩編集者の赤入れを見て、判断基準を学ぶ
- なぜこの修正が必要なのかを理解し、徐々に自分でも赤入れの視点を持てるようになる
エンジニアに当てはめると
- コードレビューを受け、指摘の意図を理解する
- 「なぜこの書き方がダメなのか」を言語化できるようになる
- 設計レビューに参加し、先輩の判断基準を観察する
- 自分のコードに対するAIの提案を批判的に評価する練習をする
この段階で意識すること
レビューコメントを「直せばいい」で終わらせないことが重要です。
背景にある設計思想やトレードオフを理解し、同じ指摘を二度受けないように体系化していきます。
この段階で「なぜ」を理解せずに過ごすと、いつまでも「赤入れを受ける側」から抜け出せません。
フェーズ3：「赤入れ」をする側へ
編集者の世界では
- 後輩の原稿に赤入れをするようになる
- 作家（書き手）に的確なフィードバックを返し、「何が良くて何が悪いか」を言語化して伝える
エンジニアに当てはめると
- 後輩のコードレビューを担当する
- AIが生成したコードの問題点を指摘できる
- 「こう直して」だけでなく「なぜ直すのか」を説明できる
- 設計の選択肢を複数示し、トレードオフを議論できる
この段階でのAIとの関係
AIを「ジュニアメンバー」のように扱う感覚が近いです。
出力に対してレビューコメントを返すように指示を出し、AIの得意・不得意を把握して適切に使い分けます。
フェーズ1で実装経験を積み、フェーズ2でレビューの視点を学んだからこそ、この段階で的確な「赤入れ」ができるようになります。
フェーズ4：設計と品質に責任を持つ
編集者の世界では
- 企画段階から関わり、方向性を決める
- 作家の強みを引き出し、作品全体をプロデュースする
- 最終的な品質に責任を持つ
エンジニアに当てはめると
- 何を作るか、どう作るかの設計を主導する
- チームメンバーやAIの出力を統合し、全体の品質を担保する
- 技術選定やアーキテクチャの意思決定を行う
- 「編集者」として、プロジェクト全体を俯瞰する
このフェーズでは、AIは強力なパートナーになります。
大量のコードを素早く生成し、複数の選択肢を提示してくれます。
しかし、最終的な判断と責任は人間が持ちます。
その判断力は、フェーズ1〜3で積み上げた経験がベースになります。
フェーズを飛ばせるか？
結論から言うと、飛ばせないと考えています。
編集者の世界でも「書いたことがない編集者」は稀です。
書く経験があるからこそ、的確なフィードバックができます。
エンジニアも同様で、AIがあるからといってフェーズ1を飛ばすのは危険です。
実装経験がないと：
- AIの出力の良し悪しが判断できない
- 的確な指示（プロンプト）が書けない
- 問題が起きたときに原因を特定できない
AI時代だからこそ、基礎フェーズの重要性は変わりません。
ただし、各フェーズの滞在期間は短くなる可能性があります。
AIを活用することで、より多くのコードに触れ、より多くのパターンを学び、より早く次のフェーズに進める可能性があります。
フェーズを飛ばすのではなく、フェーズを加速させる。
それがAIとの健全な付き合い方ではないでしょうか。
この変化をどう捉えるか
ここまで「エンジニアは編集者になる」という話をしてきましたが、この変化をどう捉えるかは人それぞれだと思います。
実装をしていくのが好きな人もいれば、問題を解決すること自体が好きな人もいます。
AIの登場によって、前者にとっては寂しさを感じる変化かもしれませんし、後者にとっては歓迎すべき変化かもしれません。
私自身は、AIの登場によって開発がすごく楽しくなったと感じています。
思い描いたものがすぐ動くものになり、動いたものに対して「ここが違うよ」と指摘できる。
そしてどんどん良いものが生まれていく。
このサイクルは、純粋に楽しいです。
そして、この変化によってエンジニアリングの本質がより純粋に浮かび上がるとも感じています。
「問題を正しく理解し、適切な解決策を設計し、結果に責任を持つ」
この部分は、実装の詳細がAIに委譲されても変わりません。
むしろそこに集中できるようになった、とも言えます。
まとめ
- AIの登場により、エンジニアの役割は「実装者」から「編集者」へシフトしていく
- 編集者とは、自分では書かないが「何が良いか」を判断でき、方向性を示し、最終品質に責任を持つ存在
- 優れた編集者は「自分でも書ける」人が多い。エンジニアも同様に、実装経験なしに「編集者」にはなれない
- ジュニアエンジニアは、フェーズを飛ばすのではなく、AIを活用してフェーズを加速させることを意識すべき
この変化を脅威と捉えるか、機会と捉えるかは人それぞれです。
しかし、変化が起きていることは間違いありません。
編集者が作家を支え、作品を世に送り出すように、エンジニアもAIと協働しながら、より良いプロダクトを世に送り出していく。
私たちは今、その真っ只中にいます。
Discussion