「キーワードから読み解くエンジニア組織とOKR」セミナーレポート(前編)BLOG

 2022.4.15

2021年7月27日(火)「キーワードから読み解くエンジニア組織とOKR」と題し、Tably株式会社代表の及川卓也氏をお招きし、OKRとプロダクト開発の関係性やスクラム開発、技術的負債、開発組織の目標設定、エンジニア評価等についてパネルディスカッションを行いました。

前編では、及川氏の講演内容『プロダクト組織とOKR』とパネルディスカッションについてご紹介いたします。

後編はこちら

目次

及川 卓也氏登壇セッション

OKRはエンパワーメントの手段である

及川氏

まずOKRはエンパワーメントの手段であるという書き方をしています。ちょうどこのエンパワーメントに関係する書籍として「EMPOWERED(エンパワード)」を紹介します。

この書籍は、プロダクトマネジメントを担っている方なら知ってる人も多いと思いますが、マーティ・ケーガンが書いた本です。これは共著なのでもう1人クリス・ジョーンズも書いてるのですが、この2人はSVPG(シリコンバレープロダクトグループ)コミュニティを率いている人で、マーティ・ケーガン自身はHPやeBayとかでプロダクトの責任者を務めた人です。プロダクトマネジメント、もしくはプロダクトリーダーシップでは米国を中心に多くの方に影響を与えてます。

書籍の中では刺激的なことが書いてあるのですが、機能開発チームを採用しているのであれば「OKRは文化的なミスマッチであり、ほとんどの場合は時間と労力の無駄に終わる」と。これに限らず、日本人で一生懸命アジャイルとかを社内に導入している人にとっては、胸を刺される言葉が多く、結構本質的なことを書いています。
ここで言っている機能開発チームは何かというのを*印で、書籍の中から引用しましたが「機能やプロジェクトの実施実装に終始していて、結果に責任を負っていないことがある」と。

誰かが作ったロードマップと、そこから適宜開発するのが必要だというところを持ってきてはそれをこなしているだけであると。形だけユーザビリティテスト・ユーザーのインタビューをやって、一通りの工程はしっかりと進めてはいるけれども、本来そのプロダクトが何のためにあるかというようなことを期待されているのではなく、課題と解決策は既に出ていて、あとはそれを形づくるように、というふうにだけ言われてしまっているという。

つまり、本来ならば重要なユーザー自身の理解であったりユーザー課題の発見であったり、そのユーザー課題に対して最適な解決策は何かということを見つけ出すところを、そこを期待されていないという組織であると。

胸に手を当ててみると、俺の組織だと思われる方も多いのではないかなと思います。事業会社の中で、ソフトウェア開発をやるようになっていたとしても、ちょっと揶揄した言い方をすると社内SIerのような形になっていて、結局考える人・作る人がかなり明確に分断されてしまっている。こういった組織を機能開発チームという言い方をして、そもそもそういう存在を作ってしまってるのが問題だということを問題提起しているんです。

残念ながらそういった方々もしっかりとモノは作り出している。なんだかんだ言いながら社内でモノづくりをやれるようになったことで成果を上げつつあり、Googleも使っているからとOKRを導入している。

それが結局、形だけの状態になってることが多いのではないかと。そもそもOKRを入れたとしてもMBOの焼き直しで、トップダウンでカンパニーOKRから部門に落ちてきてどんどん細分化し、最後は個人をやるかどうかは会社や方針によって違うと思うんです。OKRが個人まで落ちてくる形になると、トップダウンのアプローチに近いように見えて、実はMBOの焼き直しに見えてしまうんですね。

そんなことは駄目ですと。大事なのはやっぱり「エンパワーされている」ということなんです。目標管理や目標設定は大事ですが、結局はエンパワーですね。自らがそれに対して動機づけされ、しっかりと考え、解決策をユーザーに届けて価値を生み出そうとすること自身がエンパワーであると。

ですからOKRを活用するためには、ここにある3つが大事です。

