実際に機能するOKR管理スプレッドシートには、会社・チーム・個人の3階層が必要です。各層をロールアップ数式でつなぎ、進捗を自動集計できる構造にしてはじめて、毎週金曜日の手作業更新から解放されます。多くのテンプレートはこのロールアップを省略しているため、6週目には誰も更新しなくなるのです。
OKRプログラムの普及を支援するコンサルティング会社Whatmattersをはじめ、複数の実務家が一致して指摘するのは、初年度のOKR導入が頓挫する最大の原因はゴール設定の失敗ではないということです。トラッキングシステムの維持管理が、実際の業務より手間がかかってしまうことが最大の原因です。
本記事では、スプレッドシートの構造、必要な数式、そして陥りがちな失敗パターン——よく紹介されている数式の隠れた落とし穴も含めて——を具体的に解説します。
なぜOKR管理スプレッドシートは破綻するのか
典型的なOKRテンプレートはフラットなリスト構造です。A列に目標（Objective）、B列にキーリザルト（Key Result）、そして誰かが手で埋める「進捗」列——これだけです。チームが1つで目標が3つなら機能します。しかし4チーム、12目標、40キーリザルトになった途端、月曜の全社会議前に誰かが全データを手作業で全社ビューに集約しなければなりません。
構造的な問題は予測可能です：
- 階層間のつながりがない。 チームOKRと会社OKRが別タブに存在し、数式でリンクされていない。会社スコアは誰かが手計算で出す。
- スコアリング基準がバラバラ。 あるチームは0〜100%、別のチームは0〜1スケール、さらに別のチームは赤・黄・緑のRAGステータスを使う。四半期レビューが「変換作業」になってしまう。
- キーリザルト担当者が静的。 四半期途中で担当者が変わっても追跡されないため、レビュー時に間違った人に連絡が行く。
- コンフィデンス（達成確信度）を記録していない。 残り2週間で進捗20%という状況を把握したときにはもう手遅れです。週次でコンフィデンスを更新していれば、4週目の段階で異常を検知できたはずです。
実用に耐えるOKR管理スプレッドシートの構造
組織の複雑さに対応できる構造は、4つのタブで構成されます：
| タブ | 用途 | 主なカラム |
|---|---|---|
Company OKRs | 全社目標。チームから自動集計 | Team、Objective、Score（自動）、Owner、Timeframe |
Team OKRs | チーム別目標とキーリザルトを一覧 | Team、Objective、KR ID、Key Result、Target、Current、Score、Owner、Confidence |
KR Log | 週次進捗の追記専用ログ | Date、KR ID、Value、Notes |
People | ドロップダウン検証用の担当者マスタ | Name、Team、Email |
スコアリング基準は、OKRの提唱者ジョン・ドーアの著書『Measure What Matters（OKR）』に従います：0.7が「順調」、1.0は「達成」（目標設定が低すぎた可能性も）、四半期中盤で0.4未満は要対話。スプレッドシート内のすべてのスコアはこの0〜1スケールで統一します。
Team OKRs タブのカラム構成：
| 列 | ヘッダー | 種別 |
|---|---|---|
| A | Team | ドロップダウン（Peopleタブから） |
| B | Objective | テキスト |
| C | KR ID | 静的な識別子（後述） |
| D | Key Result | テキスト |
| E | Target | 数値 |
| F | Current | 数値（KR Logから取得 or 手入力） |
| G | Score | 数式（=MIN(F2/E2,1)） |
| H | Owner | ドロップダウン（Peopleタブから） |
| I | Confidence | ドロップダウン（High / Medium / Low） |
| J | Timeframe | テキスト（Q1 2026、Q2 2026 など） |
G列は MIN() で上限を1に固定し、超過達成がロールアップを歪めないようにします。I列（Confidence）が早期警戒システムです。進捗60%でコンフィデンスが「Low」のキーリザルトと、同じく60%で「High」のキーリザルトでは、まったく意味が異なります。
KR IDの正しい運用：数式ではなく静的管理を推奨
KR IDは行を一意に識別するためのキーです。=A2&"-KR"&COUNTIF($A$2:A2,A2) のような数式で自動生成する方法を紹介しているテンプレートも多いですが、行を並び替えた瞬間にカウントがずれてIDが重複・変化します。 KR LogはKR IDを外部キーとして参照しているため、ID変化はログ参照の破損に直結します。
推奨する運用は2つです：
方法1：シンプルな静的プレフィックス方式（推奨）
SALES-Q1-KR01、ENG-Q1-KR01 のように「チーム略称-四半期-連番」で手動で一度だけ入力し、値として確定させます。入力後にセル保護をかけて変更不可にします。冗長に見えますが、ログとの参照整合性が永続的に保たれます。
方法2：数式生成後に値貼り付け
=A2&"-KR"&COUNTIF($A$2:A2,A2) で生成した後、列全体をコピー→「値のみ貼り付け」で数式を取り除きます。以降は静的な文字列として扱われるため並び替えに影響されません。四半期開始時に一度だけ実施する作業として割り切る方法です。
どちらの方法でも、KR IDはいったん確定したら絶対に変更しないことが大原則です。KR Logの全履歴がこのIDに紐づいているため、変更すると過去ログの参照が切れます。
ロールアップ数式の組み方：AVERAGEIFSが正解
Company OKRs タブで各目標のスコアを集計するとき、よく紹介される AVERAGEIF には重大な落とし穴があります。
=AVERAGEIF('Team OKRs'!$B:$B, B2, 'Team OKRs'!$G:$G) ← 危険
この数式はObjective名だけで絞り込むため、異なるチームに同じ目標名が存在すると両方を集計してしまいます。 実際の組織では「業務効率化」「顧客満足度向上」といった目標が複数チームに存在するケースは珍しくありません。
正しい実装は AVERAGEIFS でチーム名とObjective名の両方を条件にします：
=AVERAGEIFS('Team OKRs'!$G:$G, 'Team OKRs'!$A:$A, A2, 'Team OKRs'!$B:$B, B2)
Company OKRs タブのA列にチーム名、B列にObjective名を置いた構成を前提としています。第1引数がスコア範囲、第2・第3引数以降が条件のペアです。これで「営業チームの営業効率化目標」と「運営チームの営業効率化目標」を区別して集計できます。
全チームを横断した全社スコアが必要な場合（特定の全社戦略目標に複数チームのOKRが紐づくケース）は、目標名の命名規則で対応します。[全社] 顧客基盤拡大 のようなプレフィックスをつけ、チーム側OKRにも同じ名称を使うことで、意図的に横断集計できる構造を作れます：
=AVERAGEIF('Team OKRs'!$B:$B, B2, 'Team OKRs'!$G:$G)
この場合は [全社] プレフィックスつきの目標名がユニークになるため、AVERAGEIF でも機能します。ただし、この方法を使うチームと通常の AVERAGEIFS を使うチームが混在しないよう、運用ルールを統一してください。
KR Log（追記方式）から最新値を取得する場合（KR LogのA列がKR ID、B列が数値）：
=MAXIFS('KR Log'!$B:$B, 'KR Log'!$A:$A, C2)
これは「最大値」を返します。KRが売上高や顧客数のように単調増加する指標であれば問題ありません。しかし、リードタイムや不良率のように小さい方が良い指標や、上下に変動する指標では最大値ではなく最新エントリが必要です。その場合：
=INDEX('KR Log'!$B:$B, MATCH(2, 1/('KR Log'!$A:$A=C2), 1))
KR LogをDate列（A列）で昇順に並べることを前提に、該当KR IDの最後のエントリを返します。古いバージョンのSheetsでは配列数式（Ctrl+Shift+Enter）として入力が必要ですが、2026年4月時点のGoogle Sheetsでは通常の数式として機能します。
コンフィデンス列はスコア列より多くを語る
四半期のOKRスコアは「何が起きたか」を教えてくれます。コンフィデンスは「何が起きようとしているか」を教えてくれます。
週次でコンフィデンスを収集するだけで——High/Medium/Lowの3択でも十分——スコアが下落する3〜4週前に問題のキーリザルトを特定できます。レビューの会話が「なぜ未達だったのか」から「何が障害になっていて、今何を変えるべきか」に変わります。これは予実管理の観点からも非常に有効なアプローチです。月次の経営会議で部門長にOKRレビューの意義を説明するとき、このフレーミングは特に有効です。
Confidenceカラムには条件付き書式を設定しましょう：
High → 緑背景 (#B7E1CD)
Medium → 黄背景 (#FCE8B2)
Low → 赤背景 (#F4CCCC)
カスタム数式ルール =$I2="Low" を範囲 $A2:$J2 に適用すると、コンフィデンスが「Low」の行全体が赤くなります。フィルタリング不要で一目で問題箇所を把握できます。
トラッカーを陳腐化させないために
OKRトラッカーが機能しなくなる主な理由は、数式設計の問題ではありません。更新する習慣が続かないことです。1人あたり週20分かかる更新作業は必ず放棄されます。目標は週5分以内です。
更新工数を削減する3つの施策：
1. KR Logへの追記方式を採用する。 担当者に「自分の行を探してセルを更新する」よう求めないでください。「日付・KR ID・数値を新しい行に追加する」だけにします。キーリザルト1件あたり1回のペースト操作で完結します。元データが常に残るため、四半期末の振り返りにも使えます。
2. 自動リマインダーを設定する。 Apps Scriptのトリガーを使えば、毎週月曜朝にトラッカーへのリンクと担当キーリザルトを各オーナーにメール送信できます。ScriptApp.newTrigger('sendReminders').timeBased().onWeekDay(ScriptApp.WeekDay.MONDAY).atHour(9).create() は外部ツール不要で安定して動作します。稟議不要なレベルの軽微な自動化で、リマインド漏れを構造的に防げます。
3. 構造を保護する。 A〜D列と数式列（G列・C列）をシート保護でロックし、編集できるのはCurrent（F列）、Confidence（I列）、メモのみにします。誰でも数式を編集できる状態にしておくと、必ず誰かが編集してしまい、ロールアップが静かに壊れます。
上限の目安として、ジョン・ドーアは1目標あたり3〜5つのキーリザルトを推奨しています。8チーム×3目標という構成でも最大40キーリザルト程度であり、Team OKRs タブ1枚で管理できる範囲です。これを超える規模（10チーム以上、複数事業部にわたる複雑なロールアップ）になれば、スプレッドシートではなく専用のOKRツールの導入を検討するタイミングです。
四半期途中に組織再編が起きた場合や、複数チームのテンプレートを統一する必要が生じた場合など、トラッカーの構造自体を見直す必要があるときは、ModelMonkey を活用してください。チャットで変更内容を伝えるだけで、シート名変更後のAVERAGEIFS数式の修正も含め、トラッカー全体の構造を再構築できます。
よくある質問
OKR管理スプレッドシートには何タブ必要ですか？
最低限 Company OKRs・Team OKRs・KR Log・People の4タブが必要です。これ以下の構成では階層ロールアップを正しく実装できず、手作業の集計が発生します。
キーリザルトのスコアはどう計算すればよいですか？
=MIN(現在値/目標値, 1) が基本です。MIN() で上限を1に固定することで、超過達成がロールアップ平均を歪めるのを防ぎます。スケールは組織全体で0〜1に統一してください。
複数チームに同じ目標名がある場合、全社ロールアップはどうすればよいですか？
AVERAGEIF ではなく AVERAGEIFS を使い、チーム名と目標名の両方を条件として指定します。=AVERAGEIFS('Team OKRs'!$G:$G, 'Team OKRs'!$A:$A, A2, 'Team OKRs'!$B:$B, B2) のように記述することで、同名目標の混在を防げます。複数チームを横断する全社戦略目標には [全社] などの共通プレフィックスをつけ、意図的に横断集計できる命名規則を採用してください。
KR IDを数式で自動生成すると何が問題ですか？
COUNTIF ベースの自動生成式は行を並び替えた際にIDが変化・重複します。KR LogはKR IDを外部キーとして参照しているため、IDが変わると過去ログの参照が切れます。四半期開始時に一度だけ数式で生成し、「値のみ貼り付け」で静的な文字列に変換してからセル保護をかけることを推奨します。
スプレッドシートで管理できるOKRの上限はどのくらいですか？
8チーム×3目標×5キーリザルトで最大120行程度、Google Sheetsは問題なく処理できます。それ以上の規模（10チーム以上、複数事業部にわたる複雑なロールアップ）になると、専用のOKRツールへの移行を検討する時期です。
コンフィデンス（達成確信度）は毎週更新する必要がありますか？
隔週でも一定の効果はありますが、毎週更新が理想です。コンフィデンスの価値はスコア下落の3〜4週前に問題を検知できる点にあります。更新頻度が低いと、その検知ウィンドウが著しく狭まります。