SES契約の費用相場は？エンジニア単価の目安と予算計画の立て方

統計や公開レポートが示すのは、外部開発リソースへの依存が構造的に高まっている現実です¹。経済産業省の試算では2030年に最大79万人のIT人材が不足し²、DXの遅れによる年間最大12兆円規模の経済損失も指摘されています³。内製だけにこだわる戦い方は現実的ではなく、SES（準委任＝時間と成果に応じて対価を支払う契約形態）を活用した柔軟な体制設計が、プロダクト成長のスピードと財務の安定を両立させる鍵になりつつあります。公開されている案件情報やIR、実務でのやり取りから見える範囲では、Web系の中堅〜上級エンジニアで月額単価の中央値が概ね70〜90万円、先端領域では120万円超と語られることが多いのが実情です。ただし、相場は役割・地域・契約条件で大きく振れます。見えている価格に飛びつくのではなく、価格の内訳と変動要因を具体的に把握することが、結果としてコストを抑え、デリバリー品質を守る最短路になります。加えて、こうした構造的課題は経済産業省の直近の報告書でも繰り返し指摘されており⁴、個社の運用設計だけでなく調達ポートフォリオ全体の見直しが重要です。

SES相場の「現実」と単価を決める変数

まず、相場をレンジで捉える視点が有効です。関東圏の常駐・フルタイムを前提にすると、サーバーサイドやフロントエンドの中堅クラスで月70〜90万円がボリュームゾーンに収まります。テックリードやアーキテクト、セキュリティやSRE（Site Reliability Engineering＝信頼性エンジニアリング）、データ基盤などの希少スキルは100〜150万円の提示が増え、日英バイリンガルや厳格なセキュリティクリアランスが求められる案件では上振れが起きやすくなります。一方で、ジュニア〜ミドル初級は50〜65万円の提示も珍しくありません。地方やリモート主体、あるいはニアショア・オフショアを組み合わせると、月35〜80万円まで下がるケースも見られますが、コミュニケーションコストや時差、品質管理の仕組みを設計しなければ、結局のところ総コストは想定より膨らむ可能性があるため、表面単価だけでの比較は危険です。

価格を押し上げる主要因は、希少スキル、期間の短さ、商流の深さ（仲介の段数）、オンサイト比率、そして供給逼迫のタイミングです。商流は特に見落とされがちで、1層深くなるごとに5〜15%程度のマージンが積み上がる構造が一般的です。直契約に近づくほど単価は下がりますが、リクルーティング力やバックフィル体制、トラブル対応の強さなど、値引きでは換えられない価値もあるため、価格だけで短絡的に商流を削ると、炎上時の回復力を失います。期間は3カ月更新の短期よりも6〜12カ月の確約の方が値決めは安定しやすく、発注側の予見可能性が高いほど、ベンダーもリスクを単価に載せにくくなります。

最後に、役割定義と期待成果の粒度が単価に直結します。単に「バックエンドできる人」では市場の一般価格で落ち着きますが、「TypeScript＋Node.jsでGraphQLのスキーマ設計から運用モニタリングまで」「KubernetesでHPA（自動スケーリング）とPodDisruptionBudget（計画停止時の許容中断数）を含むSLO（サービス目標）運用」など、成果の輪郭が明確で現場の生産性に直結する要件は、単価の交渉余地を広げます。逆に言えば、曖昧な要件はベンダーのリスク見積もりを厚くし、相場より高い提示を招きやすいのです。

見積りで確認すべき「隠れたコスト」

見積書にないが確実に発生するコストが、総額のブレを生みます。アクセス権管理やアカウント発行、セキュリティ研修、端末貸与やVDI費用、コミュニケーションツールの有償ライセンスなどは、1人あたり月1〜2万円規模で積み上がります。さらに、オンボーディングとドメイン知識のキャッチアップには2〜4週間の生産性ロスが発生し、複数ベンダー混在ではレビューと同期のための調整時間が15%前後増えることも珍しくありません。中長期のスプリント計画には、こうした組織的なコーディネーション・コストを最初から織り込むべきです。

精算幅・稼働率・契約条件が総額をどう変えるか

