AIカーソル時代のシステム開発
0. 実体験：生産性は体感で3〜4倍になった
筆者自身、AI Cursorを使い始めてから体感で3〜4倍以上の生産性向上を感じています。
正直なところ、新技術には基本的に懐疑的なスタンスなので、AI Cursorに対しても「どうせ過大評価だろう」とあまり期待していませんでした。
しかし、実際に使ってみると予想を遥かに超える生産性でした。
AIが得意なこと
- コーディング全般
- 仕様の整理・文章化
- 機能要件の壁打ち
- Git diffのレビュー
- リファクタ提案
- 設計の叩き台作成
これらは人がやるより圧倒的に速く、正確です。「考えながら手を動かす」作業がほぼ不要になりました。
AIが詰まりやすいポイント
一方で、AIでも苦手な領域は明確にあります。
- DBのデータ不整合
- APIレスポンスの想定外構造
- 環境依存のバグ
- 実データ由来のロジック破綻
特に、
エラーをそのままコピペしても同じ回答を延々と繰り返される
という状況は何度も起きました。
実データを伴うバグの原因特定は、今でも人間の領域です。
それでも「圧倒的に」価値がある
それ以外の作業に関しては、
「人がやる意味ある？」
と思うレベルで生産性が違います。
この変化は単なるツールの進化ではなく、
-
プログラミングのキャリアパス
-
エンジニアの役割
-
組織編成
-
採用戦略
にまで影響する構造的な変化だと感じました。
だからこそ、この記事を書いています。
1. 組織と人材の変化：技術より「ドメイン知識」
AIがコードの書き方を肩代わりするようになったことで、エンジニアに求められる価値基準は大きく変わりました。
「ビジネス特化型」チームへの移行
Reactなどの技術レイヤー別の編成から、特定の事業（ビジネスドメイン）を完結させる少数精鋭のチーム編成へと移行しています。
採用人数の変化：少数精鋭へのシフト
1人あたりの生産性がAIによって数倍に跳ね上がった結果、「大量採用で回す」モデルは崩壊しました。
現在は、少人数で意思決定と実装を高速に回せるチームが主流になっています。
内製化の加速
AIによって自分たちで作るコストが激減しました。
その結果、コア業務をブラックボックス化しないため、外注から自社開発（内製）へ回帰する動きが加速しています。
ベテランの再定義
構文に詳しい人よりも、業務仕様（ドメイン知識）に精通し、AIの出力を正しく評価・修正できる“生き字引”が最も重宝される存在になりました。
スキルの均一化：技術格差は急速に縮小
「技術的に難しいから実装できない」という制約は、AIの普及によってほぼ消滅しました。
誰が書いても一定以上の品質の成果物が出るようになった結果、シニアとジュニアの技術的な差は急速に縮小しています。
コーディングスキルそのものは、もはや強い差別化要因ではなくなりました。
給与構造の変化：評価されるのは何を作れるか
その一方で、市場価値の基準は大きく変化しています。
以下のようなエンジニアは、市場価値と給与が下がる傾向にあります。
-
ドメイン知識を持たない
-
管理能力がない
-
要件を汲み取れない
評価されるのは、「書けること」ではなく、「何を作るべきかを理解し、形にできること」です。
価値の源泉は、完全にビジネス理解へと移行しました。
2. 開発プロセスの激変：ドキュメントは「AIへの入力」
仕様書やワイヤーフレームは、もはや「人間が読むだけの紙」ではありません。
-
超高速アジャイル
詳細な設計書を書く前に、AIがプロトタイプを即座に生成。
動くものを見ながら仕様を固めるサイクルが標準に。 -
ドキュメントの構造化
AIが解釈しやすいMarkdown、Mermaid、YAML形式での記述が標準。
コードとドキュメントはAIによって常に自動同期される。 -
ワイヤーフレームの縮小
手書きのラフやFigmaから直接コードが生成されるため、
中間生成物としての静止画の役割は激減。
3. 指示と設計の新常識：View（見た目）を起点にする
設計思想は「美しい抽象化」から、AIと対話しやすい**「直交性と具象性」**へとシフトしました。
-
View起点の指示
言葉で説明するより、既存のView（UIコード）をコピペして
「ここをこう変えて」と指示する方がAIの精度が最も高い。 -
ベタ書き（Go言語的思想）の再評価
複雑な継承（BaseControllerなど）や共通化は、
AIの文脈理解を妨げる。
多少の重複を許容し、ファイル内で完結する
直交性の高い設計が、AIによる一括修正やテスト自動化と最も相性が良い。 -
テストコードは「防護柵」
AIが爆速でコードを生成するからこそ、
デグレードを防ぐためのテスト自動生成（AIによるテスト作成）が
品質担保の生命線となる。
抽象的な事象を計算式に当てはめる能力
AI時代のエンジニアは、確実に 「言語化能力」と「抽象→構造化能力」 が重要になります。
重要度はだいたいこう変わります。
昔
↓
設計
↓
コーディング
これから
↓
抽象 → 構造化
↓
AIへの指示
↓
AIがコーディング
抽象的な物を計算式に当てはめる能力
もう少し言い換えると
「ビジネスを数式・ロジックに変換する能力」
になります。
1. 言語化能力（曖昧な要求を言葉にする）
ビジネス側の要求はほとんどの場合こういう形です。
-
「なんか使いにくい」
-
「もう少し早くならない？」
-
「売上を上げたい」
これをエンジニアが次のように翻訳します。
例
検索結果表示までの時間
3秒 → 1秒以下
購入率
2% → 3%
つまり
曖昧な要求 → 明確な仕様
に変換する能力です。
AIはこの「翻訳された仕様」がないと強く動けません。
2. 抽象→構造化能力（問題を分解する）
AIが最も得意なのは
構造化された問題
です。
例えば
抽象要求
おすすめ商品を出したい
これを構造化すると
おすすめスコア =
閲覧回数 * 0.3 +
購入回数 * 0.5 +
レビュー評価 * 0.2
になります。
つまり
抽象 → モデル化
この能力が非常に重要になります。
3. AIへの指示設計能力（プロンプト設計）
AI時代の開発は
コードを書く仕事
ではなく
AIに正しい問題を渡す仕事
に近くなっています。
例
悪い指示
おすすめ機能を作って
良い指示
以下の条件でおすすめ商品APIを作成してください
・閲覧履歴からカテゴリ一致商品を抽出
・購入回数の多い順
・最大20件
・Go + PostgreSQL
AIは
曖昧な問題 → 苦手
構造化された問題 → 爆速
です。
登録日：
更新日：