カスタマーサクセスエンジニアがフリーランスで働く方法｜単価とキャリア

案件更新の面談で単価交渉が通らなかったとき、「このまま開発一本で40代を迎えて大丈夫だろうか」と考えたことはないでしょうか。実装力そのものは落ちていないのに、単価だけが横ばいから微減に向かう。同世代が PdM や EM に転じていくのを横目に見ながら、自分の売り方に限界を感じ始めている方は少なくないはずです。

一方で、現場では顧客企業からの API 連携相談やデータ移行の支援、障害の切り分けを任される機会が増えている。そこに商機がありそうだと感じて「カスタマーサクセス 業務委託」と検索してみると、出てくるのは非技術職の求人一覧と、正社員採用を前提にした職種解説記事ばかりです。提示されている単価レンジは月20万円台から80万円台まで開いていて、自分がどこに位置づくのか読めません。そして頭をよぎるのが「顧客対応に寄せた瞬間、エンジニアとしての単価は下がるのではないか」「一度離れたら開発案件に戻れなくなるのではないか」という不安です。

この不安が厄介なのは、事実ではなく情報の欠落から生まれている点にあります。世に出ている記事は「カスタマーサクセスエンジニアとは何か」を説明するものか、「どんな案件があるか」を並べるものかのどちらかで、その中間、つまり「エンジニアである自分が軸足を移して単価を維持できるのか」を判断する材料が抜け落ちています。判断材料がないから動けない、というのが実態です。

結論から言えば、カスタマーサクセスエンジニア（CSE）への軸足移動は、単価ダウンの片道切符ではありません。ただしそれは「技術要件のある案件を選び、スコープと契約形態を正しく設計した場合」という条件付きです。逆に条件を外すと、非技術のカスタマーサクセス職と同じ土俵で値付けされ、単価が半分近くまで落ちることも起こり得ます。この分かれ目を知らないまま媒体のレンジだけで判断するのが、最も損をするパターンです。

本記事では、フリーランスとしてカスタマーサクセスエンジニアで働く方法を、案件が増えている背景・単価の決まり方・案件の探し方と契約形態・未経験からの入り方・キャリアパスの5つの角度から整理します。加えて、開発案件を手放さずに可逆な形で試すための稼働設計も示します。読み終えたときに「自分の場合はこう始める」という具体的な一手を持ち帰っていただくことがゴールです。

カスタマーサクセスエンジニアのフリーランス案件が増えている背景

まず押さえておきたいのは、CSE という枠が「エンジニアの受け皿」として生まれたのではなく、SaaS 企業側の切実な人手不足から生まれているという点です。需要の出所を理解しておくと、後述する単価の話も腹に落ちやすくなります。

カスタマーサクセスエンジニアとは（CS職・SE職・サポートエンジニアとの境界線）

カスタマーサクセスエンジニアとは、顧客の成功を目的として、プロダクトの導入・活用における技術的な支援を担う職種です。BtoB SaaS 企業を中心に需要が高まっているとされています（お名前.com ビジネスコンシェルジュ）。

ただし、この定義だけでは近接職種との区別がつきません。エンジニアが判断に使うなら、「誰の何を、どのタイミングで解決するか」で切り分けるほうが実用的です。

ポイントは、サポートエンジニアが「問題が起きてから動く」のに対し、CSE は「問題が起きないように、あるいは顧客がプロダクトを使いこなせるように先回りして動く」という時間軸の違いにあります。この能動性が、後述する単価の根拠にも直結します。

また、非技術の CS 職とは目的こそ近いものの、扱う課題の層が異なります。CS が「解約されないための関係構築」を担うのに対し、CSE は「技術的な障壁があるせいで使われていない」という状態そのものを取り除きます。この違いを言語化できるかどうかが、案件選定と単価交渉の出発点になります。

フリーランスCSEが実際に任される仕事内容

カスタマーサクセスエンジニアの仕事内容は、案件によって幅がありますが、フリーランスに切り出される業務は次の4つに集約されやすい傾向があります。

