Kotlinエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのKotlinエンジニアがつまずきやすいのは、Kotlinの案件のつもりで入ったらJavaの保守が中心だったという食い違い、現場ごとのKotlinの書き方の揺れ、Javaとの境界でのnullやコルーチンの扱い、版の更新や障害対応で稼働が膨らむことです。どれも、KotlinがJavaと混ぜて使える言語であることと、現場ごとに使い方の幅が大きいことから起きます。

対策の基本は、つまずきの種を契約と参画初期の確認で小さくしておき、現場では記録と早めの共有で守ることです。この記事では、契約・現場・技術・お金の順に、Kotlinエンジニアならではの場面と対策を整理します。独立前の準備はKotlinエンジニアがフリーランスになるにはで扱っているので、ここでは「参画してから実際に起きやすい場面」に絞ります。

契約でのつまずき

「Kotlinの案件」のはずが、Javaの作業が中心になる

Kotlinの公式ドキュメントは、大きなコードベースをJavaから少しずつKotlinへ移せることを特長に挙げています（2026年10月時点）。そのため、案件の説明では「Kotlinを使う現場」とされていても、実際にはJavaのコードが大半で、Kotlinは新しいモジュールの一部だけ、ということがあります。逆に、Kotlinでの新規開発のつもりで入ったら、Javaからの書き換えの作業が中心だったという食い違いも起きます。

対策：面談や契約の前に、KotlinとJavaのおおよその比率、自分が触るモジュール、新規の実装か移行の作業かを確かめます。フリーランス法では、発注側は業務の内容、報酬の額、支払期日などを書面やメールで明示することになっています（2026年10月時点、公正取引委員会の案内による）。明示される事項はフリーランス法の取引条件の記事で整理しています。書面の業務の内容と、聞いた話が合っているかを照らし合わせてください。

担う範囲が実装から運用まで広がっていく

少人数の自社サービスでは、APIの実装で入ったのに、気づけばデプロイの仕組みの手入れや障害の一次対応まで任されていた、ということがあります。範囲が広がること自体は経験になりますが、報酬や稼働の前提と合わなくなることがあります。

対策：範囲の外の作業を頼まれたら、引き受ける前に窓口と範囲の扱いを話します。考え方は業務範囲が変わったときの記事をご覧ください。

指示の受け方が社員と変わらなくなる

社員のチームに深く入って開発していると、勤務時間や作業の手順まで細かく指示されるようになることがあります。準委任の契約と実態がずれてくる状態です。考え方は偽装請負の記事で解説しています。

現場でのつまずき

現場ごとにKotlinの書き方が違い、レビューで差し戻される

Kotlinは同じ処理を何通りにも書ける言語です。スコープ関数をどこまで使うか、例外を投げるか結果の型で返すか、拡張関数をどこに置くかといった決まりは、現場によって違います。前の現場で当たり前だった書き方が、次の現場では差し戻されることがあります。

対策：参画した最初の週に、コーディング規約、静的解析の設定、最近マージされたプルリクエストをいくつか読み、その現場の書き方をつかみます。決まりが文書になっていなければ、レビューで指摘された点を自分で書き留めておくと、同じ指摘を繰り返さずに済みます。

Javaの経験者とKotlinに慣れた人の間で板挟みになる

移行の途中の現場では、Javaに慣れたメンバーと、Kotlinらしく書きたいメンバーの考え方がぶつかることがあります。外部のエンジニアとして、どちらかの肩を持つ形になると、チームの中で動きにくくなります。

対策：自分の意見は根拠をつけて出しつつ、決めるのは現場のリードだという線を守ります。決まった内容はチャットや議事録に残しておくと、後から蒸し返されにくくなります。

生成AIや外部ツールの決まりを知らずに使ってしまう

コードの補完やレビューに生成AIを使うことが広がっていますが、使ってよいツール、コードを貼り付けてよい範囲は現場ごとに違います。決まりを知らずに使うと、契約や秘密保持の違反になることがあります。

対策：参画の初期に、使ってよいツールと、社外のサービスに出してよい情報の範囲を確かめます。考え方は生成AIの利用と契約の記事で整理しています。

技術でのつまずき

Javaとの境界でnullの扱いを誤る

