0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AI Driven な時代だからこそ改めて目標設定と評価をどう設計して組織を動かしていくべきかを整理した

0
Posted at

これなに

自分はどちらかというと技術でゴリゴリ押していくというよりは、プロダクト作りや組織の仕組みづくりからアプローチするような、いわゆる SE あがりなやり方で貢献することが多かったです。

とはいっても結構肌感でやっていてかなりアドホックな面が多いので、いったん自分の振り返りも兼ねて今後どうやっていくのがいいのかな?というテーマで言語化を試みました。

なお、大学入学共通テストの国語で100点を下回るレベルの国語力なので、実際に記事を書くにあたっては Claude を使って言語化しています🫠(ほとんどは自分で書いているのですが、言い回しとかは Claude にレビューしてもらった感じ)

本記事のテーマ

本記事で自分が達成したいテーマは以下の通り。

  • 数字だけを追うのではなく、チームが活性化し自律的に成長する組織にすること
  • 仕組みは複雑にせず、シンプルで運用コストに見合うものにすること

背景には、AI でアウトプット(作成物)は増えても、アウトカム(ユーザーや事業への価値)は自動では増えないという問題意識があります。作る量で貢献を測れなくなった今だからこそ、チームが何を目指し、何を評価するのかを設計し直す必要があると考えています。

なお、組織・事業・会社の状況によって最適解は変わるので、これは1つの考え方であり、状況に合わせて調整する前提で考えています。

課題感

これまでよく出会った課題としては以下のようなものが多くありました。

  • チーム目標は組織内に公開する一方で、個人目標は非公開で、マネージャーレイヤー以上でないと見えない。
  • チーム目標は組織やビジネスの状況によって変わりやすい。チーム目標を個人目標に結びつけていると、チーム目標が変わるたびに個人目標がずれたり置き去りになったりして、評価の時点では見当違いの目標になってしまう。
  • そもそもチーム目標と個人目標を結びつける作業そのものに、本来事業に割くべき時間をかなり取られている。

これらを解消するため、これからどういうことを意識していくべきかを以降のセクションで書いていきます。

まずは今たどり着いている結論だけ

以降のセクションでとっ散らかった話を書いていますが、まずは今時点自分が考えているポイントというか結論だけ。

  1. OKR は古い手法ではあるものの、今でもだいぶ有効なので使える
  2. 報酬に関わる評価軸はできるだけシンプル化して事業に集中できる環境を作った方が良い
  3. 目標設定と評価は「チームOKR」「個人の成長計画」「等級ごとの評価」「コミット型の目標」の4つに分け、それぞれ何のための仕組みかを明示して運用していくことが肝要

それではまずは課題の紐解きから始めていきます。

課題感の根っこはOKRとMBO/KPIの考え方が混ざってしまっていること

いろいろ調べた結果、自分が抱えている課題感はOKRとMBO/KPIが混ざり合ってしまう事象によるものがほとんどだと個人的にはいったん結論づけました。
言い換えると「目標」と「評価・報酬」が混ざっていると言っても良いかと思います。

※ OKRとMBOに関してはカオナビさんが公開しているOKRに関するページがわかりやすかったです。
要約すると、OKRとMBOの違いは「レビュー頻度・達成基準・共有範囲・報酬との連動有無」であり、「OKRは報酬と切り離して挑戦的な目標を全社で共有する」ことに特徴があるものとのこと。

Diff between OKR and MBO

引用元:カオナビ > OKRとは? 【Googleが使う目標管理ツール】KPI・MBOとの違い

課題の具体例

やや抽象化しているので若干わかりづらい部分もあるかと思いますが、自分の経験から抽出した具体例は以下の通り。

# 事象 具体例と発生する課題
1 MBOは「達成して終わり」になり、報酬とも結びつきやすいので、メンバーもマネージャーも個人の目標に閉じてしまう 個人目標を100%達成すること自体が目的化する
2 スキル研鑽が必要なチーム目標は、どうしてもMBOのような個人目標になる チームは「ドキュメントの英語化」を掲げても、英語に自信がない人はB1・B2の取得から始まる
3 AIの活用も、まず「活用とは何か」を理解するところから始まりがち チームとしての成果より先に、個人の学習が必要になる
4 AIで開発スピードが上がり、目標の難易度や評価の基準を決めにくくなっている 出せるアウトプットの量が増え、量が貢献の指標にならない
5 現場の課題を起点にした目標だけでは、組織が成長しにくい気がする 「保守の属人化を解消する」は大事だが、それだけでは伸びしろが見えにくい
6 仕組みが複雑になると、運用コストに見合わない 目標設定、レビュー、評価、1on1が増えすぎる