1. API 連携・外部システム連携の支援：顧客側のエンジニアと会話しながら、認証方式・データ形式・エラーハンドリングの設計を詰めます。仕様書を書いて渡すだけでなく、サンプル実装やデバッグ支援まで含むこともあります。
2. データ移行・初期セットアップの設計と実行：既存システムからのマイグレーション計画、データクレンジング、バリデーションルールの設計など。SQL とスクリプトが書けることが前提になる領域です。
3. 障害・不具合の一次切り分け：顧客からの報告を受け、プロダクト側のバグなのか、顧客環境の設定なのか、想定外の使い方なのかを判別して開発チームにエスカレーションします。ここで精度の高い切り分けができると、開発チームの負荷が大きく下がります。
4. 技術文書・ナレッジの整備：導入手順書、FAQ の技術面、実装サンプル、トラブルシューティングガイドの作成。プロダクトの利用状況を分析して改善提案につなげる役割を含む場合もあります。

いずれも「顧客と話せる」だけでは務まらず、「顧客と話しながらコードとデータ構造を読める」ことが必須になります。逆に言えば、実務8年前後のバックエンド／インフラエンジニアであれば、技術面のハードルは高くありません。

発注企業がカスタマーサクセスエンジニアを外部委託する理由

では、なぜ企業は正社員で採らずに業務委託で確保しようとするのでしょうか。背景には、カスタマーサクセス人材の採用そのものが難航しているという構造があります。

バーチャレクス・コンサルティングが2025年2月に実施した調査では、カスタマーサクセスの導入を検討している経営・管理層が挙げた最大の障壁は「人材・組織体制が不十分／スキルのある人材がいない」で39.6%に達しています。次点の「取り組みの始め方が不明／手順書がない」（26.4%）を大きく上回っており、人材確保が最優先課題として認識されている状況です（バーチャレクス・コンサルティング「2025年カスタマーサクセス日本市場動向&実態調査」）。

ここに、SaaS の導入社数が増えるにつれて技術的な問い合わせが増加するという事情が重なります。開発チームが顧客対応に引きずられて開発速度が落ちる、という問題を抱えた企業が、その負荷を外部に切り出す。これが CSE の業務委託枠が生まれる典型的な流れです。

つまり発注企業が買っているのは営業力ではなく、「開発チームへのエスカレーション負荷を減らせる技術力」です。この点を理解しておくと、案件に応募する際の訴求ポイントが変わります。発注側がどんな観点で候補者を評価しているかは、発注企業向けに整理したカスタマーサクセスエンジニアの外部委託にまとめてあります。応募前に発注側の判断基準を把握しておくと、自分の実績のどこを前面に出すべきかが見えやすくなります。

カスタマーサクセスエンジニアの単価はどう決まるか

ここが最も判断に迷う部分です。求人媒体の数字だけを見て「単価が下がる」と結論づける前に、そのレンジが何を含んでいるのかを分解しておきます。

掲載単価レンジが広い理由（非技術CSと技術職CSEの混在）

フリーランス向けのマッチングサービスでカスタマーサクセス案件を検索すると、月額20万円台から80万円台まで、非常に広いレンジが並びます（各社の案件一覧の掲載条件より、2026年8月時点）。この幅の広さは「同じ職種で評価が割れている」ことを意味していません。そもそも異なる2つの職種が同一カテゴリに混在していることが原因です。

分かりやすい傍証があります。Workship ENTERPRISE の解説では、カスタマーサクセスを業務委託する際の報酬目安として、通常業務であれば年収300万〜600万円・時給1,600円〜2,000円、リーダーや運用全体を委託する場合は年収800万円以上・時給4,000円以上という2つの水準が並記されています（Workship ENTERPRISE）。同じ「カスタマーサクセスの業務委託」でありながら、時給ベースで2倍以上の開きがあるということです。

この差を生んでいるのは、担当者の優劣ではなく任される範囲と代替可能性です。マニュアル化された問い合わせ対応は代替可能性が高く、単価は下限に張り付きます。一方、連携設計やデータ移行、運用設計まで踏み込む役割は代替可能性が低く、上限側に位置します。エンジニアが検討すべきなのは後者だけです。

案件一覧の側を見ると、Workship のカスタマーサクセス案件は68件（2026年8月時点）が掲載されており、「月80h程度／一部リモート可／副業可」「フルリモート」といった稼働条件の案件が並んでいます（Workship）。件数としては開発案件ほど潤沢ではないため、媒体の掲載だけを当てにせず、後述する複数チャネルの併用が現実的です。

正社員CSEの年収水準とフリーランス単価の比較

フリーランス単価の妥当性を測るには、正社員の年収水準を基準線として持っておくと考えやすくなります。

