経営・採算管理
SIerの要員管理を再設計する。人月モデルから限界利益へ
SIerやSESの要員管理は、人月単価と稼働率を主軸に組まれてきた。だが多重下請け・単価圧迫・離職の構造的な問題は、稼働率では解けない。
要員管理は受注後の稼働調整を担う仕組みであり、本来そこが利益を決めるレイヤーではない。利益は受注前の案件選定と単価設計で決まる。要員管理の精度を上げるのではなく、その手前に採算設計のレイヤーを置く再設計が要る。
この記事の要点
- SIer・SESの要員管理は「人月単価×稼働率」を主軸に運用されてきたが、稼働率は案件採算を映さない。
- 多重下請けで階層を下に伸ばすほど一人当たり限界利益が削られる構造を、稼働率KPIは捉えられない。
- 要員管理は受注後の稼働調整を担う仕組みで、利益が決まる受注前には届かない。
- 再設計の方向は要員管理の置き換えではなく、その手前に採算設計(受注前の限界利益設計)のレイヤーを追加すること。
- 順序は採算設計→受注→要員管理→実行。役割を分けて連動させる。
SIerの要員管理は何を最適化してきたか
SIerやSES企業の要員管理は、長らく次のKPIに最適化されてきた。
- 一人当たりの月間稼働率(80%、90%、100%)
- 人月単価(顧客請求単価)
- 月次の売上目標達成率
- 案件と人の月単位の配置表(稼働表)
これらは「いま誰が埋まっているか」を見える化し、空きを減らすことで売上を立てるための指標群だ。月初に稼働表を見て、空きが出そうな人を別案件へ振り、空白を埋める。シンプルで分かりやすく、過去から運用してきた組織にとって体に染みついた回し方である。
だがこの最適化は、案件ごとの利益を見ていない。
稼働率は埋まっているかどうかしか測らない。安単価の案件でも、自社の不得意領域の案件でも、メンバーが疲弊する案件でも、埋まっていれば100%である。固定費の回収に貢献しているかは、稼働率の式の中には現れない。
稼働率が高いのに利益率が下がる構造
「稼働率は過去最高なのに、利益率が落ちている」——この矛盾はSIer・SESで頻繁に起きる。原因は3つの構造的な圧力にある。
第一に、単価圧迫。多重下請けで上位ベンダーから降りてくる案件は、階層を下るたびに単価が落ちる。下に伸びるほど、一人当たり限界利益が削られる。稼働率では下がった単価を捕捉できない。
第二に、スキル不適合の積み重ね。空きを埋めるために、本来不得意な領域の案件にメンバーを当てると、生産性が落ち、追加工数が発生し、最終的に限界利益率が圧縮される。稼働は埋まり進捗は遅れる。
第三に、疲弊と離職。連続稼働で限界に達したメンバーが離れると、引き継ぎコスト・採用コスト・残ったメンバーへの負荷集中が連鎖する。短期の稼働率最大化が、中期で組織能力を削る。
稼働率を追うほど利益が逃げる構造は埋めるほど利益は逃げる。「稼働率100%」という錯覚に詳しい。SIer・SES特有の多重下請け構造下では、この罠が一層深くなる。
従来の要員管理と、採算設計型の要員アサインの違い
要員管理の運用を、従来のKPIと採算設計型のKPIで横に並べる。
| 観点 | 従来の要員管理(人月モデル) | 採算設計型の要員アサイン |
|---|---|---|
| 主軸KPI | 稼働率・人月単価 | 案件ごとの限界利益・グレードミックス |
| 起点 | メンバーの空き時間 | 案件の単価と必要スキル |
| 意思決定の場 | 月次の稼働表更新会議 | 受注前の提案・営業フェーズ |
| 案件選定 | 与えられた案件を埋める | 限界利益で受注を判断 |
| 多重下請け対応 | 単価が落ちても稼働は埋める | 階層と限界利益で受注可否を決める |
| 中期で起きること | 稼働は高いが疲弊と離職 | 案件構成が利益体質に転換 |
| 必要なデータ | 稼働表・スキルシート | 案件採算・編成シミュレーション |
二つは対立しない。従来の要員管理は受注後の稼働調整を担い、採算設計型のアサインは受注前の意思決定を担う。 役割が違う。問題は前者を後者の代わりに使ってきたことにある。
多重下請け構造で限界利益を守るには
SES業界特有の多重下請け構造では、案件選定と階層選択を一体で意思決定する必要がある。同じスキルセットのメンバーでも、1次請けで取れば限界利益が残り、3次請けで取れば固定費回収にも届かないことがある。
ここで稼働率KPIは判断軸にならない。1次でも3次でも、稼働が埋まれば100%だからだ。判断軸は「この案件を、この階層で受けて、いくらの限界利益が残るか」である。
意思決定の単位を「稼働を埋めるか」から「限界利益が出る案件を選ぶか」に変えると、断る案件・受ける案件・条件を交渉する案件の3分類が見えるようになる。意志を持って案件を断る判断軸については経営者が今すぐ決断すべき「お断りする案件」の採算設計学に書いた。
要員管理を再設計するレイヤー構造
要員管理を捨てる必要はない。受注後の稼働調整、案件間の融通、実績の見える化——これらは引き続き要員管理ツールが担う仕事だ。再設計の方向は、その手前に「採算設計」のレイヤーを追加することにある。
順序を時間軸で並べると次のとおりだ。
- 採算設計(受注前・提案フェーズ):案件単価・編成・限界利益を受注前にシミュレーションし、受注可否と体制を決める。
- 要員管理(受注後・月次):受注した案件群に対し、メンバーを配分し、稼働を調整する。
- 工数管理(実行中・事後):実際の稼働を記録し、原価を把握する。
上流の採算設計が「どの案件をどの体制で受けるか」を決め、その制約条件のもとで要員管理が稼働を調整し、工数管理が結果を記録する。順序が逆だと、要員管理が受注後の案件をパズルとして埋めるだけになり、利益は受注時点で固定される。
採算設計をカテゴリとして整理したのが採算設計とは。プロジェクト型組織が受注前に利益を作る新カテゴリ、PSAとの関係はZAC・Reformaは捨てるな。採算は基幹システムの前で決まるに書いた。
どこから始めるか
要員管理を再設計するといっても、ツールを入れ替えるところから始めるものではない。既存の要員管理ツールはそのまま使い続けて構わない。
始まりは、次に提案する1案件だ。受注前にその案件の限界利益と編成候補をシミュレーションし、稼働率ではなく限界利益で受注を判断する。これを案件単位で積み重ねるうちに、組織の意思決定が稼働率最大化から利益設計へと移っていく。
製品としての実装は、採算設計クラウド『CATCAREERアサインメント』である。立っているのは、案件がまだ受注されていない提案・営業フェーズ。SIer・SESの要員管理ツールが、決して触れられない場所だ。
FAQ
SIerの要員管理とは何ですか?
SIerの要員管理は、メンバーの稼働状況と顧客への配置を月単位で計画・調整する仕組みです。多くの場合「人月単価×稼働率」を主軸KPIにし、誰がいつどの案件に何時間入るかを管理します。SES企業ではこれが業務の中心になります。
稼働率を追うとなぜ採算が悪化するのですか?
稼働率は「埋まっているかどうか」しか見ず、案件ごとの単価や限界利益を映さないからです。安単価の案件で稼働を埋めれば稼働率は上がりますが、固定費の回収には届かず組織は赤字に向かいます。稼働率が高い月ほど利益率が下がるという矛盾は、この指標の構造的な限界です。
SESの多重下請け構造で要員アサインを最適化するには?
下請け階層を抜けた瞬間に単価が一段下がる構造を前提に、「どの案件を、どの単価層で受けるか」を限界利益で意思決定することです。階層を下に伸ばすほど一人当たり限界利益が削られていくため、案件選定と階層選択を一体で設計する必要があります。
要員管理から脱却して何に立つべきですか?
受注後の稼働調整を担う要員管理を捨てる必要はありません。その手前に、受注前に案件ごとの限界利益を設計する「採算設計」のレイヤーを置くことです。要員管理は実行を支え、採算設計は受注を意思決定する。役割を分けたうえで連動させます。
既存の要員管理ツール(ようかん、TimeKreiなど)との関係は?
競合しません。要員管理ツールは受注後の稼働調整・案件間の配分・実績の見える化を担います。採算設計クラウドは受注前の提案フェーズで限界利益と編成を設計します。順序は採算設計クラウド→受注→要員管理→実行となり、レイヤーが分かれます。