Scalaエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

Scalaエンジニアのスキルシートは、Scalaの版とビルドの仕組み、使ったライブラリと「どんな書き方の現場だったか」をプロジェクトごとに書き、担当内容には自分が下した設計の判断を書くのが基本です。Scalaの現場は書き方の幅が広いため、読み手は「この人の経験は、うちのコードの書き方に近いか」を見ようとします。

案件で問われる技術の中身はScalaの案件で求められるスキル、独立までの準備はScalaエンジニアがフリーランスになるにはで扱っています。この記事では、それをシートの上でどう見せるかに絞って解説します。シート全般の基本はスキルシートの書き方の基本をご覧ください。

スキル一覧は版と使い方を添える

「Scala（5年）」とだけ書くと、Scala 2.12で保守を続けてきたのか、Scala 3で新しく作ってきたのかが分かりません。scala-lang.orgの配布ページでは、2026年10月時点で、Scala 3の系列（3.10系、LTSの3.3系・3.9系）と、Scala 2の2.13系・2.12系が並んでいます。どの系列で書いてきたかを分けて書きます。

記入例（架空）：

ライブラリは、実際のシートでは具体的な名前で書いてかまいません。名前に加えて、「何年」「どの深さで」を括弧で添えると、読み手が案件の条件と比べやすくなります。

書き方の型を一言で示す

Scalaのシートで差がつきやすいのが、現場の書き方の型を一言で示すことです。同じ「Scalaでの開発」でも、Javaに近い書き方の現場と、エフェクトを型で扱う現場では、求められる慣れがまったく違います。プロジェクトごとに、次のどれに近いかを書いておくと、読み手が判断しやすくなります。

• Javaに近い書き方：クラスと可変の状態を中心に、Scalaの便利な文法を使う
• 関数型を取り入れた書き方：不変の値とOption・Eitherを中心に、副作用を外側に寄せる
• エフェクトを型で扱う書き方：エフェクトのライブラリを土台に、副作用を型で管理する

書き方の型を書くと、自分とは違う型の案件に応募するときも、どこまでが経験済みで、どこからが新しいのかを正直に伝えられます。

Javaの経験との分け方

ScalaはJVMの上で動くため、Javaの経験を持つ人が多くいます。Javaの経験はScalaの案件でも評価されますが、シートの上で混ぜて書くと、Scalaの経験の長さが分からなくなります。

1. スキル一覧の言語の行で、ScalaとJavaの年数を分けて書く
2. プロジェクト欄の使用技術に、そのプロジェクトで主に使った言語を先に書く
3. 一つのプロジェクトでScalaとJavaを両方使った場合は、どの部分をどちらで書いたかを担当内容に書く

Javaの側の書き方はJavaエンジニアのスキルシートの記事で解説しています。

担当内容には設計の判断を書く

「API開発を担当」だけでは、どの深さで関わったかが伝わりません。担当した範囲に加えて、自分が判断したことを一言添えます。

成果を数字で書く場合は、処理時間の変化など、自分の仕事の範囲で言えるものにします。利用者の数や売上など、発注元の事業に関わる数字は書かないでください。書いてよい範囲はスキルシートと守秘義務の記事で扱っています。

移行の経験は「前と後」が分かるように書く

Scala 2から3への移行や、Scala 2.12から2.13への版上げに関わった経験は、移行を控えた現場で評価されやすい材料です。書くときは、移行の前と後の版、自分が担った範囲、判断したことが分かるようにします。

• 移行前と移行後の版（例：Scala 2.13から3へ、JDK 11から17へ）
• 調べたこと（依存ライブラリのScala 3版の有無、マクロを使うライブラリの洗い出し）
• 決めたこと（移行の順番、一時的に2.13の成果物を使い続けた部分）
• 自分の担当（全体の計画か、一部のモジュールか）

Sparkを使う処理は、Apache Sparkの公式ドキュメント（4.2.0、2026年10月時点）でScala 2.13で動くとされています。Sparkの処理だけScala 2.13に残した、といった判断も、理由とあわせて書いておくと伝わります。

記入例（架空）

次は、書き方の型を示すための例です。業種と規模はぼかしてあり、実在のプロジェクトではありません。

期間：20XX年4月〜翌年9月（1年6か月）
案件概要：EC事業者向け 注文・在庫のバックエンドの機能追加とScala 3への移行
規模・立場：開発組織は数十名規模。自分はバックエンドチーム4名のサブリーダー
書き方の型：エフェクトのライブラリを土台にした関数型の書き方
担当工程：設計、実装、テスト、リリース、運用
使用技術：Scala 2.13から3、sbt、JDK 17、PostgreSQL、コンテナ、クラウドでの運用
担当内容：注文のAPIの設計と実装。Scala 3への移行で、依存ライブラリの調査と移行の順番の案を作成。チーム内のレビューと、Scalaが初めてのメンバー向けの書き方の手引きの作成
工夫・成果：マクロを使うライブラリを先に洗い出し、Scala 3版のないものを置き換える計画を立てた。移行の作業をモジュールごとに分け、リリースを止めずに進めた

実際に書くときは、ご自身の経験に置き換えてください。

個人の開発やライブラリへの貢献の扱い

Scalaでは、公開されているライブラリへの貢献や、個人で作ったものを求められることがあります。載せる場合は次の点に気をつけます。

1. 業務で書いたコードは載せない：発注元や前職の権利と守秘義務に関わるため
2. 経歴の欄と分ける：プロジェクト欄ではなく、「個人の開発・OSSへの貢献」として別の欄に書く
3. 実務と学習を区別する：実務で使っていないライブラリは「個人の開発で使用」と書き、実務の年数に含めない

個人の開発は、新しい版やライブラリを自分で試していることの裏付けになりますが、実務の経験の代わりとして読まれることは多くありません。詳しくはポートフォリオとGitHubの記事で解説しています。

よくある質問

社内独自のScalaのライブラリしか使っていません。どう書けばよいですか？

ライブラリの名前ではなく、中身を一般的な言葉で書きます。たとえば「副作用を型で扱う社内の共通ライブラリ」「非同期の処理をまとめた社内の部品」のように、何を担うライブラリかと、自分がどの層を書いていたかを書くと、社外の読み手にも経験の中身が伝わります。

Scala 2の経験しかありません。Scala 3の案件に応募してよいですか？

応募してかまいません。Scala 2での経験の版と年数を正直に書き、Scala 3を学んでいる場合は「個人の開発で使用」などと分けて書きます。Scala 3のモジュールはScala 2.13のライブラリに依存できるなど、移行の途中にある現場もあるため、2の経験が生きる場面もあります。

Sparkの経験は、Scalaのシートのどこに書けばよいですか？

スキル一覧に「Spark（Scala API）」として年数と使い方を書き、プロジェクト欄で、どの処理をどの規模で担ったかを書きます。データの基盤全体の設計まで担った場合は、データエンジニアのスキルシートの記事も参考にしてください。