開発工数を削減するレビューのやり方

レビューとは？

・要件定義書
・設計書
・ソースコード
などシステム開発の成果物に対して妥当性を検証する作業
ウォータフォール開発において要件定義や外部設計等の各工程毎に実施し、
各工程でのミスの結果として、次の工程で無駄な作業を削減する為に行われる。
設計書にミスをそのまま実装した場合、
(1)設計書修正
(2)コード修正
(3)再テスト(単体・結合…)
の作業が再度必要になり、
適切にレビューを行えばテストの工数も大幅に減らす事ができる。
レビュー形式としてインスペクションとウオークスルーがある。

レビュー形式

インスペクション

第三者が参加する会議形式の検証
検証結果も成果物として定義されている契約が多い。
一般的にレビューと言ったらこちらを指す。

ウオークスルー

開発者が自発的に行う検証。
ソースコードに対するビューはこの形式を取る事が多い。

レビュー方法

レビューの問題点

・時間切れ(レビュー対象の偏り、漏れ、誤り)
・人格攻撃(レビューで何を問題とするのか？が決まってない)
・句読点不足等のミス(優先順位低)

何をレビューするか？

レビュー前にレビュー対象について合意を得ておく
(レビューしない対象についても合意を得る)
一般的にはレビューチェックリストを作成し、
これに基づいてレビューを行う。
これにより効率的にレビューを行える。
ただしあくまでレビューチェックリストの項目をレビューしただけで、
これが効率的なソフトウェアの開発に繋がるかどうかはチェックリストの出来次第。
近年、レビューシナリオを作成するという考えが生まれている。

レビューチェックリスト

設計書チェックリスト例
(1)仕様書の要求事項との追跡性が確保されているか
(2)設計手法やフレームワークは、明確か
(3)アーキテクチャが論理的に説明できるか
(4)複数選択肢を検討のうえ、妥当な決定を行っているか
(5)設計上持ち込まれた制約事項などを確認したか
(6)データ項目のけた数、属性、識別キーなどを確認したか
(7)障害対策やバックアップ機能を確認したか
(8)エンドユーザーにとっての使い勝手への配慮があるか
一般的な観点を網羅できる
曖昧な判定になりがち
一種のテンプレートがあるがプロジェクトによって過不足が発生する。

レビューシナリオ

レビューを開始する前の道筋。
・何に対して検証するか？(対象)
・欠陥を見つけるための判断基準は？(確認方法・判定基準)
・何から検証を行うか？(優先順位)
例
全国のコンビニ店舗から売上データを23:00までに集計し、
翌3:00までに出荷する商品の解析データを作成する。
というシステムに対し、

無作為なレビューの場合
・通信障害が起こったらどうするのか？
・集計が指定時間までに終わらなかったらどうなるのか？

レビューシナリオを作成した場合
・各拠点からＤＢまでの通信経路に対し(対象)、
・集計データが完全に集まらないパターンについて対策が練られているか？を検証する(判定基準)、
・パターン検証は障害の深刻度が高い順に行う(優先順位)

シナリオの作成方法1

問題種別と検出方法の設定
漏れ、曖昧さ、誤りが無いか？
漏れレビュー前に必要項目をイメージしておく。
曖昧常識を定義した上で、その基準で不足は無いか？
誤り不整合を修正
役割による観点設定
テスター観点で設計書通りにテストできるか？
オペレーター観点で使用できるか？
発注者観点でお金を出せるか？

シナリオの作成方法2

トップダウン
最低限必要な機能から順にシナリオを作る
例システム停止しない
計画停止のタイミングは適切か？
冗長化されているか
問題発生時に被害を他システムに影響しないか？
例ファイル読み込み
ファイル容量の上限
ファイルサイズと時間の関係を明確化しておく
ファイル読み込みが他処理に影響する
※これらを実装前に定義しておく。
それをレビュー時点で定量的に判定できる様にシナリオを作る(イメージしておく)

ボトムアップ
過去の欠陥情報を優先順位高としてシナリオに盛り込む

結論

システムの「価値」を考え、そこからレビューシナリオを作ると、
レビュアーの観点が揃う＝合意が得られやすい。
結果、優先順位高の観点を網羅した質の高いレビューが行える。

補足

・レビュー対象に濃淡を付ける
・レビューは個人でやり、集まってその結果を確認する。網羅できているか？
・「24時間365日サービスが継続する事」等、曖昧な仕様に対しては、
松竹梅のサービスと対応を考えておく