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

サーバーサイドKotlinのスキルシートは、Kotlinで書いた期間をJavaやほかの言語の期間と分けて示し、プロジェクトごとにフレームワークと版、コルーチンを使った箇所、Javaとの関わり方を書くのが基本です。「Kotlin 3年」とだけ書くより、何をKotlinで作り、どんな判断をしたかが読み取れる形にすると、面談の質問が具体的になります。

この記事では、サーバーサイドKotlinならではの書き方と、架空の記入例を紹介します。スキルシート全体の型はスキルシートの基本、Androidアプリの書き方はAndroidのスキルシートの記事をご覧ください。

Kotlinの期間とバックエンド全体の期間を分ける

KotlinはJavaと同じ現場で使われることが多く、期間を混ぜて書くと、どこまでがKotlinの経験か読み手に伝わりません。スキル欄では次のように分けて書きます。

Androidでの経験がある場合は、「Kotlin（Android）」と「Kotlin（サーバーサイド）」を別の行にすると、サーバーサイドの案件での判断材料になります。

プロジェクト欄に書きたい5つの項目

1. KotlinとJavaの比率

プロジェクト全体のうち、自分がKotlinで書いた部分と、Javaで保守した部分の割合を書きます。新規のサービスを最初からKotlinで作ったのか、Javaのコードに少しずつKotlinを足したのかで、伝わる経験が大きく違います。

2. フレームワークとKotlinの版

Spring BootかKtorか、そのほかのフレームワークかを書き、分かる範囲でKotlinとフレームワークの版も添えます。Kotlinの公式ドキュメントによると、2.0.0（2024年5月21日リリース）で新しいK2コンパイラが標準になり、2.4.0では古いK1コンパイラが使えなくなりました（2026年10月時点）。参画中に版を上げた場合は、「Kotlin 1.9系から2.x系へ更新」のように書くと、更新の作業を担ったことが伝わります。

3. コルーチンを使った箇所

「コルーチンを使用」とだけ書くと、どの程度使いこなしたかが分かりません。外部APIの並列呼び出し、メッセージの非同期処理、Flowでのストリーム処理など、使った場面を具体的に書きます。タイムアウトやキャンセルで起きた問題を直した経験があれば、1行添えると面談で深い話につながります。

4. Javaとの関わり方

Javaからの移行に関わった場合は、どの範囲を、どの順で移したかを書きます。「新しいモジュールからKotlinで作成し、共通ライブラリはJavaのまま残した」のように、移さなかった判断も書くと、設計の考え方が伝わります。

移行の経験は、結果だけでなく進め方も短く添えると評価の材料になります。たとえば、混在する期間にビルドやテストをどう保ったか、ほかのメンバーにKotlinの書き方をどう広めたか、といった点です。チームの中で自分が担った役割（計画を立てた、規約を作った、レビューで支えた）を分けて書くと、リードの経験として読み取ってもらいやすくなります。

5. 周辺の技術と運用

データベース、メッセージング、クラウド、CI/CD、監視など、サービスを動かすために触れた技術を書きます。Kotlinの記述と混ぜず、別の行にまとめると読みやすくなります。運用まで担った場合は、障害の当番や問い合わせへの対応、監視の設定など、リリース後に何をしていたかも1行書いておくと、作って終わりではない経験として伝わります。

プロジェクト欄の記入例

次の2つは、書き方の型を示すための架空の記入例です。実在の案件・会社・数値ではありません。ご自身の経験に置き換えてお使いください。

架空の記入例1：新規サービスのバックエンド

期間：○年○月〜○年○月（1年半程度）
案件概要：Webサービス事業者向け 予約サービスのバックエンドAPIの新規開発
規模・立場：バックエンド5名程度のうちの1名。後半はレビュー担当を兼任
担当工程：基本設計、詳細設計、開発、テスト、リリース後の運用
言語・FW：Kotlin（2.x系）、Spring Boot、Gradle（Kotlin DSL）
Kotlinで書いたもの：予約・決済のAPI、外部の在庫APIを並列に呼ぶ処理（コルーチン）
周辺技術：PostgreSQL、クラウドのコンテナ実行環境、CI/CD
工夫・成果：予約の状態をsealedクラスで表し、状態の追加時に漏れがあればコンパイルで気づける形にした。外部APIの呼び出しにタイムアウトを設け、遅延時の応答を改善した

架空の記入例2：Javaからの段階的な移行

期間：○年○月〜○年○月（1年程度）
案件概要：社内向け業務システムのバックエンド改修とKotlinの導入
規模・立場：開発10名程度。Kotlin導入の担当として規約づくりから参加
担当工程：移行の計画、開発、テスト、メンバーへの説明
言語・FW：Java、Kotlin、Spring Boot（担当範囲では両言語が混在）
担当内容：新しい機能とテストからKotlinで書く方針を提案。Javaから呼ばれるKotlinのAPIでnullの扱いを統一した
工夫・成果：コーディング規約と静的解析の設定を整え、ほかのメンバーがKotlinで書き始めやすくした

1つ目は設計と非同期処理、2つ目は移行の判断とチームへの貢献が読み取れる形にしています。数値を出せない場合は、例のように「何をどう変えたか」を言葉で書くだけでも十分伝わります。社名やサービス名の伏せ方はスキルシートでの守秘義務の扱いをご覧ください。

提出前に見直したい3つの点

書き終えたシートは、提出の前に次の3点を見直します。

1. 言葉の粒度がそろっているか：あるプロジェクトでは「API開発」、別のプロジェクトでは細かい機能名、と粒度がばらつくと読みにくくなります。工程と担当範囲の書き方をそろえます
2. 新しい順に並んでいるか：直近の案件ほど評価の材料になります。Kotlinの経験が新しい案件にある場合は、それが最初に目に入る並びにします
3. 案件の条件と対応しているか：応募する案件がSpring Bootの新規開発なら設計と非同期処理を、移行の案件なら移行の判断を、それぞれ前に出します

更新の考え方はスキルシートの更新の記事でも扱っています。

個人の成果物やOSSの扱い

Kotlinで作ったライブラリやツールを公開している場合は、補足として最後の方に書きます。何を解決するものか、テストやCIが整っているか、ほかの人に使われているかを添えると判断材料になります。公開の仕方はGitHubをポートフォリオに使う記事で扱っています。業務委託の案件では実務の経験が中心に見られるため、個人の成果物は実務を補う位置づけにしておきましょう。

よくある質問

Kotlinの実務が半年ほどです。Javaの経験と混ぜて書いたほうがよいですか？

混ぜずに分けて書くことをおすすめします。Kotlinの期間が短くても、Javaの経験が長ければ、それぞれを正しく示すことで、JVMでの開発の厚みと、Kotlinへの移りやすさの両方が伝わります。

AndroidのKotlin経験は、サーバーサイドのシートにも書いてよいですか？

書いてかまいません。ただし、サーバーサイドの経験とは別の行にし、言語やコルーチンなど共通する部分を中心に書くと、読み手が判断しやすくなります。

使ったKotlinの版を覚えていない場合はどうすればよいですか？

正確に分からない場合は、無理に書かず「Kotlin 2.x系」のように分かる範囲で書きます。版を上げる作業を担った場合は、その事実を書いておくと、更新の経験として伝わります。