Adways Advent Calendar 2020 4 日目の記事です。

どうも、大曲です。

今日はMGRとして事業貢献を目指して色々と模索したものを簡単に紹介できればいいなと思います。
社内で改善したログをつなぎ合わせたものになりますので、読みにくい部分があると思います。
ご了承ください。

書くこと

組織体制とOKRの変化
OKRの目標内容（細かい説明はなし）

書かないこと

OKR運用の話（フィードバックや振り返り）

事前説明

言葉の定義

ユニット・・・1開発チームを指す
Div・・・複数の開発チームが所属する組織を指す
UM・・・ユニットのエンジニアリングマネジャー（スクラムマスター、1on1）
チーフ・・・ユニットのテックリード（技術選定、サービス品質管理..etc）
テックリードの定義と運用に関して
Div MGR・・・Divのマネージャー
リードチーム・・・組織体制（ユニット..etc）とは別で職能毎で集まっているチームを指す
Divが力を入れるべき分野毎でチームが結成されており、Divをリードして組織全体のスキルの向上を狙う
（スクラム、言語、テックリード、デザイン、機械学習）
技術毎のスペシャリスト・・・言語に特化したスペシャリスト
技術ごとのスペシャリスト制度に関して

組織の状況

プロダクトの開発フェーズ
- 運用フェーズ、新規開発フェーズなど、プロダクトのフェーズは様々
組織構成
- チーム規模は20~30名
- 開発チームは4つ
- 開発プロダクトは5~7くらい
プロダクトチーム体制
- 事業側組織と開発側組織に分かれている
- 事業側組織に、営業部署やプロダクトの方向性を管理する部署がある
- 開発側組織に、開発チームを統括する部署がある

別の組織ですが、以下の記事で書いてくれた状態とだいたい一緒です。

OKRで実施していること・してないこと

記事の内容の中では多少の変化はありますが、ざっくりどんな状態かイメージできれば良いかなと思います。
○＝実施中、×＝未実施、△＝調整中や不完全な状態

項目	実施の有無
KRを達成したらObjectiveが達成した事となる	△
KRは定量的である	○
OKRは四半期ごと	×
DivOKR、ユニットOKR、個人OKRがある	○
ユニットKRが必ずDivKRに紐づいている	○
OKRは全てムーンショットである	×
OKR自信度状況があるか	×
健康・健全性のチェックを実施しているか	×
Winセッションは実施しているか	×
優先事項の確認（P1、P2）	×
スクラムとOKRの併用を行なっている	○
長期的な目標あり	△

時系列での変化

導入からの経緯

2018/07~2018/10 検証フェーズ　DivOKR、役職者のみ個人OKR
2018/10~2019/02 検証フェーズ　DivOKR、ユニットOKR
2019/05~2019/08 DivOKR、ユニットOKR、個人OKR
2019/10~2020/02 DivOKR、ユニットOKR、個人OKR
2020/05~2020/08 DivOKR、PJOKR
2020/09~2021/01 DivOKR、ユニットOKR、個人OKR（期間を変更）

2018/07~2019/08までは以下のブログで説明してあります。

今回は2019/04から目標で実際の目標も見せた上で説明できればいいなと思います。

2019/10~2020/08の振り返り

2019/04~2020/02 DivOKR、ユニットOKR、個人OKR

教科書通りのOKRの設定を行いました。
サービス毎に分割されているチームに対して「DivOKR → UnitOKR → 個人OKR」を実施しました。

組織イメージ
f:id:AdwaysEngineerBlog:20201204164348j:plain

スケジュール
f:id:AdwaysEngineerBlog:20201204164415j:plain

OKR詳細

Div Objective

プロダクトへの最高の貢献をする組織

Div KR

カテゴリ	KR
ビジネス	新規価値 X 社外価値のリリースを15件消化
テクノロジー	スリム化案件消化数45件
UX	案件価値分析15件

ユニット名	Objective	主要成果(Key Results)
ユニット1	売上を生み出すための機能を提供する	検証のための提供機能7件
		ARRRA分析からの改善提案5件
