Reactエンジニアのフリーランス案件の仕事内容｜案件の種類と1日・1か月の流れ

Reactエンジニアのフリーランス案件の仕事は、画面の仕様を読み、コンポーネントを作り、レビューとテストを経てリリースすることの繰り返しが基本です。ただし、自社サービスの機能開発なのか、業務システムの画面なのか、既存の画面の刷新なのかで、1日の時間の使い方も、話す相手も、残る成果物も変わります。

この記事では、Reactの案件を5つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。報酬の決まり方はReactの報酬の記事、求められる技術はReactの案件で求められるスキルで扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

仕事の中身は「何を作る現場か」と「担う範囲」で決まる

同じ「React案件」でも、働き方の差を生むのは主に次の2つです。

• 何を作る現場か：利用者に直接届く自社サービスか、社内や取引先が使う業務システムか、既存の画面を作り直す現場か
• 担う範囲：決まった画面を実装するのか、共通部品や設計まで決めるのか、チームのレビューと方針まで持つのか

この2つを組み合わせると、Reactのフリーランス案件はおおむね次の5種類に分けられます。

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

自社サービスの機能開発

1日の流れ（例）

朝の短い打ち合わせで前日の進み具合と困りごとを共有し、その日に取り組むチケットを確かめます。午前はデザインのデータと仕様を見ながら画面を実装し、分からない点はチャットでデザイナーやプロダクトの責任者に確かめます。午後はAPIの担当者と受け渡しの形をすり合わせ、プルリクエストを出し、ほかのメンバーのレビューも行います。

自社サービスでは、仕様が実装の途中で変わることが珍しくありません。決まっていない点を自分から質問し、小さく作って見せる進め方が求められます。

1か月の流れ（例）

• スプリントの始め：計画の会議でチケットの大きさを見積もり、受け持つ範囲を決める
• 期間中：実装・レビュー・テストを回し、できたものから検証環境で確かめてもらう
• リリースの前後：表示の崩れや計測のずれを確かめ、出した後の利用状況を見て改善の案を出す
• 振り返り：進め方の問題を出し合い、次の期間の改善点を決める

成果物

画面のコードとテスト、コンポーネントの使い方の説明、プルリクエストの説明文、リリースの記録などです。利用状況を見て改善を提案する役割まで期待される現場もあります。

業務システムの画面開発

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

元請けの会社や発注元の情報システム部門のもとで、管理画面や業務の入力画面を作る案件です。設計書や画面の仕様書があらかじめ用意されていることが多く、1日の多くは仕様書に沿った実装と、その確認に使われます。入力の検証、一覧の絞り込み、権限ごとの表示の出し分けなど、画面の数が多いのが特徴です。

1か月の単位では、工程の区切りに合わせて実装を終え、単体テストの結果をまとめ、結合テストで出た不具合を直します。週次の進捗報告で、終わった画面の数と残りの課題を報告する現場が多くあります。

成果物

画面のコード、単体テストの結果、不具合の修正記録、仕様の不明点の問い合わせ記録などです。仕様の解釈が分かれた点は、口頭で済ませず記録に残しておくと、後の手戻りを防げます。

既存画面の刷新・移行

古い書き方のコードを新しい構成に置き換える案件です。クラスコンポーネントから関数コンポーネントへの書き換え、独自のビルド設定からフレームワークへの移行、Reactや関連ライブラリの版上げなどが含まれます。

参画直後と、その後

参画してすぐは、書くより読む時間が長くなります。画面の構成、状態の持ち方、テストの有無、触ってはいけない部分を把握し、置き換えの順番を決めます。その後は、画面や機能の単位で少しずつ置き換え、置き換えるたびに動作が変わっていないかを確かめます。一度にすべてを書き換えず、古い部分と新しい部分が並んで動く期間を前提に進めるのが一般的です。

成果物

現状の調査メモ、移行の計画と順番、置き換えたコードとテスト、動作確認の記録、残った課題の一覧などです。版上げの考え方はReactの将来性の記事でも触れています。

共通部品・デザインシステムの整備

ボタンや入力欄、ダイアログなど、複数の画面やチームで使う部品をまとめて作る案件です。デザイナーと部品の種類や状態の表し方を決め、使う側のチームが迷わないように使い方の文書や見本の画面も整えます。

1日の中では、部品の実装に加えて、各チームからの「この場面ではどの部品を使えばよいか」という相談に答える時間があります。アクセシビリティ（キーボードで操作できるか、読み上げで内容が伝わるか）への配慮も、この種類の案件では中心的な仕事になります。

成果物は、部品のコード、型の定義、部品ごとの見本と使い方、変更の履歴などです。

フロントエンドのリード

フロントエンドのチームを技術面でまとめる役割です。自分でもコードを書きますが、時間の多くは設計の方針を決め、レビューで質をそろえ、他の職種に技術的な判断を説明することに使われます。ディレクトリの構成、状態管理の方針、テストの範囲、版上げの時期などを決め、その理由を文書に残します。

1か月の単位では、開発の計画にフロントエンドの作業量を反映させ、技術的な負債の返済をどの程度入れるかをマネージャーと相談します。採用や新しく入った人の立ち上がりの支援を頼まれることもあります。

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

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

1. 仕様の確認：デザインと仕様の食い違い、決まっていない状態（読み込み中・エラー・データが空のとき）を早めに質問する
2. レビュー：自分のコードを見てもらうだけでなく、ほかのメンバーのコードも見る
3. APIとの受け渡し：バックエンドの担当者と、データの形やエラーの返し方をすり合わせる
4. 記録：プルリクエストの説明やチケットに、判断の理由を残す

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

働く場所については、Reactの案件はオンラインで回しやすい一方、立ち上げの時期や業務システムの案件では出社を求められることもあります。詳しくはReactのリモート案件の記事で解説しています。

よくある質問

Reactの案件では、デザインも自分で作ることがありますか？

デザイナーがいる現場では、デザインのデータをもとに実装するのが一般的です。小さなチームや管理画面の案件では、既存の部品を組み合わせて画面の配置を自分で決めることもあります。どこまで任される想定かは、参画前に確かめておくと安心です。

バックエンドの作業も頼まれることはありますか？

Next.jsなどでサーバー側の処理まで一つのコードで扱う現場では、データの取得や簡単なAPIの実装を担うことがあります。契約の業務範囲にバックエンドが入っているかは、案件票と個別契約で確かめておきましょう。Next.jsの案件の働き方はNext.jsの案件の仕事内容で解説しています。

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

開発環境の準備、コードの構成とルールの把握、小さなチケットでの最初のプルリクエストから始めるのが一般的です。初月の進め方はReactエンジニアの参画初月にやることで詳しく解説します。