2023/4/3 新人事制度のため、初版を公開
2023/6/22 「コミットするOKR」だけではなく、「コミットKR」と「ムーンショットKR」の2つを設定するよう変更。変更理由:「野心的な高い目標を掲げることで、より高い成果を追う思考にしたい」「挑戦を推奨するというバリューの考え方と近づけたい」
2023/10/4 GitClearの指標を使用する場合のルールを追記
2023/12/18 チームOKRの難易度設定について、上位のOKRとの整合性が保てないことを許容する場合があることを追記。
概要
- SocialDogでは評価(目標設定)にOKRを使っています。
- SocialDogでのOKRは一般的な定義と異なる箇所があります。
- このページで良いOKRを定義しているので、それに従ってOKRを設定してください。
目次
- 概要
- 目次
- OKRとは
- Objective
- Key Results
- OKRのメリット
- SocialDogにおけるOKRの位置づけ
- 良いOKR(SMART)
- OKRの例
- 良いOKRのチェックポイント
- Objective
- Key Results
OKRとは
- OKRとは、上記のように、会社全体・各チーム・個人にObjective(目的)とKey Results(成果指標)を設定し、定期的にその進捗を確認する仕組みです。
- 全社OKR・チームOKRから、個人のOKRまで設定し、相互の関連を定義します。
Objective
- 目的。目指す状態。
- 下位のObjectiveを達成すると、上位のObjectiveが達成されるようにします。
- 表現は自由です。聞いたらワクワクするような表現にしましょう!
- 重要なことにフォーカスするため、1つにします。複数設定したくなった場合は、抽象度を上げるか、重要でない方を削除するかして1つにしましょう。
Key Results
- 成果指標。目標。目指す状態に必要な結果。
- できるだけ「定量的」(例:15件以上)にします。
- 定性的なKey Resultsにする場合は、最低限、100%(達成度:A)の状態がどういう状態かをOKR設定のタイミングで決めておきます。
- できるだけ「結果指標」(例:●●を●●にする)にします。
- 難しい場合は、「行動指標」(例:●●をする)でも良い。
- 評価期間全体の結果を反映した指標にします。
- 最終月だけでなく、6か月間全体の成果があらわれる数値にします。
- 3つ程度、多くても5つに絞り込みます。
- 「コミットKR」と「挑戦KR」の2つを設定します。
- コミットKR
- 「OKR達成度評価」のA評価に相当します。
- 評価期間中に必ず達成することを目指す内容にします。
- 挑戦KR
- 「OKR達成度評価」のS評価に相当します。
- いわゆる「野心的なOKR」で、70%くらいなら達成できそうな、ストレッチゴールとなる内容にします。
- 必ず数値が確認できるURLにリンクしてください。
- スプレッドシートでもよいが、自動更新されるmetabase/chartmogul/gitclearが望ましい
- リリース内容にする場合
- リリース対象(スコープ)をある程度具体的にする
- 「リリース」が全員なのか一部なのかを定義してほしい
- どちらかのみだと発生する以下の問題を防ぐためです。
- 「野心的なKR」のみだと起きる問題
- 野心的な目標なので、「未達」が当たり前となり、達成感が減ってしまう。「未達」が続くと、評価・報酬制度と紐付けた運用が難しい。
- 開発組織では、スケジュールや品質など、野心的目標とそぐわない場合が多い。
- 「コミットするKR」のみだと起きる問題
- 高い成果を追う思考が生まれにくくなる。
- 挑戦を推奨するというバリューに反するように見える
比較しやすくするため、以下の定義のものを利用してください。
- 集計方法
- 6ヶ月分の合計を単純に週数(365/12*6/7=26.07)で割る。
- 計算を簡便にするため、有給等を加味しない。在籍していない期間は加味する。
- 使う指標
- Diff Delta
- PR作成数(PRs posted count)
詳細は、 を参照。
KRは、チームが期首にもっているパフォーマンスで、期末に達成すると思われる内容で設定してほしいです。「いままでよりもうまくいった」「チームの頑張りにより期首の予想よりも成果が出せた」というときに、コミットKRを超えるようにしてほしいです。
上位のOKRからブレイクダウンすると難易度が高すぎると思う場合は、上位のOKRの担当者に相談してください。相談の結果、難易度が高すぎると判断した場合は、整合性が保てないことを許容します。「OKRをブレイクダウンしたときの整合性」よりも「評価の妥当性」を重視したいです。
OKRのメリット
- 各チームが達成すべきことを明確になり、重要なことに集中できるようになる。
- OKR達成の方法を考えることで、各チーム内での戦略立案をすることの仕組み化になる。
- ほどよい緊張感を生む。
- メンバーのベクトルが揃う。
- 進捗が共有される。
SocialDogにおけるOKRの位置づけ
OKRは会社によって運用方針がかなり異なります。SocialDogにおいては以下のように運用します:
- 個人OKRの達成度を、評価制度と紐付けます。
- 成果に報酬で報いる組織にしたいからです。
- 期中に柔軟に変更できるようにします。
- 6ヶ月後の状態を正確に見積もるのは難しいです。適時最適なOKRに修正していきます。
良いOKR(SMART)
よいOKR設定のわかりやすい基準として「SMART」があります。これを参考に良いOKRの設定を目指しましょう!
- Specific 具体的
- 目指すことが明確か。何のためにやるか、マネージャーと本人の認識は揃っているか。
- Measurable 測定可能
- 設定したOKRを振り返ることができるか。評価できるか。
- Achievable 達成可能
- 容易ではないが、達成可能であるか。無謀なOKRでないか。
- Related / Relevant 経営OKR/組織OKRとの関連
- そのOKRを達成すれば会社・チームのObjectiveの達成にも貢献できるか。
- Time-bound 期限がある
- いつまでにやるか決まっているか。
OKRの例
職種 | Objective | Key Results |
開発 | 待望のInstagram投稿機能をユーザーが大満足する形でリリースする | • ●●機能を●月までにリリースする
• 不具合が●件以下 |
開発 | 開発効率を上げ爆速でリリースする | • PRの平均作成数●以上
• hotfixを月●件以下にする |
開発 | コードの品質を向上させる | • レビューの平均コメント数●以上
• 変更障害率●%以下
• 必ずEXPLAINの結果を見るようにする(行動目標) |
SRE | アプリケーションのパフォーマンスを向上させる | • ファーストビューの表示にかかる時間を●秒以内にする
• UserList画面で●●の表示にかかる時間を●秒未満にする
• コードレビューにかかる時間を半分にする |
マーケティング | 企業ユーザーを増やす | • Reg ●件以上
• FTT ●件以上
• 登録当月売上 ●円以上 |
カスタマーサクセス | ユーザーのニーズを把握し、特にBusinessプランのカスタマーのサクセスを支援する | • 解約率●%以下
• BusinessプランのTrial CVR率●%以上
• オンボーディングmtg実施率●%以上
• ユーザーインタビューを●件以上実施(行動目標) |
人事 | 従業員エンゲージメントの向上 | • wevoxのスコア●●以上 |
良いOKRのチェックポイント
まずObjectiveを決め、その次にObjectiveを達成している状態を想像してKey Resultsを決めます。
Objective
- 個人Objectiveを達成することが、上位のチームのObjectiveを達成することに繋がるか?
- →つながらない場合は上位のObjectiveとつながるものに変更します
- Objectiveの表現は具体的すぎだったり、抽象的すぎないか?
- 具体的すぎると、それ以外の重要なことに意識がいかなくなります。適切な抽象度にします。
- 例
- 「開発チームに貢献する」
- →抽象的すぎる。
- 例えば、「●●機能の●月リリースを牽引する」くらいの粒度にする
- 「Datadogを導入する」
- →具体的すぎる。手段ではなく目的を書く。
- 例えば、「サーバーのエラー・不具合を減らし、顧客のペインを減らす」
- 聞いたらワクワクするような表現になっているか?
- 例:解約率低減 → チャーン撲滅大作戦!
- 本人やそのチームの努力次第で達成でき、そのための裁量を持っているか?
- →達成できない目標は立てないでください。
- 評価期間内に最終結果が出るか?
- →評価期間内で終わるような書き方にしてください。
- 例:●●機能を●月にリリースできる状態にしておく
- 自分以外の要因で達成・未達成になる要素がないか?(マネージャーを除く)
- →Key Resulstsの達成の判断の際に、自分以外が原因で達成できないことがないようにします。
- 等級アップ(昇格)を意識しているか?
- この評価期間が終わったら昇格する可能性がある場合(等級内の報酬レンジの上限に近い場合)は、Objectiveに昇格のための必要な要素を入れます。
Key Results
Objectiveが決まったら、KeyResultsを考えます。
- 難しすぎず、簡単すぎない内容になっているか?
- 期待が高すぎると、一定の結果が出ていて評価すべきなのに「未達」ということになってしまいます。
- 期待が低すぎると、結果が出ていなくて本当は「イマイチ」なのに、「達成」したことになってしまいます。
- 「Key Resultsを達成できたらObjectiveも達成できた」と言えるようなものになっているか?
- Key Resultsの数が多すぎないか(4以上)?
- 多すぎると分かりにくいので、1〜3程度になるように設定してください。最大でも5までとしてください。
- 複数の目標のそれぞれの優先度が大きく異なる場合はウェイト(例:40%のように)を記載してください。
- 自分以外の要因で達成・未達成になる要素がないか?(マネージャーを除く)
- →Key Resultsの達成の判断の際に、自分以外が原因で達成できない、ということにならないようにします。
- 具体的・客観的・測定可能なものになっているか
- →数値化できるものはできるだけ数値にします。
- 以下のような表現は具体的ではないので使わないこと。
- 努力する、徹底する、目指す、支援する、効率化する、等、できるだけ
- 「行動指標」ではなく「結果指標」になっているか