ユニット2	自ら継続的に改善を行うTeam!	課題の発見数 70件
		自ら発見した課題に対してTry 50件
		チーム健康指標 3.5以上
ユニット３	ユーザ体験と収益方法をデザインする	顧客KPI達成のための検証14件
		ユーザー中心の設計手法に基づいて検証、分析13件
		高速化のためのスリム化案件14件

振り返り

メリット

事業に左右されないOKRが立てられる
- ユニットが抱える案件の種類に応じたKRを立てやすい
- 検証のための機能提供を7件..etc
チームの状況に合わせたKRは立てられる
- チームの組織力向上のためのKRなども可能となる
- 自ら発見した課題に対してTry 50件..etc

デメリット

実作業や成果とは直結しないことがある
- チームの状況に合わせたKRがあるため成果（案件）とは別扱いになり、チームの負担となることがあったり、行動は実施したが結果に繋がらなかったりする
ユニットが全ての分野を網羅する必要がある
- ユニット3は人数が多かったためテクノロジー、UX、ビジネスの調整が必要だった
- ユニット内でバランス調整が難しい
- 逆にユニット1は新規機能の専属チームだったのでバランスが不要だった

2020/05~2020/08 DivOKR、PJOKR

事業貢献を意識して体制をサービス単位からプロジェクト単位に変更し
PJ OKRを導入してOKRを事業貢献に直結させる動きをしました。

PJ OKRの検証
- PJ OKR = Project OKR
- メイン案件を軸にOKRを立てる
- リリーストレインを元にPdMと話し合って目標をたてます
個人OKRの削除
- 検証状態で春PJ OKRを元にした個人OKRはやらないことにした
- また検証期間として2ヶ月なので半期としてはDiv OKRを意識した個人目標を導入した

組織イメージ
f:id:AdwaysEngineerBlog:20201204164451j:plain

スケジュール
組織全体の検証の影響で個人目標決めが遅れるイレギュラーなスケジュールになりました。
f:id:AdwaysEngineerBlog:20201204164507j:plain

OKR詳細

Div Objective

プロダクトへの最高の貢献をする組織
Objectiveは変更無し

Div KR

カテゴリ	KR
ビジネス	仮説検証を通して、次期PJ候補となる案件を7件創出する
テクノロジー	オンプレサーバのクラウド比率を50％達成
チーム	スクラムリードを7人育成

UXのKRはビジネスKRと統合できたため無しにしました。
代わりにスクラム改善を活発化させるためにDivメンバーを対象にした教育に力を入れました。

PJ名	Objective	主要成果(Key Results)
Dev1	機能提供を通して仮説から検証を繰り返し、効果改善を行うことで営業の提案資料に組み込めるようにする	開発チームの改善提案数を一人あたり二件行う
		分析後の改善数6件
		MVPキャンバスの仮説立証数3件
Dev 2	xxx機能を構築してユーザーに最適な広告を提供できるようにする	xxxに沿った分析を2件
		xxxに沿った機能リリース1件
		機械学習の環境改善を1件
Dev 3	デザインプロセスを体系的に確立し、初回利用ユーザーへのサービス体験価値を提供する	デザインプロセス実施事例5件
		評価分析実施数5件
Cloud 1	システムを再利用しやすい堅牢な状態にする	xx対応対象ロールの対応率100%
		xx関連のミドルウェア・ソフトウェアのコード化100%
		受け入れテストツールの導入案件数2件
Cloud 2	クラウド化における、再現性の高い移行実績を作る	クラウド化貢献サーバ数2件
		リリースのIaC実施率 80%

xxx=案件名が直接入っていたのでボカしました。

振り返り

メリット

PJ OKRがシンプルになりやすく、やるべきことがはっきりとする
- PJチーム内でバランスを取る必要がない（テクノロジー優先？ビジネス優先？..etc）
事業に対する貢献が立てやすい
- プロジェクトとして目的や価値が明確なので事業に対する直接的な貢献が実施できる

デメリット

