組織横断チームのテックリードとして同期レビューを導入したという話

自分はDMMプラットフォームのマイクロサービスアーキテクトチームというチームのテックリードをしているが、 このチームが "DMMプラットフォームの組織的な技術戦略を策定、実行する" という目的を持っているということもあり、 普段の業務でDMMプラットフォーム内の各チームとやりとりすることが多い。 その中でも "成果物のレビュー" が自分の作業時間を圧迫し始めたので、同期レビューを導入した。

レビュー対象の成果物は?

現在は主に以下をレビューしている。

  • DMMプラットフォーム内の Product Requirements Document(PRD), Design Doc
  • 自チームの成果物
  • 他チームのGoのコード

PRD, Design Doc を書くのはシステムアーキテクチャが大きく変わるときに限定されるので、 そんなに頻度が多くない印象があるかもしれないが、 DMMプラットフォーム内の全ての PRD, Design Doc が対象となるので、意外とちょこちょこ発生する。

自チームの成果物は PRD, Design Doc に加えて、Goのコード（Pull Request）などがレビュー対象となる。 マイクロサービスアーキテクトチームは内部的にサーバサイドチームとSREチームに分かれているので、 2チーム分の成果物がレビュー対象となる。 ただ、自チームの成果物に関しては自分以外のメンバー同士でレビューを任せることも多くなってきたので、ボリュームとしてはそれほど多くないと思う。

他チームのGoのコードは、マイクロサービスアーキテクトチームが実施している "Goの実装支援" の文脈で発生する。

以下の記事で軽く振れているが、 これは "DMMプラットフォーム内の各チームの依頼に応じてマイクロサービスアーキテクトチームのエンジニアがGoのコードをレビューするというもの" である。 DMMプラットフォームはエンジニア100名規模の開発組織なので、エンジニアやチームによってGoの習熟度が異なるという問題が発生してしまう。 実装支援はこの習熟度の差を解消したり、（マイクロサービスアーキテクトチームがハブとなり）チーム間で知見を共有することを目的に実施している。

inside.dmm.com

ただ、自分は他チームのコードを直接レビューするのではなく、"マイクロサービスアーキテクトチームのチームメンバーがレビューした内容をレビューする" という "レビューのレビュー" みたいなことをやっている。

他チームのエンジニア <----review--- マイクロサービスアーキテクトチームのメンバー <---review--- pospome

これはマイクロサービスアーキテクトチームのメンバーが実装支援が可能なスキルレベルを持っているかを確認するのが主な目的だが、 "pospomeのアプリケーションアーキテクチャの知見をチームメンバーに共有する" という成長環境を提供するという目的も兼ねている。

自分のアプリケーションアーキテクチャの知見については以下の書籍に一部をまとめているが、 やはりPull Requestベースで実際のコードを相手にするとその通りともいかないので、直接 Pull Request を見る必要がある。 もちろん自分自身も勉強になることが多い。

pospomeのサーバサイドアーキテクチャ（PDF版） - pospomeの本屋さん - BOOTH

pospomeのサーバサイドアーキテクチャ3（PDF版） - pospomeの本屋さん - BOOTH

pospomeのサーバサイドアーキテクチャ4（PDF版） - pospomeの本屋さん - BOOTH

全ての Pull Request が "レビューのレビュー" の対象になるわけでないが、DMMプラットフォームで開発中のアプリケーションが対象になるので、 それなりの数のPull Requestを確認する必要がある。

レビュー多すぎ問題

同期レビューの話をする前に自分自身のレビュースピードの話をしようと思っていて、基本的に自分はコードレビューが遅い。 1つのPull Requestのレビューに2,3時間かけることもある。

コードレビューが遅い理由は可能な限りコメントを丁寧に書こうとしてしまうからである。 どのように修正するのか、なぜ修正した方がいいのかを書くのは当然として、 その際に具体的なサンプル実装を書いてコメントに残したり、 修正の根拠となる実装パターンやプログラミング原則の説明を追加したり、 修正しなくても良いパターンも参考程度に説明したり、 とにかく情報量が多くなってしまう傾向にある。

情報量を減らせば良いのでは? と思ったが、 それだと意図が伝わらないことがあったり、 チームメンバーの成長環境として物足りない気がしてしまって、なんだかんだで時間をかけてレビューをしていた。

