こんにちは！
AgVentureLabの秋元です。

新人や経験の浅いエンジニアが現場に入るとき、まずは小さな改修（文言変更や軽微なバグ修正）から任せて慣れてもらう――そんな進め方が一般的ではないでしょうか。

ところが私は、配属後いきなり 3層→DDDのリファクタリング と Vue2→Vue3のマイグレーション という、プロダクト全体に関わる大規模改修を担当しました。

結果…
💡 たった数か月で、コーディングスキルの習得に加え、設計思想を含めたプロダクト全体の構成を理解することができたのです。

この記事では、「なぜ大規模改修から始める方法が有効だったのか」を私の実体験をもとに、成功事例として紹介します。

なお、本記事では便宜的に、小規模な改修から始めるオンボーディング方法を「従来型オンボーディング」、プロダクト全体の構成や設計思想から始めるオンボーディング方法を「全体から学ぶオンボーディング」と呼びます。

教育担当の方だけでなく、新人や経験の浅いエンジニアの方にも役立つ内容となれば幸いです。

📌 筆者の経歴

エンジニア９年目
銀行勘定系システム（メインフレーム）の開発に８年間従事
　→　プロジェクト管理が主な業務であり、実開発経験は２年程度
　→　YPS-COBOL、JCLによるウォーターフォール開発を経験（モダン開発は未経験）
異動となり、今年度からWebアプリの開発に従事
　→　実開発作業が主な業務となったことに加え、開発手法、開発言語も大きく変わり、実質的に一から学び直す必要がある状況

✏️ 従来型オンボーディングの目的と現場のギャップ（背景）

新人や経験の浅いエンジニアに、小規模バグ修正や文言変更などを任せて慣れてもらう「従来型オンボーディング」は、新人の負担を軽くしつつ、安全に業務へ慣れてもらうことを狙った、確立された手法です。

しかし、私達のチームでは、以下の理由から「従来型オンボーディング」を実施するのが難しい状況でした。

PO、SM、テックリードを除き、すべての開発者が総入れ替えとなった。さらに、新規参画した開発者4名は技術力に差があり、早期にスキルを平準化する必要があった
スケジュールの都合上、他の開発作業よりも先に、リファクタリングとマイグレーションを完了させる必要があった

こうした状況を踏まえ、私たちのチームでは、自然な流れで「全体から学ぶオンボーディング」を採用することになりました。

🆚 オンボーディング方法の比較：従来型 vs 全体から学ぶ

「全体から学ぶオンボーディング」とは、新人や経験の浅いエンジニアに、小規模バグ修正や文言変更などを任せて慣れてもらう「従来型オンボーディング」とは異なり、リファクタリングやマイグレーションのような全体改修を担当させるオンボーディングを指します。

「従来型オンボーディング」と「全体から学ぶオンボーディング」とを比較し、それぞれの特徴を見ていきましょう。

観点	従来型オンボーディング 🐢	全体から学ぶオンボーディング 🚀
担当タスク	小規模バグ修正や文言変更	リファクタリング・マイグレーションのような全体改修
プロダクト全体構成	理解しなくても実施可能	理解しないと実施不可
設計思想	理解しなくても実施可能	理解しないと実施不可
コーディング内容	様々な種類の改修を担当	大量の類似改修を担当
成長速度	ステップを踏んで徐々に	複数の事柄を同時並行で学んでいく

比較すると「従来型オンボーディング」は、プロダクト全体構成や設計思想を十分に理解していなくても実施できるため、初学者にとっては負担が軽く、安全に開発へ慣れていきやすいという特徴がありそうです。
一方で、全体構成や設計思想の理解に至るまでには、やや時間がかかるように思います。

「全体から学ぶオンボーディング」は、全体構成や設計思想を並行して理解しながらコーディングを進める必要があるため、即戦力化につながりやすいという特徴がありそうです。
一方で、初学者にとっては負担が大きくなりやすいかもしれません。

それぞれ違った特徴があるため、現場の状況やチーム構成によって、最適な方法を選ぶ必要があると考えられます。

今回、私たちのチームでは、現場の状況やチーム構成を踏まえ「全体から学ぶオンボーディング」を実施することとなったため、その具体的な実践内容を紹介します。

🛠 「全体から学ぶオンボーディング」の実践

それでは、私たちのチームで実施した「全体から学ぶオンボーディング」について、その具体的な実施内容（事例）を紹介します。
私たちのチームでは、開発者が総入れ替えとなったとともに、新規参画者４名のうち、私を含めた２名は開発経験が浅かったこともあり、「全体から学ぶオンボーディング」を実施する前に、別途１ヶ月程度の基礎オンボーディング期間を設けました。

チーム構成

PO、SM、テックリード（以前からチームに在籍）
開発者１：私（モダン開発経験なし）
開発者２：エンジニア２年目（開発経験なし）
開発者３：パートナー（開発経験あり）
開発者４：パートナー（開発経験あり）

1. 基礎オンボーディング（小規模アプリ開発）：１か月程度

