SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

イベントレポート

プロダクトマネージャーがOKRを正しく運用するために、押さえておきたい7つのポイント

Resily主催「フォード流!OKR実践のリアル」オンラインセミナーレポート

プロダクトマネージャーがOKRを導入運用する際に陥りがちなトラップは?

 最後に行われたQ&Aのコーナーでは、現場での実践でつまずきがちな課題について、参加者からリアルな質問が飛び交った。ここではその一部をご紹介する。

Q サービス開発の場合OKRはフィットすると思われますが、受託開発の場合、目標設定が難しいと思います。設定のヒントはありますか。

ギルバート氏:FordLabsは、フォード社の他の部門からの受託的な役割もあります。あらかじめクライアントと、このプロジェクトに期待すること、このプロジェクトのあとにどう世界が変わっているべきなのかを共有するところから目標設定を始めるとよいでしょう。

 また、OKRをよく知らないクライアントと仕事をするうえでは、なぜOKRのような目標設定が重要なのかから説明し、合意してから始めることも必要です。

Q プロダクトマネージャーがOKRを導入運用する際に陥りがちなトラップはありますか。

レイズ氏:気を付けるべきなのは、顧客にとってのゴールを見失わないことです。ビジネス上の目標達成に執着しすぎるとそれを忘れてしまいがち。ここで重要になるのが、定量的な顧客のデータにアクセスして都度確認する習慣をつけることです。

ギルバート氏:付け加えると、データだけにこだわって数字におぼれてしまうのもよくありません。ECサイトを例に出すと、PVだけ追っても成果は出ず、コンバージョンなどもしっかり見ないといけません。さまざまな情報を関連付けて確認していくことが重要。また、OKRを正しく設定できれば、「顧客にとっての成功は何か」と「事業の成功」を結び付けることができます。

Q ユーザーからのフィードバックなどから、OKRに設定していなかったイシューが生まれた際、それがOKRに当てはまらないために(評価につながらないために)優先度が低くなり、顧客体験の改善が進まないといった課題は、どう乗り越えるべきでしょうか。

レイズ氏:これは、発生頻度の高い問題なので真剣に検討する必要があります。大きく2つの対処があると思います。

 一つは、多くの顧客から同じフィードバックをもらっている場合、プロダクト改善を早急にする必要があるので、OKRを見直す必要があります。一方、一部の顧客だけからの指摘の場合、A/Bテストなどで検証を行ったうえで判断します。プロダクトへの影響がそれほど大きくないと判断できた場合、バックログとして、将来対処すべき課題としてストックしておき、別のユーザーからのフィードバックが来た際に組み合わせてプロダクト改善を検討するといった対応になるでしょう。

ギルバート氏:新しいプロダクトは、仮説だらけになるはずです。なので仮説のリストを用意し、検証する時間が必要です。仮説を検証できたかどうかをOKRに組み込んでおけば、OKRに存在しないイシューは発生しづらくなります。顧客の声を反映させる余白を用意しておくことが重要です。

Q 組織を持つ部下のOKRを設定する際に、その部下のOKRは個人のもの(上位組織のメンバーとしてのもの)とその組織のものの2つを別々に設定すべきでしょうか。イメージとしては、ある部署の下に幾つかのグループがある時のグループマネージャー(ファーストラインマネージャー)の目標設定のあり方について教えていただきたいです。

レイズ氏:とてもいい質問です。明確な解はないので個人的見解にはなりますが、基本的には組み合わせになると思います。このケースでは2つのOKRを設定すべきではないでしょうか。

 組織全体のOKRを個人に落とし込んだ時に矛盾しないように設計するのが重要です。組織が成長するためのOKRと個人を成長させるOKRを組み合わせて、その人のいるレベルに合わせてOKRを設定するのが大事です。自分の目標が組織全体のOKRにどうつながるのかなど、OKRを通じて組織の中における自分の立ち位置を把握できる状態が重要だと思います。

Q 人事評価とOKR設定の連動はどう考えればよいでしょうか。

ギルバート氏:フォード社においても、人事面談の際にそういったトピックは頻繁に出てきます。プロダクトマネージャーとして評価される際は、プロダクトの成長とOKRの状況をまとめて話されます。気を付けたいのは、Key ResultsではなくObjectiveの部分をしっかりと強調すべきということ。例えば、セミナーを四半期のうちに3回やるというKey Resultを立てていた中、2回しかできなかったとします。Key Resultは達成できてなかったとしても、顧客から抜群の評価を得ていたなど、しっかりObjectiveの達成につながっていればきちんと評価を得られる仕組みを作るのが重要です。

 OKRを評価基準に結び付ける時に出てくる課題の一つが、達成しやすいKey Resultを立てる人が出てくることですが、Objectiveを評価する仕組みにしてコミュニケーションをしっかりとって理解してもらえれば、うまく機能していくのではないでしょうか。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
イベントレポート連載記事一覧

もっと読む

この記事の著者

岡田 果子(編集部)(オカダ カコ)

2017年7月よりCodeZine編集部所属。慶応義塾大学文学部英米文学専攻卒。前職は書籍編集で、趣味・実用書を中心にスポーツや医療関連の書籍を多く担当した。JavaScript勉強中。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/13906 2021/04/16 11:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー