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

Node.jsエンジニアのフリーランス案件を選ぶときは、報酬や稼働日数に加えて、担う層、画面の作業の割合、運用と障害の当番、Node.jsの版と依存パッケージの状態、開発の体制とレビューの流れ、契約の形と成果物、稼働の振れ幅と精算の7点を契約前に確かめておくことが大切です。Node.js案件は、募集の言葉が同じでもこの7点の違いで、毎日の仕事も負担も大きく変わります。

特に見落としやすいのは、案件票の「Node.js」が、どの層の、どこまでの仕事を指しているかです。サーバーの案件のつもりで入ったら画面の作業が中心だった、APIの追加のつもりが運用まで任された、というずれは少なくありません。この記事では、Node.js案件に固有の確認点を整理します。契約書全般の確認点は業務委託契約書のチェックポイントで解説しています。

Node.js案件の選び方で差が出る理由

Node.jsは、画面を作る人もサーバーを作る人も使う実行環境です。そのため、案件票に「Node.js」「TypeScript」「API開発」と書かれていても、中身の幅が広くなります。案件票の読み方の基本は案件票の読み方の記事で扱っています。

よくあるずれは次のようなものです。

• サーバー側の案件として入ったのに、実際は画面の修正が半分以上だった
• 新規開発と聞いていたが、サポートの期限が近い版で動く既存アプリの保守が中心だった
• 障害の当番は聞いていなかったのに、参画後に当番の表に入っていた
• 依存パッケージの更新が長く止まっていて、どこから手をつけるかの判断から求められた

こうしたずれは、面談と条件の確認の段階で、聞き方を工夫すれば多くを防げます。

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

1. 担う層と、任される判断の範囲

最初に確かめたいのは、自分が担う層です。サービスの中心となるAPIか、画面のためのBFFか、サーバーレスの処理か、リアルタイムの機能か。あわせて、API設計やデータベースの設計を自分で決めるのか、決まった設計に沿って実装するのかも確かめます。

面談では、「参画後の最初の1か月で、最も期待されている成果は何か」を聞くと、役割の実態が見えやすくなります。層ごとの働き方の違いはNode.jsエンジニアの仕事内容の記事で整理しています。

2. 画面の作業の割合

フルスタックに近い案件では、画面とサーバーの作業の割合を確かめます。

• 画面の作業が含まれるか。含まれるなら、おおよその割合
• 画面側の担当者が別にいるか
• 画面のフレームワークや作り方に、自分の経験が合うか

割合がはっきりしないまま参画すると、積みたい経験が積めない、報酬に対して範囲が広すぎる、といった問題につながります。報酬と範囲の見方はNode.jsエンジニアの報酬の記事で解説しています。

3. 運用と障害の当番

本番の運用にどこまで関わるかを確かめます。

• 障害の当番に入るか。入るなら頻度と、夜間・休日の扱い
• 監視の通知を受けるのは誰か。一次対応と二次対応の分け方
• 本番環境への操作の権限はどこまで持つか、誰が承認するか

当番は場所がリモートでも時間の拘束が生まれるため、稼働の条件と合わせて考える必要があります。リモートでの条件のつき方はNode.jsのリモート案件の記事をご覧ください。

4. Node.jsの版と依存パッケージの状態

既存のサービスに入る案件では、動いている版と依存パッケージの状態を確かめます。

• 本番で動いているNode.jsの版と、版上げの予定
• フレームワークの版と、移行の予定があるか
• 依存パッケージの更新がどのくらいの間隔で行われているか

Node.jsの公式の案内では、本番のアプリにはActive LTSかMaintenance LTSの版を使うよう示されています（2026年10月時点）。サポートの期限が近い版や、更新の止まったパッケージを多く抱えたサービスを避ける必要はありません。版上げの経験は評価にもつながります。ただ、状態を知ったうえで受けることが大切です。版上げが仕事の中心になるなら、その期間と範囲が業務の内容に含まれているかもあわせて確かめておきます。

5. 開発の体制とレビューの流れ

体制の中で自分がどこに位置するかを確かめます。

• バックエンドのチームの人数と、テックリードがいるか
• コードレビューは誰が行い、設計を決めるのは誰か
• 検証用の環境、クラウドの権限、デプロイの手順が参画時にそろっているか

レビューする人がいない現場では、自分の判断がそのまま本番に出ます。反対に、承認の流れが多い現場では、小さな変更でも時間がかかります。どちらが合うかは経験と働き方の希望で変わるため、事前に知っておくと判断しやすくなります。

6. 契約の形と、成果物の扱い

フリーランスのNode.jsエンジニアは、多くの場合、準委任契約で参画します。準委任では、システムの完成そのものではなく、業務を専門家として通常求められる注意を払って行うことが約束の中身になります。確かめたいのは、契約書や発注の書面の書き方が、この考え方と合っているかです。

• 「機能を期限内に完成させる」のように、完成を約束する書き方になっていないか
• 納品物があるなら、その範囲（コード、仕様書、手順書など）と検収の方法
• 書いたコードの権利の扱い、個人で作ったパッケージを持ち込む場合の扱い

請負の形で受ける場合は、完成に対する責任を負うことになります。契約の形の違いは準委任契約と請負契約の違いで解説しています。また、準委任の契約なのに、発注元の社員から細かな作業の指示や勤務時間の管理を受ける働き方は、偽装請負の問題につながるおそれがあります。詳しくは偽装請負の記事をご覧ください。

7. 稼働の振れ幅と精算

Node.jsの案件の稼働は、リリースの前後や障害の対応、版上げの時期に振れます。

• リリースやデータ移行の日に、夜間や休日の作業があるか
• 精算幅を超えたときの扱いと、稼働が少ない月の扱い
• 当番で待機した時間や、呼び出しに応じた時間をどう数えるか

超過した時間の扱いを確かめておかないと、責任感から無償で対応し続けることになりかねません。精算の仕組みは精算幅の記事をご覧ください。

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

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

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

1. 業務の内容に、担う層と範囲（APIの開発、BFF、運用など）が書かれているか
2. 障害の当番や運用を担う場合、そのことが業務の内容に含まれているか
3. 完成を約束する書き方になっていないか、納品物があるならその範囲
4. 稼働の幅と、超えたときの精算方法
5. 契約期間と更新の時期

また、同じ公正取引委員会の案内では、6か月以上継続して業務を委託している場合に、契約を解除したり更新しなかったりするときは、原則として30日前までに予告することが求められています（2026年10月時点）。版上げや移行の山場と契約の更新時期が重なっていないかも、あわせて見ておきましょう。

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

よくある質問

古い版のNode.jsで動いている案件は避けたほうがよいですか？

避ける必要はありません。版上げの経験は、次の案件で評価されやすい経験です。ただし、版上げが仕事に含まれるのか、含まれるならその期間と範囲、テストの体制を参画前に確かめてから受けることをおすすめします。

フルスタックの案件と、サーバー側だけの案件で迷ったらどうしますか？

積みたい経験と、稼働の見込みで比べます。フルスタックの案件は範囲が広い分、打ち合わせの相手も責任も増えます。サーバー側の経験を深めたいならサーバー側だけの案件、両方の経験を広げたいならフルスタックの案件、と目的を決めると判断しやすくなります。

面談で障害の当番や画面の作業の割合を聞くのは失礼ですか？

担える範囲を判断するための確認として聞けば、失礼にはあたりません。「参画後の働き方を具体的に思い描いておきたい」という目的を添えると、相手も答えやすくなります。その場で答えが出ない場合は、契約の前に確かめてもらうよう依頼しましょう。