Urazuke — 手でプログラムを書く時代の後のジュニア開発者：その育成で何が変わり、何を目指して、どう育てるか

著者：Pablo Kuschniroff、Claude Codeの支援による。第1版、2026年10月18日。この文書は方法の 主文書と、コースの二つのパート（新規プロジェクト、受け継いだプロジェクト）に寄り添うものだ。三種類の読者のために書いた：チームを率い、入ってくる人に何を教えるかを決めなければならない人。教えるか、メンタリングをする人。そして何になりたいのかを知りたいジュニア本人。見慣れない言葉は主文書の用語集にある。公開リポジトリ： github.com/pkuschnirof/urazuke。

なぜこれを書くのか

三十年のあいだ、ジュニア開発者はただ一つのやり方で育った：監督のもとでコードを書くことによって。半分わかった言語を持って入り、小さくて限られた課題を与えられ、シニアがそのコードをレビューし、書いては直されるのを二、三年続けるうちに手職を身につけた。コードは仕事であると同時に学校だった。

それが終わった。ジュニアがもう要らないからではなく、モデルがコードを書くからだ。私の方法では、構築する者はコードを読まない：証拠を要求する。だから私にぶつけられ、私自身も自分にぶつける問いは、正直で、急を要する。ジュニアがもうコードを書かないなら、どうやって学ぶのか。そして何を学ぶのか。そして何になるために。

答えはある。そして二つの場所から書く。一つは、こうして構築した三つのシステム。そこでは私が唯一の人間で、インシデントごとに、どの能力が私を救い、どの能力は要らなかったかを見た。もう一つは、モデルが存在する前にシステム工学を教えた年月だ。今日ジュニアに教えなければならないことの多くは、古典的なシステム工学が常に教えてきて、手職が「プログラミング」になったときに業界が実践をやめたことである。モデルは、キーボードがそれを覆い隠す前の手職が何であったかへ、私たちを戻らせる。

誤解されないための警告：私はジュニアがプログラミングを知らなくてよいと言っているのではない。 もうプログラミングによって育つのではないと言っており、プログラミングについて知らなければならないことの性質が変わる、と言っている：手職から、読み書きの素養へ。

ジュニアは何をしていたか、そして今は何をするか

育成の重点への影響

まず一文で言い、それから分解する：失われるのはモデルが二年目のジュニアよりうまくやることすべてであり、重みを増すのはモデルが下手にやり、方法がそれを正すために存在することすべてだ。二つ目のリストは私が発明したものではない。参照文書の失敗のリストを、裏返して見たものだ。モデルの各失敗は、人間が持たなければならない能力である。

重みを失う重点

• 構文と言語。 言語を「暗記で」知っていることは育成の半分だった。もう違う：モデルはどの言語でも、より良く、より速く書く。残るのはそれらを*読める*ことで、それは別のことだ（下を見よ）。
• フレームワークとライブラリ。 あるライブラリのAPIを知っていることは市場価値だった。モデルはそれを、バージョンごと、まるごと知っている。ジュニアはそれらが存在すること、何のためにあるか、いつどれを選ぶかを知る必要があり、各関数の名前を知る必要はない。
• タイピングと書く速さ。 エディタのショートカット、補完、足場を手で作ること。重点として消えた。
• 主要な手職としての一行ずつのデバッグ。 存在はし続けるが、場所が変わる：今は最後の道具であり、証拠（ログ、赤のテスト、計器）が足りなかったときのものだ。
• 「こういうときはこうする」という記憶。 パターン、レシピ、こつ。モデルはそれを全部持っている。

重みを増す重点

それらが鍛えられる段の順に並べる。それが教え方だからだ。

