ソフトウェア レビュー 手法を学ぶ 研修コースに参加してみた

今回参加したコースは ソフトウェア レビュー 手法を学ぶ です。
レビューと言うと、皆さんはどのようなものを思い浮かべられますか?
最近はすっかり GitHub などが普及し、コードレビューを真っ先に思い浮かべられるかも知れません。今回のコースは、コードではなく、それより前の工程にある仕様や設計など、ドキュメントを中心としたレビューです。
アジャイル開発でも、現在は「正しくつくる」に加えて、「正しいものを」正しくつくることが求められるようになり、より仕様や要求へのレビューが行われるようになっています。
そのレビューでで使われる手法は様々あり、そのメリット / デメリットを学び、最終的には各工程でアウトプットされるドキュメントにあわせて何を適用させるのか、わかるようになりました。
では、どのような内容だったのか、レポートします!
もくじ
コース情報
想定している受講者 | システム開発経験者 |
---|---|
受講目標 |
|
講師紹介
品質やテストと言うと、多くのコースに登壇いただいてるのがクロノスさんです。今日は 藤丸 卓也 さんです。

label藤丸さんの過去の登壇

今日の内容
講師紹介とともに今日のやることを紹介いただきました。

この中で、前提となるレビューをやる方にまず触れました。
- 人事評価者が入るのは NG (ルール化されている)
- できるだけ若手のときから入るとよいです
確かに、レビューで評価が入ってしまうと、怖がったり敬遠しますね。
またレビューはリードエンジニアぐらいの方がやるように思われがちですが、いろいろな手法があるので、若手からどんどん参加しましょう、とのことでした。
テストとレビューの違い
- ソフトウェアテスト
- バグを発見すること
- バグが存在しないことを証明はできない (バグ 0 はできない)
- バグが見つからない、というときは、だいたいテスト設計が悪い
- レビュー
- コードだけでなく、ドキュメントもレビューが必要
冒頭にもある通り、今日はこのドキュメントのレビューです。
レビューを妨げる壁
- 納期に間に合わせようとするとレビューなどが簡略化されがち
- 品質に基準がないことが多く、品質が犠牲になりがち
- 仕様変更が多いので、レビューしない
- テストの方がよいと思われがち
- 一方で、上流工程の欠陥は下流工程で工数を増加させる
- IBM の調査では総欠陥数の 45 % ~ 80 % の欠陥が上流工程に起因する
テストの方がよい?
先程挙がった、レビューするより、テストの方がよい、とすることの問題点を深堀りします。


- ソフトウェアテストでは発見が遅くなる
- 発見したときには上流工程の担当者がいないことが多い
- レビューを各工程で行うことで発見が早くなる
レビューで遅くなる?
また、レビューをやらない理由として、遅くなってしまう、という言説もあります。
- そもそもレビューの工数を WBS の中に入れておらず、追加すると遅くなる
- レビューを工数に入れると、今度はその効果が見えにくい
- レビューは「予防」なので、未来の下流の炎上は見積もれない
- レビューをやらない結果
確かに、仕様をもとに、いざ開発しようとすると、漏れや不整合が発生しがちですよね(わたしの経験談)。。仕様を書いてる人も気づきにくいんです(言い訳)。
レビューとは
ここまでレビューが行われていない現状を解説きましたが、ここからはいよいよ、レビューのやり方に触れるのかと思いきや、、、似非レビューをもとに、必要な原則に気づくグループ演習を 2 つ行いました。


