こんにちは。Wantedly Visit 開発チームで"Squad Leader"をしている森脇です。

この記事では、エンジニアブログでいつも紹介している技術の話ではなく、開発チームが普段どのようにシゴトをしているのかを紹介したいと思います。エンジニアだったらクールな技術を使っているかはもちろん重要ですが、どのような組織体制で、どのような目標を持って、どのように意思決定をするかは、それ以上に大切なことでしょう。

まずは重要なキーワードであるSquadとOKRについて簡単に説明してから、実際のチームを例にしてより詳しく具体的な話をしていきます。

チーム編成: SquadとTribe

さっき自分のことを"Squad Leader"と紹介しましたが、いきなり登場したこの"Squad"という言葉について説明します。

Squadとは、いわゆるチームのことなのですが、同じ目標をもち、互いのシゴトが強く依存しており、「ひとまとまりで動くことで意思決定の質と速度を最適化できるチームの最小単位」を指します。これ以上分割したら互いのシゴトの影響範囲を把握するために無駄が増え、これ以上大きくなるとコミュニケーションコストが増えて意思決定に時間がかかってしまうような、そのメンバーでまとまって動くことが最適だと考えられる規模のチームです。

そして、複数のSquadが集まったものをTribeと呼びます。これはいわゆる事業部のような単位です。会社の中にいくつかのTribeがあり、Tribeの中に複数のSquadがある。 Tribeのメンバーは全てどこかのSquadに属している、というのが、Wantedlyという組織の基本的な構成です。シゴトのほとんどの時間は、同じSquadのメンバーと一緒に過ごすことになります。

SquadとTribeという二つのチーム規模を明確に命名し、会社 > Tribe > Squad > メンバー、という階層に常になるように定めることで、Tribeの下に別のTribeができたり、Squadの中にもう一階層チームが生まれたりすることなく、余計な階層化でコミュニケーションコストが増えたりなどの心配はありません。

Squad / Tribeの他に、Guildという組織横断的なプロジェクトチームも存在していますが、ここでは説明を省かせてもらいます。また別の機会に、Guildの活動について紹介できればと思います。

ちなみにSquad / Tribeという呼び方は、Spotifyなどを参考にしています。興味があるかたは、こちらの記事をご覧ください。

目標設定: OKR

Squadの目標設定には、OKRという手法を用いています。OKRとは、チームでどのような目標を達成しようとしているのかを明文化した“Objective”と、そのObjectiveへの到達度を定量的に計測できる"Key Result"を設定するというものです。

一般的な目標設定と大きく違う部分は、目標値の60~70%達成すれば成功と言えるような野心的な目標を設定することです。今の延長線上で少し頑張れば手が届きそうな目標を設定するのではなく、何か抜本的な変更やアイデアがなければ達成できないような目標を立てることで、どうやって目標を達成するかを常に考えるようになり、思いがけないアイデアに出会い、予想以上の成果を上げることができるようになります。

先ほど紹介した「会社 > Tribe > Squad > メンバー」という階層のそれぞれに対してOKRが設定されます。これにより、それぞれの目標は会社の大きな目標の一部を担っていることを確認でき、各メンバーが会社と同じ方向・同じ目線の高さを持ちやすくなることも大きな利点の一つです。

OKRについては、最近は本や記事も多く出ているので形式的な紹介はこれくらいにしておきますが、詳しく知りたい人のために僕が一番わかりやすくまとまっていると思うWebページを貼っておきます。

実例: Discover Squadの場合

SquadとOKRというキーワードについてざっくりと説明しましたが、自分がSquad LeaderをしたDiscover Squadというものを例として、どのような役割を果たしているのかをより具体的に紹介したいと思います。

ちなみにDiscover Squadとは、Wantedly VisitのiOSアプリに最近実装された発見機能（社内ではDiscover機能と呼んでいる）を開発していたチームです。ユーザーが様々な切り口から募集や記事を探せるようになる機能で、A/Bテストを続けながら、2018年8月に全体リリースを行いました。

メンバーは、Squad Leaderの自分（兼任）と、エンジニア2名、デザイナー1名（兼任）という小さいサイズです。

Squadの立ち上げ

このDiscover Squadは、なぜ作られることになったのでしょうか。そこには、次のような4つの視点からの考えがありました。

• Wantedly Visit Tribeとしては、アプリを最重要フォーカス領域として位置付けています。アプリの成長率はWebより高く、応募数の半分以上はアプリ経由で発生しています。今後も、アプリにどんどん注力することで成長率を上げていきたと考えていました。
• アプリの開発を担当しているチームでは、長年継ぎ足して開発されてきたアプリの全体の体験や古くなったUIを見直したいと思っていました。その中でも、特にDiscover機能のようなものを新しい要素として入れたいと考えていましたが、フルリニューアルはとても時間がかかるので、どうにかして小さく切り分けて進められないかと考えていました。
• その頃僕が率いていたFeedチームでは、Wantedly Feedの閲覧ユーザー数を伸ばすことに注力してきましたが、アプリに手を入れることでもっと伸ばせるんじゃないかと考えていました。しかし、メンバーはWebフロントエンドが得意な人が多く、ネイティブエンジニアがいないチームであるため、なかなかアプリに手を出せずにいました。
• Reactが会社内で幅広く使われるようになっており、Reactが得意なメンバーもどんどん増えているため、Reactを使ってアプリも開発できるReact Nativeへの注目度が上がっていました。この技術を導入することで、ネイティブアプリエンジニアがいないチームでもアプリの開発を進めることができるので、チームの開発速度を向上させることができると考えていました。

