イチから全部作ってみよう（17）レビューは記録することで効率的に実施できる：山浦恒央の“くみこみ”な話（186）（2/2 ページ）

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第17回は、レビュー工程を効率的に進めるためのレビュー記録の方法を紹介する。

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

5．レビュー記録の書き方

　レビュー記録の指摘分類は、大きく分けて「要望」「不具合」「指摘ミス」「コメント」の4つです。下記に例題を交えて説明します。

5.1 要望

　新しい改善提案や追加要望がある場合には、「要望」として記載します（表2）。

NO.	指摘事項	質問者	指摘分類	日時	修正内容	Open／Closed （修正済みかどうか）
1	学生がターゲットなので、大きいタコにできないか	鈴木	要望	1/10	予算の都合上、難しいため今回はこのサイズで進めさせていただきます	Closed
2	ソースにマヨネーズも選択できるようにならないか	田中	要望	1/28	マヨネーズも追加します。	Open
表2　要望の例

　表2に示す通り、タコの大きさやソースの種類の追加などの要望を記述します。要望は、製品をより魅力的にする反面、担当者の負担増大につながります。気付いたら、予算と期間も増えないまま、要求が2倍以上に膨れ上がる可能性があります。「同じ予算で2倍の機能を実装する」ことは、「要求仕様を実現するための予算が、必要な予算の半分しかない」というデスマーチプロジェクトに他なりません。プロジェクトマネジャーの重要な仕事は、際限なく増える「顧客からの機能要求」をはねつけることです。要望を受けた場合、以下のように対処をするとよいでしょう。

• 要望事項への対処法：
  1. その場で要望を受け入れず、自社に持ち帰って検討する
  2. 現行のバージョンでは受けずに、次バージョン対応とする
  3. その要望を受ける代わりに、同程度の開発コストがかかる別機能を削除する
  4. 追加予算と期間延長を受け入れてくれる場合は、対応可能か検討する

5.2 不具合（バグ）

　不具合は、バグや誤字脱字などがある場合に記載します（表3）。

NO.	指摘事項	質問者	指摘分類	日時	修正内容	Open／Closed （修正済みかどうか）
1	たこ焼きの材料が途中で無くなった場合はどうするか書かれていない	山田	不具合	1/27	足りない材料を買いに行き、入手できない場合は閉店とするよう追記する	Open
2	ページ5に誤字脱字がある	金元	不具合	1/30	修正します	Closed
表3　不具合の例

　表3に示す通り、例えば、「あるべき要求がない」「異常ケースが記載されていない」「条件が間違っている」「誤字脱字がある」というものは、不具合に該当します。対処法は、指摘箇所を修正することはもちろんですが、下記の視点にも注意しましょう。

• 指摘の対処法：
  1. 変更することで波及する新たな不具合はないか
  2. 類似する不具合がないか再チェックする
  3. クリティカルな不具合の場合は、再発防止策を検討する（担当者への聞き取りなど）

5.3 指摘ミス

　既に検討済みだったり、本人の勘違いだったりという場合は、「指摘ミス（あるいは「仕様通り」）」として記載します（表4）。

NO.	指摘事項	質問者	指摘分類	日時	修正内容	Open／Closed （修正済みかどうか）
1	停電の時は記述されていないが、どうするか？	山田	指摘ミス	1/27	ガスボンベを使用するため、電気は必要ありません	Closed
表4　指摘ミスの例

　例えば、「停電の時はたこ焼きが焼けないはず」と指摘があったとします。しかし、「たこ焼きはガスボンベなので、電気はいらない」という場合は、指摘自体が間違っていることになります。この場合は、指摘ミスとして取り扱います。

5.4 コメント

　単なる感想や全体の総括がある場合は、「コメント」として記載します（表5）。

NO.	指摘事項	質問者	指摘分類	日時	修正内容	Open／Closed （修正済みかどうか）
1	たこ焼きのレシピがよくまとまっているため、この方向性で進めてほしい	山田	コメント	1/27	なし	Open
2	要求仕様書として問題ないとして、次のフェーズへ進めること	鈴木	コメント	1/27	なし	Closed
表5 コメントの例

　表5に示す通り、顧客の感想や全体の総括を記述するケースです。システムに対し、顧客がよい印象を持っているか、いないかがよく分かります。「次のフェーズに進めてよい」という話も、レビュー記録として入れておきましょう。

6．おわりに

　今回は、レビュー工程をトピックとして、レビュー記録の書き方とその重要性に関して説明しました。レビュー記録を作成することで、指摘事項と修正内容が明確になり、効率の良いレビューが実施できます。面倒だとは思わず、ぜひ作成しましょう。

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

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

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

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

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

【 筆者紹介 】

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

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

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

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