OKRと報酬連動：FP&Aチームのためのモデル設計ガイド

GoogleのOKRフレームワークは、当初からスコアを報酬決定に使用しないことを前提に設計されています。Google re:Workの公式ドキュメント「OKRについて学ぶ（Set goals with OKRs）」には「OKRは個人のパフォーマンス評価や報酬決定のためのツールではない」と明記されています。多くの企業はこれを読んで一応納得した様子を見せながら、結局はOKRスコアをボーナス算定式に直接組み込んでいます。

これはポリシーの選択であり、必ずしも誤りではありません。しかし、ほぼすべてのOKR実装ガイドが触れない特定のFP&A上の問題を生み出します。OKRの達成度が報酬のモディファイアになると、ボーナスプールのモデルには相関分布の問題が生じ、モデルを正しく設計しない限り、中間期の費用計上が単なる見積もりに成り下がります。

GoogleがOKRと報酬を切り離している理由

仕組みはシンプルです。OKRスコアがボーナスに影響すると分かれば、社員は達成しやすい目標を設定します。これは文書化されており、予測可能な動きで、OKRを報酬に連動させたほぼすべての企業で実際に起きています。Deloitteが実施したパフォーマンスマネジメントに関する調査レポート「Performance management: Playing a winning hand」（2023年）では、目標達成度を変動給に直接連動させた後、58%のHRリーダーが目標設定の厳格さが低下したと報告しています。

Googleのスコアは0.0〜1.0のスケールで、0.6〜0.7が「良好」とされています（Google re:Workのスコアリング手法の詳しい解説はこちら）。このキャリブレーションの根拠は、1.0が常に達成可能なら目標の難易度が足りないという考え方です。報酬連動はこのロジックを逆転させます。0.6では給与に影響が出るリスクがあるため、社員は0.8を安全圏として目標設定するようになります。

Googleはこの問題を回避するために両者を切り離しています。ただし、それはGoogleの話です。多くのFP&Aチームは、Googleの報酬体系をモデル化しているわけではありません。

実際にはどうOKRを報酬に組み込むか

実務上、最も一般的な設計は二項対立式（OKR達成＝ボーナス支給）ではなく、モディファイア構造です。

会社全体のOKR達成度がボーナスプール全体への資金積み上げ額を調整する（目標額の70〜130%が一般的）
個人またはチームのOKRスコアがプール内の個人支給額を調整する
マネージャーの裁量が計算式の出力と最終支給額のギャップを埋める

会社のOKR達成度が0.72となり、ボーナスプールへの積み上げが85%にとどまった場合、5億円の年間ボーナスプールは4億2,500万円の配分になります。この差額7,500万円はそのまま損益に直撃します。四半期ごとの費用計上が満額を前提としていれば、第4四半期に7,500万円を戻し入れることになります。これはマテリアルな金額です。取締役会向け資料では調整項目として登場し、財務部門がその振れ幅を事前にモデル化していなければ、「想定外の数字」として映ります。

OKR連動あり・なし：モデル設計の主な違い

比較項目	OKR連動なし	OKR連動あり
ボーナスプール予測	固定額で計上可能	達成度によって70〜130%変動
費用計上の安定性	高い	四半期ごとに修正が必要
目標設定への影響	ストレッチ目標を立てやすい	安全な目標に誘導されやすい
FP&Aの工数	低い	OKRデータ連携・感度分析が必要
下振れリスク	売上差異のみ	売上差異とOKR達成度の複合
モデルの複雑度	シンプル	相関変数を考慮した設計が必要

モデリングの課題：相関分布の問題

多くのモデルが見落とすアクチュアリアル的な問題がここにあります。OKRスコアは業績から独立していません。会社が売上目標を12%下回ると、OKRも低い水準に着地しやすい傾向があります。常にそうとは限りませんが、頻繁に起きます。これは次のことを意味します。

