はじめに
「で、どのシステムにする？」
グループ人事統合の話が出た瞬間、会議室で必ず聞こえてくる言葉です。
パソコンの画面には、他社事例や比較表。多くの人事システム統合の議論はこの光景から始まります。一見合理的に見えます。製品を選ばなければ前に進めない。
しかし、この方法では統合プロジェクトが途中で止まることが多いのです。要件定義が混乱し、後出しの要件が止まらない。最後は「どのシステムも合わない」という結論に落ち着く。
これは例外ではなく、繰り返し起きている失敗パターンです。このとき問題になっているのは、システムの性能ではありません。原因は、もっと手前にあります。
「制度も業務もバラバラなのに、先にシステムを決めないと話が進まない」そう感じるのは自然です。
比較表は安心感を与え、議論している感も出ます。しかし、統合を前に進めるために必要なのは、システム選定ではありません。システムを選ぶ前に、何を揃え、何を揃えないのかを決めること。それだけで、統合の議論は驚くほど整理されます。
まずは、なぜ人事統合がシステム比較から始まってしまうのか。その構造から見ていきましょう。
なぜ人事統合は、システム比較から始まってしまうのか
人事統合の議論が始まると、多くの企業で最初に出てくるのがシステムの話です。
- 「とりあえずRFPを作ろう」
- 「マルチカンパニー対応は必須」
- 「評価機能は外せない」
会話は自然と、製品名や機能一覧に流れていきます。この入り方は、決して珍しいものではありません。
実際に私たちが支援したあるグループ会社では、OSやミドルウェアのサポート終了という外部要因をきっかけに、人事システム刷新の検討が一気に進みました。既存環境の延命ではなく、SaaS型への移行を選択したため、期限は固定されました。
「制度を揃える前に、まず器を決めないと間に合わない」そう判断するのは、現場としてはごく自然な流れです。しかし、そのプロジェクトは複数社・数千名を対象に、人事給与・ワークフロー・就労を同時に導入するという、大規模かつ難易度の高いものでした。時間制約の中で比較表から議論を始めた結果、後工程で想像以上の摩擦が生じます。
こうしたケースで起きがちなのは、課題から考えるのではなく、選択肢から考えてしまうという構造です。統合プロジェクトは関係者が多く、意思決定も重たい。だからこそ、誰もが分かりやすい比較表に寄りかかります。
比較表には、数字とチェックマークが並びます。それを見ると、「ちゃんと検討している」「前に進んでいる」という感覚が生まれる。しかし、この段階で業務や困りごとの話が出ていない場合、すでに危険信号です。
- 評価が回っていないのか
- 例外処理が属人化しているのか
- 判断主体が曖昧なのか
本来は、これらが起点になるべきです。それを飛ばして比較に入ると、システム選定の目的がすり替わります。課題を解決するための選定ではなく、選ぶこと自体が目的になる。
この状態でどれだけ真剣に比較しても、後工程で必ずズレが出ます。要件定義の途中で話が戻り、後出し要件が噴き出し、プロジェクトは止まる。システム比較から入った統合が失速する理由は、ここにあります。
マルチカンパニー対応が、統合を難しくする理由
人事統合の議論で、ほぼ必ず条件に挙がるのがマルチカンパニー対応です。
- グループ会社ごとに法人を切り替えられる
- 企業別に人事データを保持できる
- 出向や兼務にも対応できる
この要件自体は、たしかに欠かせません。実際、グループ内での人の行き来が多い企業にとって、IDを維持したまま一括管理し、かつ閲覧・登録権限を企業ごとに制御できる仕組みは、システム選定における大きな判断材料になります。
ただし、ここで「マルチカンパニー対応だから大丈夫」と安心しきってしまうと、統合は止まります。なぜなら、実務で本当に揉めるのは、法人を切り替えられるかどうかではないからです。問題になるのは、同じ項目なのに、意味が揃っていないという現象です。
典型例が役職です。同じ「課長」という名称でも、ある企業では、評価責任と承認権限を持つ管理職。別の企業では、肩書だけの管理職で、実質的な判断権限は上位者にある。こうした違いは、決して珍しいものではありません。
システムは、項目名やラベルを揃えられます。しかし、その裏にある期待役割や判断責任の違いまでは吸収できません。実際の設計フェーズでは、「この役職、評価者ですよね」「いえ、うちでは承認権限はありません」などと話が噛み合わず、フロー設計が止まるといったことが頻発します。
この問題が最も顕在化しやすいのが、就労（勤怠）やワークフローといった、例外処理の多い領域です。業種や勤務形態が異なる複数社の就労ルールを、一つの標準設計に落とし込もうとした瞬間、設定は一気に複雑になります。
- 「同じ勤務区分でも、例外の考え方が企業ごとに違う」
- 「承認フローは似ているが、最終判断者の位置づけが揃っていない」
マルチカンパニー対応のシステムであっても、こうした意味のズレは自動的には解消されません。むしろ、違いを内包できる器であるがゆえに、先に設計思想が決まっていないと、混乱を増幅させる装置になります。
これは、マルチカンパニー対応のシステムを選んだから起きる問題ではありません。何を揃えるのか。何を揃えないのか。どこから先は「違っていてよい」と判断するのか。この前提を決めないまま、器だけを用意してしまった結果です。
マルチカンパニー対応は、万能な解決策ではありません。統合の自由度を広げる機能であるがゆえに、判断軸が曖昧だと現場の摩擦を可視化してしまう。その現実を直視しない限り、「対応しているはずなのに、なぜか進まない」という状態から抜け出すことはできません。
「標準機能で対応できます」が信頼を失う瞬間
システム選定の場で、よく聞く言葉があります。
「その運用は、標準機能で対応できます」
追加開発が不要でコストを抑えられるうえ、スケジュールも守れる。説明としては、正しいでしょう。しかし、この言葉が出た瞬間に、現場の温度が一気に下がることがあります。理由は単純です。現実が切り捨てられたと感じるからです。
人事業務は、最初から例外を前提にできています。途中入社、休職復帰、出向、役員判断の特例。どの企業にも、必ず「きれいに揃わない事情」があります。これらは制度の欠陥ではありません。その時々の経営判断と現場判断の積み重ねです。にもかかわらず、「標準で吸収できます」と言われると、現場はこう受け取ります。
- 「うちの企業の事情が考慮されていない」
- 「机上の理想論で話している」
結果、システムへの不信感が先に立つ。導入前から、「使われない未来」が見えてしまいます。
もう一つ、見落とされがちなのが標準機能で「できる」ことと、運用として「回せる」ことは別物だという点です。実際の大規模導入プロジェクトでは、標準機能を組み合わせることで要件自体は満たせているケースも少なくありません。しかし、就労ルールや承認フローに例外が多い場合、設定は急速に複雑化します。
- なぜこの設定になっているのか分からない
- 判断基準がドキュメント化されていない
- 特定の担当者しか触れない
こうした状態が積み重なり、稼働直前になって「この判断は、誰が責任を持っているのか分からない」という声が上がる。結果として、追加で人員と体制を強化せざるを得なくなる。「標準で対応できるはずだった」という前提が、静かに崩れていきます。
ここで問題になっているのは、システムそのものではありません。例外をどう扱うのか。どこまでを許容するのか。この設計思想が、関係者の間で共有されていないことです。「標準機能」という言葉は便利です。しかし、それに頼った瞬間、現場との信頼は静かに崩れ始めます。
標準に寄せる判断も、例外を残す判断も、本来は「誰が、どの基準で決めているのか」を明確にしたうえで行われるべきものです。それがないままでは、標準機能は効率化の武器ではなく、摩擦の引き金になります。
システム選定前にやるべき、たった一つのこと
ここまで読んで、「結局、何から手をつければいいのか」と感じたかもしれません。答えはシンプルです。システム選定の前にやるべきことは、業務と判断基準の棚卸しです。
多くの人事統合プロジェクトが止まる理由は、機能不足ではありません。判断が、誰の責任なのか決まっていないまま進んでいることです。たとえば、次の問いに即答できるでしょうか。
- この評価の最終判断者は誰か
- 等級や役職の例外は、どこまで誰が認めるのか
- 配置や処遇の最終責任は、どこにあるのか
ここが曖昧なままシステムを選ぶと、どんな製品でも「合わない」という結論にたどり着きます。実際、大規模な人事システム導入プロジェクトが前に進んだのは、要件定義が完璧に固まったときでも、標準機能で全てを吸収できたときでもありませんでした。
転機になったのは、「この領域は標準に寄せる」「ここは各社裁量を残す」「この判断は、この立場が持つ」という線引きが明確になった瞬間です。この線引きができると、議論は驚くほど整理されます。
- 「それはシステムで吸収する話ではない」
- 「そこは制度の話として持ち帰る」
- 「ここは例外として残すが、判断者は固定する」
要件定義の質が一段上がり、後出し要件は減り、比較表は「安心材料」ではなく「確認資料」に変わります。もう一つ重要なポイントは、全部を揃えようとしないことです。人事統合では、必ず差が可視化されます。そのすべてを是正しようとすると、現場は疲弊します。だからこそ、先に決める必要があります。
- 評価基準は統一するのか
- 裁量を残す領域はどこか
- 違っていてもよいと、経営が言い切る項目は何か
この判断をシステムに委ねてはいけません。システムは、決められたルールを正確に運用する道具であって、決める主体にはなれないからです。逆に言えば、この判断基準が言語化され、それを支える人員体制とコミュニケーション設計が整っていれば、システムは統合を前に進める強力な道具になります。
これらができていなければ、どれだけ高機能な製品でも、システムは摩擦を増やす装置に変わってしまうのです。
まとめ
人事統合がうまくいかない理由は、多くの場合、システムの性能ではありません。
- マルチカンパニー対応でも、意味が揃っていなければ混乱する
- 標準機能でも、現場の例外を無視すれば使われない
- システム導入を先にすると、権限を巡る不満が一気に噴き出す
比較表では、こうした問題は見えてきません。比較表が扱えるのは機能であって、企業の判断構造や感情ではないからです。だからこそ、順番が重要になります。最初にやるべきは、システム選定ではありません。
- 何を統合したいのか
- 何を揃え、何を揃えないのか
- 誰が、どこまで判断するのか
この設計思想を言語化し、関係者で共有する。それができて初めて、システムは選べるようになります。ただし、この工程を社内だけで進めようとすると、必ず壁に当たります。判断基準を言語化する作業は、制度や権限の話を避けて通れないからです。
誰かにとっては、既得権の見直しになる。誰かにとっては、これまでの運用の否定になる。だからこそ、設計思想の整理とシステム導入を切り離さず、実務と企業の両方を理解した伴走者が必要になります。
私たちが提供しているCOMPANY導入支援サービスは、単なるシステム導入ではなく、人事統合が止まらないための設計整理から支援します。比較に入る前に、立ち止まる。その判断が、統合の成否を分けます。
システム選定に入る前に、まずは私たちにご相談ください。貴社の状況に合わせた進め方についてアドバイスさせていただきます。
