アジャイル案件のフリーランス単価相場｜求められる経験と参画条件

アジャイル案件の市場実情

フリーランス向けの「アジャイル案件」は、単独の職種として募集されるのではなく、技術スタック募集の要件欄にアジャイル／スクラム経験が組み込まれる形が中心です。「アジャイルできる開発者を探す」より、「TypeScript × React × スクラム経験ある人」を探す募集の書き方が主流です。

公開案件で見られる募集の類型

主要フリーランスエージェント数社（首都圏中心）の公開案件を観測すると、開発エンジニア枠のアジャイル案件は次の4類型に整理できます。

上2つは開発者としての実装力＋チーム内での自走を、下2つは既存資産の理解＋段階的移行の設計を重視される傾向があります。募集要件の書き方から、どの類型かはある程度読み取れます。

案件の探し方：エージェントで絞るキーワード

エージェントの検索・希望条件登録では、タグと自由記述を組み合わせるのが実務的です。

• タグ：「アジャイル」「スクラム」「XP」「モダン開発」など

• 技術スタック：Web系なら「TypeScript／React／Next.js／Go／Ruby on Rails／Kotlin／Swift」等

• 契約形態：準委任

• 稼働：週4〜5日／フルリモート希望など

「アジャイル」だけで検索すると、SAP／基幹刷新系のウォーターフォール寄り案件がヒットして絞れないことがあります。技術スタックとの併用が現実的です。エージェントとのやり取りのコツは、既存記事「エージェント担当者との付き合い方｜希望条件が通る伝え方と信頼構築のコツ」も参考にしてください。

ミニFAQ｜そもそもアジャイル案件は多いのか

• Q：ウォーターフォール案件と比べて、アジャイル案件は多いのでしょうか。

• A：Web系プロダクト開発の公開案件では、要件欄にスクラム／アジャイル経験を挙げる案件が主流の一つになっています。一方で、金融・公共・製造など既存業務システム寄りの領域ではウォーターフォール案件が引き続き多く、領域によって偏りがあります。まずは志望領域を絞ってから探すのが効率的です。

フリーランスアジャイル案件の単価相場

数字の前に母集団を先に置きます。本記事の相場は、首都圏案件を多く扱うフリーランスエージェント4〜6社の公開案件情報を、開発エンジニア枠かつ週5日・準委任・フルリモートに絞って観測した目安です。同一案件の重複掲載はできる限り除外しています。公開案件はロール上位帯（テックリード級以上）ほど掲載数が減り、上位帯ほど非公開流通が中心になるため、上位帯は母集団が薄いことを前提に読んでください。数値は執筆時点のスナップショットで、時期・案件個別性で変動します。

単価目安（開発エンジニア枠）

まずは条件なしの短答から示します。開発エンジニア枠のアジャイル案件は、公開案件ベースで月額70〜90万円が中心帯です。以下の目安は、実務経験3年以上・Web／モバイル／クラウド系の実装経験を前提とした数字で、参画スキル要件が高い案件はここから上振れします。

非公開案件は個別条件で上振れするケースがあります。エージェント面談で提示されるオファーには、公開案件より高い単価が並ぶことがありますが、要求される経験・体制関与度が上がる分、条件の個別性が強く、そのまま「自分の相場」とは扱いにくい数字です。まずは公開案件ベースを基準線に置いてください。

単価を体系的に上げる考え方については「【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？」でも整理しています。自分の市場単価の目安を数分で把握したい場合は、無料のフリーランスエンジニア単価診断で参考数値が確認できます。

単価に影響する主な要素

上のレンジのどこに落ちるかは、次の要素で概ね決まります。

• 技術スタックの需要：公開案件の観測上、TypeScript／React／Go／Kotlin など募集が多いスタックは中心帯に乗りやすい傾向があります

• スクラム経験の深さ：単に参加した経験ではなく、PBIの分割・見積り・レトロスペクティブでの改善提案まで動けるとテックリード側に寄せられます

• 自動テスト／CIへの適応：既存テストコードを壊さずに機能追加できる書き方ができるか

• 要件の詰めまで踏み込めるか：PO／PdMと会話しながら受け入れ条件を詰められるスキル

