TMD45'β'LOG!!!

Life is Beta-ful.

『OKR シリコンバレー式で大胆な目標を達成する方法』を読んだ

会社で取り入れられている OKR について、良いと思うことも難しいと思うこともあって悩んでいたので、本書を読んでみた。OKR について実践的な内容でまとまった書籍がやっと出たという感じで、2018/3/15 発売の旬な書籍だ。

うさんくさいサブタイトルとコピーに不安もあったが 結果的に読んで良かったと感じた。個人的にいくつか改善できそうなヒントも得られた。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

感想メモ

なるほど

  • OKR ひとことで

数字にこだわらない人を鼓舞して動かすのがO。数字にこだわる人に対してOの現実味を示してくれるのがKR イントロダクション

従業員がベッドから飛び起きて新しい1日と新しい課題に向かうような目標(Objective)を立てよう。 第2部 OKRのフレームワーク - よくある OKR の失敗例
ゴールを、「パフォーマンスを評価するしくみ」から、「人を鼓舞し、能力を高めるしくみ」に切り替えよう。 第2部 OKRのフレームワーク - OKR と年間レビュー

  • OKR と別に「健康・健全性」の指標を持つ方法

OKR は自分が推し進めたいことであり、フォーカスして向上させたい "ただひとつの" 領域だ。健康・健全性指標は、監視しつづけるべき重要な点だ。 第1部 実業家の物語 - ハンナとジャック、CTO 候補に会う

  • エンジニアの貢献度の数値化のヒント

(抜粋)

  • あいまいさを指摘して、定義を 明確にする
  • 部門を越えて共同で 整合性をとる ようにする
  • KR が 測定可能 だとわかるように、過去の指標を確認する
  • タスクではなく結果 にフォーカスするために、ゴール達成時に想定される結果を調べる
  • 境界条件を問い、方向性 を確認する
  • KR が ポジティブ になるようにする

第2部 OKRのフレームワーク - 会社の目標をサービス部門の OKR と結びつける

  • グーグルの OKR 用社内ツール
    • へー

個人 OKR は必須ではないが、書いている社員の OKR はオンラインの社内名簿からたどることができるようになっている。 解説

  • OKR の対象外とすべき部署?

ある部署を OKR の対象外とするべきではないかと議論になったことがあった。その部署は他部署のサポートを行っており、(中略)。しかし、サポートのやり方は進化させられるし、サポートを受けている部署の目標に貢献することになるので、OKR が設定できるはずだ。そのように働きかけ、OKR を用意してもらった。 解説

わかる

  • "機能別部署ごと" に OKR を設定した場合の懸念点
    • "経営幹部レベルで議論し、優先順位を付け、関連する "プロダクト・チームの" 目標に組み込む"
    • OKR の設定とは関係なく↓こういう状態があると感じるので、プロダクト・チームより上位のレベルで整理してもらいたい気持ちがある

プロダクト・チームのメンバーがどの仕事に時間を割くかで板挟みになり、その結果マネージャーもメンバーも混乱し、フラストレーションが溜まって、残念な結果に終わるということもよくある 第2部 OKRのフレームワーク - プロダクト・チームのOKR

  • ミーティングの雰囲気をコントロールする大切さ、すごく同意する

状況報告ミーティングが多すぎると、チームメンバーはどんなに些細なことでも挙げて、自分の存在を正当化するようになる。日常業務については、各チームの選択を信頼しよう。ミーティングの雰囲気をコントロールして、チームメンバー全員がコミットして共通のゴールを達成するために、互いに助け合うようなムードにしよう。 第2部 OKRのフレームワーク - OKR の実行を習慣にする

  • "OKR のスケジュール"
    • 会社をプロダクト・チームに読みかえても良い

OKR を2週間以内に設定できなければ、優先事項を見直す必要がある。会社が結束するためのゴールを設定する以上に重要な仕事などない。 第2部 OKRのフレームワーク - OKR のスケジュール

OKR を達成できそうかどうかは、四半期が終わる2週間前にわかるはずだ。最後の2週間にシルクハットからウサギを引っ張り出せるなどと考えてはいけない。 第2部 OKRのフレームワーク - OKR のスケジュール

  • 議論の膠着状態の話
    • OKR に限った話ではないですなぁ

どんな人にも自分と最も近いビジネス領域を重視するバイアスがかかっているからだ。(中略)
ほかの機能のほうが価値があると考える人がいる場合、なぜ価値があるのか(仮説)、どれほどの価値を持つ可能性があるか(KR)を単純に話し合えばよい。こうすることで、建設的なコラボレーションが促進される。 第2部 OKRのフレームワーク - MVP のための OKR

  • ウィン・セッションの課題
    • 開発者 ⇔ デザイナーだけでなく、対セールス、対マーケティングチームにも当てはまるように思う

アジャイル開発の現場では、開発者が毎週金曜日にデモをするのが定番の儀式となっていたが、デザイナーは開発者ではないので参加できずに不満そうだった。そこで、全従業員にデモを勧めることにした。これが驚くほどの変化を生んだ。 あとがきと謝辞

