イチから全部作ってみよう（16）レビューは要求仕様書完成に向けた最後の関門：山浦恒央の“くみこみ”な話（185）（2/2 ページ）

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

4.2 開発者レビュー

　開発者レビューとは、自社内のエンジニアが開発者目線でレビューを実施し、要求仕様書を完成してよいか判断します。形式はいろいろありますが、隣のエンジニアに「ねえねえ、ちょっと見て」という軽い感じか、部長を交えた格式高いレビューを実施するなんてこともあるでしょう。主な指摘事項をリスト2に示します。

No.	レビュー例
1	社内フォーマットに合わせて要求仕様書が書かれていない
2	仕様書に曖昧な箇所がある
3	顧客からヒアリングした内容と仕様記述が合致していない
4	ある条件下の異常処理が抜けている
5	今の仕様記述をより簡単に実現する方法がある
リスト2　開発者レビューの例

　リスト2の例の通り、あくまでも開発者目線から、ソフトウェアとしての良しあしを判断します。ただし、顧客の要求を正しく理解できているかは、厳密にレビューできません。ここが開発者レビューの限界です。

4.3 顧客レビュー

　顧客レビューでは、顧客も交えて要求仕様書のレビューを実施し、要求仕様書を完成としてよいか判断します。主な指摘事項がリスト3です。

No.	レビュー例
1	顧客側が想定していた意図と異なる仕様記述となっている
2	仕様書に曖昧な箇所がある
3	工数がかかるので取り下げたい
4	ここは必須なので、大変でもお願いしたい
リスト3　顧客レビューの例

　リスト3にある通り、ソフトウェアの技術的な話というよりは、顧客の運用をイメージした指摘が多くなります。特に、顧客のイメージとのすり合わせを多く行うでしょう。これが完了できれば、要求仕様書の完成です。

5．おわりに

　今回は、レビューの全体像について説明しました。レビューとは、成果物を確認する作業で、開発者視点と顧客視点の両面を確認し、要求仕様書を完成させます。

　開発者レビューでは、他のエンジニアにレビューを依頼し、ソフトウェアの観点から要求仕様書をチェックします。一方、顧客レビューでは、顧客の運用イメージも踏まえて意図した要求仕様書となっているか確認します。また、顧客レビューが完了すると、要求仕様が完成し、要求仕様フェーズが完了です。長かったですね。

　要求仕様フェーズは、学校の授業でもなかなか取り上げづらいところです。本シリーズをきっかけに、ソフトウェア開発がどのような手順で進んでいくかのイメージができれば幸いです。

山浦先生執筆の書籍が販売中です！

　本連載で取り上げた「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の書籍「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から好評発売中です。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しています。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。

　前著「ソフトウェア技術者のためのバグ検出ドリル」（2019年11月刊行）も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。

画像クリックで出版社のWebサイトへ

　両書とも興味のある方は、Amazon.comや書店でチェックしてください！

【 筆者紹介 】

山浦 恒央（やまうら つねお）

東海大学 大学院 組込み技術研究科 非常勤講師（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科准教授、2016年より非常勤講師。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。