OKRソフトウェアとHRIS連携：財務部門が知るべき同期データの実態（2026年）

2つのシステム間で実際に何が移動し、何が移動しないのかを正確に把握することが、変動報酬計算の信頼性を左右します。それを理解していなければ、どれだけ精緻な数式を組んでいても、計算の根拠は推測の域を出ません。

OKRとHRIS連携で実際に同期されるデータ

標準的な連携はほぼ一方向です。HRISからOKRソフトウェアに社員レコードがプッシュされます。入社者があれば、LatticeやBetterWorksのプロフィールが24時間以内に作成されます。退職者は無効化され、部署異動があれば報告ラインが更新されます。

一般的に同期されるフィールド：

社員ID（すべてを紐づけるジョインキー）
氏名、メールアドレス、役職
部署およびコストセンターコード
上長との関係性（目標カスケードに使用）
雇用ステータスと有効日付

同期されないもの：報酬データ。 基本給、賞与目標率、株式報酬はHRIS内に留まります。変動報酬計算の実質的なドライバーであるOKR達成率は、OKRプラットフォーム内に留まります。

Merge.devのUnified HRIS APIドキュメント（2025年版）によれば、HRISとOKRツール間のほとんどのネイティブ連携は、リアルタイムのWebhookではなく日次バッチ処理で動作しています。つまり、組織変更から最大24時間、OKRシステムへの反映が遅れる可能性があります。通常は問題ありませんが、賞与計算サイクルの途中で組織再編が発生するケースでは注意が必要です。

リバース同期に対応しているプラットフォームもあります。Latticeの公式ドキュメント（Workday連携ガイド、2026年現在）によると、LatticeはWorkdayの人材管理モジュールに評価レーティングを書き戻す機能を持っています。ただしここで転送されるのは「期待を上回る」「期待通り」といった評価区分であり、達成率のパーセンテージではありません。またその情報はWorkdayの人材管理モジュールに格納されるため、給与計算や財務部門がそのまま活用できるフォーマットにはなっていません。

OKRとHRISの連携が完璧でも賞与引当の計算が崩れる理由

四半期の賞与引当には、社員ごとに3つの数字が必要です。基本給、賞与目標率、達成率。最初の2つはHRISにあります。3つ目はOKRプラットフォームにあります。

OKRとHRISの連携が整備されていれば、少なくとも両システムの社員名簿は一致しています。計算を始める前に2つの異なる社員リストを突き合わせる作業は不要になります。社員数75名以上の企業では、この名寄せ作業だけで賞与計算のたびに3〜4時間を消費していたケースもあります。

エクスポートデータをGoogle Sheetsに取り込んでジョインした後の計算式：

=SUMPRODUCT(
  HRIS!F2:F200,        -- 基本給
  HRIS!G2:G200,        -- 賞与目標率
  OKR_Export!D2:D200   -- OKRプラットフォームからエクスポートしたQ2達成率
)

P&Lに連動する部門別引当計算：

=SUMPRODUCT(
  (HRIS!C2:C200=Assumptions!$B$4) *   -- 部署でフィルタ
  HRIS!F2:F200 *                        -- 基本給
  HRIS!G2:G200 *                        -- 賞与目標率
  OKR_Export!D2:D200 *                  -- 達成率
  (1/4)                                 -- 四半期引当係数
)

計算式自体は機能します。問題はOKR_Exportシートです。OKRプラットフォームからエクスポートし、列構成を整えて、正しい場所に貼り付ける作業を誰かが毎四半期行わなければなりません。もし前四半期と異なる列名でエクスポートされると（これは思った以上によく起きます）、計算式はエラーも出さずに壊れ、引当額がずれたまま誰も気づかない事態になります。

たとえば社員120名、平均基本給700万円、変動報酬目標率20%の企業であれば、年間賞与原資は1.68億円になります。達成率の列がひとつずれているだけで、この金額に直接影響します。

4つの連携パターンと財務部門が得られるもの

連携の設計によって、財務部門の使い勝手は大きく異なります。

パターン	概要	同期頻度	財務部門での活用度
ネイティブ連携（Workday＋Lattice、SmartHR＋15Fiveなど）	HR/ITが設定する組み込みコネクタ	日次バッチ	組織データはクリーンだが、達成率は引き続き手動エクスポートが必要
ミドルウェアAPI（Merge.dev、Finch、Ripplingなど）	複数プラットフォームのフィールドを統一APIで正規化	15分〜日次で設定可能	カスタムデータ取得に有効だが、IT部門の関与が必要
SCIMプロビジョニング	SSOと連動したユーザーアカウント管理のみ	ほぼリアルタイム	IDマネジメント専用。報酬計算への活用は不可
SFTP/CSVスケジュールエクスポート	共有ドライブやメールへの自動ファイル配信	日次または週次	財務部門にとって最も実用的なパターン