実際に自分がやりがちだったアプローチ

これまで自分がやってきたアプローチの王道パターンは、プロダクトがやるべきことをゴールにし、チームの目標に落とし込む形でした。例えば次の2つ。

  • 保守が一部のメンバーに集中していたので、経験者と未経験者をペアにして週替わりで保守を担当させた。主担当は未経験者、レビューは経験者にした
  • 法改正があるときは、その対応を目標にし、チームとメンバーの目標に落とし込んだ

施策そのものの方向性は妥当だったと思いますが、それを毎回メンバー個人の目標にまで落とし込んで調整する作業にはかなりの労力がかかり、実際かなり時間を無駄にしていたと思います。
さらに、マーケット状況や業界動向、技術革新、トップダウンでの方向転換などは日常茶飯事なので、そのたびに個人の目標を調整し直すのは、マネージャーにとってもメンバーにとっても無駄が多かったなと振り返って思います。

ではどうするべきか?

「目標」と「評価・報酬」は切り分けることが肝要

外部の文献、ネット記事などを調べてみると、どの情報源も「OKRは評価ではない」「評価は行動の基準で、キャリブレーションでそろえる」「1on1は評価と分ける」という点でおおよそ一致していました。特に興味深かったのは Google の現状は、育成志向から成果の差を報酬に反映する方向へ動いているという点でした。

情報源 概要 自分が得られた示唆
Google re:Work:OKRのガイド Objectiveは3〜5個、KRは各3個程度。KRは活動ではなく成果で書く。達成率60〜70%が理想。OKRは人事評価ではなく、ToDoリストでもない KRに「勉強する」「資格を取る」を入れない。OKRのスコアを評価に持ち込まない
Google GRAD(2022年の報道:HR Katha、Bernard Marr) 評価は年1回、昇進は年2回。チェックインは通年で、1回はキャリアがテーマ。評価軸は5段階の「インパクト」 評価の頻度と昇格の頻度は分けられる。キャリアの話は専用の場を持つ
GRADのその後(2022〜2026年の報道:Entrepreneur、HR Katha、Storyboard18) 社内資料をもとにした報道によれば、低評価の目安が2%から6%に。2025年に上位層の報酬を厚くし、予算総額は据え置き。2026年には一部の職種でAIの活用度を評価に入れ始めたと報じられている 「インパクト」評価は成果主義に寄りやすい。AIの利用回数を評価に入れると数字稼ぎを生む
カオナビ:OKRとは? Objectiveは定性的で1〜3か月で達成できるもの。KRは自信度5/10の難しさに。週1回のチェックインで進捗・自信度・阻害要因・次の一手を確認。OKRと報酬は切り離し、評価は達成度だけでなく難易度も見る 週次チェックインの型と自信度の目安はそのまま使える
カオナビ:1on1ガイド 1on1は部下のための時間で、評価はしない。上司は8割以上聞く。キャンセルせず必ずリスケする 1on1と評価面談を混ぜない
PMP:評価尺度ガイド 尺度は目的・職種・文化に合わせて選ぶ。BARS(行動アンカー型)は主観を減らせるが作るのに手間がかかる。キャリブレーションで基準をそろえる 等級ごとの行動基準はBARSに近い。項目は絞る
PMP:グラフィック評価尺度 各レベルの意味を具体的に定義しないと評価者でぶれる。項目は4〜7個。スコアは対話のきっかけで、結論ではない 定義の具体化に一番時間をかける
PMP:評価面談の進め方 評価は役割の期待値と比べる。評価面談で初めて聞く指摘があってはいけない。評価コメントは具体例と影響で書く 普段からフィードバックし、評価時に驚きをなくす

課題ごとのアプローチ

先ほど具体例として挙げた6つの課題は、目標・成長・評価という「層」を分けることで解けるということで、自分の中で腹落ちしました。

