設計思想 — なぜこの教材はこう作られているのか

Proverse to FDE は「何を教えるか」と同じくらい「どう教えるか」に投資しています。このページでは、教材の骨格になっている6つの設計原則を、その理由ごと公開します。読んで納得できたら学び始めてください。納得できない点があれば、それはこの教材があなたに合わないサインかもしれません。それも含めて、先に正直にお見せします。

前提 — 業務に寄り添う開発を教える

6つの原則の前に、そもそも誰を育てたい教材なのかを書いておきます。目指すのは、お客様の業務を理解し、困りごとに寄り添ったシステム開発ができる人です。作る楽しさは学びを続ける力になりますし、AI に作業を頼めば手は速くなります。ただ、どちらもこの教材のゴールではありません。相手の仕事を知り、何を作るべきかを一緒に決め、できたものに自分で責任を持つ——そこまでを含めて「開発ができる」と呼ぶのが、この教材の立場です。以下の6つの原則は、すべてここから逆算しています。

1. 認知負荷バジェット — 1章につき、新しいことは1種類だけ

学習でつまずく大きな原因は「難しいから」ではなく「新しいことが同時に多すぎるから」だと考えています。そこでこの教材は、学ぶ内容を3つのレイヤーに分けています。

① ツールの操作（ターミナル・Git・Claude Code など）
② プログラミングの概念（秘密情報の扱い・Web の仕組みなど）
③ AI との協働の作法（依頼の分解・生成物の検証など）

そして1つの章で新しく導入するレイヤーは1つまで、という予算（バジェット）を章構成に課しています。第0章はツール操作だけ。第1章はコードを書かず、AI協働の入口だけ。「あれもこれも一度に」をやらないことが、この教材の章立てそのものです。

2. modify-first — 写経より「読める・直せる」

この教材では、コードをゼロから書き写す練習（写経）をほとんどしません。代わりに、Claude が書く → あなたが「どのファイルに何ができたか・どこが変わったか」を把握する → あなたが小さく手で改変する、という順番で進めます。ゼロから手で書くのは、各概念の核になる10行以下の部分だけです。

理由は単純で、AI と協働する時代の実務は「生成されたものの置き場所と役割を把握し、検証し、必要な箇所に手を入れる」ことが中心だからです。どこに何があるか分からない成果物は直せず、直せないものには責任が持てません。「自分で1箇所変えられる」ことを、常に「全部書ける」ことより優先します。

3. 理解ゲート — 「動いた」と「わかった」を区別する3つの問い

各レッスンの最後には、試験官役（gatekeeper）による口頭試問があります。問いは3種類です。

(a) 構造の説明 — 「このプロジェクトのどこに何があるか、今回の変更はどのファイルで・何のためだったかを自分の言葉で説明してください」
(b) 仕組みの説明 — 「今作ったものの構成を図で描いて、お客様に説明するつもりで話してください」
(c) 懐疑の検証 — 「この生成コードで疑った点・確認した点はどこですか。実際に動かして、期待どおりか確かめましたか」

3つすべてに答えられるまで、次のレッスンには進めません。スキップもできません。 AI と一緒に作ると「動いたけれど、どこに何があるのか説明できない」状態が簡単に生まれます。コードを1行ずつ語れる必要はありません。求めるのは「直したいとき、どのファイルを開けばいいか」が頭にあることです。動いたことと理解したことを毎回区別する関所が、このゲートです。お客様に説明できないものは納品できない——それが FDE の仕事の流れそのものだからです。

4. 罠モード — わざと間違える先生

第3章以降、教師Claude（mentor）は「私の提案は時々間違っています。気づいたら指摘してください」と事前に宣言したうえで、時々もっともらしくて微妙な提案を混ぜてきます。あなたが指摘できたら賞賛され、見逃したら後から丁寧に種明かしと解説があります。

AI の提案を無条件に受け入れる癖は、実務ではそのまま事故になります。かといって、学び始めたばかりの時期に先生を疑わせると、不安と不信だけが残ります。だから罠モードは第1〜2章では無効にし、基礎の安心感が育ってから、必ず事前告知つきで解禁します。だまし討ちはしません。「疑ってよい」というルールを共有したうえでの練習試合です。

5. AI健全懐疑 — 動かす前に疑う

この教材には「動かす前に疑う」という小さな儀式があります。AI が生成したコードを実行する前に、怪しい点・確認すべき点を最低1つ挙げてから動かす、というものです。

導入は段階的です。序盤は、教材に付属する「もっともらしく間違ったコード」をレビューする安全な練習から始め、後半は罠モードとの実戦に移ります。土台にあるのは、「AI が書いたコードも、納品するのは自分。責任は自分にある」という原則です。疑うことは AI への不信ではなく、成果物への責任の取り方だと位置づけています。

6. 模擬顧客形式 — すべての演習は「依頼」から始まる

演習は問題文からではなく、模擬のお客様役（client）からの曖昧な依頼から始まります。あなたはお客様に質問して要件を聞き出し、作り、最後にお客様の言葉で完成報告をします。技術の練習と、お客様対応の練習を切り離しません。

FDE の仕事は、コードを書く前（困りごとを聞き出して形にする）と、書いた後（相手の言葉で説明して引き渡す）にこそ核心があります。座学の「顧客対応講座」を別に設けるのではなく、毎回の演習の入口と出口に埋め込む——それがこの教材の作りです。

おわりに — これらは検証中の設計です

ここに書いた原則は、私たちが確信を持って選んだ設計であると同時に、実際の学習者と一緒に検証している最中の仮説でもあります。うまく機能しない部分が見つかれば、教材は直します。だからこそ、モニターとして学びながら感想を聞かせてくれる方を歓迎しています。

教材を読んでみる — 第0章から、ブラウザでそのまま読めます。