SES契約では、単価そのものと同等かそれ以上に、精算幅（下限・上限時間）と稼働率（実働の割合）の設計が総額に効いてきます。代表的な精算幅は140〜180時間や150〜190時間で、実績時間が範囲内なら月額は固定、下限を下回れば控除、上限を超えれば超過で調整されます。時間単価は、提示月額を基準時間（160時間など）で割り戻す形で定義されます。したがって、稼働の波があるプロダクト初期や要件調整フェーズでは、広めの精算幅やハーフ稼働の選択肢を事前に用意し、控除の連発で関係性が悪化しないように運用設計するのが得策です。

支払いサイト（締めから支払いまでの期間）や途中解約条項も、キャッシュフローとリスクに直結します。サイトが月末締め翌々月末支払いだと、キャッシュアウトのタイミングが遅れる分だけベンダー側の資金繰りリスクが増し、単価に上乗せされることがあります。発注側がサイト短縮や分割検収を用意できるなら、価格交渉で優位に立てます。また、バックフィルのSLA（欠員時の補充期限）や交代時のトランジション期間の無償対応の範囲、祝日や有給相当の取り扱い、在宅手当や交通費の扱いは、短期的には誤差でも年間では大きな差になります。これらは契約書の本文だけでなく、業務委託個別契約や作業指示書のレベルで明記し、現場運用に落とし込むことが重要です。

精算式を言語化する：式を理解すればブレは減る

計算はシンプルです。月額単価をU、基準時間をB、実績時間をHとすると、時間単価はU/Bで表せます。Hが下限Lを下回った場合の控除額は(L−H)×(U/B)、Hが上限Uppを超えた場合の超過額は(H−Upp)×(U/B)です。実務では、下限・上限のどちらで調整するのか、控除や超過に係数をかけるのか（例えば0.9や1.25とするか）といった条件も登場します。数式を文字で合意しておけば、月次の精算時に解釈の揺らぎが生じにくく、請求・支払のリードタイム短縮にもつながります。

予算計画の立て方：モデル化とシミュレーション

実務で役立つのは、人数と期間だけの粗い見積りではなく、稼働率、精算幅、商流、オンボーディング損失、ツール費用、社内の管理工数まで含めた「月次ランレート（毎月の燃焼コスト）」のモデルです。たとえば、サーバーサイド3名、フロント1名、QA/SET1名の5名体制を6カ月で組むケースを考えます。エンジニアの月額単価は90万円、基準時間160時間、精算幅140〜180時間、想定稼働実績はプロダクト移行期で平均136時間（85%）と置きます。時間単価は90万円を160で割って約5,625円です。実績136時間は下限140時間を4時間下回るため、1名あたり約22,500円の控除が発生し、5名で月11万2,500円の減額になります。名目の月額合計は90万円×5名で450万円ですが、控除後の支払見込みは約438万7,500円に調整されます。

ここに、社内のプロダクトマネジメント、コードレビュー、セキュリティチェック、ベンダーコーディネーションといった間接工数を15%相当と見積もると、運用に必要な社内人的コストが月65万前後上乗せされます。さらに、SlackやIssueトラッカー、テスト管理、監視の各ツールの有償ライセンスが1人あたり月1.5万円だと、5名で7万5,000円、VDIや端末貸与が必要なら初月に初期費用が加わります。この前提では、月次の「真の総コスト」はおおむね512万円前後になります。これを6カ月回すと、3,000万円強が初期予算のガイドになります。もちろん、スプリントが安定し実績時間が150〜160時間に戻れば控除は消え、同時に成果物のスループットも上がるため、単価は変えずに「コスト当たりの価値」は改善します。

オンボーディングの影響も明示しておきます。初月はドメイン知識と環境構築で実効稼働が70%まで落ちることがあり、上記と同じ精算幅なら控除で支払額はやや減りますが、ロードマップ上の遅延リスクは上がります。したがって、初月にクリティカルな納期を置かない計画、またはプロトタイプやスパイク（技術検証）に初月をあてる設計が安全です。離脱やバックフィルのリスクには、0.5人月のバッファ（いわゆるベンチ）を持つか、複数ベンダー構成で相互に補完できるようにロールの重なりを設計しておくと、予算と納期のブレを同時に抑えられます。

社内採用との比較も、数字で行うと意思決定が速くなります。仮にフルタイム採用の総人件費が年900万円、採用コストが100万円、入社までのリードタイムが3カ月とすると、初年度のキャッシュは1,000万円超で、デリバリー開始は最短でも四半期先になります。対して、SESなら1〜4週でアサインし、6カ月で3,000万円強のキャッシュアウトですが、価値の早期創出とピーク時の厚みづけという点で優位です。中長期で常時必要なコア領域は採用、ピークや専門性の高い領域はSESというポートフォリオが、コストとスピードの最適点を作ります。この観点を検討すると整理が進みます。

