「Gitでまた手が止まっている」「PRをどう出していいかわからないと言われた」。受託開発の現場で、Gitに苦手意識のある新人を抱えるリーダーやシニアの方なら、一度は聞いた言葉ではないでしょうか。
コマンドを一通り教えたつもりでも、いざチーム開発に入ると操作で詰まり、進捗が止まる。怖がってコミットせず、手元に大量の変更を抱えたまま黙り込む。レビュー依頼を出すタイミングがわからず、深夜に「すみません」と連絡が来る。本人もつらいですし、レビュアー側も毎回の事故対応に疲弊してしまうでしょう。
本記事では、Gitが苦手な新人を、コマンドを網羅的に教えるのではなく「個人作業 → ブランチ運用 → PR/レビュー」という3段階で巻き込んでいく指導の順序を整理します。受託開発の現場で、明日から自分のチームの育成設計に落とし込めることを目指して書いています。
なぜ「教えたのに使えない」が起きるのか
最初に整理しておきたいのは、Gitが定着しない理由は「覚える量が足りない」というわけではないことです。
新人がチーム開発でつまずくとき、原因はだいたい次の3つに集約されます。
- 操作と概念が混ざっている点です。コマンドは暗記したものの、ブランチが何を意味するかが腹落ちしていません。
- 失敗したときの戻し方を知らないこと。壊すのが怖くて、コミットも push も最低限になってしまいます。
- チーム作業の作法を知らない問題も深刻です。ブランチ命名、コミットメッセージ、PRの粒度、レビュー依頼の出し方が、なんとなくの空気で運用されています。
特に3つ目は、現場の暗黙知になっていることが多く、「教えていない」自覚すらないまま新人に丸投げしてしまっている、というのも受託開発でよくある光景です。
ここに対して、コマンド一覧やチートシートを渡しても効果は薄いでしょう。覚えるべき操作は、今そのフェーズで必要な分だけに絞り、段階的に世界を広げていく必要があります。
3段階の指導順序：個人作業 → ブランチ → PRレビュー
そこで、Gitが苦手な新人を巻き込む順序を、次の3段階で設計してみましょう。
- 個人作業フェーズ：自分一人の作業を Git で記録できる
- ブランチ運用フェーズ：他人と作業を分けて壊さず合流できる
- PR/レビューフェーズ：他人の目を通し、他人のコードを読む
この順序の意図は、「他人と関わる前に、まず自分の手元を安心して扱えるようにする」ことです。多くの現場は、この最初のステップを飛ばしていきなりブランチ運用やPRに突入させてしまい、新人の心理的ハードルを上げてしまっています。
第1段階：まずは個人作業をGitで記録できるようにする
最初のゴールは、「壊しても戻せる」感覚を新人に持ってもらうこと。
このフェーズで教えるのは、ほぼ次のものだけで十分でしょう。
git statusで今の状態を読めるgit addとgit commitで区切りを残せるgit logで過去のコミットをたどれるgit diffで何を変えたか見られるgit restoreやgit resetで「ひとつ戻す」ができる
ブランチも push も、この段階ではあえて触らせません。リモートに上げないことで、「失敗してもこの中だけで完結する」という安心領域を作るのが狙いです。
指導側の関わり方としては、課題を1つ与え、作業の節目ごとに git status と git log を一緒に眺める時間を作るのが効果的です。「今、何が staged で、何が untracked か」を口に出して説明してもらうだけで、Gitが内部でどう状態を管理しているかイメージできるようになります。
ここで起きがちな失敗は、「リーダーが代わりに git add . してしまう」ことです。本人にとっては、何が起きたのかわからないまま画面が変わる体験になり、苦手意識を強化してしまいます。手間でも、新人自身に打たせましょう。
第2段階：ブランチで他人と作業を分ける
個人作業が落ち着いてきたら、次に「他人と並行して作業する」世界に入ってもらいます。
このフェーズのゴールは、「main を壊さない」「自分の作業ブランチを持って戻ってこれる」の2点に絞りましょう。教える操作は次の範囲に絞り込みます。
git switch -cでブランチを切れるgit push -u origin <branch>でリモートに自分のブランチを置けるgit pull --rebaseまたはgit fetch+git mergeで main を取り込める- コンフリクトに遭遇したとき、慌てずに人を呼べる
ここでも欲張らないのが大事です。rebase -i やチェリーピックは、この段階ではまだ教える必要はありません。むしろ、コンフリクトが起きたときに「自分で頑張りすぎず、すぐ相談していい」というルールを明示するほうが、後の事故を確実に減らせます。
ブランチ命名やコミットメッセージのルールも、このタイミングで書面化して渡しましょう。口頭で「いい感じに」と伝えるのは、新人にとっては最も怖い指示になってしまいます。
- ブランチ命名規則（例：
feature/<チケット番号>-<短い説明>） - コミットメッセージの書き出しルール（例：プレフィックス、命令形か過去形か）
- どこまで小さくコミットするか（1機能1コミット、ではなく「動く区切りごと」など）
短くても良いので、チームのREADMEや社内Wikiに1ページ残しておくことをおすすめします。これがあるだけで、新人が「これでいいのか」と毎回悩む時間をなくすことができます。
第3段階：PRを通じてレビュー文化に慣れる
最後がPRレビューのフェーズになります。ここで初めて、新人は「自分の書いたコードを他人の目に晒す」「他人のコードを読む」体験をすることになります。
このフェーズで本当に目指すべきは、コードレビューを「指摘される場」ではなく「会話の場」として体験させることなのです。技術指導以前に、ここで心理的安全性を崩すと、その後の成長スピードが大きく落ちてしまいます。
指導側が意識したいポイントは次のとおりです。
- PRの粒度を最初に握りましょう。いきなり何百行ものPRは避け、100〜300行程度を目安にさせます。
- PRテンプレートを用意します。背景・変更点・確認手順・スクリーンショットなど、書く欄を決めておくとスムーズです。
- 最初の数本は対面（オンライン含む）で一緒にレビューしましょう。文字だけのやり取りは、新人にとって冷たく感じやすいものです。
- レビューコメントは「Must / IMO / nits」など意図も明示すると親切です。直すべきなのか、好みの提案なのかを切り分けましょう。
そして地味に効果があるのが、新人にも他人のPRをレビューさせることです。最初は「読むだけ」で構いません。他人のコードを読み、設計判断を眺める経験は、Gitの操作習熟以上に、チーム開発者としての実践的なスキルが身につきます。
よくある失敗：先回りしすぎる、放置しすぎる
3段階の設計を持っていても、運用でつまずくパターンがいくつかあります。
ひとつは、先回りしすぎる失敗。コンフリクトが起きそうになると、シニアが先に解消してしまう。新人の手元では「気づいたら main が更新されていた」という体験になり、Gitの理解は深まらないでしょう。詰まることそのものが良い教材になります。15分から30分程度のタイムボックスを決め、その間は本人に粘らせる、と握っておくとちょうどいいバランスが取れるでしょう。
もうひとつは、放置しすぎる失敗もよくあります。「Git は自分でやってみないと覚えない」と言って、最初の壁の高さを軽く見てしまうケースです。特に第1段階を飛ばしていきなりPRを出させる現場では、新人がこっそりGUIだけで操作し、何が起きているかわからないまま運用してしまいます。これは数ヶ月後、複雑なコンフリクトに遭遇した瞬間に一気に破綻します。
「先回りしない、けれど放置もしない」。この距離感を保つために、段階ごとの到達ゴールを言語化しておくのが有効です。チェックリストを1枚作るだけでも、指導側のブレを減らせます。
体系的に学んでもらうには：自学導線をセットで渡す
ここまで指導側の設計を整理してきましたが、リーダーが横についていられる時間には限界があるでしょう。新人が自分のペースで反復できる自学の場を、必ずセットで渡しましょう。
技術書を渡すのも一つの手ですが、Gitに苦手意識のある相手には、文章中心の本はハードルが高いかもしれません。手を動かしながら段階的に進められる動画講座のほうが、最初の心理的負荷は確実に下げられます。
新人本人に渡せる体系的な自学導線として、テックエイドに2つの入門講座を用意しました。どちらも新人PM・若手向けハブから確認できます。
チーム開発の流れ入門講座
Git・ブランチ・マージ・PR/レビュー・CI/CDまでを、ゲームのセーブポイントというたとえで段階的に解説するコース。本記事の3段階（個人作業 → ブランチ → PR/レビュー）と同じ流れで構成されているため、指導側がこの記事の設計を頭に入れたうえで、新人本人に学習の入口として渡すと、現場の声かけと自学が噛み合いやすくなります。
要件定義の読み方入門講座
Gitと並んで、新人が受託の現場で最初につまずきがちなのが「要件定義書が読めない」問題です。要件定義の読み方入門講座は、要件定義書の構造を家の設計図に例えて読み解く構成で、Gitの基礎が落ち着いた次のステップとして渡すとスムーズに進められます。Git運用が回り始めたあと、要件レビューに新人を入れていくフェーズで効果を発揮します。
合わせて、リーダー自身の若手育成や評価の型を整えたい方は、関連記事としてIT受託のマネージャーが最初につまずく評価面談と1on1｜新任管理職が押さえる基本の型も参考になります。
まとめ：順序を設計するだけで、定着は変わる
最後に要点を整理しましょう。
- Gitが苦手な新人をチーム開発に巻き込むには、コマンド網羅ではなく順序設計が効果的です。
- 段階は「個人作業」「ブランチ運用」「PR/レビュー」の3つです。
- 第1段階では、リモートに上げず「壊しても戻せる」感覚を作ります。
- 第2段階では、ルールを書面化し、コンフリクトで人を呼んでいい空気を作ることが大切です。
- 第3段階では、レビューを「会話」として体験させ、新人にも他人のPRを読ませましょう。
- 先回りしすぎず、放置もせず、ゴールを言語化して距離感を保ちます。
- 自学の場をセットで渡し、現場の声かけと自学を噛み合わせることが重要です。
Gitは、覚える量を絞り、順序を設計するだけで、新人の定着スピードが目に見えて変わる領域です。教える側が「全部一気に渡さない」と決めることが、最初の一歩です。
新人本人に渡せる体系的な自学導線を整えたい方は、チーム開発の流れ入門講座と要件定義の読み方入門講座を確認してみてください。本記事の3段階の設計と組み合わせて使うことを前提に作りました。