ボーナスプールへの積み上げ額が不足する（売上のネガティブ差異）
OKRモディファイアが1.0を下回る（達成度の低迷）
両者が同時に費用計上を圧縮する

ボーナスプールへの積み上げとOKRモディファイアを独立した変数として扱うモデルは、下振れシナリオを大幅に過小評価します。売上10%未達に加えて、OKRの平均達成度が想定0.80に対して0.65だった場合、5億円のプールが3億3,000万円まで圧縮されるケースがあります。33%の変動です。

正しい設計は、両変数を独立ではなく連動させた感度分析テーブルです。

Google Sheetsでのコンプモデル実装ガイド

実用的な実装では、Assumptions、OKR_Tracker、Headcount、Comp_Model、Bonus_Accrualの5タブ構成を推奨します。それぞれの連携方法を説明します。

Assumptionsタブに主要インプットを格納します。ボーナスプール目標額（5億円）、会社OKRの積み上げカーブ（達成度とプール率のマッピングテーブル。例：0.6→70%、0.8→100%、1.0→130%）、個人モディファイアの範囲です。

OKR_Trackerには四半期ごとのスコアを記録します。目標1件につき1行で、列は担当者・部門・四半期ウェイト・スコアです。部門別ロールアップの式は以下のとおりです（例：エンジニアリング部門のQ3加重平均スコア）。

// Comp_Model!D4 - エンジニアリング部門のOKRスコア（Q3加重平均）
=SUMPRODUCT(
  (OKR_Tracker!$C$2:$C$200="Engineering")*
  (OKR_Tracker!$D$2:$D$200="Q3")*
  OKR_Tracker!$E$2:$E$200*
  OKR_Tracker!$F$2:$F$200
) /
SUMPRODUCT(
  (OKR_Tracker!$C$2:$C$200="Engineering")*
  (OKR_Tracker!$D$2:$D$200="Q3")*
  OKR_Tracker!$E$2:$E$200
)

Comp_Modelでの個人ボーナス計算では、Headcountから基本給、Assumptionsからボーナス目標率、OKR_TrackerからOKRモディファイアを参照します。

// Comp_Model!G4 - 個人ボーナス費用計上（年間）
=Headcount!$E4 *
 VLOOKUP(Headcount!$D4, Assumptions!$B$14:$C$18, 2, FALSE) *
 IFERROR(
   VLOOKUP(Headcount!$A4, OKR_Tracker!$A:$G, 7, FALSE),
   Assumptions!$C$22   // 個人スコア未入力時は会社平均にフォールバック
 ) *
 VLOOKUP(Assumptions!$B$4, Assumptions!$F$3:$G$8, 2, TRUE) // 会社プール積み上げモディファイア

会社レベルのプール積み上げモディファイアでVLOOKUPの範囲検索をTRUEにしているのは、達成度の閾値間で補間するためです。完全一致ではなく近似値での検索が適切な設計です。

Bonus_Accrualでは、期間按分を加えて四半期別に集計します。

// Bonus_Accrual!C6 - エンジニアリング部門のQ3ボーナス費用
=SUMIFS(
  Comp_Model!$G:$G,
  Headcount!$C:$C, "Engineering",
  Headcount!$H:$H, "<>" & "Termed"
) * Assumptions!$D$6 // Q3の按分率（例：25%）

スコア分布の問題

ここまでの設計が正しくても、多くのモデルが見落とす問題があります。計算式のOKRモディファイアは平均スコアを使用していますが、実際の総支給額に影響するのはスコアの「分布」です。組織全体でボーナス目標額は均一ではないからです。

年収1,500万円の部長職のスコアが0.95、年収600万円のアナリストのスコアが0.60だとします。この2名のOKRスコアの単純平均は0.775です。しかし実際のボーナス費用を左右するのは、金額加重平均です。

= (1,500万円 × 20% × 0.95 + 600万円 × 12% × 0.60) ÷
  (1,500万円 × 20% + 600万円 × 12%)
