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