AIに振り回されない開発力を磨く

AIコード生成が当たり前になった今、
「動くものを最速で作る」こと自体の価値は、以前より相対的に下がっています。

一方で、

• なぜその設計にするのか
• なぜその実装にするのか
• なぜそのエラーが起きるのか
• なぜその構成は危険なのか
• AIの提案は本当に正しいのか

こういった“技術的な判断”の価値は、むしろ以前より重要になっています。

このプランは、
「AIに全部任せる」のではなく、
「AIを道具として使いこなしながら、自分の技術力を育てたい人」のためのプランです。

このプランで重視すること

最近は、AIにコードを書かせることで短期間で成果物を作れる時代になりました。

しかし実際の開発現場では、

• 原因不明の不具合
• パフォーマンス問題
• 保守不能な構成
• セキュリティ事故
• 本番環境だけで起きる問題

など、「コードが動く」だけでは解決できない問題が大量に存在します。

そして、こうした問題に向き合うには、

• WebやHTTPの仕組み
• DBやSQLの特性
• JVMやJavaScriptランタイムの挙動
• ブラウザやOSなど実行環境の理解
• ネットワークやスレッドなど並行処理の知識
• セキュリティやアーキテクチャ設計の考え方
• ライブラリやフレームワーク内部への理解

のような、“地味だけど本質的な理解”が必要になります。

このプランでは、単なる「答え」を渡すのではなく、

• なぜそうなるのか
• 他にどんな選択肢があるのか
• その設計のトレードオフは何か
• 将来的にどこで破綻するのか
• AIの回答のどこが危険なのか

を重視して解説します。

「コピペで終わり」ではなく、
「自分の頭で判断できる状態」を目指します。

具体的な進め方

基本的には、メンティー側から題材を持ち込んでもらうスタイルを想定しています。

例えば、

• 実際に開発しているアプリ
• 趣味開発のコード
• AIに生成させたコード
• 設計で悩んでいる箇所
• 原因不明のエラー
• API設計
• DB設計
• ディレクトリ構成
• クラス設計
• 状態管理
• パフォーマンス問題
• セキュリティ面の不安

などを持ち込んでもらい、それを見ながら議論していきます。

進め方としては、

1. まず「何に悩んでいるか」を整理
2. 実際のコードや設計を見る
3. 問題点や違和感を一緒に分析
4. 「なぜそうなるのか」を掘り下げる
5. 改善案や別アプローチを比較する
6. AIの提案内容も含めて妥当性を検討する

という流れになることが多いです。

単純なレビューというより、

• なぜその設計に違和感があるのか
• なぜその責務分離にしたいのか
• なぜその抽象化が危険なのか
• なぜそのコードは将来壊れやすいのか

を、一緒に言語化していくイメージです。

「なんとなく気持ち悪い」を、技術的に説明できるようになることを重視しています。

向いている人

• 技術的な話が好き
• 実装の裏側に興味がある
• “なぜ？”を深掘りしたい
• ライブラリ内部の挙動が気になる
• エラー原因を追跡するのが嫌いではない
• 設計や責務分離を考えるのが好き
• AIの出力を鵜呑みにしたくない
• 長期的に通用する開発力を身につけたい
• 「なんとなく動く」状態が気持ち悪い
• 技術的なこだわりを持ちたい

あまり向いていない人

• とにかく最速で成果物を量産したい
• 技術理解よりスピード重視
• AIに全部任せたい
• 深い技術的議論には興味がない
• バイブコーディング中心で進めたい
• 「動けばOK」を重視したい

もちろん、生産性そのものを否定するつもりはありません。

ただ、このプランは
「短期的に大量生産するためのプラン」ではなく、

• 長期的に壊れにくい設計
• 問題発生時に自力で調査できる力
• 技術的判断力
• AIを制御できる理解力

を育てる方向の内容になります。

相談できる内容の例

• Spring Boot
• Java
• TypeScript
• React
• DB設計
• API設計
• セキュリティ
• パフォーマンス
• 設計レビュー
• 技術選定
• エラー解析
• AI生成コードレビュー

など。

「AI時代だからこそ、技術を深く理解したい」

そんな人向けのプランです。