Scalaエンジニアのフリーランス案件の選び方｜契約前に確かめたい7つの点

Scalaエンジニアのフリーランス案件を選ぶときは、報酬や稼働日数に加えて、役割と領域、Scalaの版と移行の予定、書き方の型、チームの体制、運用の負担、契約の形、契約期間の7点を契約前に確かめておくことが大切です。Scalaの案件は、同じ「Scalaのバックエンド開発」でも、この7点の違いで立ち上がりの重さと参画後の負担が大きく変わります。

特に見落としやすいのは、書き方の型が自分の経験と合うかと、チームの中でScalaに詳しい人が自分しかいない状態にならないかです。この記事では、Scalaの案件に固有の確認点を整理します。契約書全般の確認点は業務委託契約書のチェックポイントで解説しています。

Scalaの案件選びで差が出る理由

Scalaは同じ処理を何通りにも書ける言語で、現場ごとに書き方の決まりが大きく違います。標準ライブラリのFutureで書く現場もあれば、エフェクトを型で扱うライブラリで統一している現場もあります。Scala 2.12・2.13・3のどれで動いているかでも、使える書き方やライブラリが変わります。

一方で、案件票は「Scalaでのバックエンド開発」「関数型の経験歓迎」のように抽象的に書かれやすく、参画してから想定との違いに気づくことがあります。よくあるずれは次のようなものです。

• 新しい機能を作る案件だと思っていたら、実際は古い版のまま残ったモジュールの保守が中心だった
• 自分の経験と違う書き方の型の現場で、慣れるまでに想定以上の時間がかかった
• Scalaに詳しい人が自分だけで、レビューや相談、ビルドの不具合の調査が集中した
• 障害の当番が回ってきて、夜間の連絡に応じる必要があった

こうしたずれは、面談と条件の確認の段階で、聞き方を工夫すれば多くを防げます。案件票の読み方全般は案件情報の読み方の記事をご覧ください。

契約前に確かめたい7つの点

1. 役割と領域

まず、どの種類の仕事が中心かを確かめます。Webサービスのバックエンド、社内の共通基盤、版の移行と保守、Sparkのデータ処理のどれかで、1日の過ごし方が変わります。種類ごとの働き方はScalaの仕事内容の記事で整理しています。

あわせて、実装を担うのか、設計やレビューまで任されるのか、技術リードの役割があるのかを確かめます。面談では「参画後の最初の1か月で、最も期待されている成果は何か」を聞くと、役割の実態が見えやすくなります。

2. Scalaの版と、移行の予定

動いているScalaの版と、JDKの版、移行の予定を確かめます。scala-lang.orgでは、2026年9月にScala 3.9が新しい長期サポートの系列として公開され、前のLTSである3.3はScala 3.9.0の公開から1年間保守が続く予定です。Scala 2.13も保守を続ける方針が示されています（いずれも2026年10月時点）。

移行の予定がある案件は、移行の経験を積める機会になります。ただし、移行の計画がどこまで決まっているか、誰が判断するのかがあいまいなまま参画すると、計画づくりから任されて想定以上の負担になることがあります。移行の担い手として期待されているのか、移行が終わった後の開発に加わるのかを確かめておきましょう。

3. 書き方の型

チームの書き方の決まりを確かめます。

• 非同期の処理はFutureか、エフェクトのライブラリか
• 失敗の扱い方（Either中心か、例外も使うか）に決まりがあるか
• 書き方の決まりが文書になっているか、コードを読んで覚える形か
• 型クラスなどの抽象化をどこまで使っているか

自分の経験と違う型の現場を避ける必要はありません。考え方が分かっていれば慣れることはできます。ただ、立ち上がりにかかる期間を見込んだうえで受けることが大切です。リモートでの立ち上がりの考え方はScalaのリモート案件の記事で解説しています。

4. チームの体制と、自分の位置

• チームの人数と、そのうちScalaで長く書いてきた人の数
• 技術リードがいるか。設計の判断は誰が下すか
• レビューは誰がするか。自分がレビューする側にも回るか
• Javaや他の言語のチームと、どこで接するか

