独自の目標管理をしていたら上位組織がOKRの開始を決定したからいい感じに改変した話

マネジメント OKR チーム

こんにちは。インフラ系の部署でチームリーダーをしています、奥村です。

チームで決めた独自の目標管理方法を2019年の4月から運用して一年が経ちました。
一年が経ち、運用が波に乗ってきたところで上位組織がOKRの策定・運用を決定しました。

この記事では下記の事柄について書いてます。

  • どのような独自の目標管理方法を運用していたか
  • OKRを運用することが決まってどうなったのか

この記事で伝えたいことは「自分たちの考えた方法が良い」とか「OKRの方が良い」ということではありません。

OKRのような上位組織と下位組織の連動が必須なものを導入する時の、ひとつの例になれば良いなと思います。

チーム紹介

私のチームが所属している組織

私のチームは、インフラディビジョンという部署に所属しています。インフラディビジョンは

  • 商用インフラ基盤+クラウド利用の管理に関する部署
  • PCや社内ネットワークなど社内インフラに関する部署
  • 内部統制や社内ITルール策定に関する部署
  • SRE的な活動を推進する部署（チームリーダーしているチーム）

上記4つのチームが存在します。

この記事では「上位組織」と呼称します。

私がチームリーダーをしているチーム

サービスの非機能系の改善を図る事でサービス・開発のアジリティを高めるのを目的として活動しております。

特定のシステムを開発・運用しているチームに所属しているわけでは無く、横断的に複数のシステムに協力しています。 また、アジリティを上げる事を目的としておりますので、GitLab Serverの運用やSaaSの契約など、開発によるエンジニアリング以外も行っております。

ざっと以下の様な事を行っております。

  • システムのCI/CD導入・導入支援
  • Infrastructure as Code導入・導入支援
  • サービスの監視・モニタリング改善
  • サーバーのインベントリ情報のデータソース管理
  • GitLab Server運用
  • Tableau Server運用
  • 各種SaaS契約

↓こんなのもやっています blog.engineer.adways.net

この記事では「チーム」と呼称します

背景

チームで決めた独自の目標管理方法を2019年の4月から運用して一年が経ちました。
一年が経ち、運用が波に乗ってきたところで、上位組織がOKRの運用を部署内に提案しました。

突然「やります！」と決まった訳ではなく、半年前からOKRっぽいものを運用しており、この2020年の4月に 書籍をインプットとしたOKR を改めて実施しようという提案でした。

書籍を読んだ上位組織のマネージャー陣が中心になって、現在のチームの状態や現在の目標管理方法を考慮した上でOKRを決めていきました。

インプットした書籍はこちら↓

OKR（オーケーアール）

OKR（オーケーアール）

本題

OKR自体の決定やOKRの運用方法の決定の中で複数の意見の衝突がありました。

  • チーム独自の目標管理方法
  • 上位組織が決めようとしているOKR

との差分で発生した内容について書きます。

チーム独自の目標管理方法

チーム独自の目標管理方法について紹介します。

チームにはOKRはなかったものの、上位組織から与えられたミッションはありました。

チームのミッションは「サービスの非機能領域のQCDを高める」というものでした。

チーム独自の目標管理方法

チーム独自の目標管理方法の特徴は以下の通りです。

  • チームのミッションに沿った軸のリストを作成する。
    • 例：システムコストの最適化、開発者の運用削減、情報の透明性の向上、障害反応速度の向上、etc...
  • 注力する軸を決める
  • 軸に関する成果で定量的に表現できるもの決定する
    • 例：システムコストの最適化 -> 〇〇円の削減、〇〇個の構成見直し、etc
  • 60%を達成とみなすような、ムーンショットな目標値を決定する。
  • 2ヶ月に一度目標を決める
  • チームの目標と各チームメンバーの目標を同列に扱う
    • 例：PoCを〇〇個実施、Infrastructure as Codeに関する技術共有
    • 個人の目標は行動目標でOK
  • 週一で進捗の確認
対象 軸 目標値 アクション候補
チーム システムコストの最適化 4サービスのRIの導入 〇〇サービスへ提案
奥村 KPT Try実施率の向上 80%以上 毎週Tryを振り返る時間を確保する

上記の特徴から得れる効果としては

  • 今後2ヶ月以内に生み出せる成果を想定し、成果を定量的にカウントできるように変換し、ムーンショットの目標を設定する。想定以上の事を実施できるように努力する。
  • 2ヶ月に1度決めるので外部の変化に強い。今自分たちが行うべき事を考える機会が増える。
  • 期間が短いので目標が立てやすい。うまく行かなくても2ヶ月しか影響が無い。
  • 行動目標も許可しているので、定量化頑張る部分に時間を割かなくて良い。

目標の定量化や60%の達成を目指すムーンショット、短期間での設定、週次の進捗確認など、OKRから良さそうな部分を採用しています。

それに加えて、行動目標を許可していること、個人の目標も同列に扱う事など、自分たちのやりやすいようにカスタマイズしたものになっています。

これは、2019年4月から2020年3月の6回の目標設定を行う中で徐々に変化していきました。

