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

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

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

2．前回の振り返り

　前回は、作成した成果物をチェックするレビュー工程の概要を説明しました。

　レビューでは、作成者以外が成果物を確認するので、自身では気づかなかった問題点がたくさん見つかります。また、レビューをした時に誰かが何かを指摘すると、それをレビュー記録に記載し、修正完了となるまでレビューを繰り返します。指摘事項の対策に時間がかかり、「一生終わらないのではないか」と挫折しかけることもありますが、これを乗り越えなければ要求仕様書は完成しません。製品としてマーケットにリリース後に修正するのか、仕様書の定義段階という初期に修正するのか。どちらが簡単で低コストか、考えるまでもありません。レビューで見つかった問題点や課題は、直ちに対策しましょう。

3．レビュー工程の作業フロー

　レビュー工程に着目した作業フローを図1に示します。

図1　レビュー工程の作業フロー

　図1は、下記の作業を指摘がなくなるまで繰り返すことを表した図です。

（1）要求仕様書作成＆セルフチェック

　要求仕様書を作成し、文書がレビューに耐え得る品質になるまでセルフチェックを行います。

（2）レビュー

　開発メンバーや顧客とレビューを実施し、要求仕様書を客観的に評価します。

（3）レビュー記録に記載

　レビュー時に指摘事項がある場合は、レビュー記録に記載します。

※写真はイメージです

　上記の通り、要求仕様書の完成は、レビューの指摘事項がなくなるまで終わりません（そうでない文書もありますが）。そのため、レビュー記録をきっちり作成し、効率良くレビューと修正の繰り返しを回す必要があります。

　もちろん、レビュー記録を書かずに、記憶を頼りに修正してもよいでしょうが、修正内容が曖昧となり、結果、「記憶が曖昧で修正不十分となる」「同じ箇所を何度もレビューする」といった非効率なレビューとなりかねません^※1）。そこで、今回は、レビュー記録の書き方と指摘事項の対処法について取り上げます。

※1）副次的な話として、レビュー記録は、レビュー実施の証拠としても使用できますので、社内の監査などでも役に立ちます。

4．レビュー記録とその重要性

　レビュー記録とは、レビュー時にレビュー担当者が気になった箇所をまとめた文書です（表1）。


NO.	指摘事項	質問者	指摘分類	日時	修正内容	Open／Closed （修正済みかどうか）
1	たこ焼きの材料が途中で無くなった場合はどうするか書かれていない	山田	不具合	1/27	材料の在庫が残り3分の1となった段階で買いに行き、入手できない場合は閉店とするよう追記します	Open
2	学生がターゲットなので、大きいタコに変更できないか	鈴木	要望	1/10	予算の都合上、大きくすることは難しいので、今回はこのサイズで進めます	Closed
表1　レビュー記録

　表1は、レビュー記録の例題です。ここには、指摘事項、質問者、日時、修正内容、Open／Closedを記述します。

　「Open／Closed」とは、指摘の修正状態のことです。Openは未修正、Closedが修正済みを表します。直感的には、「Open／Close」と書くように見えますが、これは命令形の「開け！　閉めろ！」となりますので、形容詞（過去分詞）を表す「Open／Closed」と書きます。なお、「済／未」と書いてもかまいません。

　レビュー記録を記述する最大のメリットは、指摘事項に対する修正方針が明確になることです。残念ながら、次の日になると、「鈴木さんはなんて言ってたっけ」というように記憶が曖昧になります。しっかり記録し、修正完了（Closed）となるまでトレースしましょう。

　　　　　　 1|2 次のページへ