財務チームのためのOKR作成ガイド（2026年版）

まず「目標（Objective）」がOKR用語においてどういう意味を持つかを明確にしましょう。目標は定性的・方向性を示すもの・意欲を高めるものであり、数値ではありません。どこへ向かいたいかを表すものであり、そこに辿り着いたかどうかをどう測るかを示すものではありません。

財務チームがよく陥る失敗は、KPIのような目標を書いてしまうことです：「粗利益率38.5%を達成する」「決算を6営業日で締める」。これらは主要結果（Key Result）であり、目標ではありません。これらを含む目標（Objective）は、たとえばこのようになります：「財務報告を、記録するためではなく、意思決定を変えるほど迅速なものにする」

ベースラインのないOKRは、フォーマットを整えただけの当てずっぽうです。ターゲット数値を1つでも書く前に、主要結果の候補として考えている各指標について、過去4〜6四半期分のデータを実績から引き出す作業に30分を費やしてください。

年間経常収益35億円規模のSaaS企業の財務チームであれば、たとえばこのようなデータを引き出します：決算サイクルの所要日数（決算ログから、現在の平均9日）、予測差異（過去6四半期の平均絶対誤差、現在12%）、バーンレート予測の精度（現在平均で18%のズレ）。これらの数値がベースラインになります。設定するすべてのターゲットは、このベースラインとの比較で論拠を示す必要があります。

単一のターゲット数値は多くの場合、「達成できそうな水準」と「意欲的に見える水準」の妥協点になりがちです。その結果、どちらでもない数値になってしまいます。より効果的なフレームワークとして——ジョン・ドーアが『Measure What Matters』（Portfolio/Penguin、2018年）で体系化した——3段階を使います：フロア、ターゲット、ストレッチです。

ドーアのフレームワークのスコアリング基準では、1.0満点中0.7が高い達成水準とされています。毎回1.0を達成しているなら、ターゲットが十分に意欲的ではないサインです。予算を必ず達成することに慣れた財務チームにとっては直感に反するかもしれませんが、フレームワークを正しく機能させるためには重要な考え方です。

決算サイクルのKR例：フロア＝8日、ターゲット＝7日、ストレッチ＝6日（ベースライン9日から）。予測精度のKR例：フロア＝MAEを10%に削減、ターゲット＝8%、ストレッチ＝5%。

フロア・ターゲット・ストレッチが定義されたら、スコアリングを自動化できます。計算式は段階間を線形補間します。実績・フロア・ターゲット・ストレッチを構造化されたテーブルに配置すれば、スコアが自動計算されます。

OKRトラッカータブの構成が次のようになっているとします：A列＝KR名、B列＝フロア、C列＝ターゲット、D列＝ストレッチ、E列＝実績。F列のスコアリング計算式：

=IF(E2<B2, 0,
  IF(E2<=C2, 0.3 + (E2-B2)/(C2-B2)*0.4,
    IF(E2<=D2, 0.7 + (E2-C2)/(D2-C2)*0.3,
    1.0)))

この式は、フロア未満で0、フロアとターゲットの間で0.3〜0.7、ターゲットとストレッチの間で0.7〜1.0と補間します。決算サイクルや予測誤差など、値が低いほど良いKRの場合は方向を逆にします：

=IF(E2>B2, 0,
  IF(E2>=C2, 0.3 + (B2-E2)/(B2-C2)*0.4,
    IF(E2>=D2, 0.7 + (C2-E2)/(C2-D2)*0.3,
    1.0)))

単独のOKRトラッカーは、誰も確認しないスプレッドシートにすぎません。意思決定を実際に動かすのは、財務モデルから実績を直接引き込むバージョンです。ここでの設定が活きてきます。

決算サイクルの所要日数が 決算ログ タブに、予測差異が 予算対実績 タブに、バーンデータが キャッシュフロー タブにあるとすれば、OKRトラッカーの「実績」列はそれらを直接参照すべきです：

='決算ログ'!D26
='予算対実績'!H2
=SUMIFS('キャッシュフロー'!C:C,'キャッシュフロー'!B:B,">="&Assumptions!$B$3)/'キャッシュフロー'!D2

これらはどれもハードコーディングしてはいけません。実績データが入力されてモデルが更新されると、OKRスコアも自動的に更新されます。

実績データがSheets外にある場合——HubSpotやデータウェアハウスにある場合など——は、ModelMonkeyが役立ちます。締め済み四半期のデータをトラッカータブに直接引き込めるため、取締役会資料の作成直前にミスが起きやすい手動エクスポート&ペーストの作業を省けます。

レビューは、OKRが実質的な意味を持つか、それとも形式的な作業にすぎないかが問われる場です。財務チームの四半期末レビューは45〜60分で完結し、3つのアウトプットを生み出すべきです：正直なスコア、各未達・達成に対する因果関係の説明、そして何を次に持ち越すかの判断です。

APQCの財務計画プロセスに関するベンチマーク調査では、計画精度に関する構造的な振り返りを行うチームは、そうでないチームよりも予測差異の改善が一貫して速いことが示されています——未達の原因を説明する規律が、「単なる差異」ではなく「どのモデル仮定が誤っていたか」の特定を促すためです。同じ論理がOKRの未達にも当てはまります。Q1の決算サイクルの未達をデータの問題（「システムが遅かった」）として処理したチームは、プロセスの問題（「遅延提出に対するバッファがなかった」）を特定したチームと比べて、根本的な課題を解決できないまま終わります。

1〜2サイクルを経ると、構造的な問題が顕在化してきます。財務チームに特有の、OKRプログラムを機能不全にするパターンを解説します。

最も多いのは、業務上の義務をOKRで管理しようとすることです。決算作業はOKRではありません。それは業務要件です。OKRは改善しようとしているところを反映すべきであり、契約上義務付けられていることを記録するものではありません。「Q3の監査を10月15日までに完了する」がリストに入っているとすれば、それは目標設定ではなくプロジェクト管理に滑り込んでいます。

2つ目は、四半期末まで測定できないKRを設定することです。「監査指摘事項を30%削減する」といったKRは年に1度しか測定できません。軌道修正の余地が残っている段階でフィードバックを得るためにも、毎月進捗を確認できるKRが必要です。

3つ目は、モデルと切り離されたOKRです。「予測差異を8%に削減する」というOKRを掲げながら、モデルの予測方法論が何も変わっていないなら、それは計画ではなく希望です。各KRには、ターゲット達成の可能性を高める具体的なプロセスやモデル構造の変更を伴わせてください。