KotlinからJavaのコードを呼ぶと、戻り値がnullになりうるかをKotlinの型が判断できない場面があります。Kotlinのコードだけを見て「nullは来ない」と思い込むと、本番で例外が起きることがあります。移行の途中の現場ほど、この境界が多くなります。

対策：Javaのライブラリや既存コードを呼ぶ箇所では、nullになりうるかを確かめ、境界で型をはっきりさせます。気になる箇所はテストで押さえておくと、レビューでも説明しやすくなります。

コルーチンの使い方が現場の構成と合わない

コルーチンは便利ですが、Spring MVCのようなブロッキングの構成と、WebFluxやKtorのようなノンブロッキングの構成では、使い方の注意点が違います。ブロッキングの処理をそのままコルーチンの中で呼ぶ、キャンセルや例外の伝わり方を考えずにスコープを作る、といった書き方は、負荷がかかったときに問題になります。

対策：参画した現場が、どの構成で、コルーチンをどこまで使っているかを最初につかみます。自分の経験が浅い使い方を求められたら、早めにそう伝え、レビューを厚めにしてもらうほうが安全です。

版の違いで手戻りが出る

Spring Bootのリファレンスでは、KotlinにはKotlin 2.2系以上が必要とされています（2026年10月時点）。Kotlin・Spring Boot・JDK・Gradleの版の組み合わせは現場ごとに違い、前の現場で使えた書き方やプラグインの設定がそのまま使えないことがあります。

対策：参画の初日に、Kotlin・JDK・Spring BootまたはKtor・Gradleの版を書き出しておきます。版の更新を任された場合は、一度に上げず、段階を分けて計画すると手戻りを小さくできます。

お金でのつまずき

障害対応や版の更新で稼働が精算幅を超える

障害の対応や、版の更新でビルドが通らなくなった日などは、稼働が延びやすくなります。精算幅を超えた分の扱いを決めていないと、報酬に反映されないまま働くことになりかねません。

対策：稼働を日々記録し、精算幅を超えそうな段階で窓口に伝えます。精算の仕組みは精算幅の記事、待機の扱いは待機の報酬の記事で解説しています。

移行の区切りで契約が終わる

Javaからの移行の案件では、予定したモジュールの移行が終わった時点で契約が更新されないことがあります。フリーランス法では、6か月以上の業務委託を中途で解除したり更新しなかったりする場合、原則として少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。それでも、次の案件を探す時間は限られます。

対策：契約期間と移行の計画の区切りを並べて見ておき、更新の見込みを早めに確かめます。契約期間の考え方は契約期間の記事をご覧ください。

Kotlinの案件だけを待って空白が長くなる

サーバーサイドKotlinの案件は、Javaの案件に比べると数が限られます。Kotlinだけに絞って次の案件を待つと、空白が長くなることがあります。

対策：契約の終わりの1〜2か月前には次の案件の相談を始め、JavaとKotlinが混在する案件も候補に入れておきます。

よくある質問

参画してから、Kotlinをほとんど書かない現場だと気づきました。どうすればよいですか？

まずは、聞いていた内容と実際の作業の違いを具体的に書き出し、契約で明示された業務の内容と照らし合わせます。そのうえで、紹介を受けたエージェントや発注側の窓口に相談してください。Kotlinに移す計画がある現場なら、移行の準備に関わる形を提案できることもあります。

前の現場の書き方のほうが良いと思うとき、提案してもよいですか？

提案してかまいませんが、参画してすぐは現場の決まりに合わせ、信頼ができてから根拠をつけて出すほうが受け入れられやすくなります。提案は、読みやすさや障害の防ぎやすさなど、現場にとっての利点で説明してください。参画初月の進め方はKotlinエンジニアの参画初月にやることで整理しています。

コルーチンの経験が浅いまま、非同期処理を任されました。どうすればよいですか？

引き受ける前に、経験した範囲を正直に伝え、既存のコードで同じような処理がどう書かれているかを確かめます。設計の段階でレビューを受け、キャンセルや例外の扱いをテストで押さえてから進めると、手戻りを小さくできます。求められるスキルの全体像はKotlinエンジニアのスキルの記事をご覧ください。