新人エンジニアの初日——コードは渡されますが、「設計の意図」はどこにあるのか

2026.06.03

執筆者：DigKnow株式会社 CTO 桑原脩

入社初日の新人エンジニアにリポジトリのリンクを渡し、「簡単なタスクからやってみて」と伝えます。最初の数日は順調に進みます。でも、しばらく経ったある日、彼らは静かに壁にぶつかります。「処理は追えるのに、なぜこうなっているのかがどこにも書いていない」。私自身も新人だった頃に経験した、あの停滞の感覚が今も繰り返されています。

属人化がもう一つ別の場所で顕在化する瞬間

前回の記事で書いたとおり、情報はチームの中で特定の個人に集まっていきます。マネージャー視点では、この属人化は「退職時に痛い」「引き継ぎが大変」という形で顕在化します。でも実は、この属人化はもう一つ、別の場所で日常的に顕在化しています。

新人エンジニアのオンボーディング過程です。

ここで一つ確認しておくと、新人エンジニアの初日に「設計の意図を理解させる」必要があるかと言えば、必ずしもそうではないと思います。初日は環境構築、チームメンバーとの顔合わせ、最初のタスクの受け取り——そういった手続きで一日が終わります。アーキテクチャ図を渡されても、まだ全体像を受け止める余裕はありません。
新人に渡されるのは、たいていの場合「リポジトリへのアクセス」と「最初に取り組むタスク」です。コードは読めます。処理も追えます。コーディング規約を眺めて、テストの書き方を真似して、最初のPRを出すところまでは、表面上スムーズに進みます。
問題は、ここからしばらく経った後で始まります——属人化が、新人の前に姿を現す瞬間です。

「なぜこの設計なのか」が必要になる瞬間

新人が壁にぶつかるのは、最初のタスクを終えてしばらく経った頃です。
簡単な機能追加や軽い修正なら、既存のパターンをなぞるだけで進められます。AIアシスタントも「このリポジトリでよく使われている書き方」を提示してくれます。でも、少し複雑な修正に入ると、状況が変わります。「この処理を変えると、他のどこに影響するのか」「なぜここで非同期処理を使っているのか」「このモジュール分割の意図は何なのか」——こうした問いに、コードを読むだけでは答えが出ません。　
このタイミングで、新人は初めて「設計の意図」を求めて誰かに聞きに行きます。そして多くの場合、答えを持っている人が一人しかいないことに気づきます。あるいは、その人もすでに退職していて、誰も明確には答えられないことに気づきます。
初日に必要ないものが、入社して数週間〜数ヶ月のスパンで突然必要になる。そしてその必要性に直面したとき、すでに情報は組織として体系的に残されていない。これが、新人オンボーディングで起きている本質的な問題です。

つまり、新人の停滞の正体は「コードが読めない」ことではなく、「設計の意図にアクセスする経路が、組織のどこにも整備されていない」ことだと、私は思っています。

シニアと新人で異なる視界の中身

ここで一つ確認しておきたいのは、なぜ新人だけが「設計の意図」を強く必要とするのか、という点です。
シニアエンジニアと新人では、同じリポジトリを見ていても見えているものがまったく違います。
シニアは、過去の議論・Slackの流れ・PRのレビューコメント・運用経験——そういった大量の文脈を背景にコードを読んでいます。「あ、このモジュールね」という認識の裏側に、膨大な暗黙知が貼り付いています。設計の意図は、シニアの頭の中に既に存在しているため、わざわざ「設計の意図はどこにあるか？」と問うこともありません。
新人の視界にあるのは、プレーンなコードだけです。ディレクトリ構成も関数もそこにあります。でも「なぜこのモジュール分割なのか」「どういう思想でこの構成なのか」——そういった上位概念は、どこにも書かれていません。
シニアが「見えている」と思っているものの多くは、コードの中ではなくシニア自身の頭の中にあります。このギャップを自覚しないまま「コード読めばわかるよ」と新人に言ってしまいます。新人からすれば、これほど途方に暮れる助言はありません。問題は「コードが読めない」ことではなく、「コードのどこを読んでも書いていないこと」が、新人の前に立ちはだかることなのです。

AI時代に細くなる「なぜ」の伝達経路