課題 外部の見解 自分が取るべきアプローチ
1. MBOは個人に閉じる re:Work・カオナビとも、OKRは評価や報酬から切り離すべきとしている OKRはチーム単位で設定し、評価には使わない。個人OKRは作らない
2. スキル研鑽が個人目標になる re:Workは、KRは活動ではなく成果で書くとしている スキル習得はOKRではなく「成長計画」という別の層で扱う。チームOKRは成果(例:主要ドキュメントの英語化率)、個人は成長計画(例:B1→B2)にする
3. AIは「活用とは?」から始まる Googleは職種ごとにAIの活用を評価に入れ始めているが、利用回数の指標は数字稼ぎを生みやすい 学習は成長計画で支援し、チームとしての成果はOKRで追う。評価には利用回数ではなく「ツールでチームの生産性を高めている」という行動として書く
4. AIで評価基準が難しい どの情報源も、評価は役割の期待値と行動で行うことを勧めている アウトプットの量では評価しない。等級ごとの行動とインパクトの基準で評価する。AIの時代にはこのほうが長持ちする
5. 課題起点では成長しにくい カオナビ・re:Workは、KRを自信度5/10の難しさに設定すれば挑戦になるとしている 問題は起点ではなく目標の高さ。課題起点でもKRを高めに設定する。法改正のような必達の目標は「コミット型」として別枠にする
6. 仕組みが複雑になる Googleは年2回の評価をやめて年1回にした。re:WorkはOKRがToDoリストになることを警告している 個人OKRをやめる。チェックインはスプリントレビューに相乗りさせる。年次はOKRではなく重点テーマ3つ程度にする

なお、先に挙げた保守ローテーションの例は、施策としては良いOKRの素材になると考えています。振り返ると当時も定量的な指標は入れていましたが、例として次のように書けばしっかりOKRとして成り立つと思います。

  • O: 誰でも保守ができるチームになる
  • KR1: 単独で保守対応できるメンバーを2人から6人にする
  • KR2: 経験の浅いメンバーが主担当のときのエスカレーション率をxx%以下にする

一方、もう1つの例の法改正対応は、期限までに100%やり切ることが前提なので、達成率60〜70%を成功とするOKRには向きません。後述する「コミット型の目標」として別枠で扱うのが適切だと考えています。

冒頭の課題感への答え

ここまでの整理を踏まえると、冒頭で挙げた3つの課題感には次のように答えられると考えています。

冒頭の課題感 この記事での答え
個人目標が非公開で、マネージャー以上にしか見えない チームOKRは組織内に公開し、個人OKRは作らない。成長計画は弱みを開示する場なので、本人とマネージャーだけで扱ってよい
チーム目標が変わるたびに個人目標がずれる 個人の目標をチーム目標に結びつけない。成長計画は「能力」が対象なので、チーム目標が変わっても古くならない
目標を結びつける作業に時間を取られる 個人への落とし込み作業そのものをなくし、進捗の確認は既存のスクラムのイベントに相乗りさせる

特に1つ目は、個人目標が非公開であること自体が問題なのではなく、チームの目標が非公開の個人目標に分解されてしまっていることが問題だったのだと思います。

目標設定と評価の設計方針

4つの仕組み

上記を踏まえると、目標・必達・成長・評価を別々の仕組みにし、チームOKRのスコアは評価に直接は渡さない形が良いと考えました。

Design of OKR and evaluating

チームOKRとコミット型目標は事業のテーマから下ろし、成長計画と評価は1on1でつないでいきます。

仕組み 目的 単位 頻度 評価との関係 主な場
チームOKR 方向をそろえ、挑戦する チーム 四半期 使わない (過程の行動は評価する) 四半期の計画、スプリントレビュー
コミット型目標 法改正などの必達事項をやり切る チーム 期限まで 達成は前提。やり切る過程の行動を評価する 通常の計画
成長計画 役割に必要な能力を伸ばす 個人 半期〜年 行動基準と昇格要件を通じて間接的に反映 1on1
等級ごとの評価 報酬と昇格を決める 個人 年1回または半期 直結 評価、キャリブレーション

評価については、次のルールを明文化することが良いのでは?と考えました。

  • 評価するのは、OKRに向かう過程の行動の質と挑戦の難しさ。KRの達成率ではない
  • OKRのスコアは評価資料に転記しない
  • 評価は5段階で、中央は「期待どおり」とし、十分に良い評価として扱う (Google の Significant Impact と同じ考え方)
  • 等級ごと(メンバー、リーダー、マネージャーなど)に基準を4〜5項目に絞り、各レベルに具体的な行動の例を書く
  • 評価分布の強制はしない。キャリブレーションで基準をそろえる