事業戦略に影響されやすい
- 案件に引っ張られる
- やりたい事がやれない可能性あり。自主性の欠落に繋がる可能性がある
- 組織としては成果を出す分野を決めているため成果に繋がらない場合はPdM責任となる
リードチームの方針を組み込んだOKRは無い
DivOKRに紐づく個人目標はあまりなかった
- ユニットOKRやPJOKRまで落とし込まなければ紐付けは難しそう

過去のOKRからの学び

ユニットOKR != ユニット成果
ユニットOKRのバランス調整
リードチームの台頭

ユニットOKR != ユニット成果

事象：
- OKR関連の作業がユニットの実作業や成果に関わりが少ない
影響：
- 成果（案件）とは別扱いでチームへの負担となる
- 労力をかけている内容がOKRに反映されない

f:id:AdwaysEngineerBlog:20201204164549j:plain

イコール関係が正しいというわけではないですが、頑張れば頑張るほどOKRから遠ざかるのは辛すぎます。
無の状態から目標を掲げるのは問題ないですが、それのみは良くないかなと考えました。
辛みが増すだけで、追い込まれる感じが凄くあるのでお勧めできないです。

挑戦する文化がない状態なら、行動のみを認めるのは大事だと思います。
ただ、自分たちの組織はそのフェーズを過ぎていると考えており、
より難易度の高い設定を求めても良い。成果を見据えた挑戦を実施していきたいと思いました。

本来は一番労力を使う開発案件などをOKRに組み込みたいのですが。。
案件の決定権がユニットにはないため、判断しづらく目標として定めにくいことが多かったです。
サービス単位の組織だからこそ発生する部分でもあると思います。

ユニットOKRのバランス調整

事象：
- 分野ごとが独立するKRでありバランス調整が必要
影響：
- ユニットという少ない人数でのバランス調整は逆にコストがかかり複雑度が増す

f:id:AdwaysEngineerBlog:20201204164624j:plain

2019/04~2020/02のユニット3の例を取り上げます。
ユニット3のOKRは、UX、テクノロジー、ビジネスの３つと繋がるKRを立てました。

これ自体は非常に理想的だと思います。そして進捗も悪くはありませんでした。

f:id:AdwaysEngineerBlog:20201204164650p:plain

しかし、進捗確認7回目の時にKR1の進捗が鈍化しました。そこにリソースを寄せる必要がありました。
その際は以下の手順を実施しました。

ユニットOKRの進捗が悪い
ユニット内で対応策を議論
リソース配分をPdMに交渉
PdMが案件のリソースや優先度を変更

事業への貢献度に基づいてリソース配分を決めていますが
OKR達成のために変更する動きが正しいかは微妙なケースなのではないかと思いました。
（正しい時もあるが...）
そもそも、OKR達成は事業への貢献を最優先にすべきじゃないのかと。。。

Divの規模20名以上ならば分野毎で独立しても問題ないですが、
5名程度が基本であるユニットの規模では今後は許容すべきではないと思いました。
チーム３はたまたま10名近くリソースがあり実際にバランス調整を行い、達成に向けて活動できました。

同じプロジェクトや案件を通して、技術改善もデザインプロセスもやりたいならいいと思います。
また片手間でやれる規模も問題ないと思いますが、
それぞれが独立して、リソースも結構必要そうなものをKRとして入れ込むのは良くないなと感じました。

リードチームの台頭

事象：
- リードチームの方針とOKRが一致していない
影響：
- OKRでのメリットである優先度の明確化が混乱する
- リードチームの作業優先度の取り扱いが判断出来ない
- 大事だから業務とは別でプラスαでやる羽目に..

これは、OKRの設計というより組織の変化による嬉しい悲鳴であります。

2020/04~08の間に、各リードチームが方針を立てて活動をし始めました。
その影響もあり、OKRと関連しない分野がでてきて優先度に混乱が発生しました。

f:id:AdwaysEngineerBlog:20201204164716j:plain