ここにAIコーディングの影響が重なると、話はさらにややこしくなります。
新人は入社初日からClaude CodeやCursorを使えます。AIに聞けば関連ファイルを提示し、既存パターンに沿ったコードを生成してくれます。先輩に聞かなくても進められます。表面上のスピードは上がります。コードは動きます。PRは出ます。マージされます。
私自身も最近、入って間もない若手のPRをレビューしていて「なぜここは非同期じゃなくて同期なの？」と聞いたとき、「AIがこう書いたので、そのまま使いました」と返ってきたことがありました。コードは動いています。マージしても問題ない水準にあります。でも、設計を”引き継いだ”とは、たぶん言えません。
この新人は、このチームの設計思想を理解したのでしょうか。
答えは、おそらく「いいえ」です。AIが出してきたのは「このコードベースでよく見られるパターン」に過ぎません。なぜそのパターンが採用されているのか、他にどんな選択肢があって却下されたのか——こういった判断の経緯は、コードにもAIにも存在していません。新人の手元には「答え」だけが渡されます。でも、その答えがなぜ正解なのかを説明する力は、そこには付いてきません。
以前なら、新人が先輩に質問することで、この文脈は会話の中で少しずつ伝達されていました。AIが間に入ると、この「なぜ」のやり取りがスキップされます。新人は早く動けるようになります。でも、チームの設計思想を引き継ぐルートそのものが、細くなっていきます。

CTOとして真剣に不安に思っているのはここです。新人の生産性は上がっています。でも、五年後に彼らが「このシステムの設計を説明できる人」に育っているかどうか——その道筋は、AI時代の前より明らかに細くなっている気がしています。

組織の健康診断としての新人オンボーディング

ここで「じゃあREADMEやアーキテクチャドキュメントをちゃんと書こう」という方向に話が行きがちです。気持ちはわかります。私自身も何度もそう考えました。でも、経験的にこれはあまりうまくいきません。
理由は、[コードは残るが、仕様は誰も知らない]で書いた「書くコストと得られる価値のタイミングがずれる」問題の、新人版だからです。書くのは、その領域に詳しいシニア。シニアは書かなくてもわかっています。恩恵を受けるのは、今目の前にいるかどうかもわからない将来の新人。このタイミングのずれが、ドキュメント作成のインセンティブを構造的に弱くしています。
さらに厄介なのは、「何を書けば新人に役立つか」をシニアは判断できない、ということです。シニアにとって当たり前すぎる前提は書くリストから漏れます。「これくらいわかるでしょ」で省略された情報こそ、新人が一番詰まる情報だったりします。「人間が頑張って書く」アプローチの限界については、今後ドキュメント文化を扱う記事で改めて掘り下げます。
ここでマネージャー視点で一つだけ書いておきたいことがあります。新人がチームに加わってから設計の意図を求めて壁にぶつかる瞬間は、そのチームの「理解の在庫」が可視化される数少ない瞬間です。新人が何に詰まり、どの質問が誰に集中し、どの領域の説明が属人化しているか——シニア同士の会話では「あれね」で済んでいる部分が、新人に「あれって何ですか？」と問われて誰も即答できない、という場面が発生します。
ここで起きる戸惑いや沈黙は、新人の能力の問題ではなく、組織の中で文脈が残されていなかったことの証拠です。これまで見ないことにされてきた問題の表出でしかありません。
AI時代に新人オンボーディングをどう設計するか、という問いは、「若手を育てる」話であると同時に、「組織の理解の在庫をどう可視化し、どう維持するか」という話でもあります。新人の戸惑いは、チームの構造的な課題を映す鏡——そう捉え直すと、オンボーディング設計は、ただのHRプロセスではなく、組織の持続性に関わる経営課題になってきます。

まとめ

新人エンジニアの初日に「設計の意図」は必要ありません。問題が顕在化するのは、新人が少し複雑な修正に入って「なぜこの設計なのか」を求めた瞬間です。そしてそのとき、組織の中で設計の意図がどこにも体系的に残されていないことに気づきます。AIコーディングは表面的な生産性を上げる一方で、この「なぜ」の伝達経路をさらに細くしています。新人の戸惑いは個人の能力ではなく、組織の「理解の在庫」が可視化される現象なのです。

あなたのチームで最後に入った新人エンジニアは、「なぜこのシステムがこうなっているか」を、誰に、何回聞いて、理解に辿り着きましたか？

次回は、AIがコードを高速に書く世界で、ドキュメントはどこへ消えたのか——実装速度と理解速度の乖離を、正面から掘り下げます。