成長計画は評価・報酬にどう効くのか

成長計画の達成度は、報酬の計算に直接は入れません。資格の取得などが目的化して目標が低くなったり、評価を気にして弱みを話せなくなったりするためです。一方で、完全に切り離すと業務に押されて後回しになり、「成長しても報われない」と感じさせてしまいます。

そこで、次の3つの経路で評価につなげます。

経路 何を見るか 英語化の例
1. 行動基準 自分で計画を立てて実行しているか(プロセス) 必要な英語力を把握して、学習を続けている
2. 通常の評価項目 成長が仕事にどう表れたか(結果) 英語で設計レビューができ、関われる範囲が広がった
3. 昇格要件 次の等級に必要な能力があるか リーダー等級の要件に「英語で設計ドキュメントを書ける」を入れる

ポイントは、昇給や賞与の計算(報酬)には入れず、等級の扉(昇格)には入れることです。昇格すれば結果として報酬も上がるので、成長が報われる道筋ははっきりします。
なお、受講費の補助や業務時間内の学習時間といった学習支援は、評価とは関係なく会社の制度として別枠で用意すれば十分と考えています。また、組織として英語を必須にするのであれば、それは成長計画ではなく役割要件の変更なので、等級の定義を書き換え、移行期間を設けて周知してから評価に入れるのが公平だと思います。

運用サイクル

新しい会議はできるだけ作らず、スクラムの既存イベントに相乗りさせて運用コストを抑えるようにした方が良いと思うので、以下のように設計したいと考えています。

サイクル やること 相乗りする場
年1回または半期 事業の重点テーマを3つ程度決める。本格的なOKRにはしない 事業計画の策定
四半期 チームOKRを設定し、前の四半期を振り返る 四半期の計画・振り返り
四半期の中間 進捗が遅れているKRへの対策、必要なら目標の修正 1回だけのレビュー。月次の別会議は作らない
スプリントごと KRの進捗と自信度を5分で確認する スプリントレビュー
隔週〜月1回 1on1。3回に1回はキャリア専用の回にする 既存の1on1
年1回(または半期) 評価とキャリブレーション 評価期間
半期 昇格の判断 評価とは別に実施

評価の頻度は、コストとモチベーションの交換条件で決める。

  • 評価は年1回、昇格判断は半期ごと: Google の GRAD と同じ形。キャリブレーションのコストが半分で済む。
  • 評価を半期ごと:昇給の機会が増えるが、記入フォームをかなり軽くする必要がある。
  • 昇給の原資が年1回しかない会社で評価だけ年2回にすると、「評価されたのに何も変わらない」という逆効果になるので、報酬制度と合わせて決めるのが良い。

自分としては、昇給の機会が多いほうがメンバーやマネージャーのモチベーションにつながると考えているので、報酬制度が許すなら評価は半期ごとにし、記入フォームを軽くする方向で考えています。報酬制度上それが難しい場合は、評価は年1回、昇格判断は半期ごとという形にするのが現実的だと思います。

リーダーやマネージャーなどの行動指針

リーダーやマネージャーの究極の責務は、事業の成長と売上・利益への貢献です。OKRと1on1はそのために組織を活性化する手段と位置づけ、以下を行動指針としておくのが良いと考えました。

  1. 事業への貢献を起点にする: チームの目標は、最終的に事業の成長にどうつながるかを説明できるものにする
  2. 数字は一番上に置き、チームのObjectiveは定性的にする: 会社のKRには売上や利益の数字を置く。チームのObjectiveは、メンバーが自分ごとにできる定性的な言葉にする。数字を完全に隠すと、事業とのつながりが見えなくなる
  3. チームで挑戦する文化を作る: OKRはチーム単位で追い、達成率60〜70%を成功とする。低いスコアは責めずに次の目標設定に活かす
  4. 1on1では成長と貢献の証拠を残す: 目的は「評価の時点で、成長と貢献が見える状態にしておくこと」。キャリブレーションで良い評価を取らせるための場にはしない。部下の弁護人になると評価が公平でなくなる
  5. キャリアの話は専用の回で行う: 次の役割、より広い役割に向けた志向を聞き、行動の変化を支援する。毎回の1on1を評価面談のように重くしない
  6. フィードバックは普段から行う: 評価の時点で初めて聞く指摘をなくす
  7. 何のための仕組みかを繰り返し伝える: チーム、メンバー、マネージャーが何を重視すべきかを迷わないようにする