レートカードと変更管理：予算を守る運用の型

月次の予算統制には、レートカードの整備が効きます。役割ごとに単価レンジと精算幅、稼働の最小単位（例：0.5人月）、出張・深夜・休日の係数、交代時のトランジション扱い、セキュリティ要件の有無などを一覧化し、発注側・受注側の双方で参照する共通基盤にします。変更要求はJIRAやServiceNowのチケットで起票し、承認ルールを決め、毎月の請求書と突合します。月中の要求が翌月反映になる運用だと、予算実績差異の説明が容易になり、経営会議での説明コストも下がります。テンプレートは簡単なスプレッドシートでよく、共有しておくと、事業部横断でブレが減ります。

交渉とリスク管理：価格だけでなく再現性を買う

交渉の肝は、単価の絶対値よりも総所有コスト（TCO＝Total Cost of Ownership）と速度の再現性です。商流を浅くする、複数名の同時発注でボリュームディスカウントを得る、サイト短縮や長期コミットを交渉材料にする、といった古典的な手法は今も有効です。ただし、過度に単価だけを削ると、良い人から離れていきます。クオリティを守るためには、候補者の過去の成果物レビューや、1〜2週間のトライアルスプリントでの合意ベロシティ、交代時のSLA、障害時のエスカレーションパスまで合意し、運用で品質を担保します。結果として炎上を避けられれば、総コストは安くなります。

法務面では、知的財産権の帰属、成果物のライセンス、機密保持、個人情報・機微情報の取り扱い、監査対応の権限を明文化し、SOCやISMSの証憑の提供範囲を合意します。セキュリティが厳しい業界では、開発環境へのアクセス方法やログの保存、ゼロトラスト前提のネットワーク設計まで仕様に落とす必要があります。これらは見積りの前提に強く影響するため、早い段階で開示し、価格に織り込んだうえで比較するのがフェアです。運用開始後は、月次のベロシティと欠陥率、平均回復時間（MTTR）などのKPIを定義し、レトロスペクティブでボトルネックを潰し込みます。KPIが改善すれば、同じ単価でも「価値/円」は上がっていきます。

最後に、ベンダーの選定そのものも再現可能なプロセスにしましょう。評価軸をスキル適合、文化適合、供給安定性、価格、セキュリティの5観点で点数化し、配点の重みを事業のフェーズに合わせて調整します。初期は速度に重みを、成長期は品質とセキュリティに重みを置くのが一般的です。要は「良いベンダーに偶然出会う」のではなく、「良い選定がデフォルトになる」仕組みを作ることが、相場に翻弄されない最短ルートです。

まとめ：相場に振り回される前に、式を自分ごと化する

相場の数字はあくまで出発点であり、あなたのプロダクト、チーム、ガバナンスの設計次第で、同じ単価でも成果は大きく変わります。精算幅や稼働率、商流、オンボーディング、ツール費用、社内調整という変数を、まずは一枚のシートに落とし、6カ月のランレートと3つのシナリオを作ってみてください。式で語れるようになった瞬間に、単価交渉の主導権は戻ってきますし、経営への説明は簡潔になり、現場の納得感も高まります。次のスプリント計画に合わせて、今日中にレートカードの初版を作り、関係者でレビューするところから始めてみませんか。必要に応じて、準委任と請負の使い分けやベンダー選定のフレーム、計算テンプレートの整備を、関連の解説記事と併せて一気通貫で整えていきましょう。

参考文献

厚生労働省. 令和4年度労働者派遣事業報告書（集計結果概要）. https://www.mhlw.go.jp/stf/houdou/0000199493_00024.html
NTTコミュニケーションズ BizON. 2030年にIT人材は79万人不足する？ https://www.ntt.com/bizon/d/00491.html
財務省. 広報誌ファイナンス 2023年8月号特集「DX白書2023」引用. https://www.mof.go.jp/public_relations/finance/denshi/202308/pageindices/index50.html
経済産業省. デジタル時代の人材政策に関する検討会報告書 2024. https://www.meti.go.jp/shingikai/mono_info_service/digital_jinzai/20240628_report.html