サイドバー
システム開発:設計レビュー
設計レビュー
進行テンプレート
- レビューの目的等の確認、準備
- 目的は手戻り工数の削減（品質自体は試験で担保できるが高コスト）
- 頑張ったことを説明する場ではなく、不具合になりそうなところに集中
- あらを探す場ではなく、同上
- 上記より誤字脱字等その場での指摘が効果的でないものは後でまとめて伝えること
- レビュー対象物に対する指摘であって、作成者を批判するものではない
- 「レビュー」は基本進行順に従って行い、途中で問題ある場合は中止する
- 「レビュー」中に「相談会」を行わない（中断後の時間の利用は可）
- 「問題点の検出」と「対策の検討」は分けて行う（対策が明確な場合は除く）
- 説明と進行を一緒にやるのが難しい場合は進行者を別途設ける
- 概要説明
- なぜ、何のための対応なのか？
- どのように実現するつもりなのか？
- データモデル・DB設計の説明
- 正規化できているか、多重度の認識違いはないか
- 整合性は保てているか
- 既存の制約に反しないか
- 新たな制約を設けなくてよいか
- 値はnullになり得るか？
- 値は一意か？
- カラムサイズは妥当か
- （画面の場合）画面デザイン、コントローラー（パーツ）の説明
- 違和感がないUIとなっているか？
- 利用者が分かる表記になっているか？
- 制約があるか？
- どういったイベントがあるか
- （APIの場合）リクエストパラメータとレスポンスの説明
- クライアント側と認識があっているか？
- 必須なものは何か？
- nullや例外、エラーを返すことがあるか？
- イベントやAPIの処理概要の説明
- 何をしたいのか？
- 要はなにをするのか？
- 処理詳細の説明
- 細かい条件は？
- どのようなSQLを発行するか？
よくある問題
- レビュー時間が長い
- 喧嘩になる
- 脱線する
- 重箱の隅をつついている
- 不具合を見つけたけど指摘しない
- 説明したいことと説明してほしいことが食い違っている
そもそもなぜレビューするのか？
- ×：完璧な設計書を作るため
- 些細な誤字脱字も全くない完璧な設計書・仕様書を作りあげる
- もしそのドキュメントが納品物であるなら、確かに完璧なものが必要かもしれない
- しかし、それは「設計段階」で必要なものなのか？
- 納品前に体裁を整えれば良いだけでは？
- もし完璧な設計書があったとしても肝心なプログラムがなければ、要望を何も満たすことができない
- ○：手戻りコスト削減のため
- ウォーターフォールでもアジャイルでも（1回で終わらせるか、小さく繰り返すかの違いはあるが）設計→製造→試験という流れで開発は進む
- この時、試験の段階で不具合が見つかると、試験→修正→試験と作業が必要になる
- 場合によっては設計から直す必要もあり大変
- もし、設計の段階で不具合を見つけることができれば修正や再試験の工数を節約することができる
- 多くの場合、設計段階での修正の方が試験段階（ときには製造段階）での修正よりはコストが低い
ではどうすればいいのか？
- 目的が手戻りコスト削減なので、期待できる削減コストをレビューのコストが超えないというのが判断の基準
- 誤字脱字の指摘の場合、ものにもよりますがテスト段階で見つかったとしても大した修正コストではなさそう
- 誤字脱字を指摘するなというわけでなく、レビューの時間を使って一生懸命誤字脱字を探したり、その指摘のために都度レビューが中断することが無駄
- そうやって時間を割いていると、レビューのコストが修正コストより高くなってしまう
- 誤字脱字程度であれば、気づいたらメモして後で渡してあげれば済むはず
- そうすれば本来集中すべきところに集中しやすくなる
- 不具合の起きやすい部分、過去に不具合を起こしたパターンの確認
- はじめての開発の場合は難しいかもしれないが、システム開発をしていると比較的不具合を起こしやすいところ（DB、ファイル操作、通信、特殊なロジックを組んでいる部分などなど）と比較的安定しているところ（決まりきった作り方があり、過去にも実績がある部分など）が出てくる
- 安定しているところを見なくて良いわけではないが、限られた時間で確認するのであればより不具合を起こしやすい部分（できればその中でも修正するのが大変そうな部分）から問題ないかを確認していくのが効率的
- そうしておけば、仮にレビューが時間切れになったとしても、残っている問題は些細なものの可能性が高くなる
- そうではなく、見つけやすそうなものから見つけていていると重大なものを見逃す可能性がある
- 特に過去の開発で設計段階をすり抜けて試験段階で苦労したものについては、それをフィードバックして設計段階で見つけれるように工夫した方がよい
これを行うためには？
- 全員がレビューの目的を理解している必要がある
- その上で冷静に指摘できる環境（先輩だから控えようとか、嫌いだから厳しく行こうとかやらない）と
- 指摘を冷静に受け止めれる環境（指摘されているのはドキュメントであって作成者自身ではないことを理解）が必要
- どこが重点的に見るべきところで、どこがそうではないのかはチームや開発しているものによって異なってくので、修正しながらやっていく必要がある
その他
- レビューの品質を上げるために専門家（詳しい人）に見てもらう
- 業務寄りの人
- セキュリティ詳しい人
- DB設計得意な人
- UI、UX専門家
- 単純に依頼すると目に付くところに指摘が集中しがちなため「専門的な部分のみ」に集中してみてもらう方法もある
システム開発/設計レビュー.txt · 最終更新: 2019/10/22 15:24 by y-kurose
特に明示されていない限り、本Wikiの内容は次のライセンスに従います： CC Attribution-Noncommercial 4.0 International
