目次
第１章 レビューの間違い（レビューの目的の間違い；問題検出の間違い ほか）
第２章 準備と問題検出（レビューの準備（リーダー、作成者）
レビューの準備（レビューアー） ほか）
第３章 レビュー会議の進め方（問題指摘の手順；問題の修正・フォロー ほか）
第４章 さらなる効果向上（レビューの改善・効率化；開発タイプ別のレビュー手順）
付録 レビュー観点絞り込みの効果
著者等紹介
森崎修司［モリサキシュウジ］
２００１年奈良先端科学技術大学院大学情報科学研究科博士後期課程修了。博士（工学）。同年より情報通信企業においてオンラインストレージサービスの企画、開発、運営にサービス責任者として従事。２００５年より奈良先端科学技術大学院大学情報科学研究科研究員として、文部科学省リーディングプロジェクト「ｅ‐Ｓｏｃｉｅｔｙ基盤ソフトウェアの総合開発」、経済産業省「先進社会基盤構築ソフトウェア開発事業」においてソフトウエア開発活動を分析（本データはこの書籍が刊行された当時に掲載されていたものです）
※書籍に掲載されている著者及び編者、訳者、監修者、イラストレーターなどの紹介情報です。
感想・レビュー
※以下の感想・レビューは、株式会社ブックウォーカーの提供する「読書メーター」によるものです。
kaida6213
18
日経SYSTEMSの記事まとめ本。設計書（要件定義書、基本設計書、機能設計書）のレビュ方法について、計画から実施するときの注意まで簡単にまとめられている。とはいえ、レビュ観点はどうしてもプロジェクトごとに依ってしまうので概念的な話が多い。 一番刺さった文言は、「設計レビュの目的は最終的な工数の削減である」。つまり、誤字脱字はもとより、製造工程やUTくらいで指摘すればすぐ直るようなものは、設計書レビュでは無視するということ。確かに効率は良いかも。保守するときに見にくいというのはあるがあとでまとめて直すのか。2015/08/02
Thinking_sketch_book
10
★★★★☆ 良い本です。ソフト開発向けですが、概要なので他にも考え方が使えます。『視点をしぼる』『カジュアル／フォーマルを使い分ける』は何にでも使えます。2013/12/08
yk
4
誤字脱字を無視しろと押してきますねｗ 意味としては理解できます。ここで出ているようなレビュー会議とかだと時間もったいないから。でもこんな時間かけれないから今はほとんど机上レビューというか依頼されたものを対面でなくレビューする形なので誤字脱字もな～。誤字脱字についてはそもそものドキュメントの品質を上げることで対応しないといけないのかもですね。あと観点を絞ってやるのは確かにいいですがその観点を何にするかが問題。コラム的なところに書いてあった局所的な問題しか検出できないお話はほんとにその通りだと思った。2018/02/02
きをふし
3
設計レビューとはいえ、基本的には「建設的なコミュニケーションの仕方」であって、会議とか議論の仕方に通じるところが多そう。2013/10/30
ショウヤ
2
レビューをする上での事前準備や心構えが参考になった。レビューする前に読みたい。レビュープロセスを作るときにも参考になりそう。レビューの目的は「コスト効果を最大にすること」であるということを意識しようと思う。2014/05/10
