チーム内Reviewを導入して、チームの自律性が高まった話

チーム内Peer Reviewを導入した話です。と言うと、チーム外Peer Reviewがあるのか？という疑問が湧くと思うので、まずその前提から。

メルカリは四半期ごとの評価タイミングでPeer Reviewを全社で実施している。

  • 各メンバーが任意の3人を指名する
  • 指名されたメンバーはValue軸に則って、Reviewを書く
  • 内容は本人及び上長に開示され、評価の参考情報として使われる

簡単に説明するとこんな感じ、割とよくある評価システムだ。まずは自分がイチ個人としてこのPeer Reviewをどのように扱っているかを説明する

打ち上げ花火、下から見るか？横から見るか？

任意3人の対象に基本的に制限はない。席が隣の人から、その気になれば社長を選択することも可能だ。 この時、Reviewで何を聞くか、ということにもなるが、自分の中では「影響力のベンチマーク」として使っている。 前職のVOYAGE GROUPでもCCFB(Creed Competency FeedBack) と呼ばれる同様の制度があった。この時は5人まで選べたので、その時に選んだ例が以下。

  1. 自部署(子会社)のリードエンジニア
  2. 自部署(子会社)のCOO
  3. 他部署(別の子会社)のリードエンジニア
  4. VOYAGE GROUPのCTO
  5. VOYAGE GROUPのCEO

これは自分からの業務範囲（＝距離）が近い順にSortしている。ここで期待するのは、「どこまでの人から具体的なFeedbackが返ってくるか、逆にどこのFeedbackから曖昧になるか」の境界を見つけることだ。 具体的なFeedbackが返ってくるということは、自分が業務でその人に対して何かしらの影響を与えられていた（＝仕事していた）ということだと捉えて、成果を測っている。前述メンバーとの距離を図で表しながら各人に聞いた狙いを整理するとこんな感じ。

f:id:masartz:20190606011358j:plain

  • 自部署(子会社)のリードエンジニア
    • エンジニアとしての自分のアウトプットができている
  • 自部署(子会社)のCOO
    • 自分のアウトプットが事業成果に繋がっている
  • 他部署(別の子会社)のリードエンジニア
    • グループ内の他の部署にまで自分のアウトプットが波及している
  • VOYAGE GROUPのCTO
    • グループ全体で見て、エンジニアとしての自分の成果が出せている
  • VOYAGE GROUPのCEO
    • グループ全体で見て、自分の成果が事業貢献に繋がっている

ちなみにこんな偉そうな事を聞いているが、実際は各所から具体的なFeedbackが来た！みたいな理想ケースではなくって、「自分の成果も全然まだまだだなぁー」と思わせるありがたいお返事をいただきました。

ただ、このように必ずしも良い評価だけでなく、それ以外の評価が来ることを求めて良いのが、参考情報として扱われることの最大のメリットだ。

Platformにとって顧客はDeveloper

メルカリに話を戻すと、今所属しているMicroservices Platform Teamは基盤構築のチームだ。 この時、社内のDeveloperは同僚でもあり、顧客でもある。Peer Reviewはその顧客の声を聴く貴重な機会といえる。

前述の「影響力ベンチマーク」を当てはめると例えば以下のように分類してReview相手を選ぶこともできる

  • 自分たちのPlatformをヘビーユースしてくれるDeveloper
  • 自分たちのPlatformを使いはじめたばかりのDeveloper
  • まだ自分たちのPlatformを提供しきれていないDeveloper

分類方法はこれに限らないが、いずれにしても顧客の声を大事にしてほしいと思っていて、 そのためメンバーには「Peer Reviewはチーム内のメンバーではなく、チーム外から選ぼう」と依頼してきた。 結果として、チーム外のDeveloperからありがたいFeedbackを実際いただけたので、良かったと思っている。

一方で、メンバーからは「チーム外から聞く意図はわかるし、実際のFeedbackも嬉しい。しかし、同じチームメンバーが自分の仕事をどう見ているかも知りたい」という意見もでてきた。 Platform Teamの各メンバーの良いところは、お互いをリスペクトし合ったFeedbackができることで、やはりタッグを組んで仕事をしているのでFeedbackの内容の濃さは一番だった。なので、その意見を聞きたい気持ちもよくわかる、ということで、Peer Reviewにチームメンバーを混ぜるのを許容していた時期もあった。しかし、これはもはや限られた3人枠をチーム内外で奪い合う方がもったいない。そこで「チーム内Review」を独自実装し、チーム内からのReviewはこの独自の仕組みで集める、その分本来の全社Peer Reviewはチーム外からのFeedbackを貰う、というように棲み分けするのを試してみることにした。

Release CycleとFeedback Cycleの同期

