Scalaエンジニアのフリーランス案件で求められるスキルと経験

Scalaのフリーランス案件では、型を使って失敗やデータの形を表す書き方、エフェクトや並行処理のライブラリの扱い、sbtとJVMの知識、Scala 2と3の違いの理解が中心に見られます。Scalaは同じ処理をいくつもの書き方で表せる言語です。そのため案件では、機能を知っているかより、チームの書き方に合わせて、読みやすいコードを選べるかで差がつきます。

独立までの準備はScalaエンジニアがフリーランスになるにはで扱っています。この記事では、案件で問われるスキルを分野ごとに分け、経験の段階ごとに求められる深さを整理します。

Scalaの案件で問われるスキルの全体像

案件の領域によって、どの行が重く見られるかが変わります。Webサービスのバックエンドではエフェクトと運用、共通ライブラリの整備では型と互換性、大量データの処理ではSparkとJVMが中心になりやすい傾向があります。

言語の基本：失敗とデータの形を型で表す

Scalaの案件のコードレビューでよく見られるのは、失敗の扱い方です。

• 値がないかもしれない場面でnullを使わず、Optionで表しているか
• 失敗の理由を呼び出し側に伝えたい場面で、例外ではなくEitherなどで表しているか
• 業務のデータを、case classとsealedな型の組み合わせで表し、パターンマッチで漏れなく扱っているか

ここが身についていると、Scalaの現場の「普通の書き方」になじんでいると受け取られやすくなります。Javaの経験が長い人ほど、例外とnullに頼る書き方が残っていないかを自分で確かめておきましょう。

型と抽象化：やりすぎない判断

Scalaは型の表現力が高く、型クラスやimplicit（Scala 3ではgiven・using）を使うと、共通の処理を一か所にまとめられます。一方で、抽象化を重ねすぎると、書いた本人以外が読めないコードになります。

案件で評価されやすいのは、高度な型を使えることより、どこまで抽象化するかをチームの習熟に合わせて決められることです。面談では「抽象化をやめた判断」を聞かれることもあります。

エフェクトと並行処理：副作用をどこに閉じ込めるか

Webサービスのバックエンドでは、非同期の処理を標準ライブラリのFutureで書く現場と、エフェクトを型で扱うライブラリを使う現場があります。どちらの現場でも見られるのは次の点です。

1. データベースや外部APIの呼び出しなど、副作用のある処理をどこに集めているか
2. 処理を途中で止めるとき、資源（接続やファイル）を漏れなく解放できるか
3. 並行に動かす処理の数を抑え、相手のサービスに負荷をかけすぎない書き方ができるか
4. エラーがどこで起き、どこで扱われるかを追えるか

使ったライブラリの名前より、こうした判断を自分の言葉で説明できるかが評価につながります。

ビルドとJVM：本番で問題を追えるか

sbtと依存の管理

Scalaのビルドではsbtが広く使われています。ライブラリはScalaの版ごとに別の成果物として公開されるため、版が合わないと依存の解決でつまずきます。依存の衝突を自分で調べて直せる人は、チームで頼りにされます。

JVMの知識

ScalaはJVMの上で動くため、性能の問題はScalaのコードだけでなく、メモリやスレッドの設定に原因があることもあります。docs.scala-lang.orgのJDK互換性のページでは、2026年10月時点で、JDK 17・21・25がコンパイルと実行のどちらにも適した選択肢とされ、Scala 3.8以降は必要なJDKの最低版が17になったと説明されています。参画先のJDKとScalaの版の組み合わせを確かめ、手元の環境をそろえられることも基本のスキルです。

Scala 2と3の違いを説明できるか

Scala 3への移行を控えた現場や、Scala 2と3が混在する現場では、違いを理解していることが求められます。公式の移行ガイドでは、次のような点が示されています（2026年10月時点）。

• Scala 3のモジュールは、Scala 2.13でコンパイルされたライブラリに依存できる
• Scala 3のコンパイラは、Scala 2のマクロを展開できない。マクロを使うライブラリは、Scala 3版を使うか、マクロを書き直す必要がある
• Scala 2.13からScala 3のライブラリを読む仕組み（TASTyの読み込み）は、Scala 3.7までのものに限られ、3.8以降でコンパイルされたものは読めない

移行の作業では、まず依存ライブラリのうちマクロを使うものを洗い出し、Scala 3版の有無を確かめることになります。この手順を説明できるだけでも、移行案件の面談で話せる内容が増えます。

データ処理：SparkのScala API

大量データの処理の案件では、SparkをScalaから使うことがあります。Apache Sparkの公式ドキュメント（4.2.0、2026年10月時点）では、SparkはScala 2.13で動き、Scala APIを使うアプリケーションはSparkと同じScalaの版を使う必要があると説明されています。Spark 4.0.0以降はScala 2.13です。

そのため、Sparkの案件では、Scala 3ではなくScala 2.13の書き方が求められることがあります。Scalaの開発者として見られるのは、処理を正しく速く書く部分（データの偏りへの対処、シャッフルを減らす書き方、メモリの使い方）です。データの基盤全体の設計や品質管理は、データエンジニアのスキルの記事で扱っています。

経験の段階ごとに求められる深さ

実装中心の段階では、新しいライブラリを増やすより、基本の書き方の質を上げるほうが評価につながります。設計を任される段階では、「なぜこの分け方にしたか」を文書に残す習慣が、次の案件で話せる経験になります。

資格よりも見られる材料

Scalaには、案件で広く条件にされる公的な資格は見当たりません。面談では、資格より次のような材料が見られます。

1. 本番で動かしたScalaのコードで、自分が担った設計と判断
2. 移行や性能の問題を解いた経験
3. 公開している個人の開発やライブラリへの貢献（補う材料として）

Javaの経験を合わせて示すときは、Javaの案件で求められるスキルも参考になります。

よくある質問

エフェクトのライブラリを使ったことがないと、Scalaの案件は難しいですか？

標準ライブラリのFutureを中心に書いている現場もあり、エフェクトのライブラリの経験がなくても参画できる案件はあります。ただ、ライブラリを使う現場も多いため、副作用をどこに閉じ込めるかという考え方を押さえ、小さなものを一つ書いてみておくと、選べる案件が広がります。

Javaの経験はScalaの案件で評価されますか？

評価されることが多くあります。JVMの性能調査やJavaのライブラリとの組み合わせなど、Javaの経験がそのまま生きる場面があるためです。一方で、Scalaの書き方に沿って書けるかも見られるため、OptionやEitherで失敗を表すなど、Scalaらしい書き方を身につけておきましょう。

Scala 3の経験がないと応募できませんか？

Scala 2.13で動いているシステムや、Scala 2.13を使うSparkの案件もあり、Scala 3の経験がなくても応募できる案件はあります。ただ、新しく作る案件や移行を控えた案件ではScala 3の理解が求められるため、手元でScala 3に触れ、2との違いを説明できるようにしておくことをおすすめします。