設計レビュー本をFindyさんに頂いたので読む。

1章

1-1 レビューの目的の間違い

• 思いつき/数字あわせ/つるしあげ
• レビューの目的は、早期問題の発見による修正工数の低減

1-2 問題検出の間違い

• 人間関係の持ち込み
  • 確かに、Aさんは◯◯、Bさんは△△だからレビューは手加減しようみたいなの、人によってはおこりえそう
• 作成者気分 → 全部レビュワーが作り直すこと
• 二兎追い → 一気に複数の観点でレビューしないこと
• 時間切れ

問題検出は、観点を絞って複数回見るのがいいらしい！
PRやドキュメントを見るときも、

1-3 喧嘩

喧嘩の話だった。HRTな精神持っている会社であればおこりえない内容だったので、割愛

1-4 無駄な指摘

• 意図的に見逃すことをしない → スケジュールを勘案すると発生しがちらしい

2章 準備と問題検出

レビューは業務でしていれば身につくと言ったものではない

• テクニカルレビュー
  • 技術リーダーが主導するドキュメントチェック。ITの現場で行われている一般的なレビュー方法
• ウォークスルーレビュー
  • ドキュメント作成者が主役となって実施する自由度の高い相談会

実際のシナリオベースの紹介が多かった。

ドキュメント作成で根本から覆りそうな設計面は、ウォークスルーレビューを使って方向修正するのがよし。

2-2 漏れ、曖昧、誤り シナリオの順番で効率上がる

• シナリオの順番決め
  • テスト項目も優先順位順に順序を決める
• 曖昧な言葉や定義を使わない
  • これら、それら、処理する、対応する 等
• チェックする箇所を絞る
  • PRもドキュメントも、コアとなる箇所を絞るとよき。

2-3 問題検出の手順

• 問題検出時は、あくまで検出するだけにとどめておく。どう修正するかまで考えると検出効率が下がる。

3章 レビュー会議の進め方

3-1 問題指摘の手順(前半) 周到に用意すればレビュー会議は円滑に進む

• 指摘される問題の想定
  • 完了基準を作る
• 会議の計画設定
• 問題記録表の収集と確認
• 会議室の用意
• 会議の開始宣言

進行役であるリーダーの用意がレビュー会議の成否のカギを握る。

3-2 問題指摘の手順(後半) 時間内に問題を検出し切るレビュー会議の進行方法

• 指摘された問題の共通理解
• 類似の重大な問題の検出
• 脱線の軌道修正
• シナリオ完了の確認
• 会議のクロージング

3-3 問題の修正 フォロー 作成者をフォローし、確実にドキュメントを修正

• 問題理解と順序決め

• 修正とセルフチェック

• レビュワーによる確認

• リーダーによる最終確認

• 問題の再発防止

3-4 レビュー技法 万能なやり方は存在しない 三つの技法を使い分ける

• マネジメントレビュー
• オーディット
• ピアレビュー
  • ウォークスルー
  • テクニカルレビュー
  • インスペクション

4章 さらなる効果向上

• 後工程で見つかった不具合の洗い出し
  • 見逃し問題リストを作る。
    • 特定のユースケースや考慮漏れ
    • システム構成と仕様の不具合
    • リソース競合の検討もれなど

4-2 問題種別の設定対象を広げる

• 機能間で共通の基準がない
• テスト環境を準備しにくい構成
• 不具合の切り分けが難しい構成
• 既存システムから移行しにくい
• 拡張しにくい構成
• 運用上の問題を考慮していない
• セキュリティーの問題を解決できない
• リリース遅延のリスクに備えていない
• 要素技術のリスクにそなえていない
• 要求を実現できないリスクに備えていない

4-3 保守開発、クラウド開発への応用

省略