求人ボックスの給料ナビによれば、近接職種であるカスタマーエンジニアの平均年収は456万円、ボリュームゾーンは388万〜476万円、全体の給与幅は388万〜1,087万円となっています（2026年7月21日時点、求人ボックス 給料ナビ）。上限が1,000万円を超えている点が重要で、この職種は「経験と担当領域次第で大きく伸びる」構造を持っています。

そのうえで、フリーランス側の相場と並べてみます。エン株式会社が運営する「フリーランススタート」の定点調査では、2025年12月度のフリーランスエンジニアの月額平均単価は78.3万円と報告されています。注目したいのは職種別の内訳で、CRE（Customer Reliability Engineering、顧客の信頼性に責任を持つエンジニア職）の平均単価は90.9万円と、全体平均を12万円以上上回っています（エン株式会社『フリーランススタート』定点調査レポート）。

CRE は CSE と同一の職種ではありませんが、「顧客接点を持ちながら技術で価値を出す」という点で構造がよく似ています。その職種の単価が全体平均を上回っているという事実は、「顧客対応に寄せると単価が下がる」という前提が少なくとも一律には成り立たないことを示しています。単価を下げるのは顧客接点そのものではなく、技術要件が抜け落ちたスコープです。

単価を左右する4要素

自分がどのレンジに位置づくかを推定するには、次の4要素で分解すると精度が上がります。

このうちエンジニアが最も改善しやすいのは4番目の成果指標です。技術的複雑度や商流は案件選びの段階で決まってしまいますが、成果指標は自分で定義して提示できます。「導入初月の技術問い合わせ件数を◯件から◯件に減らした」「開発チームへのエスカレーション率を◯%削減した」という形に翻訳できると、単価交渉の土台がまったく変わります。

稼働形態については補足が必要です。週2〜3日の低稼働案件は月額の総額こそ小さくなりますが、日額換算では上がりやすい傾向があります。発注側から見ると、短時間で成果を出せる人材にはプレミアムを払う合理性があるためです。月額の数字だけで案件を比較すると、この構造を見落とします。

隣接職種（プリセールスエンジニア）との単価比較

顧客接点を持つエンジニア職には、CSE のほかにプリセールスエンジニア（セールスエンジニア）があります。両者は「技術を使って顧客の意思決定を助ける」という点で共通していますが、関与するフェーズが契約前か契約後かで異なります。

単価構造の面では、プリセールスは受注への貢献が金額で可視化しやすいぶん、成果連動の設計が入りやすいという特徴があります。一方 CSE は継続利用や解約率への貢献が主戦場となるため、月額固定の準委任契約に落ち着きやすい傾向があります。安定性を重視するなら CSE、上振れを取りにいくならプリセールス、という整理が一つの目安になります。

案件の出やすさや具体的な単価レンジは職種ごとに異なるため、比較検討の際はプリセールスエンジニアのフリーランス案件と単価もあわせて確認しておくと、自分の適性と単価の兼ね合いを判断しやすくなります。どちらか一方に絞る必要はなく、両方の案件に応募して反応を見る進め方も現実的です。

フリーランスのカスタマーサクセスエンジニア案件の探し方と契約形態

単価の構造が見えたところで、実際にどこで案件を探し、どんな契約形態を選ぶかを整理します。ここは競合の職種解説記事がほとんど触れていない領域です。

案件獲得チャネル4種の比較

CSE 案件は開発案件と比べて絶対数が少ないため、単一チャネルに依存すると機会を取り逃します。4つのチャネルを性質の違いで使い分けるのが実務的です。

このうち見落とされやすいのが3番目の「既存常駐先での役割切り出し」です。多くの現場では、開発メンバーが顧客対応を片手間で引き受けている状態が常態化しています。そこを「技術支援の役割として明示的に切り出しませんか」と提案すれば、新しい案件を探さずに CSE としての実績を作れます。しかも既存の契約関係があるぶん、提案が通る確率は外部応募より高くなります。

契約形態の使い分け（準委任・成果報酬・件数課金）とスコープ設定の注意点

CSE 案件では、開発案件では馴染みの薄い契約形態が提示されることがあります。それぞれのリスク構造を把握しておかないと、稼働に見合わない報酬を受け入れてしまいます。

