dmm.go #6 の登壇資料です。 https://dmm.connpass.com/event/295065/
組織のコード品質を向上させる“レビューシステム”の取り組み@pospome
View Slide
登壇者名前：pospome（ぽすぽめ）所属：DMM.comTwitter:@pospome
内容についてDMMプラットフォームで取り組んでいる”組織全体のコード品質向上”の取り組みについて話します。
DMMプラットフォーム扱う領域：DMM会員、決済、DMMポイント、不正対策などエンジニア数：120名以上開発チーム数：16チームマイクロサービス数：約40サービスピーク時のリクエスト：19,000RPS＊2016年くらいからマイクロサービスに取り組んでいる。
レビューシステムとは?DMMプラットフォーム全体のコード品質を向上させる仕組みと活動の総称である。2021年4月くらいから取り組んでいる。
DMMプラットフォームとGo言語の歴史について
Go言語をデファクト・スタンダードな言語として定義2020年からDMMプラットフォームはGo言語をバックエンド開発におけるデファクト・スタンダードなプログラミング言語として定義した。＊フロントエンドはTypeScriptです。＊あくまでデファクト・スタンダードなだけで他の言語を利用することもできます。
補足：ここらへんの話は以下で詳細に説明しています
既存のマイクロサービスもGoにリプレイスタイミングよく既存のマイクロサービスを全体的にリプレイスする大規模プロジェクトが走る直前だったので、すべての既存マイクロサービスがGo言語で開発される予定である。＊新規マイクロサービスもGo言語で開発されています。
レビューシステムが生まれるまで
Go言語をデファクト・スタンダードにする上での課題各チームのGoに対する習熟度がまちまちなので、学習コストがかかってしまう。
学習コストを下げるための取り組みpospomeの知見を共有する形で学習コストを下げようと思い、とりあえずドキュメントを書いた。
補足：フレームワークの選定について
学習コストを下げるための取り組みペライチのドキュメントで下がる学習コストはたかが知れている。pospomeは脳筋タイプのエンジニアなので、「習熟度を上げるには、とにかく手を動かして書くしかない」という考えが強い。
とにかく書いてもらう & 有識者のレビュー単に書くだけでなく、それを有識者がレビューするというサイクルが一番効果的だと思った。しっかりと工数をかけて組織全体のGoに対する習熟度を向上させていく。
“有識者による組織横断のGoに対するコードレビュー”これがレビューシステムの原点である
レビューシステム Version 1.0
誰がレビューするのか?たまたま自分のチームにGoの有識者が数人いたので、その人達にレビューしてもらった。＊有識者がいない場合は pospomeが担当する予定だった。 pospomeチーム会員チーム 決済チームレビューする
レビュー担当者の活動時間レビュー担当者は既存の開発作業もあるので、レビューシステムにフルコミットできるわけではない。レビュー担当者の活動時間は1人あたり週に4時間を上限としている。大体2~3人が活動していたので週に8~12時間程度の工数を割くことになる。
レビューシステムのルールやっていることは単なるPull Requestのレビューだが、いくつかルールが有る。1. レビュー担当者からの指摘は提案である。2. レビューシステムによるレビューを待たずにPRをmergeしていい。3. レビューシステムを利用するかどうかは任意である。4. レビューシステムではGoのコード以外はレビューしない。
”レビューのレビュー”についてレビュー担当者同士が定期的にレビュー内容を共有する。それぞれの指摘を共有することで、”良いコード”, “悪いコード”に対する認識を合わせ、レビュー担当者自身のスキルアップを狙う。＊pospomeも参加しています。
例
補足：レビュー対象Pull Requestの管理(´・ω・`)（マツケンサンバってなに・・・ ?
補足：GoogleのReadability ProcessについてGoogleにも “Readability Process” というコードレビューのルールがある。Readability Processは「コードに対する承認権限を持つ人の承認がないと実装をmergeできない」というものらしい。承認権限を持つエンジニアは全体の1~2%らしい。
レビューシステム Version 1.0 の感想
感想1. 予想以上に好評だった
感想2. Go言語に関する指摘はすぐに不要になった最初はGoの学習コスト削減が目的だったが、言語仕様がシンプルなこともあり短期間のレビューで知見共有は不要になった気がする。むしろGoに依存しない設計部分の指摘が多かった。例：usecase層でトランザクションかけましょう
感想3. 組織全体の知見共有のハブになれる各チームのコードレビューをしているので、「これと同じ問題を決済チームが解決していたので相談するといいです」みたいなことができるようになった。
感想4. 開発効率の向上に目を向けるようになった特定のチームの開発効率が低いことを知り、改善した。
感想5. 最終的には各チームの能力に依存するレビューシステムによる指摘を受け入れるかどうかは各チーム次第なので、最終的なコード品質は各チームの能力に依存する。例：「トランザクションスクリプトの方が分かりやすいです」
感想6. ドメイン知識が必要な場合は厳しいDMMプラットフォームは以下の領域を扱っているので、それぞれのドメイン知識がない状態でのレビューには限界がある。● DMM会員● 決済● DMMポイント● 不正対策● カスタマーサポート● などなど・・・
レビューシステム自体はまあまあ成功した
レビューシステムによって感じた組織課題
レビューシステムを通して感じた組織課題レビューシステムを通して以下の課題を感じた。1. 各チームの設計スキルに大きな差があること。2. DMMプラットフォームの開発生産性が不透明であること。＊各チームのGoの習熟度は最低ライン保証されたと思う。
次に何をすべきか?
Developer Productivity Team の設立
Developer Productivity Team とは?DMMプラットフォーム内の “開発生産性” を向上させる専門チームである。今まで片手までやっていたレビューシステムを含め、DMMプラットフォームの開発生産性を向上させるためだけに活動する。
Developer Productivity Team の活動以下のような活動をしている。● レビューシステムの運用によるコード品質の改善（既存の活動● テストカバレッジの可視化 & 改善● 各種エコシステムの開発e.g. 負荷試験基盤, モノレポetc.
レビューシステム Version 2.0 について
レビューシステム Version 2.0 について「Go言語の学習コストを下げる」という目的で始まったレビューシステムだったが、それを達成したことで「コード品質の向上」という目標にシフトする必要があった。
レビューシステム Version 2.0 について既存の活動に加えて以下の2点を追加した。1. Issue共有会2. Issue消化のトラッキング
レビューシステムでの指摘が抱える課題レビューシステムによる指摘には以下の課題があった。1. 「さすがにこれは対応した方がいい」という指摘に対応してもらえない。2. merge済みのPRに対する指摘が対応されているか分からない。
Issue共有会について「対応済みかどうか分からないもの」や「これは対応した方がいい」というものを各チームのGitHubリポジトリのIssueに登録する。
登録したIssueの例
Issue共有会についてIssueがある程度溜まってきたら、各チームのテックリードとミーティングをして、対応の必要性と意図を伝える。
口頭でディスカッションすることの重要性各チームのテックリードと直接会話する機会を設けることによって以下のメリットがある。1. 効率よく設計に対する深い話ができる。2. 会話の過程で各チームが抱える開発課題をヒアリングすることができる。
Issue共有会についてIssue共有会によって以下を解決することができる。1. 「さすがにこれは対応した方がいい」という指摘に対応してもらえない。2. merge済みのPRに対する指摘が対応されているか分からない。
Issue消化のトラッキング各チームのGitHubリポジトリに登録したIssueの数はスプレッドシートで管理されており、それらがどの程度消化されたのかをトラッキングする。
なぜトラッキングするのか?長期間Issueが消化されていない場合、開発チームがリファクタリングに工数を割いていない可能性がある。そういった兆候が見られた場合は、対象チームのマネージャー、部長に直接連絡し、技術的負債の返済に対して工数を割いているかどうかを確認する。
客観的に負債具合を判断するレビューシステムによってコードの状態や既存の課題を認識しているDeveoperProductivity Teamが第三者の立場で介入することによって、開発チームの危険性を客観的に伝えることができる。＊実際にリファクタリングに工数を割く方針に倒したチームもあります。
レビューシステム Version 2.0 について1. Issue共有会2. Issue消化のトラッキング今後も継続的にコード品質を向上させていく予定です。
まとめ
まとめ大きな組織になればなるほどエンジニアのレベル差は大きくなり、コード品質にもバラつきがでてしまう。これを各チーム自身で改善するのは難しい。コード品質という領域に専門性を持ったエンジニアが第三者の観点でレビューすることによって、組織全体のコード品質を底上げする。
宣伝
pospomeがマネージャーを務めるチームの採用マイクロサービスアーキテクトグループでは、エンジニアを募集しています。詳細をブログにまとめているので、興味のある方は読んでみてください。
Developer Productivity Team の活動以下のような活動をしている。● レビューシステムの運用によるコード品質の改善（既存の活動● テストカバレッジの可視化 & 改善● 各種エコシステムの開発e.g. 負荷試験基盤, モノレポ, etc.
テストカバレッジの可視化 & 改善
エコシステムの開発（負荷試験基盤
エコシステムの開発（モノレポ
Developer Productivity Team について開発生産性に向きあう技術特化なチームなので、以下のような人であれば楽しめると思います。● 開発生産性に興味のある人● とにかく技術が好きな人● コード品質に興味がある人
おわり
pospome
katsu8686
takefumiyoshii
doggy
mugi_uno
prof18
eddie
tomokusaba
ykws
assu_ming
findyinc
texmeijin
os1ma
smashingmag
carmenintech
destraynor
danielanewman
zakiyama
jonyablonski
mthomps
revolveconf
chrislema
jrom
chriscoyier
holman