Apex案件の単価は何で決まるのか｜案件票の要件欄から読む高単価の条件

「Apexって単価いいらしいけど、実際いくらなの？」——Salesforce案件に興味を持ち始めた人からよく受ける質問です。先に結論を書きます。Apex単体の相場を数字で覚えても、単価は上がりません。効くのは「案件票の要件欄に何が書いてあるか」を読めることと、その要件に自分の経歴を接続できることのほう。私も本業でApexとLWCを書きながら副業で案件情報を眺めている当事者なので、相場表よりこの読み方を先に渡します。

そもそもApex案件の単価は何で決まるのか

求人媒体やエージェントの公開情報を見る限り、Salesforce系の業務委託は中〜高単価が多く、書ける人が需要に足りていない領域なのは確かです。ただし同じ「Apex」というキーワードでも、母集団はまるで違います。クラウドソーシングには「Salesforceの設定を手伝ってほしい」レベルの依頼が混ざり、エージェント経由には基幹に絡む設計案件がある。同じ単語で検索しているのに、行き着く先が別物なんです。

単価のブレを生むのは、地域でも経験年数でもありません。圧倒的にプロジェクトの規模と、任される範囲です。金融や大手製造の基幹に絡むSalesforce導入は跳ねる。逆に中小のSFA（営業支援システム）を軽く直す案件は伸びにくい。この差は、案件票の書かれ方を見れば手前で読めます。

案件票の要件欄には実際に何と書かれているか

ここが実務者しか知らない部分だと思います。高単価の案件票は「Salesforce経験3年以上」のような年数だけでは書かれていません。発注側が本当に見ているのは、システムの複雑さと、そこで事故を起こさないと信じられる根拠です。要件欄の粒度に、単価のシグナルが出ます。

覚えておくべきは、ユーザー数・連携本数・非同期設計という三つの言葉です。これが書いてあれば規模の大きい環境で、単価も上振れしやすい。逆に「設定変更」「サポート」中心なら、額面は控えめだと見ておけば、そう外しません。

未経験からApexを書けるようになる学習順序

Apexは構文的にはJavaにかなり近い言語です。Java経験者は有利で、コレクション操作あたりは見た瞬間に入れます。未経験の人が詰まるのはそこではなく、Salesforce特有の制約——いわゆるガバナ制限のほう。1トランザクションで実行できるSOQLの回数上限などが決まっていて、ここを知らずにループの中でクエリを回すと本番でだいたい落ちます。

学習の入口は公式のTrailheadで十分です。無料で、開発用の環境まで用意される。Apex Basicsから始めて、トリガー、テストクラス、非同期処理まで一通り触ると実務の会話についていける土台ができます。

周辺技術は欲張らず順番をつけましょう。まずApexとSOQL、次にLWC（画面のフロント側）、そしてREST APIによる外部連携、余裕が出たらBatch処理。この順で押さえると、さっきの要件欄と噛み合います。

正直に言うと、完全未経験からいきなりフリー案件を取るのは相当ハードです。本番デプロイにはテストカバレッジ75%が必要というルールひとつ取っても、実務を通さないと肌感覚がつかめない。私の見る限り、まずは正社員かSIerでSalesforce案件に潜り込んで1〜2年の実務を作ってから外に出るのが、結局は近道です。

資格は単価を上げるのか

「Platform Developer Iを取れば単価上がりますか」もよく聞かれます。答えは「入口では効くが、決め手にはならない」。

資格が効くのは実務経験が浅いフェーズです。職務経歴だけでは判断されづらいジュニア層にとって、認定は「最低限の共通言語は持っている」という証明になる。エージェント経由の案件では、保有を応募条件に挙げているものもあり、そこは通過率に直結します。

ただし中級以上で面談が聞いてくるのは、資格ではなく実装の話です。資格は持っていて当たり前、その先の経験で単価が決まる。だから私は資格を「費用がいくらか」ではなく「案件票で何が問われているか」の軸で見ることをすすめます。要件欄が連携やBatchを問うているなら、資格より、その実装を口頭で説明できるかのほうが評価される。受験料や有効期限などの制度面は変わりやすいので、受けると決めた段階でSalesforce公式の最新情報を確認してください。

単価が跳ねる分岐点は「開発力」ではない

ここが一番の本音です。月額が上のレンジに乗る案件の共通点は、実装が速いことではありません。要件整理と折衝を含めて、デリバリーを丸ごと任せられるか。単なる実装者ではなく、「どう作るか」を決めて着地まで持っていける人に、高い金額がつきます。

理由は発注側のリスクで説明がつきます。要件が曖昧なまま渡しても、実装者は言われた通りに作って手が止まる。その手戻りとスケジュール遅延は、そのまま発注側の損失です。だから彼らは、要件の穴を自分で見つけて埋め、ステークホルダーと話を詰めてくれる人に金を払う。コードの速さではなく、プロジェクトが止まらない安心を買っているわけです。

いきなり大規模は無理でも、段階は踏めます。中規模で連携を1本担当する→設計レビューに入る→サブの技術リードを任される、という順で経験の粒を大きくしていく。私自身も中規模ユーザー環境で連携まわりを積み上げてきたクチで、この順番が職務経歴の説得力になっていると感じます。交渉の準備の型は単価交渉の場で足元を見られないための準備にまとめたので、テーブルにつく前に読んでおくと落ち着いて話せます。

Apex案件で実際に詰まるところと、面談での言語化

実務でApexが詰まる場所は、だいたい三つに集約されます。ここを経験して、言葉にできるかどうかが面談の分かれ目です。

• ガバナ制限：ループの中でSOQLやDMLを回して制限に当たる、というのが典型です。バルク化（一括処理）でどう回避したかを具体的に言えるかが問われます。
• テストデータ：テストクラスは基本的に本番データを参照できず、@testSetupで自分でデータを作る必要があります。前提条件が複雑なオブジェクトほどここで沼にはまる。
• 非同期処理の設計：Batch・Queueable・Futureの使い分け、非同期の中でのガバナ制限、チェーンの上限。大量データを安全に捌く設計は、まさに単価が乗る領域です。

面談で評価されるのは、「ガバナ制限を回避しました」という結論ではありません。「ループ内クエリでSOQL上限に当たったので、対象レコードをMapに集めて一括処理に組み替えた」まで、判断の過程を再現できることです。派手な新技術より、事故りやすい領域を安全に捌いた経験のほうが、金になります。逆に言えば、この三つを口で説明できないと、要件欄の高い案件には手が届きません。

副業でApex案件を選ぶときの私の基準

最後に、落とし穴も置いておきます。相場より明らかに低いのに難易度だけ高い「勉強になります」案件は、次の交渉の基準額を下げる副作用がある。「設定中心」と書きつつ実態はゴリゴリのApex開発、という案件もたまにあるので、作業範囲は面談で具体的に確認するのが唯一の防御です。

そのうえで、副業でApex案件を取るなら、私は「本業のスキルと重なるか」を最優先にしています。本業で連携を扱っているなら副業も連携寄りを選ぶ。学習コストが二重にかからず、両方の経験が同じ経歴書に載る。時間が有限なITワーカーにとって、これがいちばん効率のいい積み上げ方だと思っています。単価表を眺める時間があるなら、案件票の要件欄を三つの言葉で読み直したほうが、たぶん早い。