SESから受託開発への転換に対応した等級・評価・報酬制度を構築
設立1970年代
従業員約130名（単体・グループ約640名）
売上約80億円（グループ）
提供サービス人事制度設計
実施期間12カ月
支援時期2018年～2019年
対象層・対象人数全社
事例サマリー
セレクションアンドバリエーションが人事制度の全面改定を支援した事例である。
人月が売上の上限となるSES・受託開発中心の収益構造から、自社アプリケーション
開発を併営する構造への転換を、等級・評価・報酬の再設計によって支えた。
等級数が多く基準が曖昧だった旧制度を、行動等級と職責等級の二軸へ再設計している。
背景
近畿地方に本社を置く同社は、1970年代前半の創業以来、生産管理・受発注・
販売管理などの業務系システム開発を手がけてきたSIerである。
同社の収益は、技術者派遣（SES）と受託開発が中心であった。この構造では
人月が売上の上限となる。技術者を増やさなければ売上が伸びず、増やせば
一人あたりの生産性は頭打ちになるという制約を抱えていた。
そこで同社は、安定的な売上を確保できる受託型ビジネスと、逓増型の利益を
生む自社アプリケーション開発とを両立させる方針を掲げた。中期目標の達成に
必要な数字を分解すると、一人あたり売上の大幅な引き上げと、3年で200名近い
増員の双方が求められる計算であった。増員手段にはM&Aも想定されていた。
しかし、SESと受託開発で成果を出す行動と、自社商材を企画し市場に出す行動は
同じではない。前者は与えられた要件を確実に遂行する力を必要とし、後者は
顧客が言語化していないニーズを掴み、事業として立ち上げる力を必要とする。
当時の人事制度は旧来の職能給を基礎としたままであり、後者の行動を評価する
基準を持っていなかった。求める人材像が変わるのに、それを測る物差しが
変わらない。ここに制度改定の必要性があった。
課題（Before）
システム開発業（SIer）である同社では、制度改定前に次の課題があった。
1．事業転換によって必要となるスキルを、従業員に対して打ち出せていなかった。
自社商材の企画・開発に必要な行動が制度上どこにも定義されておらず、会社が
何を期待しているかが伝わらない状態にあった。
2．等級数が多く、実際には使われていない等級が存在していた。制度上の階層と
運用実態が乖離し、等級が処遇決定の根拠として機能していなかった。
3．等級の基準が曖昧であった。何をもって上位等級とするかが言語化されて
おらず、昇格判断と評価結果の双方に対する納得感が低い状態にあった。
4．等級間で給与の逆転が多発していた。下位等級者の給与が上位等級者を上回る
状態は、等級制度そのものへの信頼を損なう。
5．マネジメント職が優先され、スペシャリストのキャリアが不透明であった。
技術で価値を出す人材が、管理職にならなければ処遇されない構造は、商材開発を
担う専門人材を育てる方向には働かない。
6．30代前半の離職率が高かった。IT業界はこの年代でのステップアップ転職が
多く、社内に留まる理由を制度が提示できていなかった。
7．首都圏での採用競争力が低かった。報酬水準の地域差が大きい業界であるにも
かかわらず、制度が地域間の市場差に対応していなかった。
8．業績評価の指標が個別最適であり、組織目標との連動性が弱かった。個人の
目標達成が全社業績に積み上がらない構造になっていた。
9．年間の昇給率は1%に満たない水準で固定的に推移していた。成果を出しても
報酬が動かない状態は、評価制度を形式化させる。
目的と設計方針
システム開発業（SIer）における人事制度改革の目的を、
セレクションアンドバリエーションは「SES・受託開発から自社アプリ開発への
転換を支えるマネジメントインフラの構築」と定義した。制度を処遇決定の道具
ではなく、事業構造の転換手段として位置づける、という意味である。
設計方針は4点である。
1．人月型の事業で評価される行動と、商材開発で評価される行動の双方を、
同一の物差しの上に載せる。片方だけを評価すれば、転換は制度に阻まれる。
2．能力の伸長と職責の重さを切り離して扱う。人が育つ速度と、事業が必要と
する役職の数は一致しない。両者を一つの等級で処理すると、どちらかが歪む。
3．評価制度を、給与を決めるための仕組みではなく、業績を達成し個人が成長
するための仕組みとして設計する。期末の納得性より、期初の目標設定と期中の
マネジメントに設計の重心を置く。
4．移行時点で給与額の変更が直ちに生じない設計とする。ただしキャリアパスと
賃金カーブのイメージを提示し、制度改定が事業の前進を伴うものであることを
メッセージとして発信できる状態をつくる。
実際に構築した制度のポイント
システム開発業（SIer）である同社に対して構築した制度の要点は次のとおりである。
【等級制度】
1．行動等級と職責等級による二軸構成とした。行動等級は6段階とし、指示に
基づく行動から課題の創出までを、行動の非定型性の度合いで定義した。要件が
与えられる仕事と、要件そのものを作る仕事とを、同じ尺度上で区別している。
2．職責等級は8段階とし、マネジメント職とスペシャリスト職の複線とした。
スペシャリスト側は職種別に呼称を定義し、アプリケーション、インフラ、
プロジェクトマネジメント、商材企画・開発、営業のそれぞれに上位職を置いた。
3．商材企画・開発の職種系列を等級表に明記した。転換先の職種が制度上に
存在しなければ、そこへ移る意思決定は個人にとって不利益にしかならない。
4．職責等級は経営ニーズに応じて付け替える運用とした。事業ニーズの変化に
組織の役割配置を追随させ、登用を促進することが狙いである。
5．行動等級の昇格基準は、卒業基準と入学基準の併用とした。「下位等級の行動が
十分だから昇格」ではなく「上位等級の行動が取れると期待できる者」を上げる。
6．昇格審査にBEI（行動結果面接）形式の面接を導入した。コンピテンシー項目
ごとに質問と判断基準を設け、回答内容を点数化して合否を判定する。
7．降格ルールを明文化した。行動評価と滞留年数のマトリクスでノミネートし、
1年の改善期間を経て最終判断する、2年がかりの運用とした。
【評価制度】
8．行動評価と業績評価を目的別に分離した。行動評価は年1回で行動給と昇降格に
連動させ、業績評価は年2回で賞与額に連動させる。
9．行動評価の軸を5点に整理した。経営視点、技術知識、品質改善、営業力、
人材育成であり、いずれも経営層・幹部層へのインタビューから抽出している。
10．コンピテンシーディクショナリを作成し、5軸それぞれについて等級別の
発揮レベルを文章で定義した。上位段階では、顧客が明示していない期待を予測し
提案する行動や、前例のない業務を遂行する行動を要件としている。
11．コンピテンシーの各段階を、IPAが提供するiCD（iコンピテンシディクショナリ）
のタスク体系と関連づけた。業界標準の枠組みに接続することで、育成施策と
スキル管理を同じ言語で語れるようにした。
12．コンピテンシーのウエイトを職種別に設定した。管理系は経営視点を、
オペレーション系は技術知識と品質改善を重視するなど、実態に応じて配分した。
13．組織目標（KPI）の設定例を、受託開発・技術者派遣と新製品開発の двух系統で
別々に作成した。事業モデルが違えば、追うべき指標も違うためである。
14．業績目標はマトリクスシートで管理職が先に設定し、所属ミーティングで
全員分を共有する運用とした。個人記入を起点にしないプロセスである。
15．賞与額の算定に、組織業績と個人業績のウエイトを等級別に設定した。上位
等級ほど組織業績の比重を高め、下位等級ほど個人業績の比重を高くしている。
【報酬制度】
16．行動給をレンジレート（範囲給）とした。等級ごとに上限・下限を持つ賃金
レンジを設け、年次の行動評価によって昇給率を決定する。
17．職責給はシングルレート（単一給）とした。役職の重さに対して支払う性質の
給与であるため、在任期間による変動を持たせていない。
18．昇給マトリクスを、レンジ内の給与位置と評価結果の組み合わせで設計した。
レンジ下位では昇給を早め、中間額を超えると逓減させる構造である。
19．地域手当を新設し、都市圏ごとの報酬市場の差に制度として対応した。
首都圏での採用競争力を、手当という形で構造に組み込んでいる。
20．リーダー手当を新設した。非管理職でありながら人事考課を担う層に対し、
被考課者数の目安に応じて3区分で支給する。
21．住宅手当・教育奨励手当など複数の手当を廃止し、基本給へ統合した。
支給根拠が曖昧なまま残る手当は、報酬の説明可能性を下げるためである。
【その他制度】
22．定年後再雇用者向けにシニア等級を設計し、既存の等級体系に接続した。
60歳時点の等級に応じて移行し、職責等級は担当職務に応じて設定する。
【移行と浸透】
23．移行時に給与が直ちに変動しない設計とした。新等級のレンジから外れる
部分は調整手当として設定し、数年をかけて按分解消する経過措置を置いた。
24．管理職および従業員向けの説明会を、設計フェイズの範囲内で実施した。
制度を渡して終わりにせず、設計者が直接説明する場を確保している。
25．評価者研修を複数回にわたって実施した。期初・期中・期末という運用の
節目ごとに内容を変え、評価者の行動が定着するまで反復する構成である。
26．M&Aによってグループに加わった首都圏の子会社に対しても、制度の考え方を
展開した。取得直後に一律統合するのではなく、本体の制度を確立させたうえで
順次広げる進め方を採っている。
導入後の変化
現在も運用が続いている。公開情報から確認できる変化は次のとおりである。
1．自社商材の開発・提供が事業として立ち上がっている。同社は自社ブランドの
ITサービスを立ち上げ、製品情報やレポートのギャラリーを自社サイトで公開して
いる。制度改定時に商材企画・開発の職種系列を等級表に明記し、非定型な課題
創出を上位等級の要件として定義したことが、この領域を担う人材のキャリアを
制度上あらかじめ用意していた。
2．外部認定とパートナー資格の取得が進んでいる。同社は大手ソフトウェア
ベンダーの最上位パートナー認定を受け、公的な補助金制度の対象ITツールにも
自社サービスが登録されている。人月の提供から、製品として評価される事業へと
提供形態が変化していることを示す事実である。
3．マネジメント職とスペシャリスト職の複線キャリアが、現在も維持されている。
同社グループの採用サイトには、専門性を深める道と組織運営に携わる道の双方を
選択できる旨と、年に複数回の面談を通じたキャリア相談の運用が明記されている。
これは職責等級として設計した複線構造そのものである。
4．iCDの活用が、制度の枠を超えて広がっている。同社は支援開始前の時点で
iCD活用認定企業のSilver認証を受けていたが、現在はSilver Plus認証を取得し、
グループ各社に制度と考え方を展開している。行動評価をiCDのタスク体系と
関連づけた設計が、認証の運用実績として積み上がる形になっている。
5．拠点が国内4大都市に広がっている。制度設計時に都市圏ごとの報酬市場差を
地域手当として構造化していたため、拠点が増えるたびに報酬水準の考え方を
一から議論する必要がなかった。
6．グループの規模が拡大している。支援当時のグループ従業員数は300名台で
あったが、直近では600名台となっている。人事制度が要因であると断定する
ものではなく、制度がこの規模変化を運用上支えてきたという事実である。
7．グループ再編が複数回行われ、持株会社体制へ移行している。子会社2社の
合併と新会社の設立を経て、現在はグループ7社の体制となった。等級・評価・
報酬の共通の骨格が先に整っていたため、再編のたびに処遇の統合作業を
一から設計する必要がなかった。
8．事業領域そのものが広がっている。グループにはWebソリューション、
ビジュアルソリューション、HRソリューションを担う各社が並び、システム受託
一本の構成ではなくなっている。行動を軸とした等級は職種の増加に対して
開いた構造であり、新領域の会社を同じ枠組みで扱うことができる。
9．M&Aで取得した首都圏の子会社は、グループ内で特定の事業領域を担う会社と
して定着している。取得直後の一律統合を避け、本体の制度を確立させてから
展開する進め方を採ったことが、統合の摩擦を抑える方向に働いている。
10．研修体系が階層別に整備され、グループ横断の社内公募制度も導入されて
いる。制度設計時に非管理職の考課者を「リーダー職」として区分したことが
育成対象の輪郭を先に定め、職責等級を経営ニーズに応じて付け替えるという
設計思想が、会社の枠を超えた異動の仕組みへと発展している。
事業モデルの転換は、人事制度だけで実現するものではない。しかし、新しい
事業を担う行動が等級表のどこにも書かれていなければ、その事業に移ることは
個人にとって合理的な選択にならない。セレクションアンドバリエーションが
設計した行動等級と職責等級の骨格は、同社グループにおいて、事業領域の拡張と
組織形態の変化を経てなお運用され続けている。
本プロジェクトの特徴
人事制度改革において、本プロジェクトで下した判断は
次のとおりである。
1．等級を一本化せず、二軸に分けた。
一般に、等級制度の改定では「わかりやすさ」を理由に軸を一本化する判断が
選ばれやすい。本案件では、能力の伸長を示す行動等級と、職責の重さを示す
職責等級を分離した。事業を転換する局面では、技術者の成長速度と、事業が
必要とする管理ポストの数がとりわけ一致しない。一本化すればどちらかが
犠牲になる。
2．ジョブ型（職務等級制度）を採らなかった。
自社アプリ開発への転換途上にあり、担うべき職務そのものが数年内に変わる
ことが見込まれていた。職務等級制度は職務記述書を起点とするため、職務が
安定している組織で最も機能する。変化の途上にある組織では、職務を固定した
瞬間に制度が事業の足かせになる。行動を軸に据えたのはこのためである。
3．転換先の職種を、実績が出る前に等級表へ書き込んだ。
商材企画・開発の系列は、当時まだ人数も実績も限られていた。実績を待ってから
制度に反映する順序が一般的だが、それでは誰もその職種を選ばない。処遇の
道筋を先に示すことでしか、人は新しい領域に移らない。
4．昇格に入学基準と面接審査を課した。
一般に、昇格は下位等級での評価実績（卒業基準）のみで判断されることが多い。
本案件では上位等級の行動が取れると期待できるかを問う入学基準を併用し、
BEI形式の面接で確認する運用とした。過去の実績のみで昇格を決めれば、上位
等級は前の事業モデルで成果を出した人材で埋まる。
5．業績目標の設定順序を逆にした。
一般的な運用では、本人が目標を記入し、上司との面談で調整する。この順序は
低めの目標設定を招きやすく、面談が否定から入るため信頼形成を阻害する。
本案件では管理職がマトリクスシートで先に配分し、所属ミーティングで全員分を
共有したうえで、個別面談ではアクションプランを検討する順序とした。
6．KPIの体系を事業モデル別に分けた。
受託開発・技術者派遣と新製品開発では、追うべき指標がまったく異なる。
前者は稼働率や見積精度、後者は商材提案数や協業先開拓数、発売後の不具合率
などが軸になる。全社共通のKPIに揃えれば、新規事業側は必ず不利になる。
7．M&A直後に制度を一律統合しなかった。
支援開始と同じ2018年に、同社は首都圏の企業を子会社として取得している。
統合を急げば、取得先の事業特性を無視した制度が現場に降りることになる。
本体の等級・評価・報酬の骨格を先に確立させ、その後にグループへ展開する
順序を選んだ。統合すべきは制度の骨格であり、運用の細部ではない。
8．評価者研修を導入時の1回で終わらせなかった。
制度は設計の質ではなく、評価者の運用の質で決まる。期初の目標設定、期中の
中間レビュー、期末の評価とフィードバックでは、必要となる技術が異なる。
運用の節目ごとに内容を変えて複数回実施したのは、制度の理解ではなく
評価者の行動を変えることを目的としていたためである。
9．定年後再雇用を制度の外に置かなかった。
再雇用者の処遇は個別対応で処理されることが多いが、本案件ではシニア等級を
設け、既存の行動等級と接続した。職責等級は現役時と同じ体系で運用する。
再雇用者を制度の外に置けば、その処遇は説明できないものになる。
最も判断を要したのは、商材開発の職種系列を等級表に書き込むかどうかでした。当時はまだ人数も実績も限られており、実績が出てから制度に反映するという考え方もあります。それでも先に書くことをお勧めしたのは、処遇の道筋が見えない領域に、人は自分から移らないからです。人月ビジネスで成果を出してきた方に転換をお願いする以上、会社が先に約束を形にする必要がある、と経営陣にお伝えしました。
よくあるご質問
何から変えるべきか。
等級制度から変えるのが原則である。評価や報酬を先に触っても、そもそも
新しい事業を担う職種と、そこで求められる行動が制度上に存在しなければ、
評価の対象にならないためである。本事例では、商材企画・開発の職種系列を
職責等級表に明記し、行動等級の上位段階に「課題の創出」「前例のない業務の
遂行」といった非定型の行動を要件として定義した。処遇の道筋を先に示すこと
なしに、人月ビジネスで成果を出してきた人材が新領域へ移ることはない。
Q2. なぜジョブ型（職務等級制度）ではなく、行動等級と職責等級の二軸を選んだのか。
事業構造の転換期にある企業では、職務そのものが数年で変わるためである。
職務等級制度は職務記述書を起点とするため、職務が安定している組織で最も
機能する。担うべき仕事が変わる途上でこれを導入すると、制度の改定が事業の
変化に追いつかず、制度が足かせになる。本事例では受託開発中心から自社商材
開発への転換が進行中であったため、職務ではなく行動を等級の軸に据え、
職責は付け替え可能な第二の軸として別に設けた。
Q3. 等級制度は一本化すべきか、複数の軸に分けるべきか。
事業の変化が速く、人の成長と役職の数が一致しない組織では、軸を分けたほうが
よい。等級を一本にすると、能力が伸びた人を処遇するために役職を増やすか、
処遇せずに待たせるかの二択になる。前者は組織を肥大させ、後者は離職を招く。
本事例では、行動によって決まる等級と、職責によって決まる等級を分離し、
行動等級は年次の評価で昇降格させ、職責等級は経営ニーズに応じて付け替える
運用とした。
Q4. 新規事業と既存事業で、業績評価の指標は分けるべきか。
分けるべきである。受託開発や技術者派遣では稼働率、見積精度、品質・納期の
遵守といった指標が成果を表すが、新製品開発では商材提案数、協業先の開拓数、
発売後の不具合率などが軸になる。全社共通のKPIに揃えると、売上が立つまでに
時間のかかる新規事業側は構造的に不利になり、優秀な人材ほど既存事業に
留まろうとする。本事例では、事業モデル別にKPIの設定例を作成した。
Q5. M&Aで取得した会社に、親会社の人事制度はいつ展開すべきか。
親会社側の制度が確立してから展開するのが原則である。取得直後の一律統合は、
取得先の事業特性を無視した制度を現場に降ろすことになり、キーパーソンの
離職を招きやすい。一方で、統合方針を示さないまま放置すれば「二社状態」が
固定化する。本事例では、支援と同じ年に子会社取得が発生したが、本体の
等級・評価・報酬の骨格を先に完成させ、その後にグループへ考え方を展開する
順序を採った。統一すべきは等級のフレームと評価の基準であり、報酬テーブルや
運用プロセスには一定の裁量を残す設計が現実的である。
Q6. シングルレート（単一給）からレンジレート（範囲給）へ移行すると、
人件費は増えるのか。
設計次第で、総額を維持したまま移行できる。レンジレートでは昇給率の上限が
上がるため、一見すると原資が膨らむように見える。しかし同時に、レンジ上限に
到達した者の昇給停止と、評価下位者の減給・据置が発生するため、分布全体で
見れば原資は同水準に収まる。本事例では、レンジ内の給与位置と評価結果を
組み合わせた昇給マトリクスを設計し、レンジ下位では昇給を早め、中間額を
超えると逓減させることで、昇給原資を従来水準に保ちながら分配の納得感を
高める設計とした。