SocialDog情報ポータル（一般公開）とは、SocialDog社内のルール、社内制度、ガイドラインなどをまとめたページです。会社選びの参考になるように社外にも公開しています。

★2024/2/2にNotionに移行しました。今後Confluenceは更新されません。下記をご覧ください。

移行先: 社外の方向け | 社内の方向け

OKRについて

Owned by Konishi Masafumi
Last updated: 12月 18, 2023
1 min read

人事制度：人事制度（等級・評価・報酬）・面談・OKR・等級定義表・マネージャー向け

2023/4/3　新人事制度のため、初版を公開

2023/6/22　「コミットするOKR」だけではなく、「コミットKR」と「ムーンショットKR」の2つを設定するよう変更。変更理由：「野心的な高い目標を掲げることで、より高い成果を追う思考にしたい」「挑戦を推奨するというバリューの考え方と近づけたい」

2023/10/4　GitClearの指標を使用する場合のルールを追記

2023/12/18　チームOKRの難易度設定について、上位のOKRとの整合性が保てないことを許容する場合があることを追記。

OKRとは

  • OKRとは、上記のように、会社全体・各チーム・個人にObjective（目的）とKey Results（成果指標）を設定し、定期的にその進捗を確認する仕組みです。

  • 全社OKR・チームOKRから、個人のOKRまで設定し、相互の関連を定義します。

Objective

  • 目的。目指す状態。

  • 下位のObjectiveを達成すると、上位のObjectiveが達成されるようにします。

  • 表現は自由です。聞いたらワクワクするような表現にしましょう！

  • 重要なことにフォーカスするため、1つにします。複数設定したくなった場合は、抽象度を上げるか、重要でない方を削除するかして1つにしましょう。

Key Results

  • 成果指標。目標。目指す状態に必要な結果。

  • できるだけ「定量的」（例：15件以上）にします。

    • 定性的なKey Resultsにする場合は、最低限、100%（達成度：A）の状態がどういう状態かをOKR設定のタイミングで決めておきます。

  • できるだけ「結果指標」（例：●●を●●にする）にします。

    • 難しい場合は、「行動指標」（例：●●をする）でも良いです。

  • 評価期間全体の結果を反映した指標にします。

    • 最終月だけでなく、期間全体の数字にします。

  • 3つ程度、多くても5つに絞り込みます。

  • 「コミットKR」と「野心的KR」の2つを設定します。

    • コミットKR

      • 「OKR達成度評価」のA評価に相当します。

      • 評価期間中に必ず達成することを目指す内容にします。

    • 挑戦KR

      • 「OKR達成度評価」のS評価に相当します。

      • いわゆる「野心的なOKR」で、70%くらいなら達成できそうな、ストレッチゴールとなる内容にします。

  • どちらかのみだと発生する以下の問題を防ぐためです。

    • 「野心的なKR」のみだと起きる問題

      • 野心的な目標なので、「未達」が当たり前となり、達成感が減ってしまう。「未達」が続くと、評価・報酬制度と紐付けた運用が難しい。

      • 開発組織では、スケジュールや品質など、野心的目標とそぐわない場合が多い。

    • 「コミットするKR」のみだと起きる問題

      • 高い成果を追う思考が生まれにくくなる。

      • 挑戦を推奨するというバリューに反するように見える

GitClearの指標をKRにする場合

比較しやすくするため、以下の定義のものを利用してください。

  • 集計方法

    • 6ヶ月分の合計を単純に週数（365/12*6/7=26.07）で割る。

    • 計算を簡便にするため、有給等を加味しない。在籍していない期間は加味する。

  • 使う指標

    • Diff Delta

    • PR作成数（PRs posted count）

詳細は、エンジニアOKRについてを参照。

チームのKRの難易度について

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

職種

Objective

Key Results

開発

待望のInstagram投稿機能をユーザーが大満足する形でリリースする

  • ●●機能を●月までにリリースする

  • 不具合が●件以下

開発

開発効率を上げ爆速でリリースする

  • PRの平均作成数●以上

  • hotfixを月●件以下にする

