Reactエンジニアのフリーランス案件の選び方｜契約前に確かめたい7つの点

Reactエンジニアの案件選びで確かめたいのは、役割の実態、使っている構成と版、コードとテストの状態、仕様を決める人、業務の範囲と責任、稼働と精算、契約期間の7点です。Reactの案件は、案件票に並ぶ技術の名前が同じでも、担う範囲やコードの状態で毎日の負担が大きく変わります。

この記事では、Reactの案件で選び方の差が出る理由と、7つの点を契約前にどう確かめるか、確かめた内容を書面とどう照らし合わせるかを整理します。契約全般の確認点は業務委託契約で確認すべきポイントで解説しているので、ここではReactの案件に固有の点に絞ります。

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

案件票には「React・TypeScript・Next.js」のように技術の名前が並ぶことが多く、それだけでは中身の違いが見えません。差が出るのは主に次の点です。

• 担う範囲：決まった画面の実装か、共通部品や設計まで決めるか、チームのレビューまで持つか
• コードの状態：新しく作るのか、長く使われてきたコードを直しながら進めるのか
• 仕様の決まり方：仕様書があるのか、実装しながら決めていくのか

参画してから「聞いていた内容と違う」と感じる理由の多くは、この3つのずれです。報酬も担う範囲で変わるため、範囲の確認は条件の交渉にもつながります。報酬の決まり方はReactの報酬の記事で解説しています。

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

1. 役割の実態は実装か、設計か、リードか

募集の名前が「フロントエンドエンジニア」でも、実際の役割は現場で違います。次のように聞くと実態がつかめます。

• 最初に担当する画面や機能は何か
• 共通部品や状態管理の方針は誰が決めるか
• 自分がレビューをする側にも入るか

役割ごとの働き方の違いはReactの案件の仕事内容で整理しています。

2. 使っている構成と版

Reactの版、TypeScriptの有無と型の厳しさ、Next.jsなどのフレームワーク、状態管理やスタイルの書き方を確かめます。今の構成と、版上げの予定の両方を聞いておくと、参画後に移行の作業がどのくらい入るかの見通しが立ちます。自分の経験と離れた構成の場合は、立ち上がりの期間をどう見てもらえるかも確かめておきましょう。

3. コードとテストの状態

新規の開発か、既存のコードの改修かで、仕事の中身は大きく変わります。既存のコードなら、テストがどの程度あるか、古い書き方の部分がどのくらい残っているか、レビューの仕組みがあるかを聞きます。テストが少ないコードの改修は、確かめる作業に時間がかかるため、見積もりの前提に入れておく必要があります。

4. 仕様を決める人と、デザインの受け渡し

仕様を誰が決め、デザインをどんな形で受け取るかを確かめます。デザイナーがいるか、デザインのデータに画面の状態（読み込み中・エラー・データが空のとき）まで描かれているか、決まっていない点を誰に聞けばよいか。仕様を決める人がはっきりしない現場では、判断を求められる場面が増え、作業量が読みにくくなります。

5. 契約の形と、負う責任の範囲

業務委託には、作業そのものを引き受ける準委任と、成果物の完成を約束する請負があります。Reactの案件で請負の形をとる場合は、何をもって完成とするか、不具合が見つかったときにいつまで直す責任を負うかを確かめます。違いは準委任と請負の違いで解説しています。

あわせて、バックエンドやインフラの作業が範囲に入るかも確かめます。Next.jsのようにサーバー側の処理まで同じコードで扱う構成では、範囲があいまいなまま作業が広がりやすくなります。広がったときの扱いは作業範囲が広がったときの契約の扱いをご覧ください。

6. 稼働の振れ幅と精算

月の稼働時間の幅と、幅を超えたときや下回ったときの精算の方法を確かめます。リリースの前に稼働が増えやすいか、夜間や休日の対応があるかも聞いておきましょう。精算の仕組みは精算幅の記事で解説しています。

7. 契約期間と、更新の見通し

最初の契約期間と、更新を判断する時期を確かめます。開発の区切り（リリース、移行の完了）と契約期間がどう対応しているか、区切りの後に保守や次の開発が続く予定があるかを聞くと、見通しを立てやすくなります。

案件票の書き方から読み取れること

案件票の言葉にも、確かめるべき点の手がかりがあります。次のような書き方を見かけたら、面談で中身を聞いておきましょう。

• 「フロントエンド全般」「幅広くお任せ」：範囲が決まっていない可能性がある。最初の担当と、範囲を決める人を聞く
• 「スピード感のある開発」：仕様が実装の途中で変わりやすい可能性がある。仕様を決める人と、変更の受け方を聞く
• 「リプレイス」「モダン化」：既存のコードの読み込みと段階的な置き換えが中心になりやすい。テストの状態と移行の順番を聞く
• 「Next.js歓迎」：サーバー側の処理まで範囲に入るかどうかで仕事が変わる。データの取得と配信の担当を聞く

どれも悪い案件という意味ではありません。書き方の裏にある働き方を確かめ、自分の希望と合うかで判断することが大切です。

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

面談や事前の説明で確かめた内容は、契約の書面と照らし合わせます。公正取引委員会のフリーランス法の特設サイトでは、発注事業者が明示すべき取引条件として、給付の内容、報酬の額、支払期日、業務委託をした日、役務の提供を受ける日や場所などが挙げられています。明示は書面か、電子メールなどの電磁的方法で行うこととされ、口頭は認められていません。項目の詳しい読み方はフリーランス法で明示される取引条件で解説しています。

Reactの案件で特に照らし合わせたいのは次の点です。

面談で聞いた内容と書面が合わないときは、署名の前に確かめます。口頭で「範囲は柔軟に」と言われた点ほど、書面に何が書かれているかを見ておくことが大切です。面談で何を聞くかはReactの面談の記事と業務委託の面談で聞いておくべき逆質問が参考になります。

よくある質問

古い書き方のコードが多い案件は避けたほうがよいですか？

一概に避ける必要はありません。既存のコードを少しずつ新しい形に置き換える経験は、刷新や版上げの案件で評価されることがあります。ただ、テストが少ないと確かめる作業に時間がかかるため、作業量の見積もりと稼働の条件が合っているかを確かめてから判断しましょう。

報酬の高い案件と、構成が自分に合う案件で迷ったらどうしますか？

報酬だけで選ぶと、立ち上がりに時間がかかり、評価を得るまでの負担が大きくなることがあります。構成が近い案件で成果を出し、次の更新や次の案件で条件を上げるという考え方もあります。どちらを選ぶ場合も、担う範囲と報酬が釣り合っているかを確かめることが大切です。

Next.jsの案件を選ぶときに、Reactだけの案件と違って確かめることはありますか？

サーバー側の処理やデータの取得、配信の設定まで範囲に入るかを確かめます。サーバー側の不具合の対応を誰が担うかもあわせて聞いておきましょう。詳しくはNext.jsの案件の選び方で解説しています。