「Author」から「Editor」へ

AI時代のエンジニアの役割変化

AIコーディングツールの普及により、開発者の役割が変化しています。

従来: Author（著者）

コードを一から書く
設計を考える
実装を行う

現在: Editor（編集者）

AIが生成したコードをレビュー
修正・調整を行う
品質を担保

この変化は、必ずしも悪いことではありません。問題は、その変化にどう適応するかです。

良いEditorの条件

「Editor」として成功するには、条件があります。

条件1: 「良い原稿」を見分けられる

AIの出力が正しいか判断できる
セキュリティの問題を発見できる
パフォーマンスの問題を発見できる

条件2: 「悪い原稿」を修正できる

問題点を特定できる
適切な修正を加えられる
全体の整合性を保てる

条件3: 「発注」ができる

適切なプロンプトを書ける
要件を明確に伝えられる
分割して依頼できる

vibe coderは「悪いEditor」

vibe coderは、悪いEditor です。

悪いEditorの特徴:

原稿を読まない
- Accept Allで受け入れる
- 内容を確認しない
品質を判断できない
- 良いコードと悪いコードの区別がつかない
- セキュリティの問題に気づかない
修正ができない
- 問題があっても直せない
- AIに「直して」と言うだけ
発注が曖昧
- 「〇〇を作って」としか言えない
- 要件を具体化できない

これでは、AIの能力を引き出すことができません。

「Editor」に必要なスキル

良いEditorになるには、以下のスキルが必要です。

スキル1: コードリーディング

AIが書くので、自分で書くスキルは減っても良い。しかし、読む力 は必須です。

コードの意図を理解する
問題点を発見する
改善点を見つける

スキル2: コードレビュー

AIの出力をレビューする能力。

セキュリティのチェック
パフォーマンスのチェック
保守性のチェック

スキル3: 要件定義

AIに何を依頼するか明確にする能力。

機能要件を具体化
非機能要件を明示
制約条件を伝える

スキル4: アーキテクチャ設計

全体の設計を行う能力。

システム構成を決める
コンポーネント分割を行う
責務を明確にする

Authorとしての基礎

しかし、良いEditorになるには、Authorとしての基礎 が必要です。

「自分で書けないコードをレビューすることはできない」

理由:

品質の基準がない
- 良いコードを書いた経験がないと、良いコードが分からない
問題の発見ができない
- 書いた経験がないと、問題点が見えない
修正の方向性が分からない
- どう直すべきか判断できない

つまり、Editorになる前に、Authorの経験が必要 です。

「書ける人がレビューする」原則

ソフトウェア開発には、重要な原則があります。

「書ける人がレビューする」

コードを書ける人が、コードをレビューする
設計できる人が、設計をレビューする
セキュリティが分かる人が、セキュリティをレビューする

vibe coderは、この原則に違反しています。

書けない人が「レビュー」している のです。それは、レビューではありません。

AI開発への段階的な移行方法

AuthorからEditorへの移行は、段階的 であるべきです。

推奨される移行パターン:

Phase 1: Pure Author（初心者〜3年）
- AIを補助的に使用
- 基本は自分で書く
- スキルを身につける

Phase 2: Author + AI（3年〜5年）
- AIを積極的に活用
- 自分で書けるが、AIで加速
- AIの出力を的確にレビュー

Phase 3: Editor（5年以上）
- AIに多くを任せる
- 設計とレビューに集中
- 品質を担保する

問題:

vibe coderは、Phase 1をスキップしてPhase 3に行こうとしています。基礎がないまま「Editor」になっても、良いEditorにはなれません。

「指揮者」のメタファー

良いEditorは、オーケストラの指揮者 のようなものです。

指揮者の条件:

各楽器を理解している
- 自分で演奏できなくても、音を聞き分けられる
- 各楽器の特性を知っている
全体のバランスを取れる
- どこが弱いか、強いか判断できる
- 調整できる
楽譜を読める
- 作曲者の意図を理解
- 解釈を加えられる

vibe coderは：

楽器を理解していない
バランスを判断できない
楽譜を読めない

これでは指揮者にはなれません。

Editorとしての成長

良いEditorとして成長するためのアドバイスがあります。

アドバイス1: まずAuthorとしての基礎を身につける

プログラミングの基礎を学ぶ
自分でコードを書く経験を積む
AIなしでも問題を解ける力を持つ

アドバイス2: レビュースキルを磨く

他人のコードをレビューする
オープンソースのPRを読む
セキュリティの観点を学ぶ

アドバイス3: プロンプトエンジニアリングを学ぶ

効果的なプロンプトの書き方
AIの特性を理解
分割と具体化の技術

アドバイス4: アーキテクチャを学ぶ

設計パターン
システムアーキテクチャ
マイクロサービス、モノリス

この事例から学ぶべき教訓

「AuthorからEditorへ」から学ぶべきことは以下の通りです。

役割はAuthorからEditorへ変化している
- これ自体は悪いことではない
良いEditorには条件がある
- 読める、判断できる、修正できる、発注できる
vibe coderは悪いEditor
- 読まない、判断できない、修正できない
Authorの基礎がなければ、良いEditorにはなれない
- 書けないコードはレビューできない
段階的な移行が必要
- Phase 1をスキップするな

まとめ：重要ポイントの振り返り

開発者の役割は Author（著者）からEditor（編集者）へ 変化
良いEditorの条件：読める、判断できる、修正できる、発注できる
vibe coderは 悪いEditor ：読まない、判断できない、修正できない
「書ける人がレビューする」原則 ：書けない人はレビューできない
段階的な移行 が必要：基礎なしにEditorにはなれない
良いEditorは 指揮者 のよう：各楽器を理解し、全体を導く
教訓：Editorになりたければ、まずAuthorになれ

AuthorからEditorへ：AI時代の開発者の新しい役割