他チームの PRD, Design Doc のレビューはコードレビューと違う意味で大変である。 というのも、各チームの担当領域やシステムアーキテクチャの知識を持っていないからである。 例えば、決済を担当するチームの Design Doc をレビューするときに、決済の知識と既存のシステムアーキテクチャを知らなければ、Before/Afterの妥当性を判断することができない。 コメントベースのやりとりでは、それらを確認するだけのやりとりでだけで数日かかってしまう。

自分の守備範囲が広くなるに従って、この問題が顕著になってきた。 自分のレビュー待ちで開発を止めるわけにはいかないので、なんとかしてこれを改善しなければいけなかった。

同期レビューとは?

成果物の作成者や関係者と自分がZoomやDiscordで画面共有しながら、その場で成果物をレビューすることである。 コードやドキュメントなどの成果物は大体コメントベースで非同期で行われるので "同期レビュー" という言い方をしている。 レビューを依頼するときはGoogleカレンダーに予定を入れてもらっている。

レビュー時間は大体 30 ~ 60min である。 簡単なものは30min未満で終わる。 成果物のボリュームが大きくても60minを超えることは基本的にない。

当たり前のことだが、 すべてを同期レビューにするわけではなく、 成果物の作成者とのコミュニケーションが発生しそうな成果物のみが対象となる。 例えばコードレビューでいうと"環境変数の追加"とかは Pull Request のレビュー依頼が来たタイミングで確認して Approve してしまうことが多い。

同期レビューのメリデメ

レビュー効率を向上させるために導入した同期レビューだが、当然メリデメはある。

メリット

まず、口頭コミュニケーションでレビューが進むので、シンプルにコミュニケーション効率が高い。 今まで文章で書いていた内容を話せばいいだけなので、とても楽になった。 分からないことはその場で聞けば回答が返ってくるので、非同期コミュニケーション特有の"相手の返信待ち"というリードタイムもなくなった。 Googleカレンダーに登録した時間でやりとりが終わるので、スケジュールも立てやすいはずである。 ちなみに、口頭でのコミュニケーションとはいえ、情報量が多いと忘れてしまうこともあるので、最低限の内容は話しながらコメントとして残しておく必要がある。

成果物の品質によっては差し戻しが発生してしまうが、 その場で修正内容を具体的にすり合わせているので、 差し戻しの修正をレビューするミーティングは30min未満で終わる事が多い。 修正内容が明確なものであれば「今回指摘したところを修正したらOKなので、今回のミーティングでレビュー完了という認識でいいです」という感じで差し戻し内容の確認自体を省略することもある。

普段会話することのない人と直接会話する機会にもなるので、（特にリモートワークだと）人間関係という観点でもプラスに働いているかもしれない。

デメリット

明確にデメリットだなと思うのは、"その場で成果物の品質を判断しなければいけないこと" である。 従来のコメントベースの非同期なレビューの場合、同期レビューに比べて時間的な制約が緩いので、 色々調べたり、考えたり、十分な時間をかけることができるかもしれないが、 同期レビューはそのミーティング内に結論を出さないといけないので、そこは難しいなと感じる。 ミーティングのあとにslackで「ミーティング中に言及できなかったんですけど、xxxx の部分は yyyy にすることを検討するといいかもしれないです」といったコミュニケーションをすることもたまーにある。

レビューに立ち会う人が複数人いるとミーティングを調整しづらいというのはあるかもしれない。

結果的に非同期でやった方が早かったというケースもある。

そもそも守備範囲が広いのが問題

そもそもの話をすると、単純に守備範囲が広いのが問題になっている感はあるので、自分がやっていることを他の人に委譲するような動きをする必要があると思っている。 実際にここ半年で一部の作業やレビューをチームメンバーに完全に任せていたりするので、 この調子でpospomeにブロックされず、スケールするチームにしていきたいなーと思っている。

チームメンバーからも「pospomeさんは誰かに振ればいいタスクをわざわざ自分でやっている感じがしています。もっとpospomeさんがやるべきことに注力して欲しいです。」という意見があって、本当にそうだなと思った。 ここは自分の反省点である。

宣伝

DMMプラットフォームのマイクロサービスアーキテクトチームではサーバサイドエンジニアとSREを募集しています。 選考なしのカジュアル面談が可能なので、このブログを読んで「なんか面白そうだなー」と感じたら、連絡ください。