はじめに
AIが出してきた設計書、ちゃんと読めていますか。
自分は読めていませんでした。長いし、単語も半分くらい意味がわからない。認知負荷が高すぎて、結果何を言っているかわからん状態になる。それでも手は止められないので、なんとなく「OKです」と返す。
これを変えたくて、1ヶ月で学習のやり方を4つ試しました。
で、1ヶ月経って業務で変わったのは「書けるコードの量」じゃなかったです。上司と設計の話をしてもズレなくなって、AIに書かせた設計書がちょっとわかるようになった。増えていたのは実装力じゃなく、語彙のほうでした。
見え方でいうと、こう変わりました。
全部わかるようになったわけではないです。わからない部分を「ここがわからない」と切り分けられるようになった、くらいの変化。
この記事では、試した4つのやり方と、何が効いて何が効かなかったかを書きます。4つのうち2つは実は同じ方法で、1点だけ違ったせいで結果が正反対になりました。
こんな人に読んでほしいです。
- AIにコードを書かせているけど、出てきたものを「なんとなくOK」で通している
- 学習はしているのに、業務に効いている実感がない
自分はエンジニア歴が浅くて、業務ではTypeScriptとNext.jsを触っています。手を動かす学習そのものについては前回書いたので、今回はその1ヶ月後の続きです。
この記事の流れ
- 1ヶ月前のAIの出力は全部ひとかたまりだった
- 1ヶ月で4つのやり方を試した — 何を得て、何を理由に乗り換えたか
- 効いたのは実装力ではなく語彙だった — 業務で起きた変化
- 語彙は読むだけでは入らない — 入れ方の話
- それでも速度は落とさない — 自分に課している2つのルール
1ヶ月前のAIの出力は全部ひとかたまりだった
1ヶ月前、AIに実装を任せる場面が増えていました。ただ、出てきたものを判断できていない。
具体的にはこんな感じです。
- AIの出力が長くて、認知負荷が高すぎて、結果何を言っているかわからん
- 業務で設計や動作検証をAIに当てても、どこを見たらいいかわからない
- 会話で聞いたことはあるのに、意味がわからない単語がいくつもある
- そもそも「設計」が何を指しているのかもわかっていない
判断できないから「なんか良さそう」で通す。ここがスタートでした。
1ヶ月で4つのやり方を試した
全体像から。矢印のラベルが、そのやり方をやめた理由です。
段階1. AIに教材を作らせる（答えのコードは書かせない）
業務で触っている処理を1つ切り出して、AIには「実装の順番だけをコメントにした教材」を作らせる。中身は自分で埋める。答えのコードは書かせません。
// ===== Step2: 条件に合うものだけ残す =====
// ヒント: 配列から条件に一致した要素だけを残すメソッドは何か
// （ここに答えは書かない）
ここで身についたのは破壊的変更でした。配列をそのまま操作するのと、map で新しく配列を作るのは何が違うのか。答えは、別のところで同じ配列を使っていたときに影響範囲が広がるから。
良かったのは、目の前のコードに対して「この関数はどんな動きするの」「なんでこれよりこっちがいいの」を聞きまくったことです。一般論として語られる破壊的変更のユースケースを、具体のコードから逆に知れた感じがしました。
ただ、これだといずれコードは読めるようになるけど、AIに教材を作らせている以上は網羅性がない。実務に活かせるまで時間がかかるなと思って、体系的にインプットする方向に変えました。
段階2. 既製の体系教材で面を埋める
サバイバルTypeScriptを読んで、ハンズオンで進められる部分だけをやりました。
ここで感じたのは、足りていないのはTypeScriptの文法じゃないということです。アプリケーションを作る上での前提知識のほうがなかった。
- Reactのコンポーネント思考みたいなところ
- ルーティングがそのままディレクトリ構造になっていること
- テストフレームワークでテストを書くってこんな感じなのか、という部分
この前提知識がないせいで、業務中にAIを当てながら設計や実装や動作検証をしても、どこを見たらいいかわからない。冒頭に書いた「認知負荷が高すぎて何を言っているかわからん」の正体はこれでした。コードが読めないんじゃなくて、地図を持っていなかった。
このやり方をやめたきっかけは2つあります。
1つは上司との1on1です。今やっていることを共有したら、「実務的に設計判断をするみたいなところまでいかないよね」と言われました。そのあとに続いたのがこれです。
成長するのって、コードが書けるようになったではなく、拡張していく中で判断する回数を増やすことが一番
確かに、AIがコードを書くという時代に、いまコードを書くだけやるの勿体無いなという感じがしました。
もう1つは単純で、教材の次の章がPrettierとかESLintのあたりで、ここを学んでも今は活きなさそうだなと思ったこと。
段階3. AIに教材を作らせる（今度は答えのコードごと）
次にやったのは、AIにハンズオン教材を作ってもらってCRUDアプリを一通り作る、というものです。段階1と同じ「AIに教材を作らせる」ですが、今回は教材に答えのコードが最初から書かれている形でした。
良かった点はあります。スピード感があって、CRUDの処理ってこんな感じか、という体感は得られました。実働3日です。
ただ、レベルアップしている感はなかった。理由は2つあります。
- 教材にコードがすでにあるからコピペで行けてしまう。あまり自分の中に残らない
- 設計も仕様も全部AIに任せて教材を作らせているので、自分が判断する場面がない
同じ「AIに教材を作らせる」なのに、段階1では残って段階3では残らなかった。違いは1点だけです。
⚠️ 「AIに教材を作らせる」という方法が良いか悪いかの話ではなかったです。答えのコードを書かせたかどうかで結果が反対になっただけ。速く体感だけ取りたいなら書かせる、身につけたいなら書かせない。そういうレバーだと思っています。
段階4. 1から自作して拡張する
上司の「判断の量」というアドバイスを受けて、1から自分でWebアプリを作って機能をどんどん拡張していく方向に決めました。
作っているもの: GitHub風の学習記録アプリ
日々の学習を記録して、学習時間に応じてGitHubのcontributions（草）みたいなヒートマップで積み上がりが見えるアプリです。完成したら実際に自分の学習記録に使うつもりで作っています。
進め方はこの順で考えています。
- いまここ — 基本的な一覧表示と、草のヒートマップ
- 次 — CRUD（追加・編集・削除）
- その次 — ログイン機能を入れて、認証/認可をインプットしてアウトプット
機能を足すたびに知らない領域が来るので、そのたびに調べて自分の設計に落とす。これを繰り返して判断の回数を増やしていく想定です。
ただ、アプリ開発の進め方自体を知りません。なのでAIには「進め方」だけ考えてもらいました。最初にテーマを決めて、スキーマ設計して、みたいな段取りの部分です。テーマも設計も実装も、中身は自分でやる。段階1では要件も処理の流れもAIに考えてもらっていたので、任せる対象が中身から段取りに移った形になります。
技術スタックは最低限にしました。
| カテゴリ | 採用 | 理由 |
|---|---|---|
| 言語 | TypeScript | フロントもバックも書けるから |
| フレームワーク | Next.js | 同上 |
| DB | SQLite | 立てる手間をかけたくない |
| ORM | Prisma | 業務で使っていたから |
Dockerを使ってとか、DBを立てるとかをやると、結果発散するので入れていません。増やしたいのは設計判断の回数であって、環境構築の判断ではないので。
で、スキーマ設計をやろうというところで手が止まりました。やり方がわからない。ここは書籍から体系的にインプットしたらいいんじゃないかと思って、『達人に学ぶDB設計徹底指南書』を読み始めました。
読んで最初にわかったのが、そもそも設計って何かもわかっていなかったということです。設計には論理設計と物理設計がある。これがわかるだけでも、業務で上司と会話するときにズレないなと感じました。ここで、体系的に学習するのも大事だなと実感し直しています。
そのあとテーブル設計の進め方と正規化を読んで、それを学習記録アプリの設計に落とし込みました。テーブル1つでも型や制約など知らない要素多かったです。主キー、外部キー、参照整合性制約、関数従属、第1〜第3正規形。業務で聞いたことあるけどわからなかった単語が、ここで腑に落ちるところ多かった。
ハンズオンでは得られなかった感覚でした。インプットしたことをアウトプットすることで理解できたというか、自分の中に体感で溜まっている。この感覚が成長している実感になっています。
Prismaのスキーマ定義は、設計はできているからAIに書かせてもいいかなと思ったんですが、自分で書きました。その見返りは後で書きます。
効いたのは実装力ではなく語彙だった
1ヶ月経って、業務で変わったのはこの3つです。
- 上司と設計の会話をしてもズレない
- AIに書かせた設計書が、ちょっとわかるようになった
- 業務でPrismaのスキーマが出てきても抵抗感がなくなった
書き出してから気づいたんですが、この中に「コードが速く書けるようになった」「1人で機能を作れるようになった」が1つも入っていません。変化が全部、受け取る側で起きている。
そして増えていたのは、書けるコードじゃなく言葉のほうでした。
破壊的変更と影響範囲、コンポーネント思考、ルーティングとディレクトリ構造、テストの書き方、論理設計と物理設計、正規化、関数従属、主キーと外部キーと制約。
全部、業務で飛び交っていたのに素通りしていた言葉です。AIの出力が読めなかったのは、コードが読めないからじゃなくて、この言葉を持っていなかったから。
4つのやり方を、速度と判断回数で並べるとこうなります。
| 段階 | 速度 | 判断回数 | 取りに行ったもの |
|---|---|---|---|
| 1. AI教材（答えなし） | 遅い | 少 | 判断の材料 |
| 2. 体系教材 | 中 | 0 | 前提知識の地図 |
| 3. AI教材（答えあり） | 速い | 0 | CRUDの体感 |
| 4. 自作して拡張 | 遅い | 最大 | 判断そのもの |
一直線に上がってきたわけではないです。そのとき足りないものを取りに行って、乗り換えただけ。
語彙は読むだけでは入らない
ここが一番の学びでした。同じ「本を読む」でも、読んで終わりだと入らない。
点線が段階2、実線が段階4です。段階2で読んだ内容も知識としては入っていたはずですが、実感は薄いままでした。段階4で、自分のアプリのスキーマをどう切るかという判断に使った瞬間に腑に落ちた。
Prismaのスキーマを自分で書いた件も同じでした。設計は終わっているのでAIに書かせてもよかった。でも自分で書いてみたことで得られたのは、書けるスキルじゃなくて、読める状態のほうです。業務でAIに書かせた設計書を見たときに、わかる部分が出てきた。
つまり自分で手を動かす目的は、自分で書けるようになることじゃなくて、AIや他人の出力を読めるようになることでした。ここが1ヶ月前と一番変わった認識です。
それでも速度は落とさない
じゃあ全部手で書くのかというと、そうはしていません。速度が落ちるとモチベーション的に苦しいので、自分の中で2つルールを決めています。
1. ドキュメントは見る。ただし深追いしない
気になったらドキュメントを見るのは大事です。業務をやっていて実感しました。ただ、全部それをやると自分の場合は先に進まなくて、モチベ的にも苦しい。なので一定のスピード感を維持するために、深追いはしないと決めています。
2. 一度自分で書けたパターンは、AIに生成させてよい
学習用のディレクトリには、AIに対するルールをファイルに書いて置いています。原則は「答えのコードは書かない、渡すのは地図とヒントだけ」。ただ、途中でこの例外を足しました。
## AI生成の例外（量産コード）
原則は変わらず「答えのコードは書かない」。ただし自分で一度書いて説明できる
パターンの反復・量産（seedデータの複製追加など）はAIが生成してよい。
条件:
1. そのパターンを自力で1回書いた実績があること
2. 生成後にレビューして内容を説明できること
3. 学習ログに「生成させた範囲」を記録すること
初出のパターン・学習対象のコード（スキーマ、クエリ、コンポーネント、ロジック）
は引き続き手で書く。
原則を守り切ったというより、緩める条件を先に書いておいたのでなし崩しにならずに済んだ、という感じです。
まだわからないこと
正直、AIの出力が全部読めるようになったわけではないです。設計書も「ちょっとわかる」レベル。
ただ、どこがわからないかは言えるようになりました。1ヶ月前はこれができなかったので、これはこれで進んだと思っています。次に埋める語彙のリストにもなるので。
まとめ
- AIの出力が読めなかった原因は、コードが読めないことじゃなくて、語彙を持っていなかったこと
- 語彙は読むだけでは入らなくて、自分の設計判断に使って初めて腑に落ちた
- 同じ「AIに教材を作らせる」でも、答えのコードを書かせるかどうかで残り方が反対になった
- 手を動かす目的は、書けるようになるためじゃなく、読めるようになるためだと思うようになった
アプリはまだ草のヒートマップを作っている途中です。次にCRUD、そのあと認証/認可に入ります。知らない領域が来るたびに同じことをやってみて、また語彙が増えるのか試してみます。