SM=チームKRと連動
チーフ=関連無し
技術毎のスペシャリスト=関連無し
UX=Dev3のOKRがほぼUX関連

最終的にOKRと関連がなかったチーフと技術毎のスペシャリストが細々と活動した形になりました。

OKRの再設計

過去の振り返りから設計し直しました。

方針

破綻するケースを防ぐ
- OKR：組織間の繋がりがないこと　→　仕事の優先度に混乱が起きる（どっちが優先度高いの？？？）
- 理由：破綻すると仕組みとしての意味を為さなくなるから
状況が把握できるのは3ヶ月間とする
- 理由：
  半年先まではビジネスの状況が見えないため、計画としては諦める
  3ヶ月のサイクルで事業の優先度が変わることが多いから
- 半年先まで決めるなら抽象度の高い成果とする（例：新規価値 X 社外価値のリリースを15件）
  具体的な成果にはしない（例：xxに沿った機能リリース1件）

要件

全体に関わる用件

Div OKR → ユニットOKR → 個人OKR（職務も含む）の順番で必ず決める
- ユニットに属さないMGRはDivOKR → 個人OKRとなる
- 理由：組織的な繋がりがなくなるとOKRとして破綻するため
DivOKRはObjectiveとKRで決める人を分ける
- Div Objective（目指すべき組織状態）：MGR
- Objectiveに達成のために影響あるKRを各分野で決める
- 無理な場合もあるため、その場合はそれぞれの分野の重要な成果をKRとする
- Div チームKR：UM
- Div UXKR：UXデザイナー
- Div テクノロジーKR：チーフ
- Div ビジネスKR：PdM
- 今まではMGRがメインで決めていたが、MGRだけでなくメンバーも巻き込んで決める
OKRの期間は分ける
- DivOKR（6ヶ月）→ ユニットOKR（3ヶ月）→　個人OKR（3ヶ月）とする
- Div OKR：
  Divに対して大きな変化を起こすためには半期の粒度がちょうど良いため（コストパフォーマンスを考慮した時に半年が一番良い）
  ユニットOKRほど具体的な成果を書けないので抽象度の高い成果とする。
- ユニットOKR：
  Divとは異なりより具体的な成果（案件の成果物）をKRとして定めやすい。事業貢献を高めるために案件を考慮したKRであるべきだと考える。
  それを考慮するとビジネスの状況に合わせて案件に変化があるため3ヶ月とする。
- 個人OKR：ユニットOKRが変化するため個人OKRも合わせる
事業に影響するKRがユニットOKRには必ず一つはあること（努力目標みたいなもの）
- 良い例
  - ユーザー属性・行動に沿った機能リリース1件
  - 管理画面の利用ユーザーの検索作業での時間が50％削減
  - クラウド比率を10％向上
- 悪い例
  - 分析実施1件
- 理由
  事業貢献を目指すために具体的な成果となるKRを立てたいから
  PJ OKRでプロジェクトに特化できたKRが出来たため、今後も成果に繋がるKRは継続したい
  出来ればリリースよりも事業の数値などであって欲しい
  DivOKRは半年なので見通しが難しいので具体的成果は求めない

Div OKR

Objective
MGR（3名)がメインとなって決める
理由：
各分野の状況を把握している最低限のメンバーで考えることで、組織全体を考慮した目標を考えられると思うから
Key Results
Objectiveに達成のために影響あるKRを各分野で決める
無理な場合もあるため、その場合はそれぞれの分野の重要な成果をKRとする
内容によってはGM判断でKRとして扱わない場合もある
（組織全体で優先度すべき内容であるかをGMが判断する。そうではない場合は優先度を下げる）

ユニットOKR

