関連ページ: 人事制度(等級・評価・報酬)・面談について・OKRについて・等級定義表・ ・
‣
概要
- SocialDogでは評価・目標設定にOKRを使っています。
- SocialDogでのOKRは一般的な定義と異なる箇所があります。
- このページに従ってOKRを設定してください。
目次
- 概要
- 目次
- OKRとは
- OKRのメリット
- SocialDogにおけるOKRの位置づけ
- Objective
- 良いObjective
- Key Results(KR)
- コミットKR
- 挑戦KR
- 良いKey Results
- 良いOKR(SMART)
- OKRの例
- OKRの修正が必要な場合
- OKRデータベースについて
- OKRを追加する
- 注意
- Key Resultsを修正する
- 振り返りを入力する
- FAQ
- 個人のKey Resultsを達成するためには、Key Resultsで決まっている項目以外の仕事はしない方がよいのですか?
- 定量目標を設定するのが難しいです。定性的な目標でもいいですか?
OKRとは
- OKRとは、上記のように、会社全体・各チーム・個人にObjective(目的)とKey Results(成果指標)を設定し、定期的にその進捗を確認する仕組みです。
- 全社OKR・チームOKRから、個人のOKRまで設定し、相互の関連を定義します。
OKRのメリット
- 各チームが達成すべきことを明確になり、重要なことに集中できるようになる
- OKR達成の方法を考えることで、各チーム内での戦略立案をすることの仕組み化になる
- ほどよい緊張感を生む
- メンバーのベクトルが揃う
- 進捗が共有される
SocialDogにおけるOKRの位置づけ
OKRは会社によって運用方針がかなり異なります。
SocialDogにおいては以下のように運用します:
- 個人OKRの達成度を、評価制度と紐付けます
- 成果に報酬で報いる組織にしたいからです。
- 期中に柔軟に変更できるようにします
- 6ヶ月後の状態を正確に見積もるのは難しいです。適時最適なOKRに修正していきます。
Objective
- 目的。目指す状態。
良いObjective
下記のようなものにします:
- 下位のObjectiveを達成すると、上位のObjectiveが達成される
- 聞いたらワクワクするような表現になっている
- 表現は自由です。
- 1つにする
- 重要なことにフォーカスするためです。複数設定したくなった場合は、抽象度を上げるか、重要でない方を削除するかして1つにしましょう。
- 適切な抽象度にする
- 具体的すぎず、抽象的すぎないようにします。
- 具体的すぎると、それ以外の重要なことに意識がいかなくなります。
‣
Key Results(KR)
- Objectiveをどの程度達成したかを判断するための指標です。
- SocialDogでは、「コミットKR」と「挑戦KR」の2つを設定します。
‣
コミットKR
- 「OKR達成度評価」のA評価に相当します。
- 評価期間中に必ず達成することを目指す内容にします。
挑戦KR
- 「OKR達成度評価」のS評価に相当します。
- いわゆる「野心的なOKR」で、70%くらいなら達成できそうな、ストレッチゴールとなる内容にします。
良いKey Results
- Key Resultsを達成できたらObjectiveも達成できたと言える
- 難しすぎず、簡単すぎない
- 期待が高すぎると、一定の結果が出ていて評価すべきなのに「未達」ということになってしまいます。
- 期待が低すぎると、結果が出ていなくて本当は「イマイチ」なのに、「達成」したことになってしまいます。
- 定量的(例:●件以上)
- 定量にするのが難しい場合は、無理に定量的な目標にする必要はありません。
- 定性的なKey Resultsにする場合は、最低限、100%(達成度:A)の状態がどういう状態かを決めておきます。
- 結果指標(例:●●を●●にする)
- 難しい場合は、「行動指標」(例:●●をする)でも問題ありません。
- 評価期間全体の結果を反映する
- 最終月だけでなく、6か月間全体の成果があらわれる数値にします。
- 評価期間内に結果がでるようにしてください。
- 例:●●機能を●月にリリースできる状態にしておく
- 評価期間全体の成果の大部分(少なくても8割程度)を評価できるように設定します。
- 例: 実装と設計をする必要がある場合には、実装に関するKRだけではなく、設計に関するKRも含めます。
- 3つ程度
- 多くても5つに絞り込みます。
- ウエイトが記載されている
- 複数の目標のそれぞれの重要度が大きく異なる場合はウェイト(例:50%・30%・20%のように)を記載してください。
- 数値が確認できるURLにリンクしている
- 手動更新のスプレッドシートでもよいですが、自動更新されるMetabase/ChartMogul/GitClearが望ましいです。
- 自分以外の要因で達成・未達成になる要素がない(マネージャーを除く)
- 本人やそのチームの努力次第で達成でき、そのための裁量を持っているようにします。
- Key Resultsの達成度評価の際に、自分以外が原因で達成できないことがないほうが望ましいです。
- 等級を意識している
- この評価期間が終わったら昇格する可能性がある場合(等級内の報酬レンジの上限に近い場合)は、Objectiveに昇格のための必要な要素を入れます。
- リリース内容にする場合
- リリース対象(スコープ)をある程度具体的にする
- 「リリース」が全員なのか一部なのかを定義する
GitClearの指標をKRにする場合
比較しやすくするため、以下の定義のものを利用してください。
- 集計方法
- 6ヶ月分の合計を単純に週数(365/12*6/7=26.07)で割る。
- 計算を簡便にするため、有給等を加味しない。在籍していない期間は加味する。
- 使う指標
- Diff Delta
- PR作成数(PRs posted count)
詳細は、 を参照。
チームのKRの難易度について
KRは、チームが期首にもっているパフォーマンスで、期末に達成すると思われる内容で設定してほしいです。「いままでよりもうまくいった」「チームの頑張りにより期首の予想よりも成果が出せた」というときに、コミットKRを超えるようにしてほしいです。
上位のOKRからブレイクダウンすると難易度が高すぎると思う場合は、上位のOKRの担当者に相談してください。相談の結果、難易度が高すぎると判断した場合は、整合性が保てないことを許容します。「OKRをブレイクダウンしたときの整合性」よりも「評価の妥当性」を重視したいです。
KRのリリース時期目標について
期首の時点で仕様の詳細が決まっていないものについては、仕様の決定後に見積もりを行い、内容を必ず修正してください。精度の低い見積もりによるKRを達成するために本来実装すべき機能量を調整する必要はありません。
良いOKR(SMART)
よいOKR設定のわかりやすい基準として「SMART」があります。これを参考に良いOKRの設定を目指しましょう!
- Specific 具体的
- 目指すことが明確か。何のためにやるか、マネージャーと本人の認識は揃っているか。
- Measurable 測定可能
- 設定したOKRを振り返ることができるか。評価できるか。
- Achievable 達成可能
- 容易ではないが、達成可能であるか。
- 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やKey Resultsを修正する必要があります。
- 修正が必要な例
- OKRの難易度が想定と異なった場合 (約3ヶ月間やってみて、OKRが「難しすぎる」または「簡単すぎる」と思われる場合)
- 指標の基準が変わる場合
- 状況が大きく変わった場合
- 修正が不要な例
- パフォーマンスが上がった(落ちた)ことにより、達成確度が高く(低く)なった場合
- 「がんばったら目標が上がって結局A評価になってしまう」ということにはしないため。
OKRの修正の方法については、人事制度(等級・評価・報酬) - OKRの修正 を参照。
OKRデータベースについて
- OKRは、OKRデータベース で管理します。
- Objectives、Key Resultsのステータスの意味は次のとおりです。
ステータス | 説明 |
ドラフト | 下書き状態です。 |
承認待ち | 入力が完了し、マネージャーの確認待ちの状態です。 |
有効 | マネージャー・経営陣が承認し、有効になっている状態です。 |
取り下げ | 検討の結果、採用しないことにしたものです。 |
失効 | 修正が行われた結果、新たな内容が有効になり、失効したものです。 |
OKRを追加する
期首には、下記の手順でObjectivesとKeyResultsを追加します。
- まず、Objectiveを追加します。
- の上部の「Objectives(当期)」ビューを開く
- 左端の▶をクリックしていき、自分の所属チーム(マネージャーの場合はOKRの上位)を開く
- 「新規サブアイテム」をクリック
- 追加されたページのタイトルを
[チーム名または自分へのメンション]: [Objectiveの内容]
にします。 - そのObjectiveに設定した背景、KR達成のための実施事項をできるだけ具体的・詳細に記入します。
- 昇格(上位の等級への変更)にチャレンジしたいと思う場合は、その旨も記載します。
- 次にKey Resultsを追加します。
- Objectiveのページ内の「Key Resultsを追加」をクリックし、下記のプロパティを入力します。
- Key Result
- Key Resultの項目名(「●%にする」などのコミットKRなどの内容は入力しないでください)
- 機能の開発やリリースについて書く場合は、KeyResultを「●●機能」とし、コミットKRを「リリース」などとしてください。
- 前期実績
- そのKRの定義で、前期の6か月分の実績
- 入社前だったり、「〜をリリースする」というKRのように前期に実績がない場合は入力不要です。
- コミットKR
- 挑戦KR
- ウエイト
- KRの重要度が異なる場合に、その人(チーム)のすべてのKRのウエイトの合計が100%になるように入力します。
- 未入力の場合はすべてのKRのウエイトが均等であるとみなします。
- ステータス
- 「ドラフト」のまま
- KRの個数分2のステップを繰り返します。
- を確認して、内容を見直します。
- 面談について - OKR面談 に従い、ページコメントでマネージャーに確認を依頼し、ステータスを「承認待ち」に変更します。
- 最終的に経営陣に承認されるとステータスが「有効」となります。
‣
注意
- OKRのページはすべて公開となっています。給与や健康などパブリックにすべきでない内容は書かないでください。
Key Resultsを修正する
Key Resultsを修正する場合、修正内容がわかりやすいよう、修正対象のページを編集するのではなく、新たに修正後のKeyResultsのページを追加してください。
- Objectiveのページ内の「Key Resultsを追加」をクリックしてKey Resultsを新たに追加します。
- 修正後のKeyResultsの内容と入力します。
- 本文に修正の理由を記入します。
- ステータスは「ドラフト」にしておきます。
- 内容を入力したらページコメントでマネージャーに修正したい旨のコメントをし、ステータスを「承認待ち」に変更します。
- 最終的に経営陣に承認されるとステータスが「有効」となり、修正前のものは「修正のため失効」となります。
振り返りを入力する
チームのマネージャー用の手順です。
- KeyResultsのページを開きます。
- 下記の「振り返りテンプレート」をコピーして貼り付けます。
- 同期ブロックではなく、「そのまま貼り付け」を選択してください。
- 日付を入力日に変更します。
‣
FAQ
‣
個人のKey Resultsを達成するためには、Key Resultsで決まっている項目以外の仕事はしない方がよいのですか?
‣