アプリケーションの開発で設計レビューについて、経験則に偏ることがあると実感しました。 そのため、設計レビューについて考えている書籍を手に取りました。 4章に分けて、具体的な例を提示しながら論が展開していきました。 以下のような内容が印象に残りました。 成果物と個人は切り分けること。 レビューをしたり、受けたりする上で準備をすること。 決められた時間内で後工程で手戻りのコストを下げるシナリオ作り。 レビュアー依存になりがちなレビューについて改めてかみ砕き理解が深まった一冊になりました。

Amazonでセール対象だったのと、レビューに悩む部分があって購入。 教科書的な王道のレビュー方法を説明しているんだろうけど、今まで小規模プロジェクトで自己流にしかやってこなかったので勉強になった。 レビューアーが複数人いてレビュー会を開催する…なんて大規模案件はやらないだろうけど、エッセンスは役立てたいと思った。 レビューの目的は後工程での修正工数の低減、というのは本当に納得した。分かってはいたけど、目的を改めて明言されるとやるべきことが明確になる気がする。レビュー会の最初に目的を言うのも大事だよね。

もとITエンジニアの研究者が、ソフトウェア開発400社の協力を得て、レビューのやり方を調査。些末な指摘や人格攻撃を排し効果的なレビューをするには、レビューの指針となるシナリオを作成し、些末な問題にとらわれず1件づつ実行し、記録・振り返りを行うこと。 方法や進め方についても、事例についても、具体的で明確でわかりやすい。