1. 要件工学（第0、2、3、5段）。自分が何を望んでいるかわかっていないオーナーにインタビューし、彼が望むものを散文で書き、ユースケースに名前を付け、業務のセマンティックツリーを組み、保留項目を「前提、とき、ならば」の形の受け入れ基準とともに仕様化し、一次データを派生データと区別して、推定する代わりに一次データを求めること。これが能力の第一位であり、業界が二十年前に教えるのをやめたものだ。モデルは設計上これが最悪だ：穴を最も確からしいもので埋め、最も確からしいものは業務が必要とするものではない。
2. 検証の設計（第8、7、12、19段）。テストを書くことではない：どのテストが何を実証するか、なぜテストは価値を持つ前に赤で見られなければならないか、エンドツーエンドのテストとは何で、何も証明しないシミュレーションとは何か、どの数字が何かを決め、どの計器で測るか、報告をどう読み、検証されたものと信じられているものをどう区別するかを知ること。ジュニアは、テストを読まずに「そのテストはあなたの言うことを証明していない」と言えなければならない。
3. 証拠を読むこと（すべての段）。モデルの報告を、訓練された不信とともに読むこと：証明のない主張、検証済みに化けた「動くはずです」、宣言されていない盲点、そうではなかった「完了」を見つけること Ref. 43。この能力は育成の重点として存在しなかった。これほど自信たっぷりに、これほど上手な文章で嘘をつく者がいなかったからだ。
4. サイジングと運用（第3、4、15段、16から22段）。環境とは何か、どうデプロイするか、継続的インテグレーションとは何か、本番で何を計測するか、インデックスとは、破断点とは、警報の閾値とは何か。以前は別の役割の領域だった。今はジュニアがそれを行うモデルを指揮するのであり、何を求め、それをやったことをどう検証するかを知らなければならない。
5. セキュリティと帰結（第14、18段）。システムのどの行動が世界に作用するか、錠とは何か、フェイルクローズドとは何か、脆弱性とは何か、そしてなぜ依存関係の更新は変更なのか。
6. 決定とオーナーとの意思疎通（第1、6、20段）。推薦と代替案を添えて、うまく問うこと。決定を、発言そのまま、日付、持ち主とともに書くこと。プログラミングをしない人が追えるマニュアルを書くこと。方法において、ジュニアはオーナーとモデルのあいだの翻訳者であり、翻訳は双方向に行われる。
7. 道具としての英語。 方法のプロンプトは英語だ。モデルは英語でより正確に指示に従うからだ。話せる必要はない。プロンプトを読んで各条項を理解し、場合が求めるときに新しい条項を書ければよい。
8. モデルの失敗のカタログ。 モデルが間違うそれぞれの形を、その匂いで見分けること：質問する代わりに仮定する、一次データを発明する、過剰に報告する、範囲外のことを「ついでに」する、頼まれていないものをリファクタリングする、あなたの言葉を「改善」する、証拠なしに閉じる、わからないときに黙る。私がセッション中に行い、ルールになった四つの訂正 Ref. 45 がその例だ：どれも、育ったジュニアが最初の報告で検知しなければならない失敗である。
9. 予算としてのコスト。 トークン、継続的インテグレーションのクォータ、オーナーの時間。コストを見ないジュニアは、二倍使って半分しか納めなかったマルチエージェントのチームを繰り返す Ref. 6。

ジュニアがプログラミングについて知らなければならないこと：手職ではなく、読み書きの素養

ここに、私が最も大事に思い、最も誤解される機微がある。コードを一度も書いたことのないジュニアは、モデルがコードの*中で*嘘をつくときにそれがわからない。そして方法には、今日は私が主文書で仮説として印を付けている、人間が本当に見なければならない瞬間がある。だから最低限の読み書きの素養は交渉の対象ではない。そのリスト：

• コードを読むこと、書くことではない：関数を追い、条件分岐を理解し、ループを見分け、どこでデータベースへの照会が行われるかを見ること。弁護士でなくても契約書を読むように。
• システムがどう走るか：サーバー、プロセス、データベース、HTTPの要求、ブラウザ、スケジュールされたジョブとは何か。どこに何が住んでいるか。
• Git：コミット、ブランチ、プッシュ、履歴とは何か。方法がそこに残す証拠の跡を読むのに足りるだけ。
• 基本のSQL：クエリを読んで、どのテーブルをどんな絞り込みで読むか理解すること。データの言語であり、第7段の数字の言語だ。
• ターミナル：モデルがくれたコマンドを走らせ、その出力を読むこと。ジュニアが計器を走らせられないなら、数字を検証できない。
• 最後の道具としてのデバッグ：ログもテストも計器も足りなかったとき、モデルを隣に置いてコードを開き、一緒に読むこと。

最初の段階で教えられ、コースのあいだずっと練習され、そしてそれは手職ではない：手職を営むことを可能にする読み書きの素養だ。

何を目指してジュニアを育てるか

回りくどい言い方はしない。目標の明快さに他のすべてがかかっているからだ。手でプログラムを書く時代の後にジュニアを育てる目標は、そのコードを一行も書かずに本番のシステムについて責任を負える人を育てることだ：小さなプロジェクトを二十四の段を通して端から端まで運び、モデルを指揮し、各段で証拠を要求し、オーナーとともに決定し、そしていかなるときも何が検証され、何が信じられており、何が見えていないかを知っている人。私はそれを、暫定的に*証拠の技術的な持ち主*と呼んでいる：コードを読まず、それでいて、証拠を手に、システムは業務が求めたことをしており、明日もそうし続ける、と言える人だ。

