良いOKRと悪いOKR

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

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

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

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

利用条件

要点

1つだけ覚えるなら、これです。目標は方向性を示し、主要成果は成果を測定し、イニシアチブは作業のために接続されたキャンバスです。

良い例と悪い例

方向性を示す目標を書く

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

良い目標のパターン:

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

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

タスクだけの目標を避ける

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

作成する、公開する、移行する、書き直す、監査する、インタビューする、展開するなど、実行する作業を表す項目は、多くの場合イニシアチブの作業です。増やす、減らす、引き上げる、引き下げる、到達する、短縮するなど、成果の変化を表す項目は、主要成果である可能性が高くなります。

確認できる主要成果を書く

主要成果には、明確な数値の単位、現在値、目標値が必要です。件数、パーセンテージ、金額、時間、または数値を測定するカスタム単位名を使います。品質の基準も、測定できる形で記述します。

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

適切な単位を選ぶ

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

これらは測定対象の例であり、単位メニューに追加の選択肢があるという意味ではありません。ALLOの主要成果には、標準のMilestone単位や、チェックボックスで完了にするモードはありません。カスタム単位名も数値を測定するためのラベルです。簡単な作業項目にはキャンバスのチェックリストを使います。利用可能な単位は主要成果の追加で確認できます。

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

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

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

完成度の高いOKRの例

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

目標: 顧客がサポートを待たずに、アカウントと権限の問題を解決しやすくする。

主要成果 1: アクセス関連のサポート会話を30%削減する。

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

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

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

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

よくある悪いOKRパターン

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

AIでOKRをインポートするは、計画メモを目標と主要成果の下書きに変換し、新しいセッションとして作成するか、インポートを開いたセッションに追加できます。ただし、保存前に構造をレビューする必要があります。インポートではイニシアチブは作成されないため、保存した後で各主要成果にイニシアチブのキャンバスを追加してください。

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

• 主要成果として配置されたタスク
• 目標にすべき広い宣言
• 不足している単位
• 整理されていない元メモから重複した目標
• 行タイトルにすべきではないオーナーメモや会議コメント

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

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

ツリービューは、セッションに連鎖するOKRがある場合に便利です。階層をマップのように表示するため、目標と主要成果が人に理解される形で積み上がっているかを確認できます。

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

• この子目標は、本当に親目標を支えているか。
• この主要成果は、それが測定する目標の下にあるか。
• ドラッグした項目は正しい場所に入ったか。
• 階層はレビューを助けているか、それとも飾りになっているか。

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

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

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

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

問題が起きたとき

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

目標が完了したかチームで合意できない場合、その目標は曖昧すぎるか、主要成果が正しい成果を証明していない可能性があります。

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

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

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