【AI駆動開発で学びを最大化する方法 】あれ、僕は何も成長してない…からの脱却
はじめに
この記事は、上記の記事の続編です！
AI駆動開発（Vibe Coding）中にふと感じました。
「あれ、このアプリ開発で僕は成長したのか...？」
コードはAIに書かせてる。設計もほぼAIに任せてて、僕はGoサインを出すだけ。
なぜその設計なのか、どうして他ではダメかも考えず、ただEnterを押すだけ。
この状態から脱却するため、AI駆動開発を「自分のスキル向上やキャリアに繋がるような経験」にするための方法や心構えを僕なりにまとめてみました。
これからエンジニアとして転職される方や、駆け出しエンジニアの方には、特に見ていただきたいです！
もし少しでも「ドキッとした項目」や「気になった項目」があれば、そこだけでも読んでいただけると嬉しいです！
他にも色々な考え方があると思います。
また、僕の至らない点も数多くあると思います。
ぜひご指摘やコメントをいただけると嬉しいです！
AI駆動開発で成長するための7つの方法
1. 「0 → 1」は自分で作る
公式ドキュメントを見ながら、正しい書き方を把握しましょう。
また、各種設定ファイルも自分で行えるとベストです。
大前提、AIに「0 → 1」を実装させた時は、手直しや手戻りが多い印象です。
つまり、AIに1から実装を全て任せるのは、現状ベストな選択ではなく、人がフォローをする必要があります。
そのため、AIに生成させたコードをただ読んで、「文法的に問題ないか？」を判断するだけでなく、そのコードが「ベストプラクティスかどうか？」という視点で判断する必要があります。
だからこそ「自分で1から作れる」状態になれると良いと思います。
ドキュメントを読むきっかけにもなるので、キャッチアップの能力も養われます。
2. 技術選定や、設計は必ず自分で行う。
プログラミングでは「なぜその実装にしたか？」を意識することが大切です。
実際の現場では、いろいろな要因が絡み合い、「Aという実装なら、〜のメリットやデメリットがあり、Bであれば…」と、トレードオフを常に考えて選択します。
そのため「なぜその設計が最適なのか？」を考えて説明できるようになる必要があります。
- そのアプリは今後どのように拡張していくのか？
- それを踏まえた上で、なぜその設計がいいのか？ どうして他の設計を選ばなかったのか？
- 後に出てくる課題は何か？それでもこの設計にするべき理由は何か？
もちろん、個人開発などの小規模アプリであれば、AIが一発でベストプラクティスを出してくれます。
ただ、上記の「なぜそうするのか？」を考える姿勢や視点を持つことは、今後エンジニアが求められるスキルだと思います。
設計に関しては、別の記事でまとめているので、もし興味があれば見て頂きたいです！
3. エラーの原因と解決策を理解し、説明できるようになる。
実際の現場では、様々なアプリケーションやサービスが入り混じって構成されています。
エラー発生時には、どのアプリケーション・サービスでエラーが生じているか？を把握するため、「原因切り分け」が重要になります。
原因切り分けとは？
どこでエラーが生じているか？のあたりを付けるため、「どこまで正常に動作しているか？」を確認するプロセスになります。
例えば、A → B → C → Dという順番で処理されるサービスで、Bまでは問題なく動作していたとします。
上記の情報から「AとBには問題がない」と分かるので、「CとDに原因があるかも」というあたりをつけられます。
この考え方は、デプロイ時に正常に動作しない時などにも使えます。
ローカル環境では動作してるが、クラウド環境ではうまく動作しない。
この時に、
- クラウド環境とローカル環境での差は何か？
- そもそもソースコードはデプロイされてるか？
場当たり的に調査するのでは無く、エラーの内容から、どこまで正常に動作してるか？の仮説を立て、それを元に各種設定が正しいかどうかを確認することが重要になります。
他にも、見落としているドキュメントの1行を発見する能力も重要です。
利用時の注意点などは、補足事項として書かれていて、AIも見落とす可能性があります。
そのため、エラーが発生した場合に、人が直接ドキュメントを見て修正する必要が出てきます。
これらの「エラーの原因」を調べるプロセスが、そのまま自分の知識や経験として生きます。
AIに原因の当たりをつけてもらったり、解決の目処を教えてもらうのは問題ないですが、「なぜそのエラーが出たのか？」・「その技術に対して勘違いしてたことは何か？」などを考えて、得られる経験や知識を取りこぼさないようにすることは、大切だと思います。
4. コードの質にこだわる
大規模アプリになると、保守性を高めることが重要になります。
この時に、
- 重複してるコードはないか？
- ディレクトリ構成やファイル構成はわかりやすいか？
- IF文のネストは深くないか？別関数に切り出せないか？
など、「質の高いコードを作成する」視点は沢山あります。
また、「SOLID原則」や「DRY原則」、「デザインパターン」など、質の高いコードを作成するための設計を学習・復習したり、今回のケースで適用できないか？を考え、コードを改良する姿勢が大切です。
下記の記事はとても参考になりました！ぜひご覧ください。
ただ正直、大規模アプリでないと、上記設計の恩恵は受けにくいです。重複コードが多少あっても、数個程度なら目視で確認できるので、そこまで問題になりません。
ただ、「重複コードを無くすためには？」などを考えたり経験は、実際の現場でも生きます。
なので、積極的に取り組んで欲しいです！
5. AIの出力を向上させる工夫をする
自分なりに創意工夫し、望んでいるコードを作成させてより生産性を上げる。
AIを使わない世界が訪れない限りは、このテーマは無くならないと思います。
そのため、今のうちに色々と考えて実践する経験は大切だと思います。
残りの二つは、主に個人開発でAI駆動開発をされている方向けです。
6. やりたいことに妥協しない
「難しそうだからやらない」・「やったことないからやらない」・「AIが作れなかったからやらない」
上記の理由で諦めるのは、できる限り避けた方が良いと思っています。
個人開発に限らず、エンジニアとして1番成長するのは、「やったこと無いし難しそうだけど、色々と手を動かしつつ、試行錯誤しながら取り組んで実装した」時だと思います。
また、実際の現場でも「出来ませんでした」と諦めるのは勿体無いです。
やったことが無くても、任された以上は取り組む必要があります。
これらを踏まえると、「出来るか分からないけど、まず頑張ってみる」という姿勢が大切だなと感じています。
もちろん、「今のスキルだと難しい」や、「技術的に不可能」なケースもあります。
その場合は、今は保留にして別タスクを優先するのは問題ないです。
ただ、もしやりたいと思ったことがあれば、ぜひ挑戦して欲しいと思います。
7. 常に改良して機能開発を続ける
完全に「0 → 1」の開発を除き、実際の現場で既存アプリの新規機能開発をする時は、今あるコードを元に機能拡張したり、既存実装を参考にします。
そのため、個人開発で作ったアプリにも改良を加えたり、新機能のアイデアが出てきたら、積極的に追加した方がいいと思います。
別のアプリを作るのも力はつきますが、今のアプリで機能を追加する場合、既存コードをどう修正して機能を拡張するか？の問題と向き合えます。
この時に、設計をあまり考慮できてないアプリは、元々使っていた機能がバグる（デグレする）など、色々と苦労すると思います...
ただ、そこで苦労した経験は、そのまま実務で役立ちます。
先ほどの話にも繋がりますが、「この設計だとこんなデメリットがある」や「この場面なら、こんな設計にした方がいい」を考えるきっかけになるので、新しい機能を追加したいと思ったら、積極的に取り組んで欲しいと思います。
継続的に機能を追加していると、「新しい機能を追加しやすくする」・「既存機能に影響を与えずに機能を追加する」などの設計方法を考えるようになり、それがエンジニアの設計能力に直結します。
また、リファクタリングも大切です。こちらにも取り組んで欲しいと思います！
新規機能の追加時の注意点やリファクタリングに関しては、他の記事でまとめたので、もし興味があれば見て頂きたいです！
過去の自分へ(少しだけ厳しい話)
過去の自分への戒めも込めて、少しだけ厳しい話もしようと思います。
内容としては、精神論に近いです笑
もし厳しい言葉を求めている方がいれば、見ていただけると嬉しいです！(賛否両論分かれると思います)
あなたは、その設計である理由を語れますか？答えられますか？
何度もお伝えしている通り、プログラミングのチュートリアル教材や個人開発と比べ、現場のアプリケーションは複雑です。
その上で、AIを使い開発が加速して、さらに複雑さが増していくのは、容易に想像できます。
それらを踏まえると、今後エンジニアに求められるスキルは、「複雑な状況の中でも、今後の拡張や保守の観点から、様々な要因をもとに、ベストプラクティスを導きだす能力」、だと思います。
このスキルを身につけるには場数を踏むしかなく、「この設計をすると、こんな落とし穴がある」や、「開発スピードを優先するため、技術的負債にはなるが開発スピードを優先する」などの経験積むことで、少しずつ見えてくるものです。
色々な経験を積み、沢山のアプリを開発して、設計の落とし穴を知ることで、成長していけます。
しかし、バイブコーディングは、ライブラリ選定・テーブル設計・実装まで、AIがよしなにやってくれるので、「設計・実装の学び」はほぼありません。
また、そもそもなぜそのような設計・実装をしたか？まで考えていないので、その設計の落とし穴にも気づけず、そのアプリ開発を通じて得られるはずだった経験が、全て抜け落ちてしまう、と考えています。
もちろん、アプリの機能拡張をする際に、「技術的負債に気づく」というケースはありますが、
「そもそも0から考えた上で、自分の想定できるパターンを洗い出して考えた上で、発生した技術的負債」と、「とりあえず作らせたコードの技術的負債」では、経験から得られる学びの量が圧倒的に違います。
また、そもそもの土台となる設計スキルが身に付いていないので、場当たり的なスキルしか身につかないとも感じています...
そのコード・調査結果に責任を持てますか？
今後AIの利用が活発になり、Claude Codeなどのエージェントも今後ますます利用されると思います。
そんな中で、上司から任されたタスクが出来なかった時に「AIにやらせてダメでした」という報告は、個人的にはNGだと思っています。
「なぜできなかったか？」・「どう要件を変えればできるのか？」・「何を妥協しないといけないか？」
これらの視点で調査して報告できないと、「それなら初めからAIに任せればいい」となります。
(「できるかどうか？」の事実は、AIに指示させるだけで確認できるため)
AIは調査もしてくれるし、コードも書いてくれます。でも、その調査が間違いないか、そのコードは質が高いか？ここの品質を担保して責任を取るのは、今は人の仕事です。
だからこそ、目の前のコード・調査結果に責任を持つことが大切だと思います。
「バイブコーディングでアプリを作成した」≠ 「技術力の証明」
「バイブコーディングでアプリを開発しました」
この事実だけでは、「技術力があると証明できない」と思っています。
より正確にいうと、「作る」こと自体には価値がなく、そこで行っていた「設計やバグ・障害対応」に価値が宿ります。
例えば、非エンジニアの方がアプリケーションをAIに任せて全部開発したとします。
この時に、非エンジニアの方は、「技術力はあるか？」と聞かれた際、答えは「No」だと思います。
つまり、「理解してるかどうかは確認しないと分からない」ということです。
実装で困ったことは？どこを工夫したか？
これらの質問に答えられるよう取り組むことが、学びを最大化する方法です。
と言いつつ、僕自身まだまだ出来ていません…
ぜひ、一緒に成長できればと思います！
良い方法があれば教えてください！笑
まとめ
AIを使って何としても成果を出そうとする気持ちや姿勢は、素敵なことです！
もし「さらに学びを深めたい」や「成長してる実感が持てない」という方のお役に立てれば嬉しいです！
「こうした方がいいんじゃないか？」・「こんなことに意識したらいいんじゃないか？」などあれば、ぜひコメントで教えてください！
Discussion