よくある落とし穴と予防策

最も起きやすいのは、OKRを評価から切り離したつもりでも、実際の運用で達成率が評価に流れ込んでしまうことです。実際自分も何度も経験したなと振り返ると思います。
パッと書けるだけ書くと以下のような例があると考えています。

落とし穴 兆候 予防策
OKRの達成率が評価に流れ込む KRが保守的になる。毎回100%近く達成している 評価では「OKRに向かう過程の行動の質と挑戦の難しさ」を見ると明文化する。OKRのスコアを評価資料に転記しない
OKRがToDoリストになる KRに「調査する」「勉強する」などの活動が並ぶ KRは成果で書く。活動はスプリントのバックログに置く
ストレッチ型と必達の目標が混ざる 法改正対応が「70%で成功」扱いになる 必達の目標は「コミット型」として別枠にし、100%達成を前提にする
成長計画が後回しになる 学習が業務に押されて進まない 評価の行動基準に「役割に必要なスキルを自分で計画して身につけている」を入れて間接的につなぐ
評価が成果主義に寄りすぎる 中間層のモチベーションが下がる。チーム貢献が軽視される Googleの事例を参考にしつつ、評価分布の強制は避ける。チームへの貢献を行動基準に含める
AIの利用度が数字稼ぎになる 利用回数だけが増え、成果は変わらない 利用回数は評価しない。「ツールでチームの生産性を高めている」という行動として評価する
1on1が評価面談になる 部下が本音を話さない 1on1では評価の話をしない。キャリアの話は専用の回にする
仕組みが形骸化する チェックインやレビューが飛ばされる 新しい会議を作らず既存の場に相乗りさせる。キャンセルではなくリスケする

導入ステップと調整ポイント

どの組織でも同じだと思いますが、一気にやるとハレーションの原因になります。
一度に全部を入れず、まず1チームなどの小さい単位で1四半期試して実績を積んでから広げるのが良いと思います(カオナビやPMPが勧めるパイロット運用と同じ考え方)。

  • 既存の評価制度、報酬の改定時期、等級の定義を確認する
  • 4つの仕組みが何のためにあるかを1ページにまとめ、マネージャーと合意する
  • 等級ごとの行動・インパクトの基準を、各等級4〜5項目に絞って書く
  • 1チームで四半期のチームOKRを試す。チェックインはスプリントレビューに入れる
  • 四半期の終わりに、OKRの高さ、チェックインの負担、評価との切り離しを振り返る
  • 振り返りをもとに調整し、他のチームに広げる
  • 最初の評価サイクルの前に、マネージャー同士で架空の事例を使った練習とキャリブレーションを行う

状況に応じて調整するポイントは次のとおり。

  • 組織の規模: 1〜2チームなら、事業部のOKRとチームのOKRを1つにまとめてよい
  • 事業の段階: 立ち上げ期は目標が頻繁に変わるので、OKRを1か月単位にしてもよい
  • 既存の評価制度: 会社の評価制度が決まっている場合は、行動基準の書き方とキャリブレーションの運用から入る
  • 報酬制度: 評価の頻度は昇給の原資の頻度と合わせる

さいごに

冒頭でも触れましたが、こちらの AI and Scrum (Expansion of the SGEP) でも紹介されているように、AI でアウトプット(作成物)は増えたけど、アウトカム(ユーザー価値)は自動で増えないというのはまさにその通りで、AI Driven 時代においてはアウトカムを増やしていくことが肝要だと思います。

実際に自分も作ることよりも、どのような価値を生むべきか、どのようにして利益を生み出していくかといったことに頭のリソースを割くようになったと感じています。
そしてその価値を生み出すには個人ではなくやはり組織設計をしっかり取り組むことで圧倒的なパワーとスピードを出せるのではと考えています。

なお、この記事で書いた内容はあくまで個人の意見であり、しっかり検証したものではないのでご了承ください。
こんな最後に書いたら誰も読まない気もするのですが、もしよかったら気になった点などあればコメントやフィードバックをいただけたら幸いです。

参考資料

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?