こういった様々な視点から、Discover機能という、アプリチームにとってもFeedチームにとっても重要な機能を、フロントエンドが得意な自分のチームでReact Nativeという技術を使って開発することが最適だと判断して、Discover Squadという新しいチームを立ち上げられました。

注目すべきは、これがトップダウンに決まったことでもなく、それぞれのSquadが勝手に判断したことでもなく、アプリに注力していくというTribeの戦略を理解したメンバーたちが、自分のチームだけじゃなく周りのチームの状況も考慮し、ボトムアップに全体最適で考えた結果として生まれたチームだということです。ボトムアップで自分たちがやりたいと思ったことが、会社の方向性と合致しているという状態であったため、各メンバーが高いモチベーションで働くことができたプロジェクトだったと思います。

このように、Squadは自律的に動くこと、かつ全体最適であることを求められます。何を作るか、それをどうやって作るかの意思決定は、基本的にはSquadに委ねられています。そういう体制が実現できているのは、各メンバーが、Tribeや会社というより高いレベルの目標や戦略を理解していて、会社が何を大事にしているかという価値観を全員で共有できていることにあると思います。

SquadのOKRを決める

Squadが立ち上がったら、OKRを決めます。Discover機能を作るという方向性は決まっていましたが、なぜそれをやるのか、何をゴールにするのかを、あらためて文章としてまとめて共有することで、各メンバーの視点が時間が経ってもズレていかないようにする必要があります。

Objectiveは、そのチームで与えたい事業やユーザーへのインパクトを言葉にします。注意するべきは、Tribeや会社のObjectiveにきちんと沿っているかなどですが、Objectiveを決めるのにすごく迷ったりすることは今のところあまりないです。

Objectiveができたら、そのObjectiveを達成できていると確認できる、定量化できる目標としてKey Resultを設定します。実際にKey Resultの設定をやって学んで、特に以下のようなことに気をつけています。

• 全く根拠がない数字を置かない。その目標値はどこからきたのか、それは全体に対してどういうインパクトがある数字なのかを、メンバーが理解できるようにします。納得感の無い目標を追い続けるようなチームは作りたくないです。
• 一方で、ボトムアップで考えすぎないようにしています。これとこの施策をやればこれくらい伸びるから、これくらいは達成できると思う、みたいな説明をすると、じゃあそれをやれば終わりか、思考停止してしまいがちです。本当はもっと高いインパクトを残せる可能性が高い施策があったにも関わらずに、それを探そうとしなくなってしまいます。どうやれば目標を達成できるだろうかとメンバーみんなが常に考えている状態が理想的だと思います。
• 進捗が0%から始まって100%に向かうことように設計する。例えば、月間100万PVだったのを150万PVまで伸ばしたい。現状は130万PVだとしたら、その進捗率は、130 / 150 = 87%ではなく、ベースラインからの増加量を計算して (130-100) / (150-100) = 60%となります。細かいですが、このように設定することで、全体の期間の中で今の達成率は正しいペースなのかが分かりやすくなります。
• 複数あるKey Resultの中でも優先順位をつけることで、優先度が高いものにフォーカスできるようにします。Key Resultは3個程度置くのですが、一つのKey Resultが上手く進んでいなかったら、他の達成しやすいKey Resultにフォーカスしてしまいがちです。本当に達成できない場合ならしょうがないですが、より重要で達成が難しいKey Resultにより多くの時間をかけるべきなので、そうならないようにメンバー間で優先順位の意識合わせが必要です。

また、野心的な目標を決める時にはこんな会話になることが多いです。

「これくらいの目標にしようと思うんだけど、どう思う？」
「流石に高すぎるんじゃないですかね？」
「じゃあ、それの60~70%くらいならいける可能性ある？」
「それくらいならなんとかなるかもしれないですね」
「それでもいい成果だよね。でもそこを目標にしちゃうとそれ以上の結果が出にくいから、今の目標のままでいってみよう。100%目指して取り組めば、60~70%くらいに着地しても、十分素晴らしい成果だと思うよ」

逆に、始めから「それくらいならなんとか行けそうですね」みたいな感じだと、目標がまだ低いと言えるかもしれないです。また、このような会話ができるためには、みんなが安心して高い目標を設定できるような心理になることが必要です。そのためには、達成度がそのまま直接人事評価に結びつくものではないということを認識することがとても重要です。100%達成しないと評価されないような環境では、どうしても心理的に確実に達成できるような低い目標を設定してしまうようになるでしょう。