• チーム規模と体制の複雑さ：スケール系（複数チーム）は難易度が上がる分、単価も上げやすくなります

東京と地方・フルリモート案件の単価差

単価差の即答型として、地域・出社頻度別の傾向を整理します。

上記の目安は執筆時点で首都圏フルリモート公開案件を確認した数字で、実務経験3年以上・週4〜5日稼働・首都圏企業の完全リモート案件に応募することを想定しています。実務経験3年以上で、首都圏企業の完全リモート公開案件に応募する場合は、地方在住でも東京在住者と近い単価レンジで参画できるケースが見られます。

ミニFAQ｜スクラム経験が浅くても単価は伸ばせるか

• Q：スクラム経験はあまりないが、Web実装は5年以上あります。単価は伸ばせるでしょうか。

• A：スプリント運用の型が動けば、実装力が中心帯を押し上げやすいです。初回参画時は中心帯下限からのスタートになりがちですが、レビューやテスト、リファクタリングで貢献できると更新時に交渉余地が出ます。参画後3か月の動き方は「フリーランス単価を上げる参画後3ヶ月｜初回更新までの実績づくり」で扱っています。

求められる経験・スキル

アジャイル案件で参画時に見られている観点は、大きく「実装力」「チーム内の動き方」「プロセス運用の理解」の3つです。プロセス運用は最低限で足りることが多く、実装力とチーム内での自走が中心になります。

実務経験の観点

案件要件で頻出するのは次のような書き方です。

• Web／モバイル／クラウド系の実装経験3年以上（言語やフレームワークは指定あり）

• スクラム／XP／アジャイルでの開発経験1年以上、または1〜2スプリントを最後まで回した経験

• チーム開発でのコードレビュー経験、Pull Request（Merge Request）運用の経験

• ユニットテスト／自動テストを書きながら開発を進めた経験

「アジャイル経験3年以上」と書かれていても、実際に見られるのは「バックログ／スプリントプランニングを理解し、レビュー文化とテスト文化に馴染めるか」です。ウォーターフォール寄りのSIer経験しかない場合は、副業やOSS参加でスプリント運用に触れておくと、面談時に説明しやすくなります。SIerからWeb系に踏み出すときの整理は「SIerからWeb系案件へ移るフリーランスの準備｜通過条件と案件選び」も参照してください。

技術スタック面の観点

• バージョン管理：Gitのブランチ運用、レビュー付きマージが前提

• CI／CD：GitHub ActionsやCircleCIなどでのビルド・テスト自動化

• 自動テスト：ユニットテストは必須級、Web系ではE2Eテストも書けると評価される傾向

• オブザーバビリティ：ログ・メトリクス・トレース（Datadog／New Relic 等）を触った経験

• クラウド：AWS／GCPのマネージドサービスを使った実装経験

開発者としての基礎スキルは、既存記事「バックエンドエンジニアとは？仕事内容や年収、必要なスキルを詳しく解説」でも扱っています。アジャイル案件でも土台の技術要件は変わりません。

「アジャイル経験3年」等の要件で見られていること

要件欄の「アジャイル経験◯年」は、年数そのものより次の3点が伝えられるかを見ているケースが多いです。

• スプリントプランニングで自分のタスクを見積もり、コミットラインを守った経験

• レトロスペクティブで改善提案を出し、次スプリントで反映した経験

• 障害・レビュー指摘への向き合い方（責任の押し付けにならないコミュニケーション）

面談で「スクラムを何回転回しましたか」「レトロスペクティブで直近取り組んだ改善は」を聞かれることが多いのは、この確認のためです。

参画条件と契約形態

参画条件は、準委任・週4〜5日・フルリモート中心・3〜6か月更新が中心の型です。

準委任契約がほとんどな理由

アジャイル案件は成果物を事前に確定できない開発モデルのため、成果物の完成責任を負う請負契約とは相性が悪く、準委任契約が使われます。契約形態ごとの違いは「受託開発と準委任の違いと使い分け｜フリーランスの収入構造と向く人」で詳しく整理しています。

準委任契約では、稼働時間や精算条件に応じて報酬が定められるのが一般的です。契約書では「善良な管理者の注意義務」に基づき自走することが期待される書き方が多く、時間管理と成果の可視化（デイリー・スプリントレビューでの共有）がそのまま信頼につながります。実際の義務範囲や評価対象は契約条項によって異なるため、参画前に個別契約の確認が必要です。

