OKRとは、目標とそれを達成するために必要な事柄を表現する、とてもシンプルなシステムです。
詳しくはOKR (目標と主な結果) — 前田ヒロを見ていただくと分かるかと思いますが、本当にシンプルで、だからこそ使うことが難しいシステムだと感じています。
OKRの設定で気をつける点
上の記事と重複した部分もありますが、まずOKRを設定する際のポイントを振り返っておきます。
- Objectiveが、その期間に会社として取り組むべき領域を抑えている。
- 挑戦的なObjectiveであり、実現可能でもある。
- Objectiveは定量的に評価可能でなくともよい。
- Key Resultsを達成すればObjectiveが達成できる構造になっている。
- Key Resultsは客観的かつ定量的に評価できる内容である。このとき、できた/できなかった のようなバイナリな評価ではないほうが好ましい。
- そのOKRに取り組むチームメンバーがOwnerとして適切に任命されており、また各Ownerは自分がなぜそれに取り組むべきか、具体的にどう取り組んでいくべきかを理解している。
- 上位のOKRとの整合性がとれている。
OKRの設定を失敗に導くありがちなこと
OKRを試そうとしたとき、下のような課題に直面する可能性があります。
失敗の仕方を間違えると、OKRというシステム自体をダメなものと認識するおそれがあるため注意が必要です。
- 作ってみようとするが、正しい作成プロセスは特に決まっていないのでとりあえず一人で考えてしまい、作成したOKRがチームに受け入れられない。
- チームで考えようにも制約条件の設定が難しく、結果としてあいまいなOKRができあがる。また制約条件もないため良し悪しの判断ができず、議論が成立しない。
- チームのメンバーが自分からオーナーをやりたいと言えるほど議論に参加できない。
- 最初から整合性を気にしすぎた結果、現実離れしたOKRになってしまったり、OKRの設定に時間を取られすぎてしまい本業が疎かになる。
問題を回避するためには
こうすればすべての課題が解決されるというわけではありませんが、回避する手助けにはなると思います。
- 制約条件は、経営陣やプロダクトマネージャなど長期的な視点で考える役割を担う人が決定する。
- チームで量を出すタイミングと議論するタイミングを分けて場をコントロールし、適切に議論できる状態をつくる。
- 最後はチームメンバー全員でレビューして納得のいく状態をつくり、かつ自薦または他薦という形でKey Resultsのオーナーを設定する。
- 上位のOKRとの整合性は気にしすぎない。まずはOKRを完成させることを優先する。
OKR作成プロセス案
上に書いてきた内容を元に、OKRを作成する一連のプロセスを定義してみました。組織によって合う合わないなどはあると思いますので、あくまでもたたき台ということで参考までに。
0. 参加者を揃えて準備を整える
議論をスムーズに進行するために、参加者は最大でも8人くらいが限界です。
- 意思決定者: 経営陣やマネージャ。四半期で注力するべき領域を把握している人。最初に注力領域を宣言したり、Objectiveが制約条件から外れていないことをジャッジする役割を担います。
- 参加者: OKRのOwnerとなる候補者。全員参加必須です。
- ファシリテーター: OKRが正しく設定できるかどうかはファシリテーターにかかっています。超大変なので覚悟を持って取り組む必要があります。
1. 次四半期の注力領域を意思決定者が宣言
例) 意思決定者が「今期は既存ユーザーの退会率をXX%改善しよう」と宣言する。
注力領域を決めるのは、簡単なことではありません。少なくとも、会社全体の状況や中長期戦略を把握している人間でないと判断できないでしょう。
全体像を把握していると、短期的にどの領域を攻めるべきかはアタリがつくはずなので、最初にそれを宣言してもらいます。参加者はその領域の中で最大の成果を出すためにやるべきことを考えていきます。
2. 参加者は注力領域について意見を述べつつ、Objectiveがイメージできるかを確認する
1で宣言された注力領域について、理解できていなければこの先の議論は無意味になります。
「何をやる必要があるのかイメージできない」「なぜその領域を選択したのか」「どういうことを期待しているのか」など、参加者は注力領域についての疑問を残さないよう質問し、理解を深める必要があります。
その上で、注力領域がObjectiveを考える上での制約条件として機能しているかを考えます。無制限にObjectiveを考えられる状態では、考える人間が混乱してしまいます。やってはいけない・やるべきではないことが分からないと、考える作業を苦痛に感じてしまいます。
3. 注力領域について、次の4半期でやるべきだと思うObjectiveを参加者が各自考える
10分x2セットの個人ブレインストーミング、その後10分で各自が自分の出した案からObjective候補を選定して発表の準備をします。
オフライン会議の場合はポストイットで、オンライン会議の場合はTrelloがおすすめです。
ここで、誰かが考えるのではなく参加者全員が個人で考えて、次のステップで発表してもらうのには理由があります。
この先なにをやるべきか。それを考えて選択するところには個性が現れます。参加者がどういったことを重視していて、どこに問題を感じているのか、またこの先どうするべきと考えているか。それらをうまく引き出して収束させることができれば、Objectiveを達成するための覚悟を引き出すことができます。
また、想定していなかった視点のObjectiveが生まれる可能性もあるため、収束する作業は大変になりますが有意義な時間になるはずです。
4. 全員簡単に自分が選んだObjectiveを発表し、投票を行って達成できそうな数に絞る
参加者は自分が選んだObjective候補について発表し、すべての発表を終えたら参加者全員で投票を行います。
みんなそれをやるべきだ、と強く考えているはずなので熱量を持って発表してもらいます。その上で、四半期で着手できる現実的な数にObjectiveを絞り込んでいきます。
ここで、自分の案が採択されなかった人は、採択されなかった理由が分からないままだと不満を持ってしまいます。不満を残すことはObjectiveの達成に支障をきたすため、他のものが選ばれた(自分のものが選ばれなかった)理由を理解できるところまでこの場では議論するべきでしょう。
5. ObjectiveのKey Resultをみんなでブレインストーミング
決まったObjectiveについて1つずつ、Key Resultsを考えていきます。
このときのブレインストーミングでは、ファシリテーターが記録係となり、個人で考えるのではなく議論しながら候補を出していく方がいいでしょう。
Objectiveについて話しつつ理解を深め、その上でObjectiveを達成するために必要な要素(=Key Result)を考えていく必要があるので、議論しながら進めたほうがKey Resultsを考えやすいです。
Key Resultsをすぐに思いつかない場合は、
- Objectiveが達成されるとなにが嬉しいのか
- Objectiveを満たすために必要な成果(物)はなにか
という点を先に考えると、Key Resultsを考えやすくなります。
また、このとき考えたKey Resultsが抽象的すぎてとても着手できそうにない場合、やるべきことが想像できるレベルにまで分解する方がいいかもしれません。
6. Key Resultsが達成されたらObjectiveは達成されそうか、全員でレビューする
OKRが揃ったら、ファシリテーターは場を仕切りつつ参加者の合意を形成します。
そのKey Resultsは、Objectiveを達成するために必要十分な内容であるかを考えていきます。漏れの確認もありますが、真の目的は参加者全員が全てのOKRに目を通し、理解し、発言機会をつくることで合意を形成するところにあります。
7. Key ResultのOwnerを設定する
Ownerとなった人が積極的に取り組める状態をつくるためにも、Ownerは誰かが指名するのではなくできれば自薦、難しい場合は他薦で決めるのが望ましいです。誰かが指名して決めてしまうのでもいいですが、その場合はとても慎重に決める必要があります。
なお、だれもOwnerになりたがらないKey Resultsがあった場合には、
- 具体的に何をやるべきか想像できないのでやりたくない
- 自分がやるべき作業として考えていない (Key Resultsを考える際に、その覚悟ができていない)
といったことが考えられます。前者の場合にはKey Resultsについて分解が必要ですし、後者についてはそうならないように5のKey Resultsを考える段階で気を配っておく必要があります。
8. 取り組むべきOKRの状態を確定する
挑戦しがいのあるOKRが設定できたら、あらためて全体を確認しなおして、最後に全員の合意をとります。
メンバー全員が、そのOKRを達成することをこの場で確認して、OKR作成プロセスは完了です。
Originally published at 524.design on April 11, 2016.