目標から出る三つの帰結が、育成を整える：

1. 評価の成果物はコードではなく証拠だ。 ジュニアは、書いた契約、組んだツリー、仕様化した保留項目、要求した赤、受け入れなかった報告で評価される。コースのマニュアルの付録Aの評価基準がすでにそう言っている：登っていない、登った、判断力の証拠とともに登った。その三番目の水準、モデルが間違えた事例とそれをどう検知したかを語れること、が本当の目標だ。
2. 反射はインシデントで形成され、理論では形成されない。 疑うべきだと読んで、モデルを疑うことを学ぶ人はいない。モデルが「完了」と言ってそうではなく、それをテスト環境で発見したときに学ぶ。だからコースにはわざとの試験がある（質問を一つ答えずに置いてモデルが何をするか見る、調査に仮定を残す）。だから育成には、うまくいく課題だけでなく、設計されたインシデントがなければならない。
3. ジュニアは方法の全体で育つのであって、一区間では育たない。 誘惑は、ループの中で「保留項目をやらせる」ことだ。それが小さなコードの課題を与えることに最も近い。それは誤りだ：立ち上げのないループは砂の上に建てることであり、第0段や第3段を一度もやったことのないジュニアは、なぜ第5段がその形をしているのかを理解しない。二つのガイドプロジェクトはそのために存在する：新規のものと受け継いだもの、端から端まで、二十四の段と八つのステーション。

どう育てるか：その計画

以下は私が使うであろう計画であり、最初のコホートで使うつもりのものだ：四つの段階、期限なし（方法には期限がなく、育成にもない：各段階はその修了リストが「はい」になったときに終わる）。メンター付きで、コースの二つのガイドプロジェクトの上で。そしてその後、本物のオーナーを持つ小さな実際のプロジェクト。

段階1：読み書きの素養と、研究対象としてのモデル

• 上に書いた読み書きの素養：コードを読む、システムがどう走るか、git、基本のSQL、ターミナル。モデルを隣に置いて説明させながら。ジュニアは書かない。読み、走らせる。
• 研究対象としてのモデル：モデルが失敗するのを見ることだけを目的として、モデルに依頼をするひととき。持っていないデータを求めて、発明するか見る。曖昧な依頼をして、質問するか見る。何かを閉じるよう求めて、証明なしに「完了」と言うか見る。再現せずにバグを直すよう求める。各失敗をその匂いとともに書き留める。段階の終わりにジュニアは自分のカタログを持ち、それは参照文書のカタログを、自分で発見したものだ。
• 主文書を、用語集を手元に置いて読むこと。そして参照文書を：各ルールがどこから出たかの歴史。

段階2：新規プロジェクト、メンター付き

コースのマニュアルのパート1を、そのまま、ガイドプロジェクト「Turnera」か自分の小さなプロジェクトの上で。二十四の段。三つのメンタリングのルールとともに：

• メンターはコードではなく証拠をレビューする。 共働の約束、セマンティックツリー、三つの保留項目の仕様、ある保留項目の締めの報告、監査の報告、負荷テストの報告を読む。そして毎回ただ一つの質問をする：「これが本当だと、どうしてわかるの？」。答えが「モデルがそう言ったから」なら、その段は登れていない。
• メンターはインシデントを設計する。 ときおり、予告なしに、何かを変える：調査のデータを変える、ボリュームに仮定を混ぜる、モデルを通して範囲外の変更を求める。ジュニアは証拠でそれを検知しなければならない。
• ジュニアはモデルの失敗の記録を自分で付ける：捕まえるたびに、どんな匂いがしたか、どの段でか。プロジェクトの終わりにその記録は彼個人の振り返りであり、はしごへの変更提案（第23段）は彼が書く。

段階3：受け継いだプロジェクト、メンターは控えめに

マニュアルのパート2：受け継いだTurnera、または本物の小さなレガシー。正常化の区間と最初の二つのブロック。ここでメンタリングは下がる：メンターは復元された地図と食い違い、速度の印の付いた監査の報告、そして修正モードでの最初のバグの締めを読む。この段階の目標は、新規プロジェクトが教えないことをジュニアが学ぶことだ：モデルを通して他人のシステムを読むこと、コードがしていることのうち何が間違いで何が忘れられたルールだったかをオーナーとともに決めること、そして書き直さないこと。

段階4：実際のプロジェクト、一人で