開発

コードの品質を向上させる

  • レビューの平均コメント数●以上

  • 変更障害率●%以下

  • 必ずEXPLAINの結果を見るようにする（行動目標）

SRE

アプリケーションのパフォーマンスを向上させる

  • ファーストビューの表示にかかる時間を●秒以内にする

  • UserList画面で●●の表示にかかる時間を●秒未満にする

  • コードレビューにかかる時間を半分にする

マーケティング

企業ユーザーを増やす

  • Reg ●件以上

  • FTT ●件以上

  • 登録当月売上　●円以上

カスタマーサクセス

ユーザーのニーズを把握し、特にBusinessプランのカスタマーのサクセスを支援する

  • 解約率●%以下

  • BusinessプランのTrial CVR率●%以上

  • オンボーディングmtg実施率●%以上

  • ユーザーインタビューを●件以上実施（行動目標）

人事

従業員エンゲージメントの向上

  • wevoxのスコア●●以上

良いOKRのチェックポイント

まずObjectiveを決め、その次にObjectiveを達成している状態を想像してKey Resultsを決めます。

Objective

  1. 個人Objectiveを達成することが、上位のチームのObjectiveを達成することに繋がるか？

    1. →つながらない場合は上位のObjectiveとつながるものに変更します

  2. Objectiveの表現は具体的すぎだったり、抽象的すぎないか？

    1. 具体的すぎると、それ以外の重要なことに意識がいかなくなります。適切な抽象度にします。

    2. 例

      1. 「開発チームに貢献する」

        1. →抽象的すぎる。

        2. 例えば、「●●機能の●月リリースを牽引する」くらいの粒度にする

      2. 「Datadogを導入する」

        1. →具体的すぎる。手段ではなく目的を書く。

          1. 例えば、「サーバーのエラー・不具合を減らし、顧客のペインを減らす」

  3. 聞いたらワクワクするような表現になっているか？

    1. 例：解約率低減　→　チャーン撲滅大作戦！

  4. 本人やそのチームの努力次第で達成でき、そのための裁量を持っているか？

    1. →達成できない目標は立てないでください。

  5. 評価期間内に最終結果が出るか？

    1. →評価期間内で終わるような書き方にしてください。

      1. 例：●●機能を●月にリリースできる状態にしておく

  6. 自分以外の要因で達成・未達成になる要素がないか？（マネージャーを除く）

    1. →Key Resulstsの達成の判断の際に、自分以外が原因で達成できないことがないようにします。

  7. 等級アップ（昇格）を意識しているか？

    1. この評価期間が終わったら昇格する可能性がある場合（等級内の報酬レンジの上限に近い場合）は、Objectiveに昇格のための必要な要素を入れます。

Key Results

Objectiveが決まったら、KeyResultsを考えます。

  1. 難しすぎず、簡単すぎない内容になっているか？

    • 期待が高すぎると、一定の結果が出ていて評価すべきなのに「未達」ということになってしまいます。

    • 期待が低すぎると、結果が出ていなくて本当は「イマイチ」なのに、「達成」したことになってしまいます。

  2. 「Key Resultsを達成できたらObjectiveも達成できた」と言えるようなものになっているか？

  3. Key Resultsの数が多すぎないか（4以上）？

    1. 多すぎると分かりにくいので、1〜3程度になるように設定してください。最大でも5までとしてください。

    2. 複数の目標のそれぞれの優先度が大きく異なる場合はウェイト（例：40%のように）を記載してください。

  4. 自分以外の要因で達成・未達成になる要素がないか？（マネージャーを除く）

    1. →Key Resultsの達成の判断の際に、自分以外が原因で達成できない、ということにならないようにします。

  5. 具体的・客観的・測定可能なものになっているか

    1. →数値化できるものはできるだけ数値にします。

    2. 以下のような表現は具体的ではないので使わないこと。

      1. 努力する、徹底する、目指す、支援する、効率化する、等、できるだけ

  6. 「行動指標」ではなく「結果指標」になっているか