「ネイティブ連携」は理想的に聞こえますが、財務部門が享受できるメリットは最も少ないケースが多いです。HRがOKRツールに正確な組織データを持てるようになる一方、財務は引き続き両システムからエクスポートして手動でジョインする作業が続きます。

SFTP/CSVエクスポートが財務部門にとって最も実用的なパターンである理由は、技術的な優位性ではありません。財務モデルに直接インポートできるファイルを生成できるという点が決め手です。ITがHRISの週次エクスポートとOKR達成率の週次エクスポートを同じ共有ドライブに自動配信する設定を入れてくれれば、実務上の問題はほぼ解決します。

誰も語らない「最後の1マイル」問題

見落とされがちな重要な点があります。OKRとHRISの連携が完璧に構築されていても、財務部門のループは閉じません。この連携はHRのインフラです。2つのHR系システムを同期させるためのものです。財務モデルは第3のシステムであり、連携設計の対象からほぼ常に除外されています。

実際のデータの流れはこうなります：

HRIS → OKRソフトウェア（皆が期待を寄せる連携部分）→ OKRエクスポート → 誰かが整形 → モデルに貼り付け

この最後の3ステップは、HRISとOKRの連携がどれほど高度であっても、完全に手作業です。連携によって削減できるのは「OKRツール上の社員リストが古くなる」というリスクのみ。財務モデルが実際に必要とする数値を生成するための、手動エクスポートと突き合わせ作業は残り続けます。

人事部長から「SmartHRと15Fiveを連携したので、賞与計算に必要なデータは揃っているはずです」と言われた場面を想像してください。組織データの精度は確かに上がっています。ただし達成率は、まだモデルに入っていません。

IT部門を巻き込まずに達成率データをモデルに取り込む方法

エクスポート仕様を標準化する

人事部門に対して、特定の列名・列順を指定したテンプレートを渡してください。「社員ID、部署、Q3達成率」というように、デフォルトのエクスポート出力ではなく財務側が必要とする形式を明示します。プラットフォームごとに一度設定してドキュメント化しておけば、OKRベンダーが変わっても同じテンプレートを渡すだけで済みます。

ただし、テンプレートを渡しても実際に守られるかどうかは別問題です。ツールのバージョンアップやエクスポート担当者の変更で、気づかないうちに列名が変わることは珍しくありません。「標準化テンプレートを運用する」と「それが崩れたときに検知する仕組みを持つ」は、セットで考える必要があります。

ジョインキーは社員ID一択。氏名は使わない

システムをまたぐと同じ人でも名前の表記が異なるケースがあります（HRISでは戸籍名、OKRツールでは通称名など）。社員IDのみが唯一の信頼できるキーです。

=IFERROR(
  INDEX(OKR_Export!$D:$D,
    MATCH(HRIS!$A2, OKR_Export!$A:$A, 0)
  ),
  0   -- マッチしない場合は達成率0%（入社直後などでOKR未登録）
)

引当計算を実行する前にマッチ率を検証する

ジョイン後に未マッチの社員数を確認してください。全社員の5%超が達成率とマッチしない場合、何か問題が起きています。OKR同期ラグによる社員リストのズレや、期中入社者の未登録が主な原因です。

=COUNTIF(OKR_Joined!E2:E200, 0) / COUNTA(OKR_Joined!A2:A200)

この比率が5%を超えている場合は、CFOに数字を報告する前に人事部門と確認を取る価値があります。

列名がずれたときの対処法：ヘッダー行をダイナミックに参照する

マッチ率検証の次に詰まるのが、ここです。前四半期までD列だった達成率が、今期のエクスポートではF列に移動していた--このとき、ハードコードされた列参照はエラーも出さずに壊れます。

対策は2つあります。

①列名でINDEX/MATCHを組む（最も堅牢）

列番号ではなく、ヘッダー行の列名をキーにして参照列を動的に特定します。

-- OKR_Exportシートの1行目（ヘッダー行）から
-- "Q3_achievement_rate"という列を探して、その列全体を参照する

=INDEX(
  OKR_Export!$1:$1000,        -- データ全体
  MATCH(HRIS!$A2, INDEX(OKR_Export!$1:$1000, 0,
    MATCH("employee_id", OKR_Export!$1:$1, 0)), 0),
  MATCH("Q3_achievement_rate", OKR_Export!$1:$1, 0)
)

列番号が変わっても、ヘッダー行にQ3_achievement_rateという文字列さえ存在すれば正しい列を参照し続けます。

②INDIRECTでヘッダー参照をAssumptionsシートに集約する

より簡易な方法として、達成率列の列名をAssumptionsシートで管理し、INDIRECTで動的に参照する方法もあります。

