Article

人件費を最適化!SES活用でコストを抑える工夫とは

高田晃太郎
人件費を最適化!SES活用でコストを抑える工夫とは

経済産業省の推計では、2030年に国内IT人材は最大約79万人不足する可能性があるとされています[1][2]。人が足りないほど採用単価は上がり、充足率を優先すれば固定費は膨らむ。この板挟みの中で、SES(System Engineering Service。時間単価で外部エンジニアの稼働を受ける契約)を「高いが仕方ない外注費」として受け入れるか、「意図的に設計した変動費」として扱うかで、年度の損益もプロダクトのスピードも大きく変わります。実務では、単価の一時的な値引きよりも、費用構造と作業設計を変えるほうが持続的に効くことが多い、というのが業界の通説です。複数の公開資料でも、正社員の総人件費は給与の1.4〜1.7倍(社会保険・福利厚生・間接費を含む)に達しがちで、採用初年度は採用コストを加味すればさらに膨らみます[3]。だからこそ、SESを「固定費の変動化」に活用し、資金効率とデリバリー速度の両立を図る設計が現実解になります。

SESを固定費の変動化に使う——費用構造を再設計する

まず前提として、コストの議論を「一人月単価」から「ビジネス価値あたりの支出」に引き上げたい。単価は見えやすく交渉しやすい指標ですが、意思決定に本当に効くのは、機能一つを顧客に届けるまでの総コストと時間、そしてそれがKPI(重要業績評価指標)に与えるインパクトです。SESを変動費として扱う設計を採るとき、先に置きたいのは、チーム全体のブレンデッドレート(全コストを総稼働時間で割った実効レート)と、ユニットエコノミクス(ストーリーポイントや機能あたりの実コスト)です。これを経営会議などに定例で載せ、構造的に下げる取り組みを回すほうが、単発の単価交渉より有効になりやすいのです。

正社員を基軸にしつつ、波打つ需要に対してSESでキャパシティを寄せる。需要のピークでは変動費を増やして機会損失を最小化し、谷では早めのスコープ調整と退出計画で燃えないコストを止血する。この「呼吸」を可能にするのが、SOW(Statement of Work。作業範囲の合意書)の粒度と、モジュール化された作業設計です。モノリシックな委託範囲は離脱コストを上げ、ベンチを生みます。反対に、コンポーネント単位の責任分界と、アクティビティごとの可視化は、短期の増減に強いコスト構造を作ります。

ブレンデッドレートと可視化——“安い人月”より“安い成果”へ

正社員の総コスト(公開データでは給与の1.4〜1.7倍を目安とされます[3])とSES、ツール費、間接費を一つのダッシュボードにまとめ、スプリントごとに実効レートを更新するのが有効です。例えば、月の総コストが1,200万円、総稼働が1,600時間ならブレンデッドレートは7,500円/時。ここにオーバーヘッドの削減や自動化投資が効くと、たとえ単価は据え置きでも実効レートは下がります。重要なのは、“単価の値引き”より“流れの摩擦を減らす”ほうが効く場面が多いという視点です。レビュー待ちの滞留やテストの手作業比率、デプロイのバッチ化など、レートではなくフローの改善がユニットコストを下げることは多数の研究・公開事例で示されています[4]。

機能単価・ポイント単価の設計——意思決定のための物差し

「この機能を今月リリースするために追加のSES2名を入れるべきか」を迷うとき、役立つのはストーリーポイント単価の履歴です。たとえば、過去6スプリントの中央値が1ポイントあたり3.5時間で、ブレンデッドレートが7,500円/時なら、1ポイントの実コストは約26,250円。対象機能が40ポイントなら、約105万円が追加の目安になります。SESを2名追加してベロシティ(単位期間の完了ポイント数)が1.3倍になるなら、投入からキャッチアップまでの遅延を引いても回るかどうかが判断できます。感覚ではなく、履歴とレートで意思決定するための最低限の物差しを、チームの合意事項として持つことが重要です。

単価ではなく生産性で見る——スキル、稼働、リードタイム