1つは、今言った機能開発チームではなく、プロダクトチームと言われているように、チーム全員が「誰がプロダクトの何の課題を解決するのか」をしっかりと意識して進めていく、というものになっていなくてはならない。

2つ目が、マネージャーが書く目標と個人が設定する目標が、そもそもプロダクトチームのものと違う形になってしまってることが多いのです。そうするとダブルスタンダード、トリプルスタンダード状態になります。そうではなく、あくまでもプロダクトチームが作り上げようとしている価値に対して、いかに目標として設定していくかを考えることに徹するべきだと。

最後3つ目はリーダー自身がしっかりとそれを意識した上で、推進するための行動を起こしていかなければならない。ですから、OKRの活用というところの大前提としては、しっかりとチーム全体が事業としても価値を上げ、ユーザーにも価値を届けるといったところを理解して邁進していかなければければいけません。

プロダクトチームのOKR

プロジェクトチームのOKRはすごく難しい。典型的な質問がここにあるもので、機能別部署、たとえばエンジニアリング組織が職の機能ごとにある程度、細分化されていたとします。

モバイルアプリのチームやバックエンド。最近ですとデータ分析、機械学習のチームなどに別れていたりする。それぞれのチーム目標があった上で、プロダクトチームはプロダクトチームでそこの横口となるような形で、価値をしっかりと考えていくもの。その2つ、がダブルスタンダードであったり、もしくは板挟みになるようなことはないかと。

それに関しての会議が下にあるものです。これは日経BPの、私が解説を書いている本の中から出したものです。この本自身は『クリスティーナ・ウォドキー』という方が書かれたもので、ここの文章は1枚目のスライドと同じく、マーティ・ケーガンがコメントしています。

彼は極めて一貫して同じことを言っており、ここでの回答アドバイスは何かというと、OKRを企業に導入する場合、プロダクトチームレベルのフォーカスだけをすればいいと言っています。つまり、上で言っているダブルスタンダード状態を排除し、基本はプロダクトチームのOKRに一本化して、たとえば先ほども言ったモバイルアプリケーションであったり、もしくはデータ分析っていうチームがあったとしても、そのチーム自身の目標が全てプロダクトに寄与する所に含めるような形で考えていけばいいのではないか、ということを彼自身は言っています。

一方、ここには捉えられなかったですが、組織としての成長を考えていく部分は、プロダクトの話とは別になるので、エンジニアリングマネージャーなどが組織管理としてどうするか。といった目標を別に設けるのは良いですが、プロダクトでそれぞれの個人が板挟みになるような状態を避けるためには、基本はOKRをプロダクトチームの目標管理に一本化してしまえばいいという考え方を、舵を取るような形で彼はアドバイスしています。

私とOKR

私はGoogleに入ったのが15年ぐらい前ですが、そこがOKRとの出会いでした。プロダクトマネージャーとしていろんなOKRを立てていましたが、OKRに一番力を感じたのは、2008年に出したブラウザ、Chromeのところです。

私の古巣の一つでもあるMicrosoftが当時、InternerExploler(IE)に注力していなかった結果、最大のシェアを持ったブラウザであるIEがイノベーションを止めてしまったことで進化が止まった状態を、Chromeがもう1度ウェブの再定義をする形で置き直し、ウェブの大事な要素であるフロントエンドの部分に進化を起こそうとしました。

ブラウザは色々な見方があり、インターネット閲覧ソフトという静的な情報を見るだけになってしまっている。ですがそうではなく、もう2005、6年から起きていましたが、巨大なクラウドアプリケーションの大事なフロントエンド、ユーザーとのインタラクションを持つ接点を定義し直したならば、ブラウザという言葉を使うのが正解なのかと。つまりここに書いてあるみたいに、ObjectiveとしてはWebアプリケーション、クラウドアプリケーションの中のプラットフォームという風に考えるべきなんです。

たとえば2008年のChromeのOKRで、こういった状態で開発すると言ったなら、開発されたものがしっかりと開発者に届いている状態はどこまでかというのはSeven Day Active、1週間のweekly active userを2000万人にするところまで行けたなら、プラットホームとしてまず最初のキックスタートがかけられたと。ロケットスタートできてる状態だということをイメージして、まずは我々が考えているものが成功しているかどうかを図ろう、と考えていたやり方です。