年間２学期制のセメスター制（Sex Mentisラテン語 = Semester英語 6ヶ月）を参考にして、年間６区分するということで、デュメスター制（Duo Mentis(ラテン語で2ヶ月)→ Dumester(英語ぽい造語)）と名付けて運用していました。

チーム独自の目標管理方法を作った背景

この後OKRが登場するように、デュメスター制が始まる当初、上位組織はOKRとは別の方法で目標策定・管理を半年毎に行なっていました。

半年ごとの目標管理の場合、「決定当初と状況が全然違うけど、もう決まっている目標だから変えちゃいけなそう......」というの考える機会がよくありました。

チームに目標管理方法決定の裁量が与えられていたので、よりよい方法のスモール案として

  • OKRベース
  • 2ヶ月毎の目標策定

の２つから始まりました。

OKRを運用することが決定してどうなったか

2020年4月にOKRを改めて決めることが上位組織から各チームに提案されました。

「ついにこの時が来たか！！これでデュメスター制の課題だった『上位組織との連動』が実現される！」と考えていました。

確かにこの課題は解決されます。ですが、今まで自分たちのチームが良いものだとして運用していた目標管理の方法との相違点もあります。

相違点は以下です。

項目 デュメスター OKR
ベース ミッション + 軸リスト 上位組織が注力したいこと
発案 ボトムアップ トップダウン
測定 基本定量的 定量的
目標値 ムーンショット ムーンショット
個人の目標 含む 含まない
評価 達成度は評価に直接反映されない 達成度は評価に直接反映されない
期間 2ヶ月毎 6ヶ月毎
運用 週次のMTGで進捗確認 月曜日：チェックインミーティング、金曜日：ウィンセッション

OKRを実際にチーム毎で実施するかどうか？

自分のチームでもOKRを実施することについてはノータイムで受け入れました。

受け入れた上で、「今までの目標管理方法とどう共存するのか？」を考える事にフォーカスしました。

当然、今までの方法を忘れて、上位組織から提案された方法を全受け入れして実施することも考えましたが、自分たちが運用し、最適化してきた物をすぐに捨てることはできませんでした。

上位組織のマネージャーも、私のチームが１年間掛けて最適化してきた事を知っているので、提案した方法を強要することはありませんでした。

共存

デュメスター制とOKRを折衷し、チームの目標管理で変更された点は

  • 追加
    • 6ヶ月のOKRをチームで決める
    • チェックインミーティング&ウィンセッションを指定されたフォーマットに沿って週次のミーティングで実施
  • 変更点
    • 上位組織が注力したいことを優先する

変わった点は上記3点のみで、個人の目標を含めたり、2ヶ月毎に目標を決めるのは継続して行なっています。
また、これまで2ヶ月毎に注力する領域の決定に利用していた「ミッションに沿った軸」はチームのKPIとして定量化され、OKRと別軸の成果計測方法として残りました。

つまり、単純に目標設定において行うことが追加された 感じになりました。

今はこれで良いと考えています。

上位組織のOKRがそれぞれのチームのミッションや現在の取り組みをカバーできるような内容になっていたのでこれだけで済みました。

チームが重要だと考えている事と上位組織が重要だと考えている事に大きな差がある場合はうまくいってなかったと予想しています。

課題

完全に2重管理というわけではないですが、共存するためのオーバーヘッドは確実に発生している点は課題となっています。

また、上位組織のOKRの設定期間が6ヶ月から3ヶ月になった場合には2ヶ月毎の目標策定は厳しくなることが予想されています。

f:id:AdwaysEngineerBlog:20200618212359p:plain

所感

案ずるより産むが易し

「自分たちは目標管理の目的は達成しているから、新しい方法をわざわざオーバーヘッドを受け入れてまで採用する理由は無い」というのも今思えばできたなぁと思います。

ですが、何事もやってみないと実際のところは分からないですね。

始める前は「部署に属するチームが同じ目標を追うことが重要」という点に期待し、「オーバーヘッドが増える」という点に懸念していました。

新しい目標管理方法で運用してから1ヶ月ほどしか経ってないですが、現在はオーバーヘッドが増えているのが事実です。

これも学びだとするなら、始めてみないと分からなかったことです。この経験を元に次に活かせます。

守破離大事

独自の目標管理方法を採用・運用した中で問題だった点は、はじめから守破離の「破」まで行なってしまった事でした。

「守」から行っていれば、「OKRをチームで運用した結果、〇〇の経験を得ました、なので現在はこういう運用を行なっております」と言えました。

また、カスタムせずに問題なく運用できた可能性もあります。

まとめ

「『独自の目標管理をしていたら上位組織がOKRの開始を決定した』から不満を爆発させている」ではなく、
「『独自の目標管理をしていたら上位組織がOKRの開始を決定した』けど、今の所問題なく運用できてるよ」という記事でした。

少なからず、新しい取り組みに対して保守的になる人もいると思いますが、個人的には「まずやってみる」の精神が大事だと思います。

「まずやってみる」場合は、仮説を立てて、どのタイミングでどのような振り返り・成果の確認をするか決めておきましょう。

最後までご覧いただきありがとうございました。