準委任（月額固定）は、稼働時間に対して報酬が発生する形式で、CSE 案件では最も一般的です。収入が読めるという利点がある一方、「顧客対応なので稼働が読めない」という理由でスコープが曖昧なまま契約されやすいという落とし穴があります。契約時に、対応対象となる顧客数の上限、対応時間帯、緊急対応の扱い、稼働時間の上限超過時の精算方法を必ず明文化してください。

成果報酬型は、契約更新やアップセルの成立に連動して報酬が決まる形式です。上振れの可能性はありますが、フリーランスの立場では成果に影響する変数（プロダクトの品質、営業側の動き、顧客の予算）の大半をコントロールできません。技術支援の巧拙だけで成果が決まらない構造である以上、成果報酬を単独で受けるのは不利になりやすい設計です。受けるとしても、固定部分を確保したうえでの上乗せとして扱うのが安全です。

件数課金型は、問い合わせ対応やオンボーディング支援を件数単位で課金する形式です。稼働と報酬が連動するため一見公平ですが、1件あたりの難易度がばらつく点が問題になります。5分で終わる設定確認と、3日かかる連携デバッグが同じ「1件」として扱われると、実質時給は大きく崩れます。件数課金を受ける場合は、難易度による区分（一次対応／調査対応／実装支援など）を設けて単価を分けることを前提に交渉してください。

いずれの形態でも共通する注意点は、対応範囲の「外側」を書いておくことです。「顧客側システムの改修は含まない」「営業同行は別途見積もり」といった除外事項を契約書に残しておくと、後からのスコープ拡大を防げます。

副業・週2稼働から始める場合の稼働設計

冒頭で挙げた「不可逆な選択になるのではないか」という不安に対する、最も実務的な回答がここです。CSE への軸足移動は、開発案件を手放さずに始められます。

具体的には、次のような併走パターンが取りやすい設計です。

• 週3開発＋週2 CSE：現在の開発案件を週3に縮小し、空いた2日で CSE 案件を受ける。開発の収入基盤を残したまま検証でき、合わないと判断すれば週5開発に戻せます。単価面でも、低稼働案件の日額が上がりやすい構造を活かせます。
• 週5開発＋スポット CSE：本業の稼働は維持し、月20〜40時間程度のスポット案件で CSE 業務を経験する。収入への影響がほぼなく、実績だけを積み上げられる形です。
• 既存常駐先内での役割再配分：契約先を変えずに、稼働時間の一部を技術支援業務に割り当てる。契約変更の手間が小さく、最も摩擦が少ない選択肢です。

いずれのパターンも、「開発案件を完全に手放してから CSE を探す」という順序を取らない点が共通しています。この順序を守るかどうかが、リスクの大きさを決定的に変えます。マッチングサービスの CSE 案件にフルリモート・週2稼働のものが一定数あることは、この併走設計が現実的であることを裏づけています。

開発案件からカスタマーサクセスエンジニアへ軸足を移す手順（未経験からの入り方）

「CSE の職務経歴がないから応募しても通らない」と考えて止まってしまうケースは多いのですが、この障壁は棚卸しの仕方で大きく下がります。

求められるスキルと開発経験の棚卸し（何がそのまま転用できるか）

カスタマーサクセスエンジニアに求められるスキルを分解し、開発経験のどこが直接転用できるかを対応づけると次のようになります。

見てのとおり、必要なスキルの土台はほぼ既存の開発経験でまかなえます。追加で必要なのは技術力ではなく、視点の置き換えです。「仕様を満たすか」ではなく「顧客が使いこなせているか」を基準に考える習慣が身につけば、CSE としての立ち上がりは速くなります。

未経験から初案件を取る4ステップ

実績ゼロの状態から初案件までを、4つのステップに分けて整理します。

ステップ1：現在の案件から顧客接点業務を棚卸しする

過去1年を振り返り、「顧客企業とのやり取りが発生した業務」をすべて書き出します。API 仕様の説明、障害原因の報告、データ移行の相談、導入時の設定支援など、開発業務の一部として扱っていたものが該当します。多くの場合、自覚しているより多くの CSE 的業務をすでに経験しています。

ステップ2：現場で技術支援の役割を明示的に切り出す