稼働形態と出社傾向

• 週4〜5日稼働が中心。週3以下の案件はチームの一員として動きにくいため、募集数は限られます

• フルリモート／週1〜数回オンサイトの案件が多い。プロダクト内製系はフルリモート寄り、SIer混成系は月1〜週1のオンサイトが混じる傾向があります

• 稼働時間帯はコアタイム10〜16時が中心。デイリースクラム／スプリントプランニングの時間帯はチームに合わせます

週4稼働で入れるか迷う場合は、「週4稼働のフリーランス案件｜週3・週5との違い・単価目安・探し方」も参考にできます。

参画期間の傾向

• 初回契約は3か月更新が中心。長いところで6か月

• スプリント長は1〜2週間が主流で、初回契約3か月＝6〜12スプリントを回すイメージ

• 「1スプリント目で慣れて、3スプリント目でチームの一員として貢献」が期待値のライン

参画初月の立ち上がり方は「フリーランス参画初月の立ち上がり方｜30日で信頼を得るオンボーディング型」で扱っています。

案件のケーススタディ

同じ「アジャイル案件」でも、フェーズによって求められることが変わります。応募前に、どのフェーズの案件かを見極めておくと、単価交渉と面談準備が進みやすくなります。

ケース1：立ち上げ初期のスクラム導入支援

クライアント側にスクラム経験が薄く、開発チームを立ち上げるフェーズです。実装力に加え、スプリント運用の型づけを求められます。要件のスライス、PBIの粒度感、Definition of Doneの設計などをリードできる人が重宝されます。単価は上位帯に寄せやすい半面、社内政治の調整が必要になる場面もあります。

ケース2：運用フェーズの機能追加開発

すでにプロダクトが稼働しており、複数のスクラムチームが並走するフェーズです。既存コードベースの読み解きとレビュー文化への適応が中心で、実装力があれば中心帯に乗りやすい類型です。初参画のフリーランスにとっては入りやすいケースです。

ケース3：モダナイゼーション／リプレース案件

レガシーシステムを新スタックへ段階的に移行するフェーズです。旧仕様の解読と新仕様の設計を行き来する必要があり、経験値の高い開発者が求められます。単価は上位帯に寄せやすい類型で、モダナイゼーション案件全般の相場は「モダナイゼーション案件の動向｜フリーランスの単価相場・必要スキル・探し方」で扱っています。

ケース4：内製化の伴走・スケールアップ

クライアントの内製チームを、外部専門家として伴走支援するフェーズです。実装＋メンタリングの役割で、テックリード級の経験が求められます。単価は上位帯、参画期間は6か月〜1年と長めになりやすい類型です。プライム・元請直で発生するケースが多く、「プライム・元請直のフリーランス案件｜入る条件と求められる実績」もあわせて参考にできます。

職種別に見る関わり方

アジャイル案件では、開発エンジニアのほかにスクラムマスター、プロダクトオーナー支援などの職種でも募集があります。本記事の主対象は開発エンジニア枠です。他職種については既存記事へ委譲しつつ、境界を整理します。

開発エンジニア（本記事の主対象）

上で整理してきた単価相場・求められる経験・参画条件はこの職種を前提としています。実装しながらチーム運用にも自然に貢献できる開発者が中心です。

スクラムマスター（詳細は別記事へ委譲）

スクラムマスター専任の案件は数が少なく、「スクラムマスター募集」ではなく「アジャイル開発の推進ができる人」という書き方の募集が目立ちます。仕事内容、単価、キャリアパスなどの詳細は「スクラムマスターとは？仕事内容・年収・PM/PMOとの違いをエンジニア視点で解説」を参照してください。

プロダクトオーナー・PdM支援

内製プロダクト側で、外部フリーランスがPO／PdMの実務を支援する案件も見られます。要件整理、PBI管理、ステークホルダー調整が中心で、開発エンジニア出身者がPMキャリアに移る際の受け皿になることがあります。PM／PMOの詳細は「プロジェクトマネージャー(PM)とは？ 仕事内容や年収、必須スキルについて解説」「PMOとは？仕事内容や年収、将来性について解説」で扱っています。