以上のようなことを考えながら、今回決まった実際のOKRは以下のようでした。

• Objective
• • シゴトでココロオドル状態をもっと多くの人に知ってもらうことでエンゲージメントを高める
• Key Result
• • 滞在時間を20%伸ばす
  • コンテンツの閲覧数を50%増やす
  • Discover経由で応募する人を30%増やす
  • コンテンツを毎日80%更新されるようにする
  • 毎週1回新しい要素を実験する

一番最後の「毎週1回新しい要素を実験する」というものは、Objectiveには直接関係しないが、必要があって入れたものでした。このプロジェクトには、React Nativeの導入を成功させるという目標が別であったため、React Nativeで高速な機能改善が実現できることを実証するためのKey Resultとして設定しました。こういう場合、Objectiveを複数個設定したりするパターンもありますが、複数個あるとやはり優先度付けが難しくなるため、一つのObjectiveでいくことにしました。

振り返ると、少しKey Resultが多いように感じます。下の二つは、少し行動目標っぽくなっているので、Key Resultとして入れなくてもよかったかもしれないです。やはり3つくらいがベストだと思います。

無駄なくスピーディーに仮説検証する

OKRが決まったら、ついに具体的な開発が始まります。何を開発をするかを決める方法は、SquadやTribeで自由ではありますが、全社に共通している価値観として、「リーンに開発する」ことがあります。誰も使わない機能の開発に時間を無駄にしないように、ミニマムな方法で仮説を検証していき、確証が得られたものに対してしっかりリソースをかけていくようなやり方を大事にしています。

Discover Squadでは、この仮説検証をスムーズに行うために、Lean UXという本で紹介されている「仮説ステートメント」という手法を用いました。これは、次のようなフォーマットで仮説をまとめることです。

われわれの【ビジネスの成果】は、【ユーザー】が【ユーザーの成果】を【このソリューションや機能】で実現できれば、達成できるはずだ。

このカッコ内の言葉を埋めて仮説を文章とすることで、作ろうとしているものがどういう仮説のもとに必要だと考えられているかを分かりやすくすることができます。【ビジネスの成果】には、先ほど設定したKey Resultや、それを分解した目標値が入ります。

仮説ステートメントが集まれば、どれから手を付けていくかの優先順位を決めます。その時に役立つのは、バリューと複雑性（工数）を軸にしたマトリックスです。自分はproductboardというサービスを好んで使っていますが、もちろんホワイトボードとポストイットでもできます。

左上に、低い複雑性で高いインパクトが期待できる仮説が集まります。そこがコスパの良い部分ではあり、真っ先に取り掛かるべき部分ですが、そのような良い施策はあまり多くは出ません。

そこで次に目をつけるべき施策ですが、左下の低いインパクトで低い複雑性の仮説は、とりあえず手を付けやすいので目を奪われがちですが、これはどれだけ成功してもそれほど高いインパクトを与えることはありません。それよりも、右上の高いインパクトで高い複雑性の仮説の不確実性を下げることで、取り組みやすくすることの方が重要です。そのような仮説は、分解して検証しやすい仮説に落とし込んだり、その見込み顧客にヒアリングをしたりすることで、不確実性をできるだけ取り除いていくことで、安心して開発に集中することができます。

開発した機能は、基本的にA/Bテストでリリースされます。そこで、既存のものと比較して良くなることが確認できたものは全体にリリースされ、その後の動きをしばらく注視してから、問題がなかれば、その施策はようやく完了したと言えます。

1on1ミーティングでヘルスチェック

せっかくチームの目標を立てても、はじめの頃は意識できていても、時間が経つにつれて目標への意識が薄れていくことはとてもよくあることです。そういった問題を防ぐために、Wantedlyでは 15Fiveというサービスがとても役に立っています。会社の全てのOKRツリーが可視化され進捗が常に分かるようになっていたり、毎週のSquad LeaderやTribe Leaderとの1on1のアジェンダとして15fiveを使うことで、OKRの進捗をアップデートして報告することが必須になるため、確実に毎週更新され、必要なフィードバックをすぐに受けられるようになっています。

もちろんこのようなツールを必ず使う必要はありませんが、定期的に確実に目標への進捗度合いを確認する仕組みは必須だと思うので、OKRを導入するなら検討してみる価値はあると思います。

以上、僕がSquad Leaderとして高い成果を発揮するSquadを作るために特に大事にしていることを、できるだけ具体的に紹介してみました。

もちろんここに書いたことがチームにとって大事なことの全てではないですし、ここに挙げたことを全て完璧にできている訳でもなく、試行錯誤しながら走ることはとても大変です。

それでも、Wantedlyには本当に優秀なメンバーが集まっていると思うので、みんなが100%の力を出せるような環境を作ることができれば、自分にとってもすごく喜ばしいことだし、会社がさらに成長していくためにとても重要なことだと思うので、もっと強い開発チームを作っていくことにさらに力を入れていくつもりです。

Wantedlyの開発チームの働き方に少しでも興味があると思ってくれた人は、ざっくばらんに話しましょう。ぜひ遊びに来てください。