ですからこの後Chromeはどんどん進化していくと。そのうちユーザー数が十分に取れて、デスクトップからモバイルへの移行が始まっている。じゃあモバイルユーザーにしっかり使われることを考えたときには、モバイルユーザーのアクティブユーザー数を同じくらいにすると。それをどんどん細分化していくと、私が言った東京のチームは、その中でもブラウザのパフォーマンスやメモリ消費というところを、しっかり努力していくと。

つまり、デスクトップと違ってアンドロイドなどは特に新興国とかだと、メモリもすごく少ないので、Chromeを十分に走らせるために、メモリ使用量を減らさなきゃいけないことが見えているので、実現するOKRをそこに落としていると。なので大きなビジョンとそれを達成できたときにどんなことが起きるか、というKey Resultを考えて組織・プロジェクトで細分化し、階層組織に応じてネットワーク的に、それぞれのOKRを実現していくことを皆が目指すというのを、自分自身体験したことがあります。

なので、今の仕事でも多くの支援先にOKRの導入を進めている形になります。

以上、簡単ですが3つについて私から伝えさせていただきました。

パネルディスカッション

Resily 西川
本日パネルのテーマ、今回ご参加いただいた皆様からの投票の上位、4つをご用意いたしました。

パネルディスカッションテーマ①

エンジニアに対する評価は何を指標にする?OKRとの兼ね合いは?

及川氏:
エンジニアの部分を除いて人事評価で、まず一般的にお話します。 

よく言われていますが、人事評価とOKRというのは完全に非依存な形にし、OKRを人事評価には使わないというところが鉄則になります。ただ、こればかりがひとり歩きしているなと思うこともあります。というのは、チームメンバーがしっかりOKRを同じ方向に進む。たとえば四半期なら四半期、半年なら半年、1年なら1年で、OKRに沿った仕事をしている人に対する人事評価でOKRを全然見ないというのは、それはそれで不自然です。 

OKRはご存知の通り四半期の最後にスコアリンググレードを付けます。1.0を最高値にしたら、0.1から0.9、1.0までつけるわけですが、そのスコアをそのまま評価に使ってしまってはいけないので、OKRのグレードもしくはスコアを人事評価に直結するのは、やってはいけないアンチパターンと考えられます。 

OKRに対してあなたはどのぐらい貢献しましたか?これを定量的な数値ではなく定性的な中身を見て、その人がOKRすなわち事業・プロダクトの開発に対して、貢献したかを見ていく作業をするべきであると。 

では何を指標にするのか。OKRとは別に、普通に人事評価の仕組みを作りましょう。それは職種ごと、たとえばエンジニアならば、人事評価って2つあると思うんです。 

1つは能力評価・コンピテンシーの部分であり、もう1つはパフォーマンス、実際にその能力を使ってどういうような貢献をしたか、になるわけです。その両方を見る必要があり、たとえばコンピテンシーである能力は、エンジニアならば多くの場合は技術力が半分以上入ってきますし、それ以外に、技術者としてのソフトスキルの面も能力になりますから、その能力を見ていくと。その能力を使って実際にどのような開発を行って、さらには事業に貢献を出したかが、業績や成績のパフォーマー部分になり、これも会社ごとにしっかりとした評価の仕組みを作って測っていく、というやり方をとるといいのかなと思います。

Resily 西川: 
定性・定量だとか能力・成果という形で、職種ごとに丁寧に設計するところに尽きるのかな。 

Resily 西方
弊社の場合ですとOKRをたてるときには、その事業にどれだけインパクトを残したかは最優先に考えるべきかと。一方で、エンジニアという職種に対したときに、技術力の部分をどうやって評価に絡めていくかがあり、そこに関しては、会社によって色々あるかとは思いますが、基本的にはその技術力を使ってどれだけ事業に貢献できたかということがあります。そして、もう1つ。