参画前に確認しておくこと

面談で聞くべきポイントを、チェックリスト形式で整理します。アジャイル案件の看板だけを見て入ると、実際はウォーターフォール寄りの運用だったというケースを避けるためのリストです。

• スプリントの長さ（1週間／2週間／その他）

• デイリースクラム・スプリントレビュー・レトロスペクティブは実施されているか

• プロダクトオーナー／プロダクトマネージャーが常駐しているか、意思決定の速さ

• Definition of Doneが明文化されているか

• 自動テストのカバレッジ、CIパイプラインの実装状況

• コードレビュー文化（PR/MRの回転速度、レビュー基準）

• 1スプリントあたりのベロシティが安定しているか、それとも計画倒れが多いか

• 「アジャイル」と呼びつつ、実態は短期ウォーターフォールになっていないか

面談で確認しにくい場合は、エージェント担当者経由でクライアントに投げてもらうと角が立ちにくいです。

よくある失敗と対策

参画後にトラブルになりやすいパターンと、その回避策を整理します。

失敗1：スクラム経験を過大に見せて参画してしまう

見積もりが甘くなり、スプリント中に約束したPBIを消化しきれないケースです。対策は、面談時点で経験の粒度を正直に伝えることです。「参加経験はあるが、レトロスペクティブで改善を主導した経験は浅い」など、具体的にどこまで動けるかを開示すると、参画後の期待値ミスマッチを避けられます。

失敗2：既存コードのレビュー基準を把握せずにPRを出す

初回のPRで大量指摘を受け、参画初月の信頼獲得に失敗するパターンです。対策は、初週にレビュー済みPRを10〜20本読み、レビュー基準を把握することです。ドキュメントよりも実際のレビューコメントに基準が現れます。

失敗3：稼働時間を消化することだけを目標にしてしまう

準委任だからと稼働時間の消化だけを意識すると、スプリントレビューでの成果が薄くなり、更新時に単価を下げられるリスクがあります。対策は、PBIの完了ベースで自分の貢献を可視化することです。デイリーで「今日終わらせるPBI」を宣言し、レビュー時に達成度を報告する動き方が有効です。

失敗4：レトロスペクティブで意見を出さずに終わる

意見を出さない参加者はチームへの貢献度が低いと見なされやすいです。対策は、問題点1つと改善案1つを毎回持参することです。実装者目線での「詰まったポイント」は、他メンバーが気づいていない改善余地であることが多く、貢献ポイントになります。

まとめ

Web系・プロダクト開発の公開案件では、アジャイル案件は開発エンジニアが週4〜5日・準委任・フルリモート中心で参画するのが中心の型で、公開案件ベースの単価は月額70〜90万円が中心帯、テックリード級で90〜120万円が目安です。求められるのは実装力とチーム内での自走で、スクラム運用の型は基本理解で足ります（金融・公共・基幹系はウォーターフォール寄りの案件が引き続き多く、領域差があります）。

参画を検討する際のポイントを最後に整理します。

• 探し方は、アジャイル／スクラムのタグに技術スタックを掛け合わせて絞る

• 単価は公開案件ベースで70〜90万円を基準線に、経験・役割に応じて上下する

• 求められるのは実装力＋チーム内の自走。プロセス運用は基本理解で足りる

• 契約は準委任、稼働は週4〜5日、参画期間は3〜6か月更新が中心

• 参画前に、スクラムイベントの実施状況・自動テスト・レビュー文化を必ず確認する

• スキルシートには「スクラム／チーム規模／スプリント長／回した期間／役割」を案件ごとに整理して書く

アジャイル開発の手法そのものを復習したい場合は、既存記事「アジャイル開発とは｜仕組み・スクラム・ウォーターフォールとの違い」に体系的な整理があります。参画候補の案件を絞り込みたい場合は、フリコンの案件一覧からアジャイル関連の公開案件を確認できます。

参考リンク

• アジャイルソフトウェア開発宣言（Agile Manifesto 日本語版）

• スクラムガイド 2020 日本語版（Scrum.org PDF）

• Atlassian｜アジャイル開発とは（Agile Coach）