Share
Embed
Slide 1
Slide 1 text
〜 数値で分かるチームの弱点 〜
レビューガイドラインで
技術力を見える化する
@akkiee76
Slide 2
Slide 2 text
自己紹介
Akihiko Sato / 株式会社ラクス Lead Engineer / @akkiee76
SaaS 開発 (Backend, Frontend) / Mobile 開発 (iOS, Android)
上流工程、コードレビュー、チームの課題改善など
読書 / コーヒー / HHKB / 腹筋ローラー
Slide 3
Slide 3 text
今日伝えたいこと
レビューガイドラインで
チームの特徴を見える化させることはとても有意義！
Slide 4
Slide 4 text
私が join した当時のチーム状況
・実装のセオリーが分からない
・レビューの観点が分からない
レビューがしっかり行われていない体制だった
モバイル開発経験者が少なく実装のノウハウがない
Slide 5
Slide 5 text
その結果・・・
・技術力がなかなか伸びない
・定期的にバグが発生する
Slide 6
Slide 6 text
レビュー指摘を類型化できないか？
チームメンバーの弱点を表せないか？
どうやって課題を改善するか
ガイドラインを作って、レビューコメントを類型化しよう！
（ レビュー指摘は財産 ）
Slide 7
Slide 7 text
ガイドライン作成にあたって
基本的なアウトラインを決めよう！
重要度 x 観点
の基準でレビューコメントを類型化することに
Slide 8
Slide 8 text
重要度について
まずは指摘の重要度を 4 つに分類
・MUST（修正が必須）
・SHOULD（リリースまでには修正が必要）
・IMO（修正なしも許容）
・NITS（細かい指摘）
Slide 9
Slide 9 text
観点について ①
指摘の観点を 7 つに分類
・Design（設計）
・Functionality（機能を充足しているか）
・Simplicity（理解容易性）
・Style（コードスタイル）
Slide 10
Slide 10 text
観点について ②
指摘の観点を 7 つに分類
・Naming（クラス、メソッド、変数名などの命名）
・Tests（自動テストが適切である）
・Document（コメント、ドキュメンに関連）
Slide 11
Slide 11 text
具体的な利用方法
コメントの prefix として利用する。
指摘例
MUST（Design）：ドメインロジックがControllerクラスに実装されてます。
domain層の対象packageに新しくクラスを作成して実装を移してください。
Slide 12
Slide 12 text
prefix を付けたコメントを集計
GitLab API （Note API）を利用してコメント集計します。
具体的な方法は、
ラクス Advent Calendar 2021（12/23）
「GitLab API で Merge Request のコメントを一括取得する方法」
をご覧ください。
Slide 13
Slide 13 text
集計結果
運用開始 2 ヶ月で、コメント数は約 75 件。
Slide 14
Slide 14 text
得られた気付き
➔ Tests のコメントが圧倒的に多い
◆ テストコードの実装力の課題
➔ 次いで Design のコメントが多い
◆ 設計力、オブジェクト指向が課題
Slide 15
Slide 15 text
苦手克服のため今後のアクションプラン
① オブジェクト指向の輪読会の実施
② テストの書き方トレーニング会
③ ペアプロの導入
Slide 16
Slide 16 text
まとめ
レビューガイドラインで技術力を見える化すると
① チームメンバーのスキルが定量化できる
② 苦手分野が明らかになる
③ スキルアップのためのアクションプランが検討しやすい
チームでの導入を検討してみてはいかがでしょうか
Slide 17
Slide 17 text
ご清聴ありがとうございました