Scalaエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのScalaエンジニアがつまずきやすいのは、作業の範囲があいまいなまま始まる移行の案件、現場ごとに大きく違う書き方、版・マクロ・JDKの組み合わせの壁、案件の切れ目にできる空白です。どれも、Scalaの書き方の幅の広さと、案件の数が多くないことから起きやすくなります。

対策の基本は、つまずきの種を契約と参画初期の確認で小さくしておき、現場では判断の理由を記録して早めに共有することです。この記事では、契約・現場・技術・お金の順に、Scalaならではの場面と対策を整理します。独立の手順はScalaエンジニアがフリーランスになるにはで扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

「Scala 3への移行」の範囲が決まっていない

移行の案件では、契約書に「Scala 3移行対応」とだけ書かれ、どのモジュールまで、どの版まで、テストの整備やビルドの設定の移行を含むのかが決まっていないことがあります。進めるうちに依存ライブラリの置き換えやJDKの更新が必要だと分かり、作業が膨らみやすい案件です。

対策：参画前に、対象のモジュール、目標の版、含む作業（ビルド、テスト、依存の更新）を確かめておきます。調べて初めて分かる作業が出たら、その時点で発注側に共有し、範囲を見直してもらいます。範囲が変わるときの考え方は作業範囲が変わったときで整理しています。

準委任なのに完成の責任を求められる

フリーランスのScalaエンジニアは準委任契約で参画することが多い一方、移行の案件では「期日までに移行を完了させる」ことを成果として求められる場面があります。準委任と請負では、責任の持ち方が違います。

対策：契約の形と、何をもって業務が終わったとするかを、参画前に書面で確かめておきます。現場で勤務時間や作業の手順まで細かく指示される状態が続く場合は、偽装請負の記事を参考に、契約と実態がずれていないかを見直してください。

取引条件の書面が届く前に作業を始める

開始日が迫っていると、条件の書面を待たずに作業を始めてしまうことがあります。フリーランス法では、発注側は業務委託をしたら直ちに、業務の内容、報酬の額、支払期日などを書面や電子メールなどで示すことになっています（2026年10月時点、公正取引委員会の案内による）。

対策：業務の内容、報酬、支払期日、契約期間が書かれた書面を受け取ってから作業を始めます。

現場でのつまずき

前の現場の書き方を持ち込む

Scalaは、Javaに近い書き方から、エフェクトのライブラリで副作用を型で扱う書き方まで幅があります。前の現場で身につけた書き方をそのまま使うと、レビューで何度も差し戻されたり、チームの中で浮いたりします。

対策：参画の最初の週に、コーディング規約、よく使う型やライブラリ、エラーの表し方を集め、既存のコードを読んで「この現場の普通」をつかみます。変えたほうがよいと思う点は、理由と代わりの案を添えて提案にとどめます。

抽象化をやりすぎる

型クラスや高階の型を使えば、汎用的なコードは書けます。ただ、チームの多くが読めないほど抽象度を上げると、保守しにくいコードとして扱われ、評価を下げることがあります。

対策：新しい抽象化を入れる前に、チームの誰が読み、誰が直すのかを考えます。迷ったら、読みやすい書き方を選び、プルリクエストに判断の理由を書きます。

待ち時間に見えない遅れが積み上がる

Scalaはコンパイルに時間がかかることがあり、大きなプロジェクトではビルドやテストの待ち時間が長くなります。リモートの現場では、待っている間の進み具合が見えにくく、「進んでいない」と受け取られることがあります。

対策：作業を小さく区切ってプルリクエストを出し、進み具合と詰まっている点を短く共有します。リモートでの進め方はScalaのリモート案件の記事で扱っています。

技術でのつまずき

Scala 2のマクロが移行を止める

Scala 3のコンパイラは、Scala 2のマクロを展開できません（Scala 3移行ガイドによる）。マクロを使うライブラリに頼っている部分は、Scala 3に対応した版への置き換えや書き直しが必要になり、移行の計画が大きく狂う原因になります。

対策：移行に入る前に、依存しているライブラリとマクロの使い方を洗い出し、Scala 3に対応しているかを調べます。Scala 2.13とScala 3のモジュールは同じビルドの中で依存し合えますが、同じライブラリを2.13用と3用の両方で載せることはできないなど、組み合わせ方に条件があります。段階的に移すなら、移行ガイドで条件を確かめてから順番を決めてください。

JDKの版を見落とす

scala-lang.orgのJDK互換性のページでは、Scala 3.8以降はJDK 17以上が必要と案内されています（2026年10月時点）。3.9 LTSへの版上げを進めようとしたら、実行環境のJDKが古く、先にJDKの更新が必要だった、という場面が起きやすくなります。

対策：版上げの計画では、本番の実行環境、CI、開発者の手元のJDKの版を最初に確かめます。JDKの更新は運用の担当者の作業になることも多いため、早めに関係者へ共有します。

担当外の基盤まで抱え込む

Sparkの処理やビルドの基盤、CIの設定など、Scalaのコードの外側で起きた問題を、Scalaに詳しいという理由で一人で抱え込むことがあります。

対策：自分の作業範囲の外の問題は、調べた結果を共有したうえで、担当を決めてもらいます。求められる技術の範囲はScalaの案件で求められるスキルで整理しています。

お金でのつまずき

調査の時間が精算されない

移行や性能の調査は、作業の見通しが立ちにくく、稼働が想定を超えることがあります。精算幅の外に出た時間の扱いが決まっていないと、報酬に反映されないことがあります。

対策：契約の精算幅と、超えたときの扱いを参画前に確かめ、稼働が膨らみそうな時点で発注側に伝えます。考え方は精算幅の記事をご覧ください。

支払いが遅れる

フリーランス法では、報酬の支払期日は成果物などを受け取った日から60日以内のできる限り短い期間で定めることになっています（2026年10月時点、公正取引委員会の案内による）。期日を過ぎても支払いがないときの動き方は60日ルールの記事で扱っています。

次の案件までの空白が長くなる

Scalaの案件は数が多くないため、条件にこだわると次の案件まで時間がかかることがあります。

対策：契約終了の2〜3か月前から次の案件の相談を始め、JavaやKotlinなどJVMの案件も選択肢に入れておきます。空白期間の備えは案件が途切れたときで整理しています。

よくある質問

参画してから、聞いていた書き方と現場の書き方が違うと気づきました。どうすればよいですか？

まずは既存のコードと規約を読み、現場の書き方に合わせて書くことを優先します。そのうえで、立ち上がりに時間がかかりそうな点があれば、早めに発注側に伝えます。参画初期の動き方はScalaエンジニアの参画初月にやることで整理しています。

移行が期日までに終わらなかったら、責任を問われますか？

契約の形と、契約書に書かれた業務の内容によって変わります。準委任であれば、決められた業務を注意を払って行うことが求められるのが基本ですが、個別の判断は契約書の文言によります。気になる場合は、契約書を確かめたうえで専門家にご相談ください。

Scalaの案件が見つからないとき、ほかの言語の案件に移っても不利になりませんか？

JavaやKotlinの案件で経験を積むことは、JVMの知識が生きるため、Scalaに戻るときにも説明しやすい経験になります。どの言語で何を担ったかをスキルシートに分けて書いておけば、不利になりにくいでしょう。