Google’s OKR playbook

OKR の実装において Google ほど集合的な経験を持つ企業はありません。

同社は規模が拡大するにつれ (そして規模が大きくなるにつれ)、OKR ガイドラインとテンプレートを定期的に発行しています。 以下の抜粋は、ほとんどが内部資料から引用したもので、Google の許可を得て転載しています。 (注：これはOKRに対するGoogleのアプローチである。 (注: これは OKR に対する Google のアプローチです。あなたのアプローチは異なるかもしれませんし、そうあるべきです。)

Google では、大きく考えることが好きです。 OKR (objectives and key results) と呼ばれるプロセスを使用して、これらの高い目標を伝え、測定し、達成するのに役立っています。 検索、Chrome、Android などで何度も見てきたように、全従業員の数パーセントからなるチームが、野心的な共通の目標に向かって協調して行動すれば、2 年足らずで成熟した業界全体を変えることができるのです。 そのため、Googleの社員やマネージャーは、個人として、またチームの一員として、自分の時間やエネルギーをどのように配分するかについて、意識的かつ慎重に、そして十分な情報に基づいて選択することが非常に重要なのです。 OKRは、そうした慎重な選択の現れであり、大きな集団目標を達成するために個人の行動を調整する手段でもある。

私たちはOKRを使って、人々が何を生産しようとしているかを計画し、計画に対する進捗状況を追跡し、人々やチーム間で優先順位やマイルストーンを調整する。 また、OKRを使用して、人々が最も重要な目標に集中できるようにし、緊急だがあまり重要でない目標に気を取られないようにしています。 (0.0～0.3は赤0.4～0.6は黄0.7～1.0は緑

効果的なOKRを書く

不十分なOKRは時間の無駄で、空っぽの管理ジェスチャーである。 よくできたOKRは、何が重要で、何を最適化し、日々の仕事でどのようなトレードオフを行うべきかをチームに明らかにするのに役立つ、モチベーションを高める管理ツールです。

よいOKRを書くことは簡単ではありませんが、不可能でもありません。

目標は「何」であるかということです。

Key Results are the “Hows.”.

• 達成された場合、その構成員にとって有益な方法で目的を前進させる、測定可能なマイルストーンを表現すること。 KRに「相談する」、「手伝う」、「分析する」、「参加する」などの言葉が含まれている場合、それらは活動を記述しています。 代わりに、これらの活動の最終用途への影響を記述してください。 「コロッサスのレイテンシを評価する」ではなく、「3月7日までに6つのコロッサスセルから平均およびテールレイテンシの測定値を公表する」
• 完了の証拠を含まなければなりません。 この証拠は入手可能で、信頼性があり、容易に発見できるものでなければなりません。 4071>

Cross-team OKRs

Googleの多くの重要なプロジェクトは、異なるグループからの貢献を必要とします。 OKRは、この調整にコミットするのに理想的である。 チーム横断 OKR は、その OKR に実質的に参加しなければならないすべてのグループを含み、各グループの貢献をコミットする OKR は、そのような各グループの OKR に明示的に表示されるべきです。 たとえば、Ads DevelopmentとAds SREとNetwork Deploymentが新しい広告サービスをサポートするために提供しなければならない場合、3つのチームすべてが、プロジェクトの一部を提供するという約束を記述したOKRを持つ必要があります。 コミットメントとは、達成されることに同意する OKR であり、それが確実に実現されるようにスケジュールやリソースを調整することも厭わないものです。0は、計画および/または実行におけるエラーを示すため、失敗についての説明が必要です。

対照的に、志の高いOKRは、そこに到達する方法やそのOKRを実現するために必要なリソースが明確でないにもかかわらず、世界がどのようになってほしいかを表現しています。

• Aspirational OKRの予想平均スコアは0.7で、分散が大きい。

古典的なOKR作成の間違いと罠

TRAP #1：コミット型とアスピレーション型のOKRを区別していない

• Commitable OKRをアスピレーション型としてマークすると失敗する可能性が高くなる。
• 一方、熱望型OKRをコミット型にマークすることは、そのOKRを実現する方法を見つけられないチームに防衛力を与え、熱望型OKRに集中するためにコミット型OKRが人員削減されるため、優先度の逆転を招く。

TRAP #2：いつも通りのOKRを。

• OKR は、チームや顧客が本当に望んでいることとは対照的に、チームが現在行っていることを何も変えずに達成できると信じていることに基づいて書かれることが多い。

TRAP #3: Timid aspirational OKRs.

• Aspirational OKR は、現状から始めて「もしスタッフが増えて少し幸運だったら何ができるだろうか」と効果的に尋ねることがとても多いのだ。 別の良いアプローチは、”ほとんどの制約から解放されたら、数年後に私 (または私の顧客) の世界はどのように見えるだろうか?” というところから始めることです。 定義上、OKRを最初に策定した時点では、この状態を達成する方法を知ることはできないでしょう-それが、OKRが志の高いものである理由です。 しかし、望ましい最終状態を理解し、明確にしなければ、それを達成することはできないのです。
• The litmus test: 顧客が本当に望むものを尋ねたら、あなたの熱望する目標は彼らの要求を満たしているか、あるいは超えているか。

TRAP #4: Sandbagging

• A team’s committed OKRs should credibly consumes most but not all of their available resources. チームのコミットメントされた+志の高いOKRは、利用可能なリソースよりいくらか多く消費することができると信頼できるはずです。 (そうでなければ、それらは事実上コミットです。)
• チームの人員/資本をすべて必要とせずにすべての OKR を満たすことができるチームは、リソースをため込んでいるか、チームを推進していないか、またはその両方であると見なされます。 これは、ヘッドカウントやその他のリソースを、それらをより効果的に使用するグループに再割り当てするための上級管理職の合図です。

TRAP #5: 低価格目標 (別名、「誰が気にするの？」 OKR).

OKR は明確なビジネス価値を約束しなければなりません-さもなければ、そのためにリソースを消費する理由がありません。 低価値目標 (LVO) とは、目標が 1.0 で完了しても、誰も気づかないか、気にしないような目標です。

• LVO の古典的な例 (そして魅惑的な例)。 古典的な (そして魅惑的な) LVO の例: “タスク CPU 使用率を 3% 増加させる”。 この目的自体は、ユーザーまたは Google を直接的に支援するものではありません。 しかし、（おそらく関連する）目標である「品質/レイテンシー/ … に変更を加えずに、ピーク クエリに対応するために必要なコアの量を 3 パーセント減らし、結果として生じる余剰コアを無料プールに戻す」には、明確な経済価値があります。 これは優れた目的です。
• ここでリトマス試験をしてみましょう。 エンドユーザーまたは経済的利益を直接提供することなく、OKR が合理的な状況下で 1.0 を得ることができたかどうか。 もしそうなら、目に見える利益に焦点を当てるように OKR を書き換えてください。 典型的な例です。 成功の基準がない「Xを立ち上げる」。 もっといいのは 「

TRAP #6: コミットされたOsに対する不十分なKR。

• OKRは、望ましい結果（目的）とその結果を達成するために必要な測定可能ステップ（主要結果）に分割される。 4071>
• よくある間違いは、必要ではあるが、目的を達成するのに十分ではない結果を書くことである。
• この罠は、目的のためのリソース要件の発見と、目的がスケジュール通りに完了しないことの発見の両方を遅らせるので、特に悪質です。 すべての主要な結果で1.0を獲得することは合理的に可能だが、それでも目的の意図を達成することはできないか。 もしそうなら、成功裏に完了することで目的も成功裏に完了することが保証されるまで、主要な結果を追加または手直しする。

Reading, Interpreting, and Acting on OKRs

For committed OKRs

• Teams are expected to rearrange their other priorities to ensure the on schedule 1.0 delivery.
• Teams who cannot credibly promise to deliver a 1.0 on a committed OKR must be escalate promptly.チームは1件の1点獲得について約束できない。 ここが重要なポイントです。 この (一般的な) 状況でエスカレーションすることは、問題ないだけでなく、必要なことなのです。 OKRについての意見の相違、その優先順位についての意見の相違、十分な時間／人／リソースを割り当てられないこと、などの理由で問題が生じたとしても、エスカレーションは良いことです。 4071>

このことから、すべての新しい OKR は、既存の優先順位とコミットメントを変更する必要があるため、ある程度のエスカレーションを伴う可能性があることがわかる。

• 期限までに1.0を達成できないコミットメントされたOKRは、事後評価を必要とする。 これはチームを罰するためのものではありません。 OKRの計画および/または実行において何が起こったかを理解し、チームがコミットされたOKRで確実に1.0を達成する能力を向上させることを目的としているのである。
• Committed OKRのクラスの例としては、サービスがその四半期のSLA（サービスレベル合意）を満たすこと、インフラストラクチャ・システムに対して定められた機能または改善を定められた期日までに提供すること、またはコストポイントで大量のサーバーを製造して提供すること、などが挙げられます。 OKRの優先順位は、グループのコミットメントが満たされた後の残りの時間をどこに費やすかというチームメンバーの意思決定に影響するはずである。 一般に、より高い優先順位のOKRは、より低い優先順位のOKRより先に完了すべきである。
• Aspirational OKRとその関連する優先順位は、完了するまでチームのOKRリストに残り、必要に応じて四半期ごとに繰り越すべきである。 それは、優先順位付け、リソースの利用可能性、または問題/ソリューションの理解不足という永続的な問題を隠蔽するためである。
  • チームマネージャーは、志の高いOKRを達成するために必要なリソースを評価し、四半期ごとにそれを求め、ビジネスに対して既知の要求を表明する義務を果たすことが期待される。

  その他のリトマス試験

  あなたのOKRが良いかどうかを見るためのいくつかの簡単なテスト：

  • あなたが5分でそれを書き留めたなら、それはおそらく良くないだろう。
  • 目的が1行に収まらない場合、おそらく十分に鮮明ではありません。
  • KRがチーム内部の用語で表現されている場合（「Launch Foo 4.1」）、おそらく良くないと思います。 重要なのは、立ち上げではなく、その影響です。 なぜFoo 4.1が重要なのでしょうか？ より良い。 「Foo 4.1をリリースし、サインアップ率を25%向上させます。 あるいは単に「サインアップを25％改善する」
  • Use real dates.
  • 主要な結果が測定可能であることを確認する。 四半期末に客観的に評価を下すことが可能でなければなりません。 「サインアップを向上させる」というのは、重要な結果とは言えません。 もっといい。 「5 月 1 日までに毎日のサインアップを 25% 改善する」
  • 測定基準があいまいでないことを確認する。
  • チームの重要な活動（またはその努力のかなりの部分）でOKRがカバーしていないものがあれば、さらに追加する。

  質問がある場合は、どこに送ればよいですか？

  ぜひご連絡ください！

  。