Scalaエンジニアの参画初月にやること｜現場で信頼される進め方

Scalaエンジニアの参画初月は、手元でビルドとテストを通し、現場の書き方の型をつかみ、小さな変更を何度か本番まで届けるところまでを目標にします。最初の1か月で求められるのは、大きな機能を作ることより、このチームのScalaを読んで、同じ流儀で直せる人だと発注側が判断できる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の進め方は参画初日から最初の1週間でやることで解説しています。この記事では、Scalaならではの初月の動き方に絞ります。

初月のゴールを3つに分ける

1か月でやることを、次の3つに分けて考えると、何を優先するかが決めやすくなります。

1週目：環境を通し、書き方の型を集める

手元でビルドとテストを通す

最初にやるのは、手元の環境でビルドとテストを通すことです。Scalaのプロジェクトは、Scalaの版、ビルドの仕組み、JDKの版の組み合わせで動きが変わります。scala-lang.orgのJDK互換性のページでは、Scala 3.8以降はJDK 17以上が必要と案内されています（2026年10月時点）。手順書と実際の設定が食い違っていることもあるため、詰まった点と解決の方法は記録して、チームの手順書に反映してもらいます。

初回のビルドやコンパイルには時間がかかることがあります。待ち時間の間に、次の項目を読み進めておくと効率よく進められます。

最初に読むもの

• コーディング規約とフォーマッタの設定：書式だけでなく、使ってよい機能、避けたい機能の決まりがあるか
• よく使われる型と共通の部品：エラーを表す型、設定の読み込み、ログの出し方など、現場で決まっている書き方
• 使っているライブラリ：エフェクトや並行処理、HTTP、データベースのライブラリと、その使い方の流儀
• 最近のプルリクエストとレビュー：どんな指摘が多いかを見ると、チームが大事にしている点が分かります

関係者と短く話す

テックリード、レビューを担う人、プロダクトの担当者と短く話し、誰が書き方の方針を決めるのか、レビューは誰が見るのか、急ぎの相談はどこでするのかを確かめます。

2週目：小さな変更を届ける

最初の変更は小さく選ぶ

2週目には、小さなバグの修正、テストの追加、ログの改善など、範囲の狭い変更を選んでプルリクエストを出します。最初の変更の目的は、成果の大きさより、ビルド・レビュー・リリースの流れを一周することです。

プルリクエストに判断の理由を書く

Scalaは同じ処理をいくつもの書き方で表せるため、なぜその書き方を選んだかを短く書いておくと、レビューのやりとりが減ります。現場の流儀と違う書き方をしたくなったときは、先にチームの書き方で書き、別の案はコメントで提案にとどめます。

3〜4週目：担当の範囲を広げ、次の計画を相談する

少し大きな作業を担う

流れを一周できたら、一つの機能の改修や、モジュールの一部の整理など、少し大きな作業を担います。作業を小さく区切ってプルリクエストを分け、進み具合が見えるようにしておくと、リモートの現場でも安心してもらえます。リモートでの進め方はScalaのリモート案件の記事で扱っています。

気づいた課題を整理して共有する

1か月コードを読むと、テストの薄い部分、古い書き方が残る部分、ビルドが遅い原因など、課題が見えてきます。直す提案は、影響の範囲と優先度を添えて一覧にし、月末の振り返りで共有します。

次の1〜2か月の作業を相談する

月末に向けて、次に任されたい作業と、自分が担える範囲を発注側と相談します。作業の範囲が契約の内容から広がりそうな場合は、その時点で確かめておきます。

案件の型によって初月の重心は変わる

既存サービスの保守・改修の案件

重心は「書き方の型をつかむこと」です。既存のコードを読み、同じ流儀で直せることを示すのが先です。障害の対応手順や監視の見方も、早めに確かめておきます。

版の移行の案件

重心は「現状の把握」です。使っているScalaとJDKの版、依存ライブラリ、マクロの使い方を洗い出します。Scala 3のコンパイラはScala 2のマクロを展開できないと移行ガイドで案内されているため、マクロに頼る部分は早めに見つけておくと、計画が狂いにくくなります。2026年9月にScala 3.9が新しい長期サポートの系列として公開されたこと（scala-lang.orgによる）も踏まえ、目標の版を発注側と確かめてから進めます。

新規開発の案件

重心は「方針を確かめること」です。ライブラリの選定やモジュールの分け方が決まりきっていないことがあるため、誰が決めるのかを確かめ、自分が提案する範囲を言葉にしておきます。

データ処理（Spark）の案件

重心は「データと実行環境の把握」です。処理の流れ、データの量、実行の時間帯、失敗したときのやり直し方を確かめます。

初月に避けたい動き

• 現場の書き方を自分の流儀に書き換える：大きな書き換えの提案は、流儀をつかんでからにします
• 抽象化を増やす：共通の部品を新しく作る前に、既存の部品がないかを確かめます
• 詰まったまま抱え込む：ビルドや環境の問題で半日以上止まったら、状況をまとめて相談します
• 作業の範囲を黙って広げる：頼まれていない整理や改修を、相談なしに大きく進めない

職種を問わない現場での振る舞い方は現場での立ち位置の記事で整理しています。

1か月の終わりに振り返ること

月末には、次の点を短くまとめて、発注側との振り返りに臨みます。

1. 届けた変更：取り込まれたプルリクエストと、その中身
2. つかんだ現場の流儀：規約、よく受けた指摘、使うライブラリの流儀
3. 見えた課題と提案：テスト、ビルド、古い書き方などの課題と、優先度の案
4. 次の1〜2か月に担いたい作業：自分が担える範囲と、必要な権限や情報

初月の振り返りを評価につなげる考え方は評価につなげる記事をご覧ください。

よくある質問

手元の環境がなかなか動きません。どこまで自分で調べればよいですか？

まずはScala・ビルドの仕組み・JDKの版が手順書と合っているかを確かめます。半日ほど調べても進まない場合は、試したことと出ているエラーをまとめてチームに相談するほうが、全体として早く進みます。解決した手順は、手順書に反映してもらうと次の人の助けになります。

現場のScalaの書き方が、自分の経験と大きく違います。どうすればよいですか？

初月は現場の書き方に合わせることを優先します。最近のプルリクエストとレビューを読み、よく使われる型やライブラリの使い方を真似るところから始めてください。違和感のある点は、流儀をつかんでから理由を添えて提案するほうが受け入れられやすくなります。

前任者からの引き継ぎがほとんどありません。何から始めればよいですか？

ビルドとテストを通したうえで、最近のプルリクエスト、障害の記録、チケットの履歴を読むと、前任者が何をしていたかがつかめます。分からない点は一覧にして、テックリードや発注側にまとめて確かめます。引き継ぎの考え方は引き継ぎの記事で整理しています。