概念

  • サンドバック
    • "自分たちがいい気分になるために、本物のストレッチ・ゴールではなく確実に達成できるゴールを設定すること"
    • すべての KR が "達成できてしまった" 場合の懸念
    • OKR の達成を人事評価に用いると、評価を上げるために KR をサンドバック化してしまう懸念が増す(健全なゴールたり得なくなるので人事評価に用いるのは避けたほうがよい)
  • ムーンショット
    • "月に届くほど" 高い目標の揶揄。KR の目標は、達成できるか五分五分でなければならない
    • "目指せば、たとえ月までたどりつけなくても、きっと壮大な眺めを楽しめる"

やりかたの話

  • 設定の仕方
    • "設定ミーティング"
      • 10 人以下での開催を推奨。 2時間セッション+30分休憩+2時間セッション。後半のセッションをキャンセルできるくらい早く終わらせることを目標に 集中して ミーティングを進める
    • 設定ミーティングの準備
      • すべての従業員(プロダクト・チームの OKR ならプロダクトのチームメンバーかな)に目標の案を提出してもらう。部門長などが "最も優れた目標" と "最も多かった目標" をまとめておく
      • 経営幹部チームにはそれぞれ目標を1,2つ考えておいてもらう
    • ミーティング内容
      • 目標のブレスト:準備しておいた目標を付箋に書き出し、壁に貼る
      • 目標のランク付け:議論しながら同じような目標を統合し、上から順に貼ってランク付けする。最後に、3つに絞る
      • 指標のプレスト:目標を計測するための指標をできるだけ多く書き出す
      • 指標のマッピング:アフィニティ・マッピングで付箋を関連付ける
      • 指標のチェック:指標の値が本当にムーンショットになっているか話し合う
      • OKR の最終チェック:四半期の間ずっと、この OKR を生活の一部にできるか?
  • "OKR の実行を習慣にする"
    • 月曜日にチェックイン・ミーティング
      • 自信度の評価ファイブフィンガー を使ってみるのも良さそう
      • 健康・健全性は、いわゆる ヘルスモニター。状態を赤、黄、緑(青)で、直感で判断するもの
      • 一部は毎週末の KPT でやっていることに共通しそう。フォーカスの仕方が違う感じ
    • 金曜日にウィン・セッション(勝者のセッション)
      • "各チームが見せられるものをなんでも見せ合う"
      • 職能またいで実現したいなぁ…こうなったらいいなぁ、という理想(夢に近い…)

今週の優先事項:目標に向けてやるべき特に重要な仕事を3~4つ挙げよう。この優先順位によって OKR が達成できるか話し合おう。
今後4週間:チームに知らせるべき今後の予定。メンバーがそれらの予定に貢献したり、準備ができたりする。
OKR 自信度状況:自信度10分の5を設定したとして、それが上がったか下がったか。またその理由について話し合おう。
健康・健全性指標:すばらしい結果を目指した歩む一方で守りたいことを2つ選ぼう。失ってはいけないものはなんだろうか。(中略)悪化してきたときに把握して、話し合おう。 第2部 OKRのフレームワーク - OKR の実行を習慣にする - 月曜のコミットメント

この表は、とにもかくにも会話のためのツールだ。(中略)

  • この優先順位は OKR の達成につながるか。
  • OKR 達成の自信度が下がっているのはなぜだろうか。手伝える人はいないだろうか。
  • 新しい大きなことに取り組む準備はできているか。マーケティング部門は製品部門の計画を把握しているか。
  • 従業員を追い込んでいないか。あるいは、コードで手抜きが蔓延していないか。

第2部 OKRのフレームワーク - OKR の実行を習慣にする - 月曜のコミットメント

このようなセッションには、いくつものメリットがある。まず、メンバー自身が、特別な勝者のチームに属しているような気分になれる。次に、共有できるものをつくることが、チームにとっての楽しみになる。メンバーが勝利を求めるようになる。そして最後に、会社が各部門の仕事に感謝し、社員が日々何をしているのかを理解するようになる。
第2部 OKRのフレームワーク - OKR の実行を習慣にする - 金曜は勝者のために

  • おすすめの KR 指標(いつもこれが適切とは限らない)
    • 使用率指標
    • 売り上げ指標
    • 満足度指標
  • 週次報告の改善(うちの場合はメールでなく Qiita:Team でのレポート形式)
    1. 冒頭に、チームの OKR と、今四半期に達成できる自信レベルを書く
    2. 今週予定していた優先タスクと、それらが達成されたかどうかを書き出す
    3. 来週の優先事項を並べる。最優先は3つまで、"タスク" レベルにならないようにする
    4. リスクや障害があれば挙げる
    5. メモ(所感や私信。ただし有用な内容)を添える

仕事は雑用のリストではなく、グループ一丸となって共通のゴールに向かうものでなければならない。状況報告メールはこの事実を全員に念押しし、チェックボックス式の思考に陥らないようにするために役立つ。 第2部 OKRのフレームワーク - OKR で毎週の状況報告メールを改善する

  • 1on1 の改善(ワークボード社による例)
    • 目的:メンバーのエンゲージメント、パフォーマンス、方向性の3点の調整
    • これらの3点に5つのレベルを設定し、マネージャーと従業員の両方が見解を共有する