棚卸しした業務を、現在の常駐先やクライアントに対して「この部分を役割として切り出しませんか」と提案します。開発チームの顧客対応負荷が高い現場ほど、この提案は歓迎されやすくなります。ここで役割が明示されれば、その時点から「CSE としての稼働実績」が発生します。新しい案件を探すより圧倒的に早く、かつリスクがありません。

ステップ3：可視化できる成果物を残す

役割が決まったら、成果物を形として残します。導入手順書、トラブルシューティングガイド、連携実装のサンプルコード、FAQ の技術セクションなど、応募時に「こういうものを作りました」と示せるものが有効です。守秘義務の関係で現物を出せない場合は、目次構成と分量、想定読者を説明できるようにしておけば十分に材料になります。

ステップ4：単価根拠として提示できる指標に翻訳する

最後に、実績を数値に翻訳します。ここを飛ばすと、媒体の掲載レンジに引きずられた値付けしかできなくなります。翻訳の具体的な手順は次で扱います。

単価根拠として提示できる実績の作り方

単価交渉の場で効くのは、「何をやったか」ではなく「相手のどのコストをどれだけ減らしたか」です。前述の単価4要素のうち、自分で改善できるのは成果指標だけでした。その成果指標を作る作業がここにあたります。

翻訳の型はシンプルで、「対象 × 変化量 × 期間」の3点セットにまとめます。

• 「新規導入顧客20社について、初月の技術問い合わせ件数を平均12件から5件に削減（6か月間）」
• 「開発チームへのエスカレーション率を月間40%から15%に低減（4か月間）」
• 「データ移行の標準手順を整備し、1社あたりの導入リードタイムを3週間から10日に短縮」

数値を取っていなかった場合でも、着手前後の状況を関係者に確認すれば概算は作れます。厳密な統計である必要はなく、「この人を入れると開発チームの手が空く」と発注側が納得できる粒度で十分です。

なお、こうした実績は CSE 案件に限らず、開発案件の単価交渉でも使えます。顧客接点の業務を数値化しておくこと自体が、どちらの方向にも効く投資になります。

カスタマーサクセスエンジニアのキャリアパスと将来性

軸足を移す判断で最後に残るのが、「3〜5年後に自分の市場価値がどうなっているか」という問いです。出口が見えないままでは、目先の単価が維持できても踏み切れません。

CSE経験から広がる3つのキャリアパス

CSE として経験を積んだ先には、主に3つの方向があります。

ソリューションアーキテクト方向：顧客ごとの技術要件を汲み取り、最適な構成を設計する役割です。CSE で蓄積される「顧客の業務文脈と技術構成を結びつける力」がそのまま評価対象になります。クラウドベンダーや大規模 SaaS の案件では、この役割が独立した高単価ポジションとして存在します。

プロダクト側（PdM・PM）方向：顧客の利用実態を最も近い距離で見ている立場は、プロダクトの意思決定において希少です。「どの機能が使われていないか」「どこで離脱が起きるか」を一次情報として持っていることが、PdM としての強みになります。開発経験と顧客接点の両方を持つ人材は、この方向で特に評価されやすい傾向があります。

導入支援の独立コンサル方向：特定領域（データ基盤、MA ツール、ERP など）の導入支援に特化し、複数社に対して技術支援を提供する形です。案件単価は高くなりますが、集客を自力で行う必要があるため、実績と発信の蓄積が前提になります。

いずれの方向も、共通して評価されるのは「技術が分かったうえで顧客の言葉を扱える」という希少性です。開発一本のキャリアでは獲得しにくい部分でもあります。

開発スキルは陳腐化するのか（スコープ設計と併走による維持）

「顧客対応に寄せると実装から離れて、開発案件に戻れなくなるのではないか」という懸念は、条件付きで正しく、条件付きで誤りです。

正しい部分は、スコープ設計を誤ると実装から離れるという点です。問い合わせの一次対応と社内エスカレーションだけを担う案件を選ぶと、コードを書く機会は確実に減ります。この形が数年続けば、開発案件への復帰は難しくなります。

一方で誤りなのは、それが CSE という職種の必然だと考える点です。連携実装の支援、移行スクリプトの作成、検証環境の構築、ログ分析基盤の整備といった業務が含まれる案件を選べば、実装機会は維持されます。案件選定の段階で「自分がコードを書く場面はどこか」を確認することが、そのまま陳腐化対策になります。

