　山浦恒央の“くみこみ”な話の連載第170回から、入門者をターゲットとして、「イチから全部作ってみよう」というシリーズを始めました。このシリーズでは、多岐にわたるソフトウェア開発の最初から最後まで、すなわち、要求仕様の定義、設計書の作成、コーディング、デバッグ、テスト、保守までの「開発フェーズ」の全プロセスを具体的に理解、経験することを目的にしています。

　なお、本シリーズ第1回目を読んでいない方は、以下のリンクから一読することをオススメします。

⇒連載「山浦恒央の“くみこみ”な話」バックナンバー

2．前回の振り返りと現状の位置

　前回記事では、要求仕様書をよりブラッシュアップするため、セルフチェックに関して取り上げました。自分は完璧だと思っても、見直してみると思わぬミスがあることが少なくありません。ぜひ、作成しただけで終わりとせずに、もう一度見直してみましょう。

3．要求仕様書フェーズの残り作業を確認する

　要求仕様フェーズの残りの作業を確認します（図1）。

図1　要求仕様フェーズの残りの工程［クリックで拡大］

（1）作成した要求仕様書をセルフチェックします。このチェックで、90％は正しい仕様書にブラッシュアップできます
（2）自身の納得のいく要求仕様が完成したら、他の開発者を交えてレビューを行います。このチェックで、自分の見落としや勘違いが見つかります。レビューが終了すると、開発会社内の合意ができた要求仕様書となります
（3）顧客と一緒に最終的な顧客レビューを行います。顧客には当たり前すぎて、仕様書に書いていなかった項目なのに、開発者全員が気が付かなかった重大なバグが見つかります。お互いの合意ができれば、要求仕様書の完成です

　上記が残りの要求仕様フェーズの作業になります。あとちょっとで完成ですね。今回は、図1で示した「開発者レビュー」「顧客レビュー」の作業を確認し、レビューの全体像を把握します。^※1）

※1）図1では、「開発者レビュー」「顧客レビュー」という2つの呼び方をしていますが、一般的にはどちらも「レビュー」と呼びます。今回は、自社のみのレビューと顧客も含んだレビューを分けたかったため、別々の用語としました。

4．レビューの作業内容

4.1 レビューの全体像

　まず、開発者レビューと顧客レビューの全体像を説明します。レビューとは、自分の成果物を他の人に確認してもらうことです。確認時に修正事項が出る場合は、その都度修正を行います（図2）。

図2　レビューのイメージ

　図2は、会議室でレビューを行っているイメージです。レビューでは、会議室に開発メンバーや顧客を集め、説明や質疑応答をしながら成果物の確認を行います。時間を効率よく使うため、出てきた質問、疑問、コメントに対し、その場できちんと回答したり、解決案を策定したりするのではなく、質問、疑問、コメントを「指摘事項」に記載するだけに留め、回答や解決案の策定は、レビュー終了後、時間をかけてまとめて取り組みましょう。

　レビューの実施方法はいろいろで、対面形式で格式高くやるタイプから、添付資料を回覧し、確認してもらう場合もあります。

　また、レビュー時に指摘事項がある場合は、指摘内容をExcelなどにまとめます（リスト1）。


No.	指摘事項	ステータス（Closed, Open）
1	たこ焼きの材料が途中で無くなった場合はどうするか書かれていない →ある条件下の異常処理が抜けているので、同件をチェックする	Open
2	学生向けに大きいタコを入れるという話だったが、大きさが小さい →当初のヒアリングの結果と異なっているので、同件をチェックする	Closed
リスト1　指摘事項