なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー（日経BP Next ICT選書）

投稿元：

レビューを見る

薄いし読みやすいので、入門書としてはとても良いものかと。
当たり前のこととも言えるけど、改めて実践できてるか振り返るいいきっかけになりました。
内容はマインドに寄ってるかな……レビューの戦術/戦法よりは戦略に近いかも。ボリュームの割に高いとは感じてしまったけれど、レビューに向き合ったことがないなら読んで損はないはず。

投稿元：

レビューを見る

「レビューあるある」と笑えない、時として耳が痛い内容。レビューアーは左手をこの本に置いてレビューをすると良いかも。

投稿元：

レビューを見る

正直、読むのが辛い本。
思い当たるところがあって耳がいたいのもあるし、IT業界は終電帰宅、休出が当たり前のような論調も嫌。

投稿元：

レビューを見る

レビュー時に気をつける事のまとめ。
概要＋コラムレベルの記載が多く、組織としてレビューの体系がある場合、記載内容は薄く感じるかもしれない。

研究者の本はどうしても内容の抽象度が高い傾向があり、理論としては綺麗なのだが、もう一歩踏み込んだ記載にして欲しかった。

例えば、レビュー実施単位(設計書一つ一つ？サブシステム単位？)、具体的なレビューシナリオなど、現場に即したケースでの説明があれば、説得力が増すのではないか。

設計レビューの流れをよく知らない人が、あるべき姿を学ぶ際には役立つかもしれない。

※本書とは関係ないが、プロジェクトとしてレビュー工数を軽視する風潮がある場合があり、それを改善する必要がある。

投稿元：

レビューを見る

研究者の本らしく実験結果が載っているのが面白い。
確かに、レビューにおいて誤字脱字のみ指摘してくる輩がいるのは困りもんだ。
事前に観点を絞り込んでレビューを進める、というのがベストなんだろうな。
でもそれがキレイに実践できるためには、レビュアー、レビュイ共にこの本を読んでないといけない。

しかし「表記に関する問題は無視する」は確かに有効かもしれないけど、やっぱりひどい文章を書くSEがいることも確か。
SEの選定基準に作文力を追加して欲しいと思う今日この頃。

投稿元：

レビューを見る

この本を読んで目から鱗が落ちるといったことはないでしょう。分かっているけれどできない、といったごく普通のことが書かれていると思います。また、いずれの職場でもそのまま適用できる、というわけでもないと思います。しかし、レビューに関する書籍だと抽象的な記述で結局どうすればよいかよく分からないという書籍がありがちですが、本書では具体的な心構え、記述がされておりレビューの実施方法について考える上で指針の一つとなるのではないかと思います。

投稿元：

レビューを見る

IT業界の設計レビューが題材なのだけど、藁をも掴む思いで読んでみた・・・が、観念的でやはり自分の業務にはあまり参考にならず。仕方ないか。

投稿元：

レビューを見る

設計レビューにおける進め方の概説と「べからず」的な内容。
設計レビューじゃなくても活用できるところは多々あると思う。レビュアーをうまくコントロールしなきゃ、という部分とかは特に。

投稿元：

レビューを見る

レビューによる誤り検出向上を目指す全ての人が対象となる本だと思う。個人的には、シナリオを用いたレビューというのが、新しい視点だった。シナリオの揃え方などが難しそうだが、従来のレビュー内容と照らし合わせて、自前でカスタマイズしていくしか道はなさそうと思った。

投稿元：

レビューを見る

レビューの心構えと手順が結果データとともに易しく書かれている本です。
こういうこと、ある・ある。こういう人、いる・いる。と膝を叩きながら読むことができます。

これといった新しいテクニックの紹介は少なく、オーソドックスな方法で攻めてきます（もちろん、それで必要十分なんだけど、博識の森崎先生のアンテナにひっかかった新技術の深掘りも読みたかったなー。

投稿元：

レビューを見る

⚪︎レビューの準備(リーダー、作成者)
・レビューポイントを最大で15個程度設定する。修正工数がかかる問題に注力する。他プロジェクトを参考にするボトムアップアプローチと、プロジェクト特性からのトップダウンアプローチがある。
・検証シナリオを作る。何を検出するためにドキュメントのどこをどのように見るのか。具体的に事前に決める。
・レビュー前の品質が悪いと、レビュー後にも最低基準の品質にならない。

⚪︎レビューの準備(レビューア)
・漏れ、曖昧さ、誤りの順で検出する。漏れはじっくり読むと気づかない。あらかじめめ、こういうことが書かれているべきと想定がないと検出できない。


