OKRを導入した組織で、リーダーはしばしば「目標をもっと明確に書きなさい」と言う。しかし、OKRが実際に揺らぐ地点は文章ではなく運用である。メンバーはObjectiveを書くことができ、Key Resultも数値にできる。問題は、その目標のために何を諦めるのか、衝突が起きたら誰が調整するのか、進捗が悪化したときにどのような意思決定を行うのかが決まっていないときに発生する。
OKRにおけるリーダーの役割は、鼓舞する人ではない。リーダーは優先順位を絞り、資源の衝突を調整し、チーム間の依存関係を明らかにし、チェックイン会議を意思決定の場に変える人である。この役割を果たさなければ、OKRはメンバーにより多くの目標を求める文書になる。
リーダーが最初に決めるべきものは目標ではなく「やらないこと」である
Google OKR playbookは、適切に運用されたOKRは、チームにとって何が重要で、何を最適化すべきで、日常業務でどのようなtradeoffを行うべきかを明確にすると説明している。この一文は、OKR運用におけるリーダーの第一の責任を示している。より多くの目標を書かせることではなく、この期間に何を選び、何を手放すのかを決めることだ。
AtlassianもOKR設定において、1〜3個のObjectiveとObjectiveごとに3〜5個のKey Resultを提案している。数字の意味は単なる記入ルールではない。目標数を減らさなければ優先順位は生まれない。すべての目標が重要だと言う組織には、実際に重要な目標が存在しない。
リーダーが問うべき質問は、「この目標も入れるか」ではなく、「この目標を入れるなら何を外すべきか」である。OKR会議で削除される目標がないなら、戦略対話はまだ終わっていない。メンバーは、リーダーが承認した目標リストではなく、リーダーが諦めると決めた仕事のリストを見て優先順位を理解する。
OKRチェックインは報告会議ではなく衝突解決会議である
Atlassianは、OKRを毎月score、analyze、summarizeすることを提案している。また、定期的で可視的な進捗確認が責任感と推進力を強めるとも説明している。しかし多くの組織で、チェックインは報告会議に変わる。各チームが進捗率を話し、リーダーはもっと頑張ろうとまとめる。このやり方では、OKRが運用リズムになりにくい。
Google playbookは、committed OKRを達成できないと判断した場合、チームは直ちにescalateすべきだと述べている。より重要なのはescalationの目的である。優先順位の意見不一致、時間・人員・資源の不足、目標そのものへの意見不一致が生じたとき、経営陣が選択肢を作り、衝突を解決できるようにするための手順だという説明である。
したがって、OKRチェックインでリーダーが問うべき質問は進捗率の数字ではない。「どの障害が目標達成を妨げているのか」「他チームの依存関係は解消されていないのか」「資源が不足しているのか、それとも目標の優先順位が下がったのか」「今調整しなければ、来月どの損失が大きくなるのか」。こうした質問がなければ、チェックインは報告書の読み上げで終わる。
たとえば製品ローンチOKRが遅れているとき、リーダーが「来月までに進捗率を80％に上げなさい」とだけ言えば、チェックインは鼓舞の会議になる。一方で、「法務レビューがボトルネックなのか、開発人員がボトルネックなのか、営業要件が過度に増えたのか」を切り分け、その場で優先順位を調整すれば、チェックインは運用会議になる。OKRリーダーシップはメンバーに圧力をかける技術ではなく、衝突を意思決定に変える技術である。
Cross-team OKRにおけるリーダーシップは協業の掛け声ではなく責任設計である
Google playbookは、重要なプロジェクトが複数グループの貢献を必要とする場合、cross-team OKRが適していると説明している。このとき、materially participateすべきすべてのグループがOKRに含まれる必要があり、各グループの貢献が各グループのOKRに明示的に表れなければならないと述べている。
この原則は韓国企業の部門間協業でも重要である。多くの組織は「協業強化」を目標に書くが、実際にはどの部門がどの成果物をいつまでに提供すべきかが明確ではない。マーケティング、営業、プロダクト、人事、データ組織が一緒に動かなければならない目標なら、各組織のOKRに互いの責任が表れていなければならない。そうでなければ、共同目標は誰も最後まで責任を負わない目標になる。
リーダーはcross-team OKRを宣言する人ではなく、接続構造を設計する人である。会議体を作って終わるのではなく、依存関係リストを公開し、ボトルネックが生じたとき誰にescalateするかを決め、共同目標の成功基準を同じ言語で合わせなければならない。協業は良い態度だけでは機能しない。協業には責任線と調整権限が必要である。
CommittedとAspirationalを区別しなければ、リーダーは誤ったシグナルを送る
Google playbookはcommitted OKRとaspirational OKRを区別している。committed OKRは達成を約束した目標であり、期待スコアは1.0である。達成できなければ説明と振り返りが必要だ。一方、aspirational OKRはより高い挑戦と革新を促す目標である。同じ達成率でも、解釈の仕方は異ならなければならない。
リーダーがこの区別をしなければ、メンバーは混乱したシグナルを受け取る。挑戦目標を出せと言いながら低い達成率を叱責すれば、次の四半期には安全な目標だけが上がってくる。逆に、約束目標の未達を「挑戦したのだから問題ない」とだけ処理すれば、実行責任が弱まる。二種類の目標を同じ表情で扱うリーダーは、OKRの言語を曖昧にする。
リーダーは目標を承認する時点から種類を明確にしなければならない。この目標は必ず達成すべき約束なのか、それとも組織をさらに遠くへ押し出す挑戦なのか。約束目標なら資源と優先順位を保証しなければならない。挑戦目標なら失敗の可能性を許容しつつ、何を学ぶのかを決めなければならない。区別があってこそ、メンバーも目標を正直に設定する。
HRはリーダーにOKRの様式より運用質問を提供すべきである
OKR教育が失敗する理由の一つは、様式教育にとどまるからである。Objectiveをどう書き、Key Resultはいくつが適切かを伝えるだけでは十分ではない。リーダーが実際の会議でどのような質問を投げかけ、どのような意思決定を下すべきかまでつなげなければならない。
HRはリーダーに少なくとも四つの運用質問を提供できる。第一に、今四半期に諦める仕事は何か。第二に、このOKRが失敗するとしたら最も可能性の高いボトルネックはどこか。第三に、他チームの貢献が必要な部分は各チームのOKRに明示されているか。第四に、この目標はcommittedなのかaspirationalなのか。この質問が会議で繰り返されるとき、OKRは文書ではなく運用言語になる。
OKRリーダーシップはカリスマや鼓舞の問題ではない。優先順位を絞り、不都合なtradeoffを公開し、衝突を適時に引き上げ、チーム間の責任を設計する管理能力の問題である。メンバーは目標を聞いて動くのではない。リーダーが何を選び、何を調整するのかを見て動く。OKRが成果管理の運用体系になるには、リーダーの役割も目標管理者ではなく実行構造を設計する人へと変わらなければならない。