本物の小さなプロジェクトを、一日十五分を持つ本物のオーナーとともに、端から端まで。メンターは介入しない。最後に数字付きの振り返りを読む。ジュニアがリリースのチェックリストの二十四の条件すべてを「はい」にして本番に到達したら、育成は済んでいる。そうでなければ、そのリストがどの段を登り直すべきかを正確に言い、それもまた育成だ。

何が進み具合を測るか

いくつ保留項目を閉じたか、ではない。三つのこと、この順で：

1. 何回モデルを捕まえたか、そしてどの段で。新規プロジェクト全体で一度もモデルを捕まえなかったジュニアは見ていない：モデルは必ず失敗する。
2. オーナーにいくらかかったか。 一日あたりの質問の分数。増えているなら、ジュニアは方法が自分に解かせようとしていることをオーナーに転嫁している（第1段）。
3. はしごへの変更提案の質。 これが判断力の指標だ：自分のインシデントで正当化された具体的な変更を提案するジュニアは、方法をリストとしてではなく生きたものとして理解した。

役割とチームへの影響

チームを率いる人が必ず聞くので書いておく。ジュニアがこうして育つなら、チームは形を変える：

• ジュニアは「簡単なものを書く人」であることをやめ、小さなプロジェクトを方法で丸ごと運ぶ人になる。より早く価値を持ち、より早く危険にもなる。速く構築するモデルを指揮するからだ。だから方法は付け足しではなく条件なのだ。
• シニアはコードのレビューをやめ、三つのことに移る：契約（共働の約束、ゲート、錠）を書いて保守すること、別のセッションで監査すること（第13段）、そしてジュニアが決められないことを決めること（アーキテクチャ、「十倍」、何がブロックするか）。その価値はキーボードから判断力へ移る。優れた人においてはいつもそこにあった。
• チームは小さくなり、平らになる。 方法を持つシニア一人とジュニア二、三人が、以前は八人のチームで運んでいたものを運ぶ。エージェントのチームを丸ごと廃止したとき、自分の数字でそれを見た Ref. 6：同じ論理が、モデルを指揮する人間にも当てはまる。
• ドメインのオーナーがチームに入る。 一日十五分で、だが入る。方法がそれを要求するからだ。ジュニアを育てることには、その十五分を獲得することと、それを浪費しないことを教えることが含まれる。

リスク、和らげずに言う

• コードを一度も書いたことがなく、いつ見るべきかわからないジュニア。 これが主要なリスクであり、必須の読み書きの素養と、最後の道具としてのデバッグの演習で和らげる。だが仮説として印を付ける：他人の書いたコードをうまく読むために、どれだけコードを書いたことがなければならないのか、私はまだ知らない。少しで足りると疑っているし、重要なのは書いたことではなく*デバッグした*ことだと疑っている。
• 一つの道具への依存。 方法はわざと道具に対して中立だ。一つの道具だけで育ったジュニアは、方法ではなくその道具のこつを学ぶ。育成は少なくとも二つを通らなければならない。
• 見えないコスト。 モデルを持つジュニアは、トークンを無料であるかのように使う。トークンの予算は最初の段階から育成の一部でなければならない。数字を目に見える場所に置いて。
• 速さの幻想。 モデルは以前ならずっとかかったものを一つのセッションで構築し、ジュニアは終わったと信じかねない。二十四の条件を持つ本番リリースのチェックリストが解毒剤だ：「終わった」には定義があり、それは「動く」ではない。
• 習慣でコードをレビューしてしまうメンター。 これはシニアの側のリスクで、深刻だ：コードを読むメンターは、証拠では足りないとジュニアに教えることになり、それはまさに方法の正反対だ。メンターはジュニアより先に方法を身につけなければならない。

まだ練り上げるべきこと 仮説

1. 他人のコードをうまく読むために、どれだけプログラミングをしたことがなければならないか。私の直観では、重要なのはデバッグしたことであって書いたことではなく、少しで足りる。まだデータはない。
2. 四つの段階の計画は、私のプロジェクトと、モデル以前に教えたことから書かれたものであって、コホートから書かれたものではない。最初のコホートがそれを修正するだろう、コースと同じように。
3. 「証拠の技術的な持ち主」が新しい役割なのか、別の道具を持ったいつものシステム技術者なのか。私は後者に傾いていて、ならば名前は余計だ。だが市場は名前を必要とするだろうし、もっと悪い名前が提案される前に一つ提案するほうがよい。
4. 方法を使わないチームに入るジュニアはどうなるか。この文書はチームがそれを採用することを前提にしている。そうでなければ、こうして育ったジュニアはコードを求めるシニアとぶつかる。答えは持っていない。ただ、そのシニアが読めるように方法は公開されている、ということのほかは。