お疲れ様です。ゆうきです。
昨日のYouTube「AIに全部書かせたプロジェクトが破綻した話」は見てくれましたか？
まだの人はこちらから
動画の最後に予告した通り、今日は「AIに任せていい作業と、絶対に自分でやるべき作業」の具体的な線引きをメルマガ限定で全部話します。
保存しておいてください。
AIに任せていい作業
① ボイラープレートの生成
CRUDのAPI、バリデーション、ファイルの雛形。毎回同じようなコードを書く部分。「このスキーマでCRUDのAPI作って」で一発。ただし、AIの出力をそのままコピペしない。自分のプロジェクトの規約に合わせて調整する。
② テストコードの生成
「この関数のユニットテストを書いて」はAIがかなり正確にやってくれる。エッジケースの洗い出しもAIの方が漏れが少ないことがある。ただし、テストの方針設計は自分でやる。どこまで細かくテストするか、何をユニットテストで担保して何をE2Eで担保するかは、ビジネスの重要度によって変わるから、AIには判断できない。
③ リファクタリングの提案
長い関数の分割、ネストを減らす、命名の改善。AIがいい提案を出してくれる。ただし、AIは「見た目」を綺麗にするのは得意でも、「そのリファクタが既存機能に影響しないか」は弱い。提案をもらったら「なぜその構造にしたか」を自分で理解してからマージする。
④ ドキュメントの下書き
READMEやAPI仕様書の下書き。コードを読ませれば仕様書を自動生成してくれる。ただし「なぜこの設計にしたか」の背景情報はAIには書けない。技術的な仕様はAI、設計判断の背景は自分で書き足す。
⑤ エラーの原因調査（仮説出し）
「このエラーの原因として考えられるものを3つ挙げて」はAIが優秀。自分だけで考えると視野が狭くなるところに、別の可能性を提示してくれる。ただし仮説を検証するのは自分。鵜呑みにして修正すると、モグラ叩きになる。
絶対に自分でやるべき作業
① アーキテクチャの設計
プロジェクト全体の構造を決めること。AIに聞くと「教科書的に正しい構成」は返ってくるけど、「このプロジェクトに最適な構成」じゃない。チームのスキルレベル、保守のしやすさ、将来の拡張。これは文脈を全部知ってる人間にしか判断できない。動画で話した知り合いのケースも、まさにここだった。
② 技術選定
「GoとNode.js、どっちを使うか」をAIに聞いても一般論しか返ってこない。チーム構成、既存コードベース、採用市場。全部の文脈を踏まえたトレードオフの判断は人間にしかできない。
③ コードレビュー（最終判断）
AIにセキュリティチェックやパフォーマンスの洗い出しをさせるのはOK。でもマージするかどうかの最終判断は自分。「AIがOKって言ったから」は本番で壊れた時に通用しない。
④ 障害対応
本番で何か起きた時に、冷静に原因を切り分けて判断する。「ちょっと待って、AIに聞いてみます」は通用しない場面がある。自分でコードを理解していれば5分で復旧できるものが、理解してなければ何時間もかかる。ここが「AIに全部書かせた人」と「設計を自分でやった人」の決定的な差。
⑤ ビジネス要件の翻訳
お客さんの「もっと使いやすくしてほしい」を、具体的な仕様に変換する作業。これは人間同士のコミュニケーションの領域で、AIには無理。しかもこの「翻訳力」がある人は現場でめちゃくちゃ重宝される。
この線引きの「基準」はたった2つ
ここまでリストを並べたんですけど、迷った時はこう考えてください。
「壊れた時に、自分で説明できるか？」
説明できるなら、AIに書かせてもいい。説明できないなら、自分でやるか、理解してからマージする。
「この判断は、文脈を知らないと正しくできないか？」
文脈が必要な判断は自分。文脈なしで機械的にできる作業はAI。
この2つで、ほぼ全ての作業を振り分けられるんですよね。
なぜこの線引きがそんなに大事なのか
で、ここからが本当に伝えたいことなんですけど。
この線引き、実はエンジニアだけの話じゃないんですよ。
うちの奥さんが最近料理にハマってて、最初はクックパッドのレシピ通りに一品ずつ作ってたんですよね。
それが3ヶ月経ったら、冷蔵庫の中身を見てレシピなしで作れるようになってた。
「レシピ見なくなったね」って言ったら、こう返ってきたんですよ。
「レシピは見なくなったけど、”なんでこの順番で炒めるか”とか”なんでここで塩を入れるか”は、最初にレシピ見ながら自分で考えたからわかるようになった」って。
これ、さっきのリストと全く同じ構造なんですよね。
奥さんがやってたのは「レシピ通りに作る」→「なぜこう作るのか考える」→「レシピなしで判断できるようになる」っていうプロセス。
最初からレシピなしで作ってたら失敗しまくってた。
逆に、ずっとレシピ通りに作り続けてたら、いつまでもレシピがないと何も作れない。
レシピを「答え」として使うか、「考えるための材料」として使うか。
動画で話した知り合いは、AIのコードを「答え」としてそのまま使ってた。
だから破綻した。
医療でも同じことが起きてて。
AIの診断支援ツールがレントゲン画像を読んで「この部位に異常がある可能性が高い」って教えてくれるんですけど、医者はAIの診断をそのまま患者に伝えたりしないんですよね。
「この患者は先月こういう薬を飲んでるから、この影はそっちの影響かもしれない」っていう文脈の判断を通してから使う。
道具が出す答えをそのまま使うんじゃなくて、自分の判断を通してから使う。
これが料理でも医療でもエンジニアリングでも、プロとアマチュアの分かれ目なんですよ。
なんで僕がこの線引きにこだわるかっていうと、SES時代に全く同じ構造の失敗をしてるからなんですよ。
当時、先輩に言われた通りにコードを書いてたんですよね。
「ここはこう書いて」って言われたらそのまま書く。なぜそう書くのか考えずに。
で、先輩が異動した瞬間に何もできなくなったんですよ。
自分で判断する力が全く育ってなかったから。
障害が起きても「これ先輩が書いたところだからわからない」って手も足も出なかった。
AIに全部任せるのは、あの時と同じ構造なんですよね。
先輩の代わりにAIに頼ってるだけ。AIが的外れな回答を出した時に、自分では何も判断できない。
だから僕は「説明できないコードはマージしない」を絶対のルールにしてるんですよ。
あの時の失敗があるから、自分で判断する部分だけは絶対に手放さないと決めてる。
包丁は最高の道具だけど、「何を作るか」は料理人が決める。
AIは最高の開発ツールだけど、「何をどう作るか」はエンジニアが決める。
この線引きを持ってるかどうかで、AI時代のエンジニアの価値が決まると本気で思ってます。
追伸
今日の線引きって、結局「自分で判断する力があるかどうか」なんですよね。
AIに任せていい作業と自分でやるべき作業を見分けるのも、現場で「これは自分が動くべきか」を判断するのも、全部同じ力。
この「判断力」を体系的に身につけたい人向けに、僕が改善の錬金術師っていう教材を作ってます。
クリティカルな課題の見つけ方から、改善の型、提案の仕方まで全部入ってるんで、今日の話が刺さった人は見てみてください↓
https://yuki001.com/p/r/L8ky6Muw
登録後、メールで詳細をお伝えします。