Objective
PdMがメインとなって素案を作り、最終決定はユニットで合意を取る
理由：
プロジェクトのObjectiveをPdMが素案を作ることによってプロジェクトKRが効率よく決まったため
また、今回のユニットOKRもプロジェクOKRと同様で事業貢献を意識するため案件がメインとなる
そのためプロジェクトの状況を把握しているPdMが素案を作ることでユニットとしての方向性が定まると判断
Key Results
ユニットメンバーがメインとなりKRを決める
PdMも参加し、意見を言ったりしてユニットと一緒にユニットOKRの合意を取る
事業に影響するようなKRが必ず一つは含まれる様に心がける
詳細は上記の要件部分に書いてある
OKR達成のために重要視したい分野がある場合はそれもKRに含めておk
PdMとの合意した上で含める事で開発時の価値の不一致が起こりづらくなる
例：
　リリースのIaC実施率50％（クラウド率だけでなく、成果物の品質であるインフラのコード化を重要視した）
　デザインプロセス実施事例5件（開発案件を通して、プロセスの最適化を重要した）

個人OKR

Objective
各自自分の状況に合わせて重要視する項目に寄せたObjectiveを決める
複数のOKRに紐づく人もいますが、優先順は「DivOKR>ユニットOKR」とする
ただし、DivOKRでの活動の度合（メイン担当ではないや意見を言う立ち位置）によってはユニットOKRを優先しDivKRに紐付くKRを立てなくても良い
Key Results
組織としてDivKRやユニットKRに紐付く目標が最優先である
それらを意識した個人KRを考える必要がある
個人の成長のためのKRは組み込んでも問題ない
ただし、半期で取れる時間は限られる前提で判断すること（明確な制限を行うかは個人OKRがDiv全体で出揃った時に判断する）
DivKRとチームKRの両方に紐付くメンバーもいる（役職者などが該当する）
個人OKRでの優先度で迷った場合はMGR判断で優先度を決める
理由：UMや役職者だけではDivとチームの両方を加味して優先度を決めることは難しい。全体を把握できるGMが優先度を決めて、リソース調整を行う
例：DivKRを優先するため、一時的にユニットのスクラムから抜けて一人で集中する時間を確保する）

メリット

大きな破綻を防げる
- 優先度の混在が起きない
- ※技術ごとのスペシャリストは仕事内容が教育や技術研究に近いので混在が発生する可能性あり

デメリット

OKRでの時期的なズレ
- DivOKRは半期毎、ユニットOKRは四半期毎となる。
- ユニットを取り巻く環境は事業に左右されることがある（これはある種仕方ない部分と判断する）ため、より事業貢献を目指すKRの精度を上げるためにあえて時期をずらす

振り返りに対する改善

ユニットOKR != ユニット成果
- → 3ヶ月であるため開発案件を見据えた目標が立てられる
ユニットOKRのバランス調整
- → 目的に沿ったユニット構成であるため独立したKRが乱立はしない
リードチームの台頭
- → リードチームが中心になりDiv KRを推進する

2020/09~2021/01 DivOKR、ユニットOKR、個人OKR（期間を変更）

上記のOKRの再設計を行い、OKRを決めました。

組織イメージ
f:id:AdwaysEngineerBlog:20201204164809j:plain

スケジュール
f:id:AdwaysEngineerBlog:20201204164833j:plain

OKR詳細

Div Objective

間接的な事業貢献を継続的に出せる組織にする

Div KR

カテゴリ	KR
ビジネス	仮説実証3件
UX	課題やソリューションの仮説に結論を出した件数が20件
テクノロジー	クラウドアーキテクチャの新規追加や改善8件
チーム	リードタイム20%削減

ユニット名	Objective	主要成果(Key Results)
プロダクト新規価値ユニット1	MVP仮説検証のためのリリースを行い、分析できるような状態になっている	ユニットOに関わる挑戦・改善 7件
		仮説検証ための機能のリリース 1件
		仮説検証の為の要件定義・設計が1件できている
プロダクト効率化ユニット2	xxに関わる本質的な課題を発見し、解決に向けた準備を完了し、開発着手できる状態	仮説検証サイクル9件
		エンジニアのDESIGNタスク参加率20%
		Scala移行率xx％
技術改善ユニット３	システムを再利用しやすい堅牢な状態にする	xx対応率が100%
		xx対応済みのサーバーのコード化率100%
		Datadogの活用事例の検証3件