小規模SPAで環境・規約・レビューに慣れる
開発言語・チーム用語に慣れる
AI活用に慣れる

2. 「全体から学ぶオンボーディング」による開発：２ヶ月程度

サーバ資産の3層→DDDへのリファクタリング
　→　既存の3層構造をドメイン駆動設計をベースにしたレイヤードアーキテクチャへ移行し、業務ロジックをドメイン層に集約。役割の明確化と責務分離により、保守性・拡張性を高める。
フロント資産のVue2→Vue3への移行（OptionAPI→CompositionAPIへの移行）
　→　Vue2の公式サポート終了に備え、移行を実施。フロントエンドをVue2からVue3へアップグレードし、Composition APIへの移行でコードの再利用性と可読性を向上。依存ライブラリも最新化し、パフォーマンスと将来性を確保。

私たちのチームでは「全体から学ぶオンボーディング」が上手く機能し、短い期間の中で、新規参画した開発者4名のスキルを一定程度平準化することができました。また、設計思想を含めたプロダクト全体構成への理解も進んだことで、設計にかかる議論にも参加できるレベルになりました。

📈 「全体から学ぶオンボーディング」が機能した理由

開発経験の浅いメンバーを含む私たちのチームが、リファクタリングやマイグレーションといった比較的難易度の高い大規模改修に取り組み、成果につながったのには、いくつか理由があると感じています。
以下にその要因と考えられる事項を記載します。

完全初心者を含んでいたため、別途基礎オンボーディング期間を設けた（1ヶ月程度）
　→　開発言語に対する知識等、最低限の知識を事前につけることができた
各コンポーネントの構成図や依存関係について、資料を作成した
　→　構成図とコードを見比べながら、各々が作業をできる状態になっていた
リファクタリング等の方針について、具体的なチェックリストを作成した
　→　チェックリストとコードを見比べながら、各々が作業をできる状態になっていた
AI活用を推進した
　→　有識者が忙しい時でも、いつでもAIと相談できる状態になっていた

具体的なチェックリストの例（サーバリファクタリング）

カテゴリ	チェック項目
Controller	- `@RequiredArgsConstructor` を使用 - メソッド名は `get`／`create`／`update`／`delete` ＋名詞 - バリデーションは `@Valid` に統一
Application Service	- `@RequiredArgsConstructor` を使用 - クラスレベルに `@Transactional` を付与 - メソッド名は `get`／`create`／`update`／`delete` ＋名詞
Domain Service	- `@RequiredArgsConstructor` を使用 - クラス名は業務寄り動詞で開始（Find／Update／Validate／Insert） - 公開メソッドは `exec()` 固定 - `@Transactional` は付与しない
DTO	- 一覧は `XxxListDto`、詳細は `XxxDetailDto` - 生成は静的ファクトリ `from(...)` - `implements Serializable` は付与しない
Support（Reader／Writer）	- ReaderはSELECT、WriterはINSERT／UPDATE／DELETEを担当 - 検索条件は `DbQuery` に集約 - `DbQuery` 名は「ビジネス用語＋DbQuery」（例：`FindUserDbQuery`）

特にチェックリストについては、開発経験の浅いメンバーがいる中で、リファクタリングやマイグレーションを進めるためには、必要不可欠だったと感じています。
また、有識者レビューに先立って、当該チェックリストを用いて新任者同士でレビューを実施できたことも、コーディング＋コード理解にかかるスキル平準化の役に立ったと感じています。

📝 実践して分かった課題と改善点

実際に「全体から学ぶオンボーディング」を実施してみると、メリットだけでなく運用上の課題も明らかになりました。ここでは、特に影響の大きかった課題とその改善策を紹介します。

課題1：レビュー対象のコード量が多すぎる
全体改修では1つのプルリクに含まれる変更量が膨大になり、特に経験が浅いメンバーにとってはレビュー負荷が高くなりがち。

改善策：プルリクを機能単位や画面単位に細分化し、1回のレビューで確認するコード量を減らす。
課題2：何が分からないのかが分からない状態に陥りがち
設計思想や構造理解など複数の学習が並行するため、「何が分からないのかが分からない」状態に陥ることがある。

改善策：不明点を的確に質問できるスキルが必須。特に新入社員には、質問を引き出すための声かけや1on1など、積極的なサポートを行う。

🎯 まとめ

従来型オンボーディングは安全で取り入れやすいが、設計思想や全体構成の理解には時間がかかる
全体から学ぶオンボーディングは負荷が大きいが、短期間で即戦力化を促す効果がある
今回の事例では「開発経験の浅いメンバー・短期間での平準化・大規模改修が必須」という条件が揃っていたため、後者が有効に機能した
成功の鍵は 基礎オンボーディング期間の確保・構成図やチェックリストの整備・AI活用 にあった

💬 本記事は特定条件下で有効だった成功事例の紹介となります。現場の状況やチーム構成しだいでは参考になると思いますので、「自分の現場でも実施してみたい！」と思った方は、必要に応じて基礎オンボーディング期間を設けた後に、小規模リファクタリングから「全体から学ぶオンボーディング」に挑戦してみてください！