・レビューのながれは
レビューの準備
問題の検出
問題の指摘
修正とフォロー
そもそも、机上レビューすることが大前提


・レビュー効果は、修正工数がかかるものに注力する。誤字脱字は指摘しないというルールだけでも効果あり。
・レビュー観点を
①定量的に絞り込む
②定性的に絞り込む
③絞り込まない
の順に効果(修正工数の高い問題を炙り出せる)が高い。
定量的とは過去のプロジェクトの実績を活用するということ。

投稿元：

レビューを見る

私の所属している組織では「ちょっと改まったウォークスルー」を頻繁に用いる。そのためウォークスルーの質を良くする方法を知りたかったが、この本に記載されていたのはほとんどテクニカルレビューについてであり、期待していたものとは違った。
しかしレビュー進行役、レビュアー、ドキュメント作成者が持つべきマインドはウォークスルーの場合にも共通するものが多い。また、記載されているテクニカルレビューの方法も応用すれば、私達が使っているウォークスルーにも適用できそうだ。
この本を参考にして、少しずつでもレビューの質を良くしていこうと思う。

投稿元：

レビューを見る

ITプロジェクトで一番苦労する
といっても過言ではない設計レビュー。

・有識者の時間が取れない
・時間が取れたとしても終わらない
・そもそも時間が確保出来ない
・途中脱線ばっかりして時間を浪費する
・致命的な問題を指摘出来ない

色んな問題が起きて、
後続で多くの問題が起きてしまいます。
レビューが大事なのにも関わらず、
時間が無いからと後回しにされる
＝レビューによる効果が分かっていない
というのが持論ではありますが、
それを可視化することの大切さや
そもそもどんな準備が必要かを書いていてくれて、
非常に分かりやすかったです。

メンバー全員の意識がこうなってくれるといいなあ
と思いつつ、読み進めてました。

【勉強になったこと】
・他のレビュアーが指摘した内容がきっかけとなり、
　新たに致命的な指摘が見つかることがある。
　これをファントムインスペクターという。
　一人ではなく、複数のメンバーでレビューを行うべき。

・レビュー前準備
　検出すべき問題種別の選定
　指針となるシナリオの作成
　簡易なレビューの実施検討（事前にやるかどうか）
　レビュアーの選定と割り当て
　ドキュメント配布と告知

・指摘の順番
　まずは漏れがないか？
　曖昧な内容がないか？
　誤りは無いか？

・主な曖昧語
　など、これら、それら、処理する、対応する、
　〜を考慮して、〜を踏まえて、〜に基づいて、
　通常は、基本的には、できる限り、可能な限り、
　十分な、余裕をもって、すぐに、ただちに、
　現在の、最新の、現状通り

・レビュアーの経験による指摘傾向
　ベテラン：利用部門を意識した問題
　中堅：例外処理や異常系の処理
　若手：正常系の処理

・レビュー技法の分類
　マネジメントレビュー
　　経営層や管理職が、プロジェクトの状況把握や
　　承認のために実施する
　オーディット
　　法令や社内規則、開発標準に従っているかどうかを
　　調べる
　ピアレビュー
　　ドキュメントなどに含まれる問題の検出・指摘および
　　関係者間の意識合わせを行う
　　・ウォークスルー
　　　ドキュメント作成者が主役となって実施する
　　　自由度の高い相談会
　　・テクニカルレビュー
　　　技術リーダーが主導するドキュメントチェック
　　・インスペクション
　　　あらかじめ定めたルールに従うドキュメントチェック

投稿元：

レビューを見る

設計書のテクニカルレビューにおけるプロセスとマインドについて、陥りがちな問題と解決のポイントが示されています。

それらの問題は、筆者のITベンダーでの経験やレビューの研究者として多くの企業を見てきた経験を踏まえていると思われ、私もうなずけるところが多かったです。また、巻末の付録には幾つかの検証事例が載っており、これも直観に合致する結果でした。

レビューについて苦い経験を持つ方であるほど、本書から得られる知見は大きいことでしょう。また、本書は特に前提知識を必要とせず、少ない時間で読むことができます。平易な記述が多いですが、レビューがチームで行う活動であり、本書にはベテランが陥りがちな問題も記載されているので、ベテランかルーキーに関わらず読む価値があると思います。チームメンバー全員が本書の要点だけでも理解すれば、レビューの効果と効率が劇的に変わるのではないか、と感じさせられる内容でした。