単価の安い人員を増やしても、レビューや要件確認のボトルネックで詰まれば、全体のコストは下がりません。むしろ、コミュニケーション負債と管理工数が増えて逆効果になることもあります。したがって、SESの選定は「一人で何ができるか」より「チームに入るとどのボトルネックが解消されるか」を軸にします。典型的には、テスト自動化、CI/CD(継続的インテグレーション/継続的デリバリー)の整備、設計レビューの強化、SRE(Site Reliability Engineering)の観点で運用品質を高めるスキルに寄せると、変更のリードタイムが縮まり、デプロイ頻度が上がります。DORA(DevOpsの実践度を測る研究コミュニティ)の指標を月次で見ながら、SESの稼働がどの指標をどれだけ動かしたかを結び付けると、経営は投資対効果を語りやすくなります[5]。

スキルミックスでスループットを最適化する

バックエンドの実装者を増やす前に、E2E(エンドツーエンド)テストの整備やパフォーマンス・ボトルネックの計測に強い人材を入れるほうが、結果としてスループットが伸びる場面は多いものです。プロダクトの現状を計測し、レビュー待ち時間の中央値、PR(Pull Request)のサイクルタイム、ステージング在庫の量を洗い出す。詰まっている地点にピンポイントでSESを差し込むことで、同じ人月でも成果の出方が変わります。公開事例や研究でも、テスト自動化の比率向上に伴い、ポイント単価やリードタイムが一桁%〜十数%改善するケースが報告されています[4][5]。単価交渉を続けるよりも、スキル構成の見直しが効く好例です。

稼働率の最適点——100%は最適ではない

稼働率を上げればコスト効率が上がるという直感は、知識労働ではしばしば外れます。キャッチアップやレビュー、仕様の不確実性に対応する余白がなければ、リワークが増えて総コストはむしろ上がるからです。SESを含む混成チームでは、稼働率の目標をあえて90〜95%程度に置き、バッファを見える化するほうが結果として早く安く終わることがあります。バッファは、緊急課題や依存関係のズレに対する保険であり、品質ゲートの確実な通過にも使われます。「常にフルスロットル」は短距離走では機能しますが、プロダクト開発という長距離走ではコスト高の近道になりがちです[6]。

契約と運用でコストを締める——SOW、責任分界、退出計画

準委任(時間単価で稼働を提供する)型のSES契約でも、アウトカム志向のSOWを設計すれば、実効コストは下げられます。重視したいのは、タスクの粒度と受け入れ基準、依存関係、エスカレーションの窓口を明確にすること。SOWに品質ゲートと定量的な受け入れ条件(例:テストカバレッジ、性能閾値、アラートのSLO=Service Level Objective)を組み込み、進捗は時間ではなく成果物の通過数で追う。こうしておくと、スプリント中にスコープの微修正が入っても、合意に基づいて優先度の入れ替えや範囲調整ができ、結果としてベンチや無駄な待機を減らせます。

加えて、入場より退出が難しいのがSES運用の現実です。だからこそ、初回のSOWに退出プランを含めます。具体的には、ナレッジ移転の成果物(運用Runbook=運用手順書、アーキテクチャ図、決定記録ADR=Architecture Decision Record、テストスイートの維持手順)を受領条件に含め、交代・縮小時の影響を極小化する。ベンダーロックインの温床は、契約ではなくドキュメントの欠落にあります。成果物とプロセスの属人性を減らすほど、変動費の“出口”は軽くなります。

時間準委任でもアウトカムに結び付ける

時間売りの契約形態は、成果責任が曖昧になりがちです。そこで、チームレベルのOKR(Objectives and Key Results)やスプリント目標にSESも紐づけ、評価や継続判断をアウトカム起点にします。例えば「変更のリードタイムを8週間で30%短縮」「主要ユースケースの失敗率を四半期で50%削減」といったKPIを掲げ、レビューは時間消化ではなくKPIへの寄与で行う。これに合わせ、レビュー待ち時間を短縮するためのレビュアー割当SLA(Service Level Agreement)や、テスト自動化の到達基準をSOWに明記すると、契約と運用が同じ方向を向きます。

