良いOKRと悪いOKR

良いOKRはレビューを楽にする

良いOKRとは、もっとも立派な言葉で書かれたOKRではありません。チームが「これは何を意味していたんだっけ」と聞かずにレビューできるOKRです。良いOKRは、方向性、測定、作業をそれぞれ別の場所で見えるようにします。

悪いOKRは、だいたい決まった形で失敗します。オブジェクティブが曖昧。キーリザルトが実質的にはタスク。イニシアチブが作業場所ではなく指標の繰り返しになっている。どの数値が動くべきかわからないため、チェックインが見せかけのステータス報告になります。

計画ミーティングの前、OKRをインポートした後、またはセッションが忙しそうに見えるのにレビューしづらいと感じたときに、この記事を使います。

利用条件

要点

1つだけ覚えるなら、これです。オブジェクティブは方向性を示し、キーリザルトは成果を測定し、イニシアチブは作業のために接続されたキャンバスです。

良い例と悪い例

方向性を示すオブジェクティブを書く

オブジェクティブは、定性的で、覚えやすく、その配下にまだ作業が属しているかを判断できる程度に具体的であるべきです。

良いオブジェクティブのパターン:

• 何かをより簡単に、明確に、速く、安全に、信頼できるように、または有用にする。
• 改善すべき顧客、チーム、ワークフローを示す。
• タイトルに測定値を詰め込まない。
• 起こり得るすべてのタスクを並べない。

より良いオブジェクティブは、計画ミーティングが終わった後でも理解できる必要があります。タイトルを理解するために説明の段落が必要なら、タイトルを書き直します。

タスクだけのオブジェクティブを避ける

タスク形のオブジェクティブは、何も改善していなくても「完了」できるため、レビューを弱くします。

文が作成する、公開する、移行する、書き直す、監査する、インタビューする、展開するで始まる場合、それは多くの場合イニシアチブの作業です。増やす、減らす、引き上げる、引き下げる、到達する、短縮するで始まる場合は、キーリザルトになり得ます。

確認できるキーリザルトを書く

キーリザルトには、可能な限り明確な単位、現在値、目標値が必要です。単位には、数値、パーセンテージ、マイルストーン、時間、金額、カスタム件数、品質基準などを使えます。

目標値は完璧でなくても構いませんが、レビュー可能である必要があります。セッション中に誰も値を更新できない場合、そのキーリザルトは推測になってしまいます。

適切な単位を選ぶ

チームが理解しているなら、カスタム単位でも問題ありません。項目のような曖昧な単位ではなく、顧客インタビュー、レビュー済みキャンバス、営業日のように書きます。

イニシアチブを作業に使う

Goals/OKRsでは、イニシアチブはOKRに接続された、作業が行われるキャンバスです。レビュー担当者が開いたときに、計画、文脈、意思決定、ファイル、タスク、利用可能なサブタスク、レビュー資料を確認できる程度に具体的であるべきです。

イニシアチブを2つ目の指標として使わないでください。成果が動いたかどうかはキーリザルトが示します。イニシアチブは、その成果を動かすための作業を保持します。

完成度の高いOKRの例

セッション: 2026 Q3 サポート品質

オブジェクティブ: 顧客がサポートを待たずに、アカウントと権限の問題を解決しやすくする。

キーリザルト 1: アクセス関連のサポート会話を30%削減する。

キーリザルト 2: ワークスペースロール、共有、無効化されたアクセス、招待、請求所有者について、レビュー済みヘルプセンター記事を公開する。

イニシアチブ: サポート例とレビューメモを含む接続済みキャンバスで、ワークスペースアクセスドキュメントを書き直す。

チェックイン: キーリザルト1は18%削減。ワークスペースロールと共有の記事は公開済み。招待のトラブルシューティングはレビュー中で、無効化アクセスの復旧にはまだスクリーンショットが不足しています。

この例が機能するのは、オブジェクティブが方向性を説明し、キーリザルトがレビューを可能にし、イニシアチブが作業にキャンバスを与え、チェックインが最新のストーリーを伝えているからです。

よくある悪いOKRパターン

インポートしたOKRを整理する

AIでOKRをインポートするは、計画メモをセッション、オブジェクティブ、キーリザルト、イニシアチブの下書きに変換できますが、保存前に構造をレビューする必要があります。

インポートした内容では、次を確認します。

• キーリザルトとして配置されたタスク
• オブジェクティブにすべき広い宣言
• キーリザルトを繰り返しているだけのイニシアチブタイトル
• 不足している単位
• 整理されていない元メモから重複したオブジェクティブ
• 行タイトルにすべきではないオーナーメモや会議コメント

下書きがほぼ正しい場合は、保存前に行を編集します。構造が大きく間違っている場合は、キャンセルして元テキストを先に整理します。

ツリービューで構造を確認する

ツリービューは、セッションに連鎖するOKRがある場合に便利です。階層をマップのように表示するため、オブジェクティブとキーリザルトが人に理解される形で積み上がっているかを確認できます。

ツリービューでは、次を確認します。

• この子オブジェクティブは、本当に親オブジェクティブを支えているか。
• このキーリザルトは、それが測定するオブジェクティブの下にあるか。
• ドラッグした項目は正しい場所に入ったか。
• 階層はレビューを助けているか、それとも飾りになっているか。

作業を隠すために階層を使わないでください。その項目が実行の詳細なら、代わりにイニシアチブキャンバスを使います。

チェックインはストーリーを残す

良いチェックインは、数値を更新するだけではありません。前回のレビュー以降に何が変わったか、何がブロックされているか、次に何が起きるべきかを説明します。

スナップショットは、その背後にあるチェックインと同じだけ有用です。すべてのチェックインが曖昧なら、スナップショットも曖昧さを保存するだけです。

問題が起きたとき

すべてのキーリザルトがタスクのように聞こえる場合は、タスク形の項目をイニシアチブへ移し、キーリザルトを測定可能な成果として書き直します。

オブジェクティブが完了したかチームで合意できない場合、そのオブジェクティブは曖昧すぎるか、キーリザルトが正しい成果を証明していない可能性があります。

キーリザルトを更新できない場合は、次のチェックイン前に単位を変えるか、データソースの明確なオーナーを割り当てます。

セッションの行が多すぎる場合は、ツリービューで重複した階層を見つけ、チームのポリシーに従って古い作業を統合またはアーカイブします。

作業がどこにあるのかを何度も聞かれる場合は、重要な作業ごとに明確な接続済みキャンバスがあるように、イニシアチブを追加または名前変更します。