レビューに向けて ⼯夫した話 2024.7.31 アノテーション株式会社 ⾼崎 渉

Xへの投稿の際は、 ハッシュタグ #devio2024 でお願いいたします。 2 お願い

⾃⼰紹介 3

⾃⼰紹介 4 高崎 渉 たかさき わたる 【所属】 アノテーション株式会社 エンジニア統括部 パートナーアライアンスゾーン LINE/アプリ DevOps チーム 【入社】 2023 年 3 月 【これまで】 オンプレミス開発 約６年 組込開発 約２０年 →LINEミニアプリの運用保守にジョブチェンジ

今回のお話 5

今回のお話について 6 ■お話すること ■対象 ● レビュー資料に⼀⼯夫したこと ● レビュー⾃体を⼀⼯夫したこと ● 形骸化したレビューをなんとかしたい ● どういった観点でレビューすればよいかわからない

ソフトウェアにおけるレビュー 7 ■「ソフトウェア レビュー 課題」 google 検索：約 200 万件ヒット ● レビューは合意形成の場だということを理解する ● 事前にレビュー対象物を展開して準備する ● 揚げ⾜取りで個⼈攻撃にならないようにする ‧‧‧といった話ではなく、 レビューの対象物ややり⽅に⼀⼯夫したお話。

背景 8 ■LINE ミニアプリ運用保守業務 クラスメソッドグループ全体で LINE 事業の維持と拡⼤ ● 脆弱性に積極対応し、安定した運⽤を維持 ● クラスメソッド開発エンジニアの負荷軽減 ● LINE 業務で得たナレッジを集約、蓄積 中規模を超えた差分開発を携わることになり、 ドキュメントやソースへの確認事が増えてきた

要件や処理の 経緯が知りたいが、 あるのはドキュメント やソースのみ 9

経緯を残す 仕組みを作ろう 10

１．レビュー対象物に⼀⼯夫 11

レビュー対象物へ⼯夫したこと 12 レビュー対象物：設計書・データフロー図・ソース これらのようないわば「検討の成れの果て」ではなく、 下記のような成果物に⾄る⾏間の部分を残して記載する。 ● お客様と整理した内容（Backlog や JIRA の URL でも可） ○ 経緯の記録を余すことなく出す ● 設計⽅針の検討内容 ○ 検討項⽬の要否 ● 改修するソースの事前調査内容 ○ 検索して調査した場合はその検索を⾏った⽂⾔と対応要否 ● 追加するソースの実装⽅針 ○ 要件実現のために実装する内容 →ADR（Architecture Decision Report）を作成

まずは ADR を確認する 13 確認内容 ● お客様と整理した内容（Backlog や JIRA の URL でも可） ● 設計⽅針の検討内容 ● 改修するソースの事前調査内容 ● 追加するソースの実装⽅針 →整理内容のチェック
 →方針や検討の是非
 →調査内容の是非
 →コストの確認（処理時間、従量課金） 
 →実装モレのチェック
 レビュアーの判断対象 
 検討内容の妥当性 
 次期開発の参考資料 
 新規メンバーの教育 
 ＝チームの重要な資産 


１．のまとめ 14 設計書・ソースの 行間こそがレビュー対象 
 ● 検討事項を ADR として整理 ● レビューは ADR に関する妥当性を判断 ● 品質記録や今後の参考資料として活⽤

２．レビューに⼀⼯夫 15

レビュー 16 ■英語の「レビュー（review）」 直訳すると、 ● 再検査 ● 評価 ● 批判 ● 振り返り レビューはレビューアの振り返りの場

振り返りのフレームワーク 17 ■KPT（Keep Problem Try） ● Keep‧‧‧？？？ ● Problem‧‧‧レビュー対象物への問題指摘 ● Try‧‧‧指摘された問題に対する施策、修正 レビューでKeepするものを明らかにする

どうしたら？ 18

褒めましょう 19

褒めましょう 20 その検討⽅法、 とても良く 整理されていますね 可読性の上がる リファクタリング 有難うございます とても観点の広い テストケースだと 思います 複雑な要件の整理 お疲れ様でした きめ細やかな 条件分けの検討、 さすがです そのコメント、 わかりやすいです などなど 等々 etc.

２．のまとめ 21 レビューでは褒めることも意識する 
 ● 「ダメ出し」だけではなく「良かった探し」も実施 ● ⾃分だと出来なかったものをどんどんピックアップ ● 出てきたものをナレッジとして後段に活⽤

まとめ 22

まとめ ● 経過、経緯を残して判断する ● 「良かった探し」を⾏う 23

24