その他 所感

  • 第1部 実業家の物語
    • 賛否両論ありそうだけど、私はわりと感情移入して読んだ。ハンナのイライラも、ジャックの不満もわりとわかる… ただしエリック、てめぇは許さねえ(現実にここまでわかりやすい悪人はなかなかいないけどな)
    • 物語のモブキャラって大して個性が出てこないので、だいたいすんなり話が進むけど(そうじゃないと物語が拡散しちゃうからね)、現実のチームにはモブなんていないのでこんなにすんなり良い方向に向かないし難しいよなぁと思う
    • 結末の "口論さえも、前よりはずっと楽にできる"
      • 互いに同じゴールを目指してることが理解できているのは、こういう面でも大事。口論しないことが重要ではない
  • 確認: 現在の自分の立ち位置
    • 会社>プロダクト・チーム>プロダクトの開発チームメンバー【← ここのリーダー/マネージャー】
    • 直接の関係者は「プロダクト・オーナー」と「開発チームメンバー(複数人)」
      • セールス、マーケティングメンバーとの関係が薄いことに課題感があるが特にアクションはできていない
    • プロダクト・チームで決めた OKR に向かうように開発チームをマネージメントする役目(と思ってはいるものの、開発・運用に手を取られたり、内外から発生するいろいろな "やらなければならない" ことに気を取られて、普段から1つの OKR を意識できているかというとそうでもない状態)
  • いま会社で実施している OKR
    • 会社のミッションから、会社の OKR が設定されている
      • 経営幹部レベルの議論で設定され、丁寧に社内共有された。その後 振り返りが行われていない?(よく見たら 2017 年度上期の情報で止まってる🤔)
      • 日常的に振り返っているかと言われると(私個人は)覚えてもいない状態。公開されている社内ページはすぐ見られるようにはなっている
      • 書籍のセオリーから見ると、Objective に夢が足りない。Key Result の数値化が甘く(どうやって計測するのかよくわからないのがある)Result(結果)ではなく Action(やること)が挙げられている
    • プロダクト・チームごとの OKR が設定されている
      • プロダクトオーナーが設定し、各職能チームが確認・微調整して決定した。ある程度の期間で振り返りも行っているが「お祝い」的な共有は無いので、(とくにメンバーレベルで)いまいち未達成感も達成感も無いように思う
      • 毎週週報には書いているがテンプレ化されているだけでちゃんと意識しているわけではないし、週次の振り返りにも利用していない
      • 週に一度くらいは思い出すが、普段のタスクがそこに向かって発生しているかというと、そうでもない感じ
      • Objective が(プロダクトの)ミッションそのものという感じ。たとえば「この四半期でなにに注力するか」というレベルではないため、指標としづらいかもしれない
      • Key Result の数値化は計測できそうなものになっていて良さそう(売り上げ指標、契約率指標)。しかし開発チームの指標とするものに悩んでいる状態(稼働率を挙げているが、維持の側面が強く、結果的にいまやっているタスクとつながっていない。というかこれは書籍でいうところの「健康・健全性」の指標だと思った)
    • 個人の OKR が設定されている
      • 正直うまく運用できている感じがせず、悩ましい。絶対ではないが人事評価にも影響するような雰囲気になっているのでアンチパターン感がある
      • 導入して浅いので試行錯誤している(目標の修正とかも許容されている)ため、フォーカスできないでいる
      • ↓"当然ながら…"とあるが、ギーク寄りなエンジニアは必ずしもそういうポリシーで仕事してない場合があると思う。そのポリシーを自分は「悪」とは判断したくないし、できれば社会的にも許容されてほしい。そういうエンジニアはプロダクト・チームのメンバーという立ち位置とは別の場所で活きてくるのではなかろうか?

プロダクト・チームの個々の貢献者(エンジニア、デザイナー、プロダクト・マネージャーなど)が、特定のテクノロジーに関する知識を深めるなど個人の成長に関連する目標を多少掲げても、通常は大きな問題にはならない。ただし、当然ながらプロダクト・チームへの貢献が最も重要な仕事なので、この仕事を妨げなければ、という条件がつく。 第2部 OKRのフレームワーク - プロダクト・チームのOKR

出てきたやつ

  • アイゼンハワーマトリックス(重要・緊急性マトリックス
  • デザイン思考のワーク
    • フリーリスティング(ブレインストーミングの手法)
    • アフィニティ・マッピング(内容が似ている付箋紙をグループ化する。重ねたり近くに置いたりする)(そんな名前だったのか)
  • 1on1 面談
    • プロダクト・チームの OKR を指標として、メンバーの状態を把握し、必要であればフォローする(プロダクト別マネージャーとしての役割)
    • 月2回はやることを推奨(いまは必要性とコストの天秤で月1にしているが↑の指標にフォーカスできるようになれば時間も短縮できそうだし月2回で良くなるかもしれない🤔)
  • "腐ったリンゴは…"
  • MVP(Minimum Viable Product、実用最小限の製品)
    • 狩野モデル(Kano Model)の第3、4象限に当たる部分

▲ ページトップへ移動