こちらのスライドはサンプルのOKRですが、具体的には、このプロダクトのOKRは2層目のOKRをイメージしています。

技術力を使ってどう事業に貢献したかについては、右側のOKRでお話しますが、基本的には、事業の目標に対して意義をどれだけ伝えられるかがすごく重要になってくると思っていて、意義に対してどれだけ、あなたはパフォーマンスを出せましたか? が、重要なポイントです。 

具体的に左側のOKRに関しては、プロダクトの成長を促すためのOKRをイメージしてます。このプロダクトにユーザーがどういう課題を持っていて、それに対してどうアプローチをしていきますかというOKRになっています。 

右側はもう少し技術的な話です。この意図は、事業目標に対してテクノロジーを使い、どれだけ会社に貢献できるかを語れる人であることがすごく重要になってくると。 

具体的にはResilyの場合、プロダクトマネージャーやエンジニアリングのマネージャーですが、プロダクトの品質を低下させる問題・KRに対して、どういうアプローチを取れるかは、エンジニアのスキルにかなり依存してくるものだと考えています。

結局OKRをたてるときの技術的な指標と、事業目標に関してはバランスがすごく大事で、プロダクトを成長させるためのプロダクトチームとしてやらなければいけないこと、加えて技術を使ってプロダクトをどうやってグロウさせるかの観点を2つ敷いています。

及川氏:
もう1個だけ別の視点で言うと、結局個人の人事評価でよくありがちなのが、自分でセルフアセスメント・自己紹介シートを書いて、それに対して上長がコメントして人事評価決まることがあると思うんです。 

その自己評価シートに書く内容は、OKRの内容が書かれることが多いのですが、一方でプロダクト視点で見たときのOKRの項目と、一個人のエンジニアからしてみたときに、結果的にOKRをやってるとしても、その視点が違うことがあると思うんです。

エンジニア視点からは、コードベースの領域に関して、たとえば「半年間ではこういうことをやった」と、エンジニアの書き方があって。ただ、ソフトウェアを変えたことによってプロダクトとしては「こういうようなユーザーに対しての見え方ができた」もあると思います。同じことだとしてもエンジニアやエンジニアマネージャーが最終的に評価を下すのだとすれば、そちらのコンテキストで見たときには別の表現方法になったりすることもあると思うので。たとえばOKRとエンジニアの人事評価は最終的には同じものを見てたとしても切り口が違ったりエンジニアの技術力で見たりするところで違ってくるのかな、とは思います。

パネルディスカッションテーマ②

 プロダクト開発組織の優れた目標(OKR)の立て方とは?(事業指標?技術的負債など緊急度低いものは?)

Resily 西川:
たとえば技術的負債だとか、緊急度の低いようなものの取り扱いだとかのご関心を持っている方が今日は多いと思うんです。そういう色々な課題がある中で、2個目はどう目標を立てるかというところ。いかがでしょうか。

及川氏:
あまり長くならないようなロードマップ的なものをしっかり立て
て、緊急度が低かったとしても『緊急度が低い=優先度が低い』ではないので、優先度はそこそこ高いけれど緊急性が低いものは、どこかのタイミングで入れることを、プロダクトチームとして決めた上でしっかり巻き取っていく、やり方をとればいいのかなと思います。あと技術的な負債というのも、エンジニアからの提案や問題提起で、そこに対しての取り組みが必要、という風に考えられることが多いのですが、そこで全てプロダクト価値・事業価値というところに結びつけるべきものであり、プロダクトに対して結果どう貢献できるのか、を考えた上で、技術的・負債的なエンジニアからの主導で出てくるようなものも、うまく取り入れられるようにするといいのではないかと思います。

Resily 西方:
どれだけ事業貢献できるかにもよるかと。もう1つ、技術的な課題に対して、事業がどれだけマイナスのインパクトを起こすかそれをマネージャー、もしくは経営陣に対してメッセージを伝えられるかどうか、はすごく重要になってくると。経営陣やマネージャーなどに対して技術的な負債、もしくは事業にとってマイナスポイントになるものを伝えるメッセンジャー/代弁者みたいな方が組織にいるべきなのかな、と個人的には思ってます。 

