ディップ Advent Calendar 2019 の13日目です。
この記事について
私はディップ株式会社の開発部門で、「フロントエンド課」というWeb画面の開発を担当している部署の課長をやっています。
今回、部長から開発部門でOKRの検討を任されていろいろ調べて検討したのですが、最終的には「OKRを導入しない」ことに落ち着きました。
その検討プロセスを公開する事で、これからOKRを検討する誰かの参考になるかもしれないと思ったので、この機会に記事にしたいと思います。
OKR導入検討の目的と背景
開発部門の貢献度を可視化したい
以前から、開発専門部隊である我らが開発部門の頑張りがサービスにどれだけ貢献できているかを、どうにかして定量的に示したいという意見がありました。
OKRでは定量的な指標を持って目標設定することになるため「これによって開発部門の貢献度の推移をグラフで分かりやすく示せるかもしれない」という期待感があり、OKRの導入を検討する理由の一つになりました。
評価に対するメンバーの納得感の改善
弊社の人事評価は「MBO（Management By Objectives）」で行われていますが、評価（査定）への納得感が低いエンジニアが多く、これを少しでも改善したいという組織長たちの想いがありました。
OKRの導入によって評価の納得感を改善できる、という想定ができていたわけではなく「運用の仕方次第でいい感じにできたらいいな」くらいの感覚でした。
OKRについて調べた
「OKR」という言葉を耳にしたことはありましたが、「各自で目標立てて、時折振り返りつつ頑張る制度」というふんわりしたイメージを持っている程度で、ちゃんと調べたことはありませんでした。私以外の組織長も、OKRを正しく理解できているとは限らないし、知識に偏りがあるかもしれません。
制度として導入していくなら、前提として各組織長の「OKRとは」の認識をしっかりと合わせておかないと、運用フェーズでメンバーの解釈にバラつきが生じてカオスになります。
そこでまず、「OKRとは何か？」について情報を整理し、組織長に展開しました。
非常にざっくりとまとめるとこんな感じ。
OKRとは
「Objectives and Key Results（目標と主要な結果）」のアクロニム。
MBO（Management By Objectives）との対比でよく説明されます。
チャレンジングな目標設定を可能にする
MBOは、自身が設定した目標の難易度と達成の度合いによって個人報酬を決定する仕組みです。
目標を設定するのはOKRでも同じですが、MBOの目的は「報酬決定」です。
必然的に、目標設定時点から達成率を高めようという心理が働くため「チャレンジングな目標が設定されにくい」という特徴があります。
それに対しOKRは「個人の報酬決定とは分離する」ことによってチャレンジングな目標設定をしやすくするという目的があり、MBOへのアンチテーゼとして注目されるようになりました。
メンバーのモチベーションを高める
「OKR」の著者・クリスティーナ・ウォドキーはこう述べています。
「朝ベッドから目覚めたときにワクワクするような、心躍るような目標を立てましょう」
Objectivesは、メンバーのモチベーションを高められるような目標にすることが重要です。
Objectivesは定性的・抽象的で構いませんが、野心的で挑戦しがいのあるものを設定します。
そうできることが、MBOにはない、OKRならではのメリットだからです。
目標を集束させる
まず上位の組織でOKRを設定し、関係する下位組織ではその役割に応じて上位組織のOKRに基づいたOKRを設定し、さらにそこに所属するメンバーのOKRを・・・とやっていくことで、たとえば企業で定めた全体の方向性に各組織や個人の目標が集束した状態ができあがります。
そうすることで、企業・組織の業績を伸ばすために大きな目標を達成することが、OKRの狙いです。
MBOに置き換わるものではない
OKRとMBOは目的が異なります。
OKRを導入しても、報酬決定の手段であるMBOが不要になるわけではありません。
現在運用しているMBOを置き換えるには、報酬決定のための別の手段を模索することになります。
OKR導入検討の方針
OKRについて組織長の認識を合わせたところで、導入検討の方針を立てました。
OKRを知らないメンバーも多いと考え、スムーズかつ効果的に運用に入れるよう、方針は下記の2点としました。
- できるだけシンプルな設計にすること
- OKR導入の目的を明確にし、全員が理解できる状態にすること
検討したこと
- 組織レイヤーのどこからどこまで導入するか
- Objectives と Key Resultsをどのように持たせるか
- KR検討のガイドライン
順に説明していきます。
組織レイヤーのどこからどこまで導入するか
どこから
- 開発部門のみ？他部門も巻き込む？
→ 他部門ですでにOKRの運用を始めているところがあったため、開発部門のみとしました。
どこまで
- 課まで？個人まで？
→ OKRを個人レイヤーまで落とし込むとMBOとの両立で混乱が生じる恐れがあるため、課までとしました。
Objectives と Key Resultsをどのように持たせるか
以下の2案を検討しました。
①部・各課がそれぞれOとKRを両方持つ
- Good 各組織に最適化したOを設定できることで、モチベーションを引き出しやすい
- Bad 追いかける指標が増えて、複雑になりすぎる
- Bad 下層レイヤーから見て目標が複数になり、目的がぼやける
②部がOを持ち、各課がKRを持つ
- Good 部全体の目標の実現に直接的につながるKRを各組織が持つことで、部の目指す方向に組織全体が集束する
- Good 運用がシンプルで分かりやすい
- Bad 部全体で通用する目標設定をするため目標の抽象度が高くなり、目標達成度の判断が難しくなる恐れがある
→検討方針と照らし合わせ、よりシンプルな運用が実現できそうな「②部がOを持ち、各課がKRを持つ」としました。
KR検討のガイドライン
各組織でKRを考えてもらうにあたり、設定の仕方にガイドラインを設けることにしました。
（必ず従ってもらうルールではなく、設定方法に迷った場合のための手引きとして使う想定）
各項目の例は、仮にObjective＝「Just In Time Delivery（最適なものを最適なタイミングで提供する）」と定めた場合のものです。
1. Objectiveを単語に分解し、別の言葉に置き換えてみる
- 「最適なもの」とはどんなものか？
- 「最適なタイミング」とはどんなタイミングか？
2. それぞれの単語に、自組織で対応するものをリストアップする
- 自組織で提供できる「最適なもの」はどんなものが考えられるか？
- 自組織でそれを「最適なタイミング」で提供できている状態とはどういう状態か？
3. リストアップしたものを実現するための、具体的なアクション（KR候補）を出す
- アウトプットをより「最適なもの」にするために必要なアクションは何か？
- アウトプットをより「最適なタイミング」で出すには何をしたら良いか？
- 継続的に実施するアクションは、期間や頻度を定めることで回数などをKRにできる（例：毎月N回、半年間でN回など）
- プロジェクトやROIT（Return On IT）、SLAに関連する指標もあり得る（PJ予実差N日以内、○月までのダウンタイムN分以内など）
4. KRに定めるアクションを選抜する
- できれば、途中経過も定量的に計測可能なもの
- 結果を判断する際、「できた or できなかった」「どのくらいできた」が明確にわかるもの
ここで壁にぶつかった
導入が現実的なのかを検証するため、上記のガイドラインを元にいくつかの組織で実際にOKRを考えてみたのですが・・・
組織構造とKR設定との親和性に課題が見つかりました。
組織ごとの定量的指標が出せない
弊社の開発部門は、プロジェクトマネジメント・バックエンド開発、システム基盤（サーバー・DBの保守運用）、フロントエンド開発、API開発、ネイティブアプリ開発といった各専門分野ごとに組織が分かれています。
「バイトル」「はたらこねっと」「ナースではたらこ」など、弊社が運用しているプロダクトは複数あるのですが、各組織内でそれぞれプロダクトのチームに分かれており、関係する専門組織が連携することで一つ一つのプロジェクトを回す分業体制をとっています。
各プロダクトのアクセス解析データ（PVや応募数など）はもちろんいろいろと取られているのですが、それらの指標の変動量に対して開発部門の各組織がどれだけ影響を及ぼしたかは算出不可能です。
なぜなら、それらのデータはプロジェクトで企画部門を含む各組織が連携して成し遂げたことが集約された結果だからです。
また、それ以外で定量的な指標を出せるかというと、その材料がほとんどなく、それも困難であることが分かりました。
こうして、当初思い描いていた「開発部門の貢献度を可視化したい」は、組織単位のOKR導入という方法では実現が難しいという結論が導かれました。
組織でOとKRを対応させる難しさ
KRを設定するにあたり、組織としてOKRを導入する以上、各組織にいるすべてのメンバーが何らかのKRに関われるように設計するべきと考えました。
実際は各組織にはそれぞれ専門性の高いメンバーがいて、やっている事は一人一人異なります。
結局、個人個人の業務や組織内のチームに合わせたKR設定にならざるを得ませんでした。
KRの粒度も揃えられず、開発部門全体を俯瞰した時にいびつな制度になってしまう懸念もあり、このような状態でOKRを導入しても、メンバーのモチベーション向上につながるとは考えにくい状態でした。
評価の納得感は改善しない
OKRが報酬と切り離された存在である以上、メンバーの評価（査定）に対する納得感の改善には寄与しないと考えられました。
組織のKRに寄与する内容でMBOの個人目標を設定し、KRへの貢献度を報酬決定の判断材料にするような事をしてしまうと、本末転倒です。
結論
その後、部長や他の組織長たちとも幾度となく議論を重ねましたが、弊社のような組織の構造ではOKRをそのままの形で導入することはしない、と一旦結論付けることになりました。
OKRを検討してみて、プロダクト別の組織があってこそ本来の形で機能するものなのかな、と感じました。
弊社のように企画・開発がはっきりと分かれている組織構造の場合、企画部門と開発部門で目的（Objective）を共有できている状態をまず作ることがOKR導入の第一歩になるかもしれません。
ただ、「目標を集束させる」「メンバーのモチベーションを高める」というOKRの利点をうまく生かすことができれば、メンバーの目線を高いレベルで合わせる事にもつながっていくのではないでしょうか。
OKRという形ではなかったとしても、それを実現する方法を今後も模索していきたいと思います。