ナレッジ移転とシャドーイング——内製化を前に進める

コスト最適化の本丸は、必要な時に必要なスキルを呼び込み、不要になったら知識を残して滑らかに退出する設計です。シャドーイング期間を設け、正社員が隣で手を動かしながらプロセスと判断基準を吸収する。コード所有権は常に自社に置き、レポジトリのレビュー権限やCIの設定権限も社内に残す。ペアでの設計・実装・レビューを通じて、SESがいなくなっても回る体制に近づけます。移転計画には、教育セッションの回数と到達基準、FAQとトラブルシュートログの整備を含め、達成状況をレトロスペクティブで検証する。これらは短期的には追加コストに見えますが、半年スパンで見れば退場コストとリスクを下げる可能性が高い取り組みです。

予測とガバナンス——需要変動に強い編成にする

SESを戦術的に増減できる状態にするには、需要予測の精度とガバナンスの軽さが鍵です。プロダクトのロードマップとベロシティの履歴から、四半期ごとのキャパシティ曲線を描き、先行してアサインの当たりを付ける。ここで有効なのが、スプリントベロシティの中央値と分散(MAD=Median Absolute DeviationやIQR=Interquartile Range)に基づく“現実的な幅”の予測です。上限一杯で計画を組むのではなく、中央値ベースでコミットし、上振れ分をバッファや技術負債返済に回す。予測の幅を見える化すれば、SESの募集〜稼働開始のリードタイムも逆算でき、無駄な待機費を抑えられます[7]。

ベロシティ予測とキャパシティプランニング

現実的なプランニングは、過去データの統計的な扱いから始まります。スプリントごとの完了ポイントの中央値を使い、外れ値の影響を抑えた範囲での予測を出す。さらに、依存する外部要因(他チームのAPI、承認プロセス、外部審査)を洗い出し、そこでのリードタイム分を先に差し引く。そうすることで、「このタイミングからSESを2名投入しても成果が出るまでに2スプリントかかる」といった現実に即した判断ができます。「早く入れれば早く進む」は幻想であり、キャッチアップ曲線まで含めて投資判断をすることが、最終的なコストを守ります

セキュリティとコンプライアンスのコストを織り込む

外部人員の受け入れで見落としがちなのが、権限設計と監査対応にかかる隠れコストです。最小権限の原則(Least Privilege)を守り、環境ごとに権限テンプレートを用意して入場と退出を自動化する。アカウント発行やVPN、端末セキュリティの設定にかかる工数を事前に見積もり、SOWに含めておく。ソースコードや設計情報の持ち出しを防ぐためのDLP(Data Loss Prevention)設定やログ監査を整えておくと、インシデント時の調査コストも下がります。こうしたガバナンスが整っていれば、SESの出入りを前提とした運用でも、スピードとコンプライアンスを両立できます[8][9]。

まとめ——“値切る”から“設計する”へ

人手不足とスピード要求が高まるいま、SESはコスト高の象徴ではなく、うまく設計すれば事業の機動力になる選択肢です。単価の値引きに注力するより、ブレンデッドレートでコストを見える化し、スキルミックスでボトルネックを外し、アウトカム志向のSOWと退出計画で変動費の“入口と出口”を整える。予測とガバナンスで需要の波に先回りし、セキュリティをシステム化して受け入れを軽くする。こうした積み重ねは、月次で数%規模の実効コスト改善につながり得るうえ(状況によっては5〜10%程度の改善が報告されることもあります[10])、品質とスピードの両立にも寄与します。

次のスプリントで何から変えられるか。まず、チームのブレンデッドレートを算出してみる。過去6スプリントのポイント単価を出して、意思決定に使える物差しを置く。SOWに受け入れ基準と退出成果物を一行追加する。小さな一歩ですが、再現性の高い改善につながるはずです。あなたの現場で、どのボトルネックから外しますか。