そこのコミュニケーションが分断することによって、一方から見たときにはエンジニアチームがリファクターしたがっている。技術的負債をなんとなく整理したがっている。という見え方になってしまう。一方通行のコミュニケーションにならないようにするというのはすごく重要かと思っています。

Resily 西川
及川さんのお話の中で、その会社のフェーズや置かれてる事業環境、またプロダクトのOKRを会社のレベルのOKRにするところにおいても、変わってくる部分があると思うんです。この点について何かあればお伺いしてみたいと思っていて。 

及川氏
よく言われるのが最初のうちってピボットするかもしれないし、そもそもPMF(プロダクトマーケットフィット)ができなかったら撤退するかもしれないし、みたいなところに「10年これで戦えます」みたいなクオリティの行動を3ヶ月かけて作るよりは「とりあえず半年は持ちます」というのを、2週間で作ってくれる方が大事だったりするわけです。そのステージにおいて求められる進出というものも異なってくると思いますから、それも含めてOKRをたてるといいです。

品質面でしっかりとしたものを求められることが、あるフェーズでは絶対に入ってくると思いますから、どんどん果敢にストレッチで攻めていくものをうまくどこかのステージからバランスよく混ぜていく、ということが必要になってくるのでは。

Resily 西方:
フェーズによっては品質をある程度無視して、プロダクトをグロースさせなくちゃいけない、現実的な局面はありますね。最近弊社ではエンジニアのリソースを拡充し、今までグロースだけに振り切っていたんですが、チーム体制を分けました。具体的にはプロダクトをグローさせていくチームと、タスクフォースを切ってプロダクトの品質向上をさせていく組み方をしてます。 

パネルディスカッションテーマ③

エンジニアリング組織でOKRを定着させるポイントは?

及川氏: 
スクラムとかをやっているのであれば、そこのイベントにうまく絡めたらいいんじゃないかな。 

Resily 西方: 
弊社はガチでスクラムをやっています。スクラムのセレモニーに対して、OKRを意識させることが、スクラムをやっている上では一番重要です。具体的にどうやってスクラムとOKRを接合させていくかですが、プロダクトバックログリファインメントの中では、必ずOKRを確認した方がいいと思っています。

結局プロダクトチームでは「何を目指しているんだっけ?」「だからプロダクトバックログリファインメントはこうしなきゃいけないんだっけ?」「この優先順位は本当にいいんだっけ?」「これは本当にやるべきなんだっけ?」と、会話が生まれるので、プロダクトバックログリファインメントの場には、必ずOKRの話題を持ち込むべきです。もう1つ、スクラムセレモニーとどう混ぜ込むかの話でいくと、プランニングとレトロスペクティブでも同様にOKRを意識した方がいいと思っています。

 意思決定の上で一番優先順位、プライオリティを高く判断するべき物差しとして、OKRを用いた方がいいです。

及川氏: 
スクラムに限らず、会社や組織のチームにおける趣旨の定例的なイベントはあるので、そこでOKRを常に意識することをやる。 そのイベントで毎回しつこいほどOKRを見て、今回どこまで行っただとか、今やってることはOKRのどこに関係あるんだ、ということを全員が意識するようにさせていくことや、各種意思決定でOKRを使うようにしたらいいかと。 

エンジニアリング組織は、割り込み仕事があったりします。何か他組織から急に頼まれたと。あるお客さんに「ちょっと対応してくれ」って言われてるけど、と。そのときに、どこのOKRと関係するんでしたっけ?と依頼主に聞いちゃえばいいと思っているんです。 

OKRに関係しないんだったら、一番後回しにしますっていうようなことがあってもいいのでは。今かなり極端な話をしたので、そんな風にバッサリ切れないと思うんだけれど、でもそのぐらいOKRに関係するんだっけ?どの優先度だっけ?と考えるときに、常にOKRを基準にするようにしていくと、自分たちで意思決定するときのよりどころになると思います。