さらに確実なのは、前述の併走パターンを継続することです。週3で開発案件を持ち続けていれば、そもそも実装から離れる状況が発生しません。CSE への移行を「全面的な転向」ではなく「ポートフォリオへの追加」として捉えれば、可逆性は最初から確保されています。

将来性と長期稼働の持続性（開発一本との比較）

将来性の議論では、需要の伸びと同時に「自分が何歳まで稼働できるか」という観点を持っておく必要があります。

需要面では、前述のとおりカスタマーサクセス人材の不足が最大の導入障壁として挙がっている状況が続いています。SaaS の導入社数が増えるほど技術的な問い合わせは増え、開発チームだけでは吸収しきれなくなります。この構造がある限り、CSE の需要が急に消えることは考えにくいでしょう。

持続性の面では、開発一本との違いがより明確になります。実装速度や新技術のキャッチアップ速度が競争軸になる領域では、年齢とともに相対的な優位を保ちにくくなる側面があります。一方、CSE で問われるのは顧客の業務理解、過去の障害パターンの引き出し、関係者の調整力といった、経験の蓄積が有利に働く要素です。40代・50代でも稼働を続けやすい職種であるという見方ができます。

もっとも、これは「CSE に移れば安泰」という話ではありません。開発一本でのキャリア継続そのものにも、単価維持と稼働継続の戦略があります。年齢とキャリアの持続性という論点を先に整理しておきたい場合は、フリーランスエンジニアのキャリア生存戦略を確認したうえで本記事の内容と突き合わせると、判断の前提が揃います。

軸足を移す前に確認したい判断チェックリスト

最後に、ここまでの内容を自分に当てはめて判断するためのチェックリストとしてまとめます。

向いている人・避けたほうがよいケース

向いている条件

• 顧客との会話が苦痛ではなく、むしろ「何に困っているか」を聞き出すのが得意だと感じる
• 設計書や手順書を書くことに抵抗がなく、人に読ませる文章を書いた経験がある
• 1つのプロダクトを深く理解して長く付き合う働き方に魅力を感じる
• 実装だけでなく、運用・保守・障害対応の経験がある
• 現在の案件で、すでに顧客対応を部分的に任されている

5項目のうち3つ以上が当てはまる場合は、少なくとも試してみる価値がある状態です。特に最後の項目に該当するなら、既存の現場で役割を切り出す道筋がすでに開けています。

避けたほうがよいケース

• スコープを曖昧にしたまま成果報酬型を受ける：成果に影響する変数の大半をコントロールできない立場で、報酬だけを成果に連動させるのは不利な設計です。固定部分を確保してください。
• 単価根拠を持たずに媒体のレンジで交渉する：掲載レンジには非技術 CS の水準が混ざっています。自分の成果指標を提示しないまま交渉に入ると、下限側に引きずられます。
• 開発案件を完全に手放してから移行する：合わなかった場合の退路がなくなります。併走から始めれば、この判断は可逆になります。
• 実装機会がゼロの案件を初回に選ぶ：一次対応のみの案件は入りやすい反面、実績としての説明力が弱く、開発スキルの維持にもつながりません。

今週から着手できる最初の一手

最後に、着手すべきことを1つに絞ります。過去1年の案件で自分が担当した顧客接点業務を、すべて書き出してください。

API 仕様の説明をしたやり取り、障害の原因を顧客に報告した場面、データ移行の相談に乗った件、導入時の設定を代行した作業。開発業務の一部として処理してきたこれらを一覧にすると、多くの場合「思っていたより CSE 的な業務をしている」ことが見えてきます。

この一覧ができれば、次の動きは自動的に決まります。件数が十分にあるなら、現在の常駐先に対して役割の切り出しを提案する。少ないなら、マッチングサービスで週2稼働の案件を1件だけ試してみる。いずれにせよ、開発案件を手放す必要はありません。

判断に必要なのは決意ではなく材料です。棚卸しは1〜2時間で終わりますし、それ自体が単価交渉の材料にもなります。「単価が下がるかもしれない」という漠然とした不安は、自分の実績を数値に翻訳した瞬間から、具体的な交渉の話に変わります。

カスタマーサクセスエンジニアの案件や、開発案件と併走できる週2〜3日稼働の案件をお探しの場合は、Workee で条件を指定して案件を検索できます。稼働日数・リモート可否・単価条件から、いまの案件を手放さずに試せる範囲の案件を確認してみてください。

Workee で案件を探す