間違いだらけだった設計レビュー
主にレビューとはそもそもなぜ行うのか？という話から、レビューをするための準備・場づくり、レビュー会議など、レビュープロセスそのものに関して解説した書籍です。
自分はほとんどレビュー会議をした経験はないのですが、それでも設計のみならずコードのレビューにまで応用できるところが多々ありとても参考になりました。
レビューの目的
レビューの目的は修正工数を減らすこと
設計レビュー段階でバグや不整合を見逃して実装後に見つかった場合、コードを修正・確認して、テストしたりするとなると何倍もの工数がかかってしまいます。
本書の中では設計だけの修正と比較し、10倍以上は工数がかかるとまで書かれていました。
そもそもなぜレビューをするのか？ということを中心に、枝葉の問題を確認するのではなくレビューの目的に沿って、しっかりと準備をして取り組むのが大切です。
レビューの間違い
・思いつきで指摘
・見つけやすい誤字脱字を指摘
・指摘件数のノルマ達成で終了
・ドキュメント作成者の人格攻撃
ここら辺は思いっきり刺さりました。（流石に人格攻撃はしたことはありませんが…）
特に専門性が高いドキュメントだと、誤字脱字だけみて終わりみたいなことが多々ありました。
これに関しては自分の担当部分を加味して考えたり、スコープを分割して何度も読むことで問題を見つけ出す方法などが挙げられており、また後者の方法はセキュリティやスコープを絞ることで集中してレビューすることにより、レビューしきれてない不安感を払拭するのにも役立つと書かれていました。
その他のTips
レビュワーが作り直してはいけない。
作り直すこと自体に時間が取られ問題検出が疎かになりかねないし、作り直したものをレビューする人がいない。
エラー処理の定義や依存関係など一度に全ての観点で見るのではなく、レビュー観点を設定して何度も見直す。
どこをどのように調べるのかシナリオを用意する。
レビューのスキルは、ITエンジニアとして知識を得て開発経験を積み、レビューを担当していくうちに身についていくーーは間違い。
レビューで重大な問題を見逃してしまうのはレビュワーの頑張りが足りないからも間違い。
レビューの標準的な手順を身につける。
レビュワーがそれぞれ思い思いにチェックしても効果は上がらない。
今回のプロジェクトではどんな問題を重点的に検出するべきか、を考えるところから始まり、検出した問題について修正したことを確認するまでがレビュー。
レビューの四つのステップ
・レビューの準備
・問題の検出
・問題の指摘
・修正・フォロー
最後に
中盤はレビューをするための準備や環境の構築、レビュー会議でのファシリテートなどにも触れられていましたが、今回は自分が知らなかったり勘違いしたりしていた「レビューはなぜするのか？」というところを中心にまとめました。
今まで設計やそのレビューは経験を積んで学習していくしかないと勘違いしていたのですが、本書のおかげでだいぶ仕事がしやすくなりそうです。
本書の全部を実践するのは機会の関係もあり難しいとは思いますが、システムの設計をするなら一度は手にとってみると参考になるんじゃないかと思います。
P.S. 改訂版が出てたみたいですね。
こちらの方がそれぞれの事例やシナリオが追加されていて読みやすくなっているようです。
この記事が気に入ったらサポートをしてみませんか？