参考文献

  1. NTT Com Bizon. 経済産業省がみずほ情報総研に委託した「IT人材需給に関する調査(※)」によれば、IT人材は2030年に最大で79万人不足する可能性。https://www.ntt.com/bizon/d/00491.html#:~:text=%E7%B5%8C%E6%B8%88%E7%94%A3%E6%A5%AD%E7%9C%81%E3%81%8C%E3%81%BF%E3%81%9A%E3%81%BB%E6%83%85%E5%A0%B1%E7%B7%8F%E7%A0%94%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE%E3%81%AB%E5%A7%94%E8%A8%97%E3%81%97%E3%81%9F%E3%80%8CIT%E4%BA%BA%E6%9D%90%E9%9C%80%E7%B5%A6%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%AA%BF%E6%9F%BB%20%E8%AA%BF%E6%9F%BB%E5%A0%B1%E5%91%8A%E6%9B%B8%E3%80%8D%EF%BC%88%E2%80%BB%EF%BC%89%E3%81%AB%E3%82%88%E3%82%8C%E3%81%B0%E3%80%81IT%E4%BA%BA%E6%9D%90%E3%81%AF2030%E5%B9%B4%E3%81%AB%E6%9C%80%E5%A4%A779%E4%B8%87%E4%BA%BA%E4%B8%8D%E8%B6%B3%E3%81%99%E3%82%8B%E5%8F%AF%E8%83%BD%E6%80%A7%E3%81%8C%E3%81%82%E3%82%8B%E3%81%A8%E8%A9%A6%E7%AE%97%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82

  2. 財務省『ファイナンス』2023年8月号. IT人材の“量”と“質”に関する不足感(2030年に先端IT人材が45万人不足の試算)。https://www.mof.go.jp/public_relations/finance/202308/202308k.html#:~:text=%E8%B3%AA%E2%80%9D%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8B%E4%B8%8D%E8%B6%B3%E6%84%9F%E3%80%81%E5%9B%B3%E8%A1%A83%E3%80%80IT%E4%BA%BA%E6%9D%90%E3%81%AE%E2%80%9C%E9%87%8F%E2%80%9D%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8B%E9%81%8E%E4%B8%8D%E8%B6%B3%E6%84%9F%EF%BC%89%E3%80%812030%E5%B9%B4%E3%81%AB%E3%81%AF%E5%85%88%E7%AB%AFIT%E4%BA%BA%E6%9D%90%EF%BC%88%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E4%BA%BA%E6%9D%90%EF%BC%89%E3%81%8C45%E4%B8%87%E4%BA%BA%E4%B8%8D%E8%B6%B3%E3%81%99%E3%82%8B%E8%A9%A6%E7%AE%97%E3%81%8C%E3%81%A7%E3%81%A6%E3%81%84%E3%82%8B%EF%BC%88%E5%9B%BE%E8%A1%A84%E3%80%80%E5%85%88%E7%AB%AFIT%E4%BA%BA%E6%9D%90%20%E3%81%AE%E3%80%8C%E4%B8%8D%E8%B6%B3%E5%88%86%E3%80%8D%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%A9%A6%E7%AE%97%E7%B5%90%E6%9E%9C%EF%BC%89%E3%80%82

  3. 厚生労働省. IT・デジタル人材の労働市場に関する研究調査事業報告書(令和5年度). https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000089556_00021.html

  4. Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of DevOps. IT Revolution, 2018. https://itrevolution.com/accelerate/

  5. DevOps Research and Assessment (DORA). Accelerate: State of DevOps Report 2019. https://cloud.google.com/devops/state-of-devops

  6. Rothman, J. Management Myth #1: The Myth of 100% Utilization. AgileConnection. https://www.agileconnection.com/article/management-myth-1-myth-100-utilization/1000

  7. Vacanti, D. When Will It Be Done? Lean-Agile Forecasting to Answer Your Customers’ Most Important Question. 2022. https://actionableagile.com/

  8. NIST SP 800-53 Rev. 5. Security and Privacy Controls for Information Systems and Organizations (AC-6 Least Privilege). https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final

  9. NIST SP 800-61 Rev. 2. Computer Security Incident Handling Guide. https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

  10. DevOps Research and Assessment (DORA). 2021 Accelerate State of DevOps Report. https://dora.dev/research/