Scalaに詳しい人が少ない現場では、自分に相談が集まりやすくなります。頼られることは評価につながる一方で、本来の担当が遅れたり稼働が延びたりする原因にもなります。相談役やレビューの役割が期待されている場合は、それが業務範囲に含まれるかを確かめておきましょう。

5. 運用の負担

• 障害の当番の有無と、夜間・休日の連絡の扱い
• 反映の頻度と、反映の作業を誰が担うか
• 監視の仕組みと、自分がどこまで見るか

Sparkのデータ処理の案件では、夜間に動く処理の失敗への対応が求められることがあります。当番の有無と、当番の時間が稼働として扱われるかを確かめておかないと、責任感から無償で対応し続けることになりかねません。精算の仕組みは精算幅の記事をご覧ください。

6. 契約の形と、負う責任の範囲

フリーランスのScalaエンジニアは、多くの場合、準委任契約で参画します。準委任では、成果物の完成そのものではなく、業務を専門家として通常求められる注意を払って行うことが約束の中身になります。

確かめたいのは、契約書や発注の書面がこの考え方と合っているかです。

• 「移行を期限内に完了させる」のように、完成を約束する書き方になっていないか
• 成果物の納品が求められる場合、その範囲は何か（移行の計画書、コード、手順書など）
• 不具合に対する責任の定めがどうなっているか

移行や特定の機能の開発を請負の形で受ける場合は、完成に対する責任を負うことになります。契約の形の違いは準委任契約と請負契約の違いで解説しています。また、準委任なのに、参画先の社員から細かな作業の指示や勤務時間の管理を受ける働き方は、偽装請負の問題につながるおそれがあります。詳しくは偽装請負の記事をご覧ください。

7. 契約期間と、移行の区切り

契約の期間と、移行や大きなリリースの区切りが合っているかを確かめます。移行の山場の直前に契約の更新時期が来ると、更新されなかった場合に最も大事な局面を見届けられません。

フリーランス法では、6か月以上の業務を委託している場合に契約を解除したり更新しなかったりするときは、少なくとも30日前までに予告することが求められています（2026年10月時点、公正取引委員会の案内による）。契約期間と更新の時期は、移行の見通しとあわせて確かめておきましょう。

確かめた内容を書面と照らし合わせる

面談や事前の確認で聞いた内容は、契約の前に書面と照らし合わせます。フリーランス法では、発注する事業者は業務を委託したら直ちに、取引条件を書面または電子メールなどで明示することとされています（2026年10月時点、公正取引委員会の案内による）。明示される事項の内容はフリーランス法で明示される取引条件をご覧ください。

Scalaの案件では、特に次の点が書面に反映されているかを確かめます。

1. 業務の内容に、担う範囲（開発、レビュー、移行の計画、運用など）が書かれているか
2. 完成を約束する書き方や、移行の期限そのものの責任を負う書き方になっていないか
3. 障害の当番や稼働日以外の対応の扱いと、稼働の幅を超えたときの精算方法
4. 契約期間と更新の時期

面談で聞いておくとよい質問はScalaの面談でよく聞かれる質問と答え方の逆質問の項目でも紹介しています。一般的な逆質問の考え方は面談で聞いておくべき逆質問をご覧ください。

よくある質問

自分の経験と違う書き方の型の現場は避けたほうがよいですか？

避ける必要はありません。副作用の閉じ込め方や失敗の扱い方といった考え方が分かっていれば、慣れることはできます。ただ、立ち上がりに時間がかかる分、初月の期待値を参画先とすり合わせておくと安心です。

移行の案件と、新しい機能を作る案件のどちらを選ぶべきですか？

狙うキャリアによります。移行の経験は、版の切り替えが続くScalaの現場で次の案件の材料になりやすい経験です。新しい機能を作る案件は、設計の判断を積む機会になります。報酬の決まり方とあわせて考えたい場合はScalaの報酬の記事も参考になります。

Scalaに詳しい人が少ない現場は避けたほうがよいですか？

一概には言えません。技術の方針づくりに関われる機会にもなります。ただし、相談やレビューが集中しやすいため、その役割が業務範囲に含まれるか、稼働としてどう扱われるかを参画前に確かめてから受けることをおすすめします。Javaの案件選びとの違いはJava案件の選び方も参考になります。