このチーム内Review、実はまだ2回しかやっていないのだけど、既に2パターンのやり方を試している

  1. 四半期単位でチーム内から任意の3人選んで、Feedbackを貰う
  2. Release単位で 同Release メンバー同士でFeedbackをし合う

1つ目はシンプルで図にすると、こんな感じ。Review相手を選ぶリクエストの矢印は簡易的にTech Lead, Bさん、Eさんの3人分のみ表現している。

f:id:hossy0108:20190605073217j:plain

チームのメンバー間でフラットにReviewする形とした。基本的には全社Peer Reviewのスキームをそのままチーム内のスコープで実現しただけだ。Engineering Manager(= masartz)が輪に入っていないのは、Managerとしてのオフィシャルな評価があるので、俺からのFeedbackはその時伝えられるからだ。

一方、2つ目のやり方の背景を少し補足するのに、先日開催した Mercari Meetup for Microservices Platform #2 でTech Leadが発表していた素晴らしい資料を先に紹介したい。

この説明にあるように、現在は6weekのリリースサイクルでProjectを回している。会社組織的には1つのPlatform Teamの中で都度ミニチーム(下記で言う、Release1,2,3それぞれ）が組成されるイメージだ。

f:id:hossy0108:20190605073239j:plain

各Release Teamには Release Leadを任命していて、そのReleaseのOwnershipとResponsibilityをTech Leadから委譲されている。Tech LeadはそれをしながらPlatform Team全体のアウトプットにコミットしている。

このミニチームを6週間単位で運営し、成果を出して解散する。次の6週間はまた別のチームが組成され、Release Leadも変わる運用だ。例えば、次はEさんとCさんのペアでチーム組成され、EさんがRelease Leadを担うチームになるかもしれない。

Peer Reviewに戻ると、各Releaseチーム内（例えばCさんとAさん）でReviewするのを基本とし、Tech LeadはRelease ReadとReviewしあう形にしている。（この図も簡易的に一部の矢印は省略している）

実際どうだったか？

チーム内の独自実装について

全社Peer Reviewは四半期末に実施され、自己評価の記入などと合わせてやや忙しくなる。そこにチーム内Reviewの記入タスクまで積んでしまうとメンバーにとって過負荷になってしまうので、ちょっとだけ時期を前倒して実施して負荷分散している。それもあってか、チーム内外それぞれのPeer Reviewを皆しっかりと書いてくれている。特にチーム内ReviewのFeedbackは受けた側の満足度がとても高いため、この取組を継続したいと言ってくれている。

四半期単位とRelease単位の実施時期について

1つ目のやり方でやると実施時期は四半期単位になる。それは全社的に見れば最短期間だが、チーム内で見ると2回分Releaseが回っている。つまり、1つ前のReleaseの時の事を思い出しながら書くことになるのでどうしても内容が薄まりがちになってしまう。また、必ず書いてもらうようにしている「もっと良くしたほうが良い点」が受け手に伝わって改善に取り組むまでにラグができてしまう。という経緯でRelease サイクルと同期している形にしてみたが、そちらの方がしっくり来ているようだ。

マネージャー視点での感想

予期していなかった成果として、俺がFeedbackしたい内容と同じことをメンバー自身が感じ、それをチーム内Reviewで伝えてくれていたりする。これが本当に嬉しい。例として、メンバーAからメンバーBへの課題をマネージャーが吸い上げる必要もなければ、マネージャーが思う事をわざわざマネージャー自身で伝えなくても代わりにメンバーAが伝えてくれる。それによって、チーム内のお互いの信頼感とリスペクトが高まっていく好循環が生まれている。チームが自律的にお互いを補完しあっているのは「チーム」という単位でのセルフマネジメントができているとも言え、マネージャーとして感謝しかない。チーム内Reviewの仕組み改善も、「2パターン目のRelease単位でやってみよう」というのはメンバーからの提案であり、正直俺は1つ目のパターンの方が良いと思いつつ試してみたら思った以上に好感触だったので、「じゃあ、2パターン目で行こう」とコロッと方針転換できたりした。

まとめ

いくつか話題があったが、まとめるとどれもFeedback Cycleの話である。

  • 個人として、前職のPeer Review 指名方法や、他チームのDeveloperのReviewを貰う狙いの件
    • 自分との距離間を元にして改善点を見つけ、それを次に活かすということ
  • マネージャーとして、メンバーにどういうReviewを受けてもらうかの試行サイクルの件
    • 受け手としての感想をメンバーから貰い、書き手をどう見つけていくかに活かすということ
  • チームとして、チーム内ReviewによってFeedbackを交換する件
    • マネージャーから見て、メンバーが自律的に改善しあうということ
    • また、それをするためにFeedbackの仕組み(チーム内Reviewの実施時期)すらも自分たちで改善するということ

ということで、とにかくトライアンドエラーで改善していって成果を出すという話でした。