Kotlinエンジニアのフリーランス案件の仕事内容｜案件の種類と働き方

サーバーサイドKotlinのフリーランス案件の仕事は、APIやサービスを設計して書き、テストを通し、本番での動きを確かめることの繰り返しです。ただ、まっさらな新規開発か、Javaの既存資産を抱えた移行か、運用中のサービスの改善かで、1日の時間の使い方も、話す相手も、手元に残る成果物も変わります。

この記事では、Kotlinの案件を4つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。報酬の決まり方はKotlinエンジニアの報酬の記事、求められるスキルはKotlinの案件で求められるスキルで扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。Androidアプリの仕事はAndroidエンジニアの仕事内容をご覧ください。

仕事の中身は「既存資産の量」と「サービスの段階」で決まる

Kotlinの公式ドキュメントは、KotlinがJavaベースの技術スタックと完全な互換を保ち、テストや新しいコードからKotlinで書き始めて、ほかの部分はJavaのまま残せると説明しています（2026年10月時点）。この性質から、Kotlinの案件は「どれだけJavaの資産と付き合うか」と「サービスがどの段階にあるか」で中身が分かれます。

以下はそれぞれの典型的な例です。時間の配分は現場ごとに違うため、目安として読んでください。

新規サービスのバックエンド開発

1日の流れ（例）

朝は、チャットとチケットを見てその日の作業を決め、短い朝会で進み具合と困りごとを共有します。午前はSpring BootやKtorでAPIを実装し、単体テストを書きます。午後はフロントエンドやモバイルの担当者とAPIの形を詰めたり、ほかのメンバーのプルリクエストをレビューしたりします。夕方は検証環境に配置して動きを確かめ、翌日の作業を整理します。

新規開発では、決まった設計に沿って書くだけでなく、エンドポイントの形やエラーの返し方、データの型を自分で決める場面が多くなります。

1か月の流れ（例）

• 月初：その月に出す機能を決める計画の会議に出て、自分の担当と見積もりを出す
• 毎週：設計のレビュー、APIの仕様のすり合わせ、テスト環境での確認
• 月の半ば：リリースに向けた結合テスト、性能の確認
• 月末：リリースと振り返り。次に直したい技術的な課題を挙げる

成果物

APIの実装とテスト、APIの仕様書（OpenAPIなど）、テーブルの設計、設計メモ、Gradleの設定、CIの設定などです。立ち上げ期に参画すると、コーディング規約やプロジェクトのひな形づくりも任されることがあります。

Javaからの段階的な移行

1日の流れ（例）

午前は既存のJavaのコードを読み、移す対象のモジュールの依存関係を洗い出します。分からない動きは、既存システムの担当者に聞いて確かめます。午後は、テストを先に整えてからKotlinに書き換え、Javaのコードから呼んでも使いやすい形で公開できているかを確かめます。ビルドが遅くなっていないか、混在した状態でテストがすべて通るかも毎日見ます。

移行の案件では、書く時間より読む時間と確かめる時間が長くなりやすいのが特徴です。

1か月の流れ（例）

• 月初：移す順番の計画を見直し、その月に移すモジュールを決める
• 毎週：テックリードとの進め方の確認、既存システムの担当者への聞き取り
• 月の半ば：移したモジュールのリリースと、動きの比較
• 月末：移した範囲と残りを整理し、規約や手順の文書を更新する

成果物

移行の計画、移したコードとテスト、Javaとの境界での注意点をまとめた文書、規約の追記、ビルド設定の変更などです。移行の案件で残した文書は、後から入るメンバーが同じ作業を進めるときの手引きになります。

運用中のサービスの改善・運用

1日の流れ（例）

朝は監視の通知とエラーのログを見て、前日からの異常がないかを確かめます。問い合わせや不具合のチケットがあれば、再現と原因の調査から入ります。日中は機能の追加や改善の実装を進め、合間に性能の指標を見て遅くなっている処理を調べます。コルーチンを使ったサービスでは、ブロッキングする処理が紛れ込んでいないか、キャンセルや例外が意図どおりに伝わっているかを追う場面もあります。

1か月の流れ（例）

• 月初：前月の障害や問い合わせを振り返り、直す優先順位を決める
• 毎週：機能追加のリリース、依存ライブラリの更新、性能の確認
• 月の半ば：KotlinやSpring Bootの版の更新の計画と検証
• 月末：障害の報告書や改善の結果をまとめ、次の月の計画に反映する

成果物

改善した機能、障害の報告書、調査の記録、版の更新の手順、監視の設定の見直しなどです。運用の案件では、障害のときの連絡の当番が仕事に含まれることがあります。働く場所の条件はKotlinエンジニアのリモート案件の記事で扱っています。

クライアントと共有するロジックの開発

Kotlin Multiplatformを使い、サーバーとモバイルのクライアントでデータの型や入力の検証を共有する案件です。案件の数は多くありませんが、サーバー側の知識を持つKotlinエンジニアが関わる余地があります。

1日・1か月の流れ（例）

日々の仕事は、共有モジュールの実装とテスト、iOS・Androidのチームとの仕様のすり合わせが中心です。片方の変更がもう片方に直接影響するため、変更の前に関係するチームへ知らせ、合意してから進める手順が日々の仕事に組み込まれます。1か月の単位では、クライアントのアプリのリリース時期に合わせて、共有モジュールの版を出す計画を立てます。

成果物

共有モジュールの実装とテスト、変更の手順書、APIとデータの型の定義、各クライアントへの組み込みの手引きなどです。

どの案件にも共通する仕事

種類が違っても、次の仕事はほぼすべてのKotlinの案件にあります。

1. レビュー：自分のコードの説明と、ほかのメンバーのコードへの指摘
2. テスト：単体テストで業務のロジックを、結合テストでデータベースや外部APIとのつなぎを確かめる
3. 版の更新：Kotlin、JDK、フレームワーク、ライブラリの版を上げ、動きを確かめる
4. 文書化：設計の意図、とくに非同期の処理の考え方を残す

フリーランスならではの仕事として、自分の稼働の記録と報告もあります。月の稼働時間に幅を決めて精算する契約が多いため、日々の作業時間をつけておく必要があります。精算の仕組みは精算幅の記事をご覧ください。

関わる相手と、その相手に出すもの

よくある質問

Kotlinの案件では、Javaのコードも書くことになりますか？

多くの現場で、Javaのコードを読む場面はあります。移行の案件や混在した現場では、Javaの修正を頼まれることもあります。どのくらいの比率になるかは案件によるため、参画前に確かめておくと、思っていた仕事とのずれを防げます。

インフラや運用の作業まで任されることはありますか？

小さなチームや運用中のサービスの案件では、配置の設定や監視、障害の調査まで担うことがあります。どこまでが自分の範囲かは、契約の業務範囲と照らして参画前に確かめましょう。

参画して最初の1か月は何をすることが多いですか？

手元でビルドとテストを通す環境づくり、既存のコードと設計の読み込み、小さな修正の担当から始めるのが一般的です。初月の進め方はKotlinエンジニアの参画初月にやることで解説します。