TypeScriptエンジニアのフリーランス案件の選び方｜契約前に確かめたいこと

TypeScriptエンジニアのフリーランス案件を選ぶときは、報酬や稼働日数に加えて、画面・サーバー・基盤の仕事の割合、型の設定と決まり、コードベースの状態と版上げの予定、APIの型の持ち方、開発環境、成果物と権利の扱い、稼働の振れ幅の7点を契約前に確かめておくことが大切です。TypeScriptの案件は、案件票の書き方が似ていても、この7点の違いで毎日の負担が大きく変わります。

特に見落としやすいのは、コードベースの状態です。型の無視が多いコードや、古い設定のまま止まっているコードに入ると、機能を作る前に型エラーと向き合う時間が増えます。この記事では、TypeScriptの案件に固有の確認点を整理します。契約書全般の確認点は業務委託契約書のチェックポイントで解説しています。

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

TypeScriptは画面でもサーバーでも使われるため、案件票には「TypeScript」「React」「Node.js」のような技術名が並ぶだけで、実際の仕事の中身が読み取りにくいことがあります。参画してから想定との違いに気づく例として、次のようなものがあります。

• 画面の案件のつもりが、BFFやバッチの改修が中心だった
• 型チェックがほとんど効いておらず、型エラーの片付けに時間を取られた
• 機能開発の案件なのに、版上げやビルドの設定変更まで任された
• APIの型が画面とサーバーで別々に書かれ、ずれによる不具合の調査が続いた

こうしたずれは、面談と条件の確認の段階で聞き方を工夫すれば、多くを防げます。仕事の種類ごとの働き方はTypeScriptの仕事内容で整理しています。

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

1. 画面・サーバー・基盤の仕事の割合

最初に確かめたいのは、自分が書くコードがどこで動くものかです。面談では、「主に触るリポジトリはどれか」「画面とサーバーの仕事の割合はどのくらいか」を聞くと、実態が見えやすくなります。フルスタックの募集なら、インフラやデプロイまで担うかも聞いておきます。

2. 型の設定と、チームの決まり

strictなど型チェックの設定がどうなっているか、anyや型の無視をどう扱う決まりがあるかを確かめます。

• 型チェックの設定は厳しいか、ゆるいか。厳しくする予定はあるか
• anyや型の無視を使ってよい場面の決まりがあるか
• リンターやフォーマッターの設定が決まっているか

設定のゆるさそのものは悪いことではありません。大切なのは、その状態を前提に、自分が何を期待されているかです。設定を厳しくする役割を期待されているなら、その作業の時間が見込まれているかもあわせて確かめます。

3. コードベースの状態と、版上げの予定

案件票に書かれていない「今の状態」を確かめます。

• TypeScriptの版と、使っているビルドの道具
• 型エラーや型の無視がどのくらいあるか
• テストがどの程度あり、CIで型チェックが回っているか
• JavaScriptのコードが残っているか、移行の途中か

Microsoftの公式ブログによると、2026年7月8日に公開されたTypeScript 7.0では、strictが初期設定で有効になり、target: es5やbaseUrlなど一部の設定がエラーになりました（2026年10月時点）。古い設定のプロジェクトでは、版上げの際に設定の書き換えが要ります。版上げの予定があるか、それを誰が担うかを聞いておくと、参画後に仕事が増えたときに慌てずに済みます。

4. APIの型の持ち方

画面とサーバーの間で受け渡すデータの型を、どう管理しているかを確かめます。

• APIの仕様書から型を生成しているか、手で書いているか
• 画面とサーバーで型を共有しているか、別々に持っているか
• 外部から届くデータを、どこで実行時に検証しているか

型が別々に書かれている現場では、ずれによる不具合の調査や、型を揃える作業が仕事に入ってきます。自分がその仕組みを整える役割を期待されているのか、既存の仕組みに沿って書けばよいのかを確かめましょう。

5. 開発環境と、使ってよい道具

リモートで働けるか、貸与の端末や仮想デスクトップでの開発か、ソースコードを手元の端末に置いてよいかを確かめます。生成AIのコード補完を使ってよいかも、案件ごとに決まりが違います。使ってよい道具の範囲は、情報の扱いと関わるため、契約の前に確かめておくと安心です。生成AIの扱いの考え方は生成AIの利用と契約の記事で解説しています。

6. 成果物の範囲と、コードの権利

TypeScriptの案件では、書いたコードの権利の扱いも確かめます。

• 契約の形は準委任か請負か。完成を約束する書き方になっていないか
• 書いたコードの権利がいつ、どこまで発注元に移るか
• 自分が以前から持っている汎用の部品や型の定義を使う場合の扱い
• オープンソースのライブラリを使うときの決まり

準委任の契約なのに、発注元の社員から細かな作業の指示や勤務時間の管理を受ける働き方は、偽装請負の問題につながるおそれがあります。契約の形の違いは準委任契約と請負契約の違い、ライブラリの扱いはOSSを使うときのライセンスの注意点で解説しています。

7. 稼働の振れ幅と精算

• リリース前の追い込みや、夜間・休日のリリースの立ち会いがあるか
• 障害が起きたときの連絡と対応の体制に、自分が入るか
• 精算幅を超えたときの扱いと、稼働が少ない月の扱い

サーバー側の案件ほど、障害の対応で稼働が振れやすくなります。超過した時間の扱いを確かめておかないと、責任感から無償で対応し続けることになりかねません。

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

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

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

1. 業務の内容に、担う層（画面・サーバー・基盤）と主な作業が書かれているか
2. 移行や整備の案件なら、対象の範囲と完了の形が書かれているか
3. 完成を約束する書き方になっていないか（準委任の場合）
4. 稼働の幅と、超えたときの精算方法
5. 契約期間と更新の時期

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

よくある質問

型の状態が悪いコードベースの案件は避けたほうがよいですか？

避ける必要はありません。型を整えた経験は、次の案件で評価されやすい経験です。ただし、その作業の時間が見込まれているか、機能開発と並べてどこまで期待されているかを確かめてから受けることをおすすめします。

版上げをまだしていない現場は、選ばないほうがよいですか？

版上げをしていないこと自体は問題ではありません。使っている道具や依存のライブラリの事情で、あえて版を据え置く判断もあります。大切なのは、今後の予定と、それを自分が担うかどうかを知ったうえで受けることです。

報酬の高い案件と、仕事の範囲がはっきりした案件で迷ったらどうしますか？

一概には言えませんが、範囲があいまいなまま基盤の仕事や障害の対応が重なると、稼働が増えて時間あたりの報酬が下がることがあります。報酬の額だけでなく、稼働の見込みと範囲をあわせて比べるとよいでしょう。報酬の決まり方はTypeScriptの報酬の記事で解説しています。