Zoom のブレイクアウトルームを使って、各グループでこの絵から問題点を洗い出しましたが、講義やプレゼンになっている、議事録をとってない、なにか討論になってしまっている(恐らく解決方法でも揉めている)など、様々に挙がりました。
ここで藤丸さんから、レビューについて、そもそものところから解説いただきました。
- レビューとは各工程で 曖昧なこと、問題点を洗い出すこと
- プレゼンや説明ではない(説得ではない)
- 解決策は考えない
- レビューは大きく分けると 2 つの種類がある
- 今回はピアレビューが中心
なるほど、問題が見つかると、解決策まで踏み込みがちで、ただでさえレビューに工数がかかると言われるので、目的を絞るのはとっても合理的ですね。
レビュー手法
ここから、レビューの手法の解説です。
作業成果物レビュー(ピアレビュー)には、以下の種類があります。下に行くほどカッチリとしたものになります。
- アドホックレビュー
- ペアレビュー
- パスアラウンド
- ウォークスルー
- インスペクション
では、それぞれの手法を見ていきましょう
アドホックレビュー
- やり方
- ちょっとデスクに立ち寄ったときにレビューしてもらう(軽いノリに近い)
- 非公式なレビュー
- かんたんにできる
- 注意点
- 優秀な人、親切な人に集中しやすい
- タスク化が困難
ペアレビュー
- やり方
- レビュイーとレビュアーがペアを組んで行う
- シニアレベルとジュニアレベル or 同じレベル同士
- 比較的低コスト
- レビュイーとレビュアーがペアを組んで行う
- 注意点
- レビュアーの知識・経験に依存してしまう
- セキュリティだけに詳しいなど
- チェックリストを入れると良いでしょう
- レビュアーの知識・経験に依存してしまう
パスアラウンド
- やり方
- 成果物を回覧・配布・掲示板でレビューする
- ミーティングは実施しない
- 招集コストが少ない
- 遠隔地含め、多人数からレビューをもらえる
- 成果物を回覧・配布・掲示板でレビューする
- 注意点
- 多人数のため、レビュアーが積極的でなくなる
- フィードバックが重複する
- フィードバックが矛盾し、解決コストがかかる
ウォークスルー
- ピアレビューというと、ウォークスルーを指すこともある
- やり方
- レビュイーが成果物を説明する
- 事前に資料は配布する
- レビュイーのプレゼンで欠陥が見過ごされる可能性がある
- レビュイーの批判をしない
- 欠陥の修正はしない
インスペクション
- やり方
- 第三者がチェックリストをもとにレビューする
- もっとも公式なレビュー
- レビュイーは何もせず、第三者がプレゼンする
- 参加者の役割を明確にする
- 注意点
- 時間とコストがかかる ( 15 % 工数が増加する)
- 82 % のエラーが見つかる ( Michael E. Fagan [IBM] の論文)
- エラーが発生しやすいところでやるとよい
- 時間とコストがかかる ( 15 % 工数が増加する)
最適なレビュー手法を考える演習
先程解説いただいたレビュー手法をもとに、各工程の成果物はどの手法でやるべきか、演習しました。

藤丸さんからその考えるポイントと解答例を紹介いただきました。
- 前半の上流工程に力を入れる
- 欠陥があると、影響が大きいものに力を入れる
- リスクの高い重要なドキュメントに力を入れる
解答例はこちらarrow_drop_down

リーディング技法
ここまで演習してきたレビュー技法でも問題点があり、それをさらに改善できる、新しい手法も紹介いただきました。
- これまでのレビュー技法では罰のようになってしまう可能性がある
- 結果、隠す、非公式に直す、などの結果を引き起こしてしまう
- 合わせて使うと効果を発揮するのが、リーディング技法
- 名古屋大 情報学研究科 森崎 修司 准教授が提唱
- “「何を重視してチェックするか」という目的を決めたら、その範囲内で、できる限りさまざまな視点からチェックすることが大切”
- ドキュメントの種類によって手法が変わる
- パースペクティブ・ベースド・リーディング
- ユーザが使うドキュメントのレビュー
- 基本設計以前のレビュー
- ディフェクト・ベースド・リーディング
- 開発者が使うドキュメントのレビュー
- 詳細設計以降のレビュー
- パースペクティブ・ベースド・リーディング
ディフェクト・ベースド・リーディング
- 複数のエラーシナリオを用意
- ex. 一貫性の欠如、機能上の誤り、曖昧さ、機能の不足などのエラーのタイプごとに作成
- 1 シナリオにつき、担当者 1 人で行う
- 抜け漏れダブリを防ぐことができる
- 他プロジェクトや製品でも流用しやすい
- シナリオの出来次第でレビュー結果が変わる
- 徐々に成長させるという観点が必要
- シナリオを用意するのにコスト (時間含む) がかかる
パースペクティブ・ベースド・リーディング
- 異なる立場でチェックする
- admin なのか、 user なのか、 未 login なのか
- 多様な視点のチェックで抜け漏れダブリを防ぐ
- 立場に慣れていない方がレビューすると漏れる可能性がある
- 流用が難しい
リーディング技法の演習
最後に、習ったばかりのリーディング技法を使って、実際に演習してみます。

先程の似非レビューの絵の演習と同様にグループに分かれて、予め用意された、以下のドキュメントをもとにレビューします。
- 画面遷移図
- 画面レイアウト
- 画面項目定義
- 入力チェック仕様
- テーブル定義
- 単体テスト仕様書(レビュー対象)
- 観点(チェックシート)
この演習が終わったところで、コースは修了しました。
まとめ
以前、テストのコースで紹介されてから、いかに上流で欠陥やバグが見つけるのか、レビューの手法が気になっていたのですが、ようやく学べました!

また、リーディング技法の「視点を変える」というのは、とっても秀逸で、実際、受け入れテストのときにやってみましたが、効率的に、また今まで見落としがちだったエラーがたくさん見つかりました。
ただ、レビューも、やはり銀の弾丸ではなく、工数がかかります。そうなると、現場で導入させるのが難しそうに感じました。セキュリティのように予防コストをどれだけ理解してもらえるかが鍵になりそうです(となると、アドホックレビューやペアレビューで試してみてみるのも手なのかも知れません)。
なので、プロジェクトの手戻りや炎上で困っている方は、ぜひぜひこのコースを受講して、レビューの効果を説明 → 導入しましょう!

SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。