新しい会社への入社前、エンジニアが準備しておくとよいこと

新しい会社へのジョインが決まったとき、いざ初出社までに何を準備すればいいのか戸惑うことって多いですよね。慣れない言語を使ったり、ドメインがなじみのないものだったり、チームの文化を知らなかったりすると、なおさらです。ジョインが決まった時点から最初の一ヶ月まで、エンジニアが前もって用意しておくと適応がぐっとラクになることを整理してみました。

まずは自分のポジションを一文で定義します#

入社が決まったら最初にやるべきことは、「このチームで自分はどんな役割を担うのか」を自分なりに整理することです。職務記述書に書かれた肩書きではなく、実際にどんな価値を生み出すのかを一文で定義してみましょう。

たとえばバックエンドとフロントエンドをつなぐフルスタックのブリッジポジションなら、具体的な業務はこんなふうに分解できます。

こうして役割を前もって分解しておくと、入社後にどの仕事へ時間を使えばいいか迷わなくなります。面接で聞いた期待値と自分が定義した役割がずれているなら、まずそこから確認するのがよいですね。

新しい言語・スタックは「読める水準」から#

会社が使っている言語やフレームワークが不慣れだからといって、必要以上に怖がることはありません。入社初期に必要なのは、ゼロから全部作れる力ではなく、コードレビューについていける読む力だからです。

目標はこんなふうに二段階で立ててみましょう。

1. 読める水準 — チームのコードレビューに意見を出せる程度
2. 直せる水準 — 簡単なバグ修正やフィールド追加を自分でできる程度

たとえばJavaからKotlinベースのチームにジョインするなら、まずは主要な文法の違いをサッと押さえるのが効率的です。

// 1. Data Class — イミュータブルなモデルを簡潔に
data class Reserve(
    val id: Long,
    val doctorId: Long,
    val startTime: LocalDateTime
)
 
// 2. Null Safety
val name: String? = null
name?.length ?: 0  // Elvis演算子: nullなら0
name!!.length      // Non-null断言（危険なので避ける）
 
// 3. 拡張関数
fun String.toSlug() = this.lowercase().replace(" ", "-")
 
// 4. スコープ関数
reserve.let { println(it.id) }
reserve.apply { status = "CONFIRMED" }
reserve.also { log.info("Created: $it") }
 
// 5. When (switchの代替)
when (status) {
    "PENDING" -> handlePending()
    "CONFIRMED" -> handleConfirmed()
    else -> handleDefault()
}

学習の順序を時間単位で分けます#

漠然と「勉強しなきゃ」と思うより、時間と公式リソースをセットで書き出しておくほうが、実際に最後までやり切れます。

さらに一歩進んで、会社のスタックでよく使う標準的なパターンを一つ二つ、先に書き写してみるのもおすすめです。レイヤー構造が手になじむと、実際のコードベースを初めて開いたときの戸惑いがずっと減りますから。

// Controller — リクエストを受けてサービスへ委譲
@RestController
@RequestMapping("/api/reserves")
class ReserveController(
    private val reserveService: ReserveService
) {
    @GetMapping("/{id}")
    fun getReserve(@PathVariable id: Long): ResponseEntity<ReserveDto> =
        reserveService.findById(id)
            ?.let { ResponseEntity.ok(it.toDto()) }
            ?: ResponseEntity.notFound().build()
}
 
// Service — ビジネスロジックとトランザクション境界
@Service
@Transactional(readOnly = true)
class ReserveService(
    private val reserveRepository: ReserveRepository
) {
    fun findById(id: Long): Reserve? = reserveRepository.findByIdOrNull(id)
 
    @Transactional
    fun create(request: CreateReserveRequest): Reserve {
        // 検証ロジック
        return reserveRepository.save(request.toEntity())
    }
}

最初の一ヶ月のオンボーディングロードマップを描きます#

入社後に何をするかを前もって段階に分けておくと、初日から迷子になりません。週ごとのチェックリストにしておくのがおすすめです。

1週目: 環境構築とコードの把握#

• ローカル開発環境の構築（IDE、DB、Dockerなど）
• プロジェクト構造の把握（パッケージ構成、レイヤー構造）
• ドメイン用語の整理・ドキュメント化
• 既存のAPIエンドポイント一覧の把握
• DBスキーマの分析

2週目: 最初の貢献#

• 小さなバグ修正、またはAPIレスポンスへのフィールド追加
• コードレビューへの参加を開始
• チームの規約の把握（コードスタイル、コミットメッセージ、PRルール）

一ヶ月後の目標#

• 小さな機能を独立して追加できる
• ドメインロジックの設計に参加する
• 他チームとのインターフェース（APIスペックなど）の調整を主導する

最初の貢献は小さいほどよいです。大それた機能より、フィールドを一つ追加するPRを先に出してみると、チームのレビュー文化やデプロイの流れを自然に身につけられますから。

持っている強みを早めに証明します#

新しい環境では萎縮しがちですが、入社前に積み上げてきた強みがきっとあるはずです。それを序盤で自然に見せれば、信頼を素早く得られます。

特にドメインを前もって分析しておいた内容は強力な武器です。面接や事前調査の過程でつかんだ既存システムの限界や改善アイデアなどを整理しておくと、ジョイン直後に自然な形で共有できます。

「既存システムを見てみたんですが、この検証クエリは3段ジョインで複雑なんですよね。テーブルを直接つなげば単純化できそうです。」

こうした具体的な観察を持って入っていくと、ただ言われた仕事を受ける人ではなく、一緒に問題を解く同僚として早く定着できます。ただし入社初日からすべてを変えようとするより、まずは背景を十分に聞いてから提案する順序がよいですね。

入社前に確認しておくとよいこと#

契約にサインする前や初出社の前に、次の項目を確認しておくと、入社後に慌てることが減ります。

• コードレビュー文化があるか
• オンボーディング期間に期待されること
• フロントエンドのバージョンと状態管理の方式（Redux? Zustand? React Query?）
• テストカバレッジの基準があるか
• リモートワークが可能か
• コミュニケーションツール（Slack、Teamsなど）

こうした質問は、面接の終盤や条件交渉の段階で聞くのにちょうどよいです。会社の働き方を前もって知るほど、初日の適応コストが下がりますから。

おわりに#

入社準備のカギは、「初出社の前に適応コストをできるだけ前払いしておくこと」です。自分の役割を一文で定義し、新しいスタックを読める水準まで引き上げ、オンボーディングのロードマップと強みのカードを手に持って入っていけば、最初の一ヶ月がぐっと軽くなります。完璧に準備しようと先延ばしにするより、いま自分にできる小さな準備から一つずつチェックしてみてください。

A man who doesn't trust himself can never really trust anyone else.

— Cardinal Retz