1.はじめに
システム開発の上位設計（要件定義、基本設計など）において、エンドユーザーとのレビューを効率的に進めるための「ちょっとした工夫」について、いくつかお話します。
ここでいうレビューとは、ユーザーと定期的に行う仕様決めの打合せ(会議）のことです。
2.ちょっとした工夫
今回は、３つほどお話します。
(1)ドキュメントに登場するプログラムに通し番号を付ける ・・・・・ 主に要件定義レビュー
新業務フローなど、ドキュメント上に複数の画面、帳票、プロセスなどのプログラムが登場する場合は、それら固有のプログラムID（画面ID、帳票ID、プロセスIDなど）とは別に、そのドキュメント内だけで使用する通し番号を記載します。
この通し番号は、A-001、A-002などの単純なルールの番号で構わないのですが、この番号を表記することで、ユーザーとの会話や書面でのやりとりをスムースに行うことが可能になります。
(2)吹き出しコメントの枠線に色を付ける ・・・・・ 主に要件定義レビュー
これも業務フローに対してですが、吹き出し形式等で補足説明を記載する場合に、ユーザー側の要望に対するものとシステム側からの提案によるものを吹き出し枠の色を変えて表現しておくと、仕様決定にいたる経緯をたどる際の助けになります。（ときどき、後からかえりみたときに「なんで、こんな仕様にしたんだっけ・・・？」ということがあります）
(3)レビューシートを共有する ・・・・・ 主に基本設計レビュー
要件定義レビューで個々の画面や帳票のレイアウトや機能のイメージをある程度共有している場合は、それらの画面・帳票に対する基本設計レビューを行う数日前(２～３日前）に、画面設計書・帳票設計書をレビューシート付きでユーザーに送付し、当日までに指摘事項・要望・質問等を書き込んでおいてもらうと、レビュー当日の確認作業を効率よく進めることができます。
ここでいうレビューシートとは、「画面レイアウト」、「画面項目名」、「表示桁数」、「エラーメッセージ」など、各画面・帳票で共通的な項目を中心に表形式で作成する程度のものでよく、一度ひな形を作ってしまえばそれほど手間の掛かるものではありません。
3.終わりに
いかがでしょうか。2(3)はちょっと重たい作業になりますが、これらの工夫をすることで上位設計のレビュー効率や精度を高めることができますので、もしよかったら一度試してみてください。
以上