【講演概要】要件定義書や設計書などのドキュメントレビューで、その手間に見合った効果を上げている現場は、決して多くありません。失敗レビューを続けている現場のほうが多いのが実情です。本講演では、「準備作業の時間切れ」「ドキュメント作成者のつるし上げ」「指摘問題数の数字合わせ」といった失敗レビューの典型を挙げ、それらを回避するレビューの進め方を解説します。具体的なレビュー技法として、基本的で実践しやすい「Defect-based reading」「 Perspective-based reading」の二つを取り上げます。レビューを担当するITエンジニアの方、レビュー会議の進行を務めるプロジェクトリーダーの方に、現場で役立つ実践的なノウハウを紹介します。
■ 9月16日（金）16:00-16:40 B会場
タイムテーブル・参加登録はこちら
講師へのインタビュー
システム開発における要件定義書や設計書などのドキュメントレビューに関して、ITエンジニアの問題意識が高まっているようです。
私も日頃の研究活動やセミナーを通じて、問題意識の高まりを感じています。感覚的な数字ですが、ドキュメントレビューをうまく実施している現場は、全体の3割ほどにすぎないと思います。大半の現場では、レビューに問題を抱えているのです。
具体的には、レビューに関してどんな問題が起こっているのでしょうか。
典型的な失敗レビューの代表例として、私が「思いつき」と呼んでいるものがあります。これは、レビューアーが自分の思いつくままに問題を指摘していく、というものです。思いつくままだと、誤字や脱字、表記揺れのような目に付きやすい軽微な問題がどんどん挙がります。そうなると、貴重なレビューの時間の多くが、軽微な問題の指摘に費やされてしまいます。レビューでは重大な問題をたくさん見つけるべきなのに、そのための時間が失われてしまうのです。これを避けるには、レビューアーの間でどんな問題を指摘するかというレビュー観点を定めておく必要があります。
ほかにも、レビューアーがよってたかってドキュメント作成者に対して人格攻撃をする「つるし上げ」、問題の指摘件数のノルマを達成することが目的になっている「数字合わせ」も、レビューの典型的な失敗例です。
どうして、そういった失敗レビューに陥ってしまうのでしょうか。
レビューの進め方についての基本が、開発の現場にあまり浸透していません。これが大きな原因の一つだと思います。実際、レビュー技法をしっかりと習得しているITエンジニアは少数派だと思います。
ITエンジニアが知っておく価値の高いレビュー技法にはどんなものがありますか。
「Defect-based reading」「Perspective-based reading」の二つがお薦めですね。どちらも基本的なレビュー技法です。
Defect-based readingは、検出すべき問題種別を事前に設定し、対象ドキュメントからその種別の問題を重点的に検出する、というものです。代表的な問題種別として、「漏れがある」「一貫性がない」「表現が曖昧」という三つがあります。
Perspective-based readingは、レビューアーにソフトウエア開発における役割を割り当て、それぞれの役割から問題がないかを確認していくものです。代表的な役割として、ユーザー、テストエンジニア、運用エンジニア、プログラマがあります。例えば運用エンジニアであれば、運用時に困ることはないかという観点で問題を検出します。
こうしたレビュー技法を知っておけば、重大な問題を検出しやすくなります。レビューには貴重な時間を費やすわけですから、ぜひセオリーを理解して効果を最大限に高めてほしいと思います。
タイムテーブル・参加登録はこちら