Resily 西川: 
定例的なイベントの中で常にOKRにたち戻って話をする、OKRに触れるところは、OKRを導入する際、一番最初のポイントとして弊社ではお伝えしています。場合によっては全社イベントで社長様自ら仰っていただくような形で、組織の文化として刷り込む。そのためにはマネジメント層の方々が、自分の言葉でメッセージを伝えることが、浸透させる・定着させるには重要だと思っていて、まさにおっしゃる通りかなと。

パネルディスカッションテーマ④

これからのエンジニアリング組織にOKRは必要か。OKRによってエンジニアリング組織はどう進化するか

及川氏: 
『エンジニア組織をプロダクトチーム化する』もしくは『エンジニア組織はプロダクトチームの一部として機能してる』を考えなくてはならない。プロダクトチーム全体とメンバーの1人として、プロダクト自身を良くしていくところで、専門職としてソフトエンジニアリングをやっていこうとするならば、まさに、エンパワーがすごく大事です。

 OKRがエンパワーメントのためであることを考えると、自分たちが何のためにエンジニアリングをしているか、開発しているかというところに紐づきを考えられるし、自分たちがそれ自身を追求していくことを、OKRを理想の形で運用していたならば、嫌でも常に意識していくことになるんです。 

何のために作ってるのか、何を作ってるのか、これは誰の何のためなのか、そのためにはどう作るのがいいのか。何を作るのか、自分たちで意見をどんどん言っていきながら、プロダクトマネージャーなり企画職の人がいい意味でそれを理解し、必要においては激しい議論をして、本当にそれを作る必要があるのか?もっといいやり方あるんじゃないか?ってことを考えられるために、OKRがコアの軸として機能するような形になっていくと思います。

ですので、ちゃんとした運用ができるOKRは必要だと思っています。僕がよく言ってるのが、「ソフトウェア開発からプロダクト開発に、みんな意識を変えましょう。」

ソフトウェア開発って行動を変えてれば、ソフトウェア開発になるんです。これは面白いし難しいし、本当に尊い仕事なんだけれども。でもエンジニア組織ではなく、プロダクト開発組織になりましょう、プロダクトチームになりましょうの意味合いは、そのコードの先でどういう風に事業貢献できるのか?どんな人のどんな課題を解決しているのか?自分の書いた1行1行で人が喜んでいる姿を見ると、めちゃくちゃ嬉しいじゃないですか進化していくためには、OKRがすごい重要なフレームワークになりうるんじゃないかと思います。

Resily 西方: 
及川さんと少し別の視点になりますが、OKRは必要だと思っていて、エンジニアリング組織だけに必要かと言われると、もう会社として必要じゃないかと思っています。

理由としては、OKRを作って従業員に発信することによって、会社の戦略を伝えるコミュニケーションツールになる。加えて、コミュニケーションツールを会社共通のプロトコルとしてOKRが使えると。

エンジニアリング組織に閉じず、会社のコミュニケーションツール、目標に関するコミュニケーション・プロトコルとしてOKRはすごく必要だと思ってます。 

OKRを導入して理想の組織作りを目指そう!

ここまで、及川氏をお招きして、エンジニア組織の中でOKRはどう位置付けていくか、どう運用していくかなど重要な3つの点についてお伺いしました。


また、パネルディスカッションでは、Resilyの西方も加わり、ResilyでどのようにOKRを運用しているか具体的なご紹介もいたしました。


引き続き後半では、OKRの概念のご紹介、そしてご参加者様からいだいた質問への回答をご紹介いたします。特に、質問の内容を拝見すると「すでにOKR運用されている」企業様が多いという印象を受けました。ぜひ、ご覧ください。

後半に続く

当日のセミナー動画を以下より視聴いただけます!

本セミナーの録画映像を無料で公開しています。

以下のURLから視聴のお申し込みをいただくと、視聴URLが表示されます。
(メールでも視聴URLをお送りいたします。)

OKRを1つのツールに
まとめて運用しましょう

製品資料のダウンロードはこちら

お問い合わせ・導入のご相談はこちら