-- Assumptions!B10 に "D" と入力しておく（達成率の現在の列記号）
-- エクスポートで列が変わったときはここだけ変更する

=IFERROR(
  INDEX(
    INDIRECT("OKR_Export!" & Assumptions!$B$10 & ":" & Assumptions!$B$10),
    MATCH(HRIS!$A2, OKR_Export!$A:$A, 0)
  ),
  0
)

この方法の利点は、列が変わったときに修正箇所が1セルで済むことです。欠点は、Assumptionsシートを更新する担当者が列の変更に気づく必要があること。それでも「40箇所の数式を修正する」よりははるかに安全です。

どちらのアプローチを選ぶにしても、エクスポートのたびにヘッダー行の列名が前回と一致しているかをチェックするセルを設けることを強く推奨します。

-- A1に前回のヘッダー行スナップショットを保存しておき、
-- 今回のエクスポートのヘッダー行と比較する
=IF(
  EXACT(JOIN(",", OKR_Export!1:1), Assumptions!$C$2),
  "ヘッダー変更なし ✓",
  "⚠ ヘッダーが変更されています。列参照を確認してください"
)

このチェックセルが警告を出した時点で、引当計算を止めて確認に入れます。列名のズレを見落とすリスクを、仕組みの力で排除するということです。

Assumptionsシートをロックする

引当タイミング（月次 vs. 四半期次）、部門集計ロジック、達成率の下限・上限ルール、そして上記の列名管理は、個々の計算式にハードコードせず、Assumptionsシートで一元管理してください。OKRサイクルが四半期評価から随時評価に変更になったとき（いずれ必ずそうなります）、40箇所の計算式を修正するのではなく、1つのセルを変更するだけで対応できます。

よくある質問

Q：OKRソフトウェアとHRISを連携すれば、賞与計算は自動化できますか？

A：いいえ。OKRとHRIS連携が自動化するのは社員レコードの同期のみです。賞与計算に必要な「達成率」はOKRプラットフォームに残ったままであり、財務モデルへの取り込みは依然として手動エクスポートが必要です。連携によって組織データの精度は上がりますが、財務部門の手作業をゼロにするわけではありません。

Q：WorkdayとLatticeを連携済みですが、達成率がWorkdayの給与モジュールに反映されないのはなぜですか？

A：Lattice→Workdayのリバース同期で書き戻されるのは「期待を上回る」などの評価区分のみで、達成率のパーセンテージは含まれません。また書き戻し先はWorkdayの人材管理モジュールであり、給与計算モジュールとは別です。2026年現在、この制約はLattice以外のほとんどのOKRプラットフォームにも共通して当てはまります。

Q：SCIMプロビジョニングとネイティブHRIS連携は何が違いますか？

A：SCIMはユーザーアカウントの作成・無効化を管理するIDプロビジョニング規格で、主にSSOと連動します。同期されるのはログイン情報のみです。ネイティブHRIS連携はより広範な組織データ（部署、上長関係、コストセンター等）を同期しますが、どちらも報酬データや達成率は対象外です。

Q：HRISとOKRツールの連携は何分おきに更新されますか？

A：2026年現在、ほとんどのネイティブ連携は日次バッチ処理（最大24時間の遅延）です。ミドルウェアAPI（Merge.devなど）を使えば15分〜1時間単位での同期も可能ですが、IT部門の設定作業が必要になります。SCIMのみがほぼリアルタイムですが、対象はIDマネジメントに限られます。

Q：OKRエクスポートの列名が変わったとき、どうすれば早期に気づけますか？

A：ヘッダー行の列名を前回スナップショットと比較する検知セルをモデルに組み込むのが最も確実です。詳細は上述の「ヘッダー行をダイナミックに参照する」セクションをご参照ください。エクスポートのたびに目視確認するよりも、仕組みとして検知する方が長期的な信頼性は高まります。

Q：OKRとHRIS連携のデータ精度を財務部門が独自に検証するには？

A：毎四半期の計算前に、HRIS社員リストとOKRエクスポートの社員IDをジョインし、未マッチ率を算出してください。5%以上のズレがある場合は人事部門に確認を取ることを推奨します。社員IDをジョインキーとして使い、氏名では突き合わせないことが精度確保の基本です。

ここで説明したデータ突き合わせ作業--マッチ率検証、列名の変更検知、動的ヘッダー参照--は、賞与計算のたびに繰り返される手作業です。ModelMonkeyを使えば、Google Sheets上で直接この処理を実行できます。「社員IDでOKR達成率とHRIS社員データをマッチさせ、未マッチのレコードにフラグを立て、列名の変更を検知する」と指示するだけで、エクスポートごとの構造変化に自動で対応しながら構築・検証まで完了します。ModelMonkeyのプランを選ぶ。Google SheetsとExcelの両方に対応しています。