= (285万円 + 43.2万円) ÷ (300万円 + 72万円)
= 328.2万円 ÷ 372万円
= 0.882

0.775とは異なります。高年収かつOKRスコアが高い社員は、総報酬費用に対して単純平均以上の影響を持ちます。単純平均の達成度を使ったモデルは、ハイパフォーマーがOKRスコアでも上位を占めているとき、費用計上を過小評価することになります。

修正方法はシンプルです。OKRモディファイアを人数加重平均ではなく金額加重平均で計算することです。ただし、最初からその設計にしておく必要があります。人数加重を前提に組んだ計算式に金額加重を後から組み込むのは、モデル構造の大幅な変更を伴います。

2026年6月現在、これはOKR連動型報酬モデルで最もよく目にする設計ミスです。また、第4四半期の決算クローズで戻し入れが発生する可能性が最も高いエラーでもあります。

四半期末のOKRデータ更新

もう一つの実務的な課題があります。OKRスコアの確定は、四半期末から2〜4週間後になるのが一般的です。Q3の帳簿は10月に締まりますが、最終OKRスコアが出揃うのは10月中旬になることがあります。これにより、未確定の暫定スコアを基に費用計上するというタイムラグが生じます。

対応策は2つあります。①前四半期の平均達成度を仮の数値として計上し、翌期に差額修正する。②どの社員のOKRスコアが暫定値か確定値かをモデルでフラグ管理し、単一の点推定ではなく幅を持たせた試算を出す。

AsanaやLattice、または自社構築のSheetsトラッカーからOKRスコアを取り込んでいる場合、ModelMonkeyを使えば四半期末に自動でデータをコンプモデルへ反映できます。CSVを手動エクスポートする手間なく、締め時点のスコアを「暫定」フラグ付きで費用計上に反映させることが可能です。Google SheetsおよびExcel両方に対応しており、ModelMonkeyのプランを選ぶ。

よくある質問

Q. OKRスコアをボーナスに連動させると、必ずストレッチ目標が設定されにくくなりますか？

必ずしもそうとは限りませんが、設計上のリスクとして織り込む必要があります。Deloitteの調査では、58%のHRリーダーが目標設定の厳格さ低下を報告しています。マネージャーの裁量幅を十分に確保し、目標設定プロセスでの上位キャリブレーションを行うことで、ある程度は緩和できます。

Q. FP&Aモデルでは、OKRスコアをいつ確定値として扱えばよいですか？

四半期末から2〜4週間後が実務上の目安です。それまでは前四半期の平均達成度を暫定値として使用し、モデル上で「暫定」フラグを立てておくことを推奨します。確定スコアに差し替えた際の差額修正を翌期に織り込んだ設計にしておくと、決算クローズ時の戻し入れを最小化できます。

Q. 会社全体のOKR達成度と個人OKRスコアは、別々に管理すべきですか？

はい、必ず分けてください。会社レベルのOKRはボーナスプール全体の積み上げ率を決め、個人・チームレベルのOKRはプール内の配分を決めます。この2層構造を1つの変数に統合してしまうと、どちらの要因によって費用計上が変動したのかの原因分析ができなくなります。

Q. 金額加重平均と人数加重平均、どちらを使うべきですか？

ボーナス費用の予測精度を優先するなら、金額加重平均を使うべきです。人数加重平均はシンプルで直感的ですが、高年収層のOKRスコアが高い傾向がある組織では、費用計上を体系的に過小評価します。モデルを最初に設計する段階で金額加重を採用しておくことが、後から修正する工数を避ける最善策です。

Q. 感度分析テーブルには何を軸に取ればよいですか？

横軸に売上達成率（例：80%〜120%）、縦軸に会社OKR達成度（例：0.5〜1.0）を取り、各セルにボーナスプール積み上げ額を表示する2次元テーブルが標準的です。下振れシナリオ（売上未達×OKR低達成）と上振れシナリオ（売上超過×OKR高達成）の両極端を可視化することで、取締役会向け資料での説明も容易になります。