はじめに
転職や異動のたびに「立ち上がりが早いですね」と言われることが多いので、自分がやっていることを言語化してみました。
はじめに
オンボーディングの速さは、エンジニアとしての評価に直結します。早く戦力になれれば、チームからの信頼も得やすく、その後の仕事がスムーズになります。
私が意識しているのは 「情報」「人」「組織」「自分」 の4つの軸です。順番に解説していきます。
1. 情報収集の仕組みを作る
ドキュメントは全部AIに食わせる
自分が困ったときに聞ける仕組みを最初に作ります。私は専用のGitHubリポジトリを作成し、社内ドキュメントをまとめてClaude（またはCursor）から参照できるようにしています。
onboarding-docs/
├── architecture/ # システム設計書
├── api-specs/ # API仕様書
├── runbooks/ # 運用手順書
└── meeting-notes/ # 議事録
「あのドキュメントどこだっけ？」と探す時間がゼロになります。AIに聞けば一発です。
GoogleドライブやSlackの過去ログは全部読む
地味ですが効果絶大です。特にSlackの過去ログには、ドキュメント化されていない暗黙知が大量に眠っています。
- なぜこの設計になったのか
- 過去にどんな障害があったのか
- 誰がどの領域に詳しいのか
これらの情報は、公式ドキュメントには載っていません。
現行システムの全体像を構造で把握する
最初の1週間で、システム全体の構造を頭に入れます。細部は後回しでOK。
自分で図を描いてみて、先輩に「この理解で合ってますか？」と確認するのがおすすめです。
2. 人との関係を築く
質問する（されないと相手も困る）
質問しない新人は、周りから見ると「何を考えているかわからない」存在です。質問することで：
- 自分の理解度を示せる
- 相手に「教える機会」を提供できる
- コミュニケーションのきっかけになる
AIやGoogleが知らない社内知識とかは人に聞かないとINPUTできません
「誰に聞けばいいか」のマップを作る
最初の2週間で、以下のようなマップを頭の中に作ります。
| 分野 | キーパーソン |
|---|---|
| インフラ・デプロイ | Aさん |
| ドメイン知識（業務ロジック） | Bさん |
| フロントエンド | Cさん |
| 過去の経緯・歴史 | Dさん |
これがあると、問題解決のスピードが段違いです。
どんなベテランでも最初の1ヶ月は助けてもらう
変なプライドは捨てましょう。経験10年のベテランでも、新しい環境では新人です。
「助けてもらう」ことを前提に動くと、周囲も協力しやすくなります。
3. 組織を理解する
業務の流れ（仕事の進め方）を把握する
技術だけでなく、仕事の進め方も理解します。
- PRのレビューフローはどうなっているか
- デプロイの頻度とタイミング
- 会議体の種類と目的
- 誰が何を承認するのか
これを把握していないと、技術的に正しくても「進め方が違う」と指摘されます。
マネージャーの見ている世界を見る
マネージャーが何を気にしているかを理解すると、自分の動き方が変わります。
- 今期のチーム目標は何か
- どんな課題を抱えているか
- 上層部から何を求められているか
1on1があれば、これらを直接聞いてみるのも手です。
組織が変えたいと思っている課題を把握する
「ここが困っている」「ここを改善したい」というポイントを早めに把握しておくと、自分が貢献できる場所が見えてきます。
4. 自分の立ち位置を見つける
社内で足りていない部分を探る
チームをよく観察すると、「誰もやりたがらない仕事」や「手が回っていない領域」が見えてきます。
どの分野で活躍できそうか見極める
自分の強みと、チームのニーズが重なる部分を探します。
最初の1ヶ月は観察期間。2ヶ月目から「ここなら自分が貢献できそう」という領域で成果を出しにいきます。
おわりに
オンボーディングは「受け身で教わる期間」ではなく、 「能動的に情報を取りにいく期間」 です。
最初の1ヶ月の動き方で、その後の半年〜1年の働きやすさが決まります。ぜひ参考にしてみてください。