この記事の要約
発注者は設計書の内容が自分たちの仕事に合うかを業務の目線で確かめます。5つの観点ごとのコメント例と、資料名・版・ページをそろえた返し方、修正後の再確認までをまとめました。
基本設計のレビューで発注者が見るのは、5つです。「仕事の流れに合うか」「画面で迷わないか」「帳票が使えるか」「権限が正しいか」「未決事項が残っていないか」です。
見た目の好みより、毎日の仕事で困らないかを確かめます。この記事では、設計書に返すコメントの具体例を紹介します。例はすべて架空の会社のものです。
基本設計で要件を画面や帳票に具体化する
IPAの解説では、基本設計は要件定義の後に、要件を具体化し、業務の流れや機能、外部とのつながりを整理する工程とされています。要件定義で決めた「何を作るか」を、画面や帳票などの形にしていく段階です。
発注者が、技術の正しさを細かく判断する必要はありません。自分たちの仕事に合っているかを、業務の目線で見ます。技術的に実現できるか、セキュリティは十分かといった点は、開発会社と一緒に確かめます。
レビューの前に確かめること
- 設計書の版番号と日付（例：基本設計書 第3版、11/12）
- 前の版から変わった箇所
- 要件定義で「未決」にしていた項目
古い版にコメントすると、すでに直った点を指摘してしまいます。まず版を確かめ、変わった箇所から読むと効率よく進みます。
5つの観点とコメント例
架空の会社「B社（食品の卸売、社員25名）」が、受注管理システムの基本設計書を見る場面です。
1. 仕事の流れに合うか
業務フロー図を、実際の一日の仕事と照らし合わせます。
コメント例：「業務フロー p.4：注文の取り消しの流れがありません。月に数回、電話で取り消しがあります。誰が、どの画面で処理する想定か教えてください。」
取り消し、返品、急ぎの注文など、いつもと違う仕事は抜けやすいところです。
2. 画面で迷わないか
コメント例：「受注入力画面 p.8：取引先を選ぶとき、いまは略称で探しています。略称でも検索できますか。」
コメント例：「入力欄の順番が、注文書の並びと違います。注文書の順に並べられるか相談したいです。」
色やデザインの好みより、入力の順番、探し方、間違えたときの戻り方を見ます。
3. 帳票が使えるか
帳票とは、納品書や請求書、集計表など、印刷したり出力したりするものです。
確かめること | コメント例 |
|---|---|
項目 | 納品書に取引先の注文番号を入れたい |
出す人と時期 | 月末に経理がまとめて出せるか |
出し方 | 取引先にはPDFで送りたい |
いま使っている帳票の実物と並べて見ると、抜けている項目に気づきやすくなります。
4. 権限が正しいか
権限とは、誰が何を見られて、何を変えられるかです。
利用者 | 確かめること（例） |
|---|---|
営業 | 受注の入力と確認。単価は変えない |
経理 | 請求と入金。受注は見るだけ |
管理者 | 利用者の追加と削除 |
コメント例：「権限表 p.12：パートの方は、取引先の連絡先を見られない設定にしたいです。」
担当者が休んだときに、代わりの人が何をできるかも考えておきます。
5. 未決事項が残っていないか
設計書の中の「検討中」「要確認」「TBD」といった書きこみを探します。
コメント例：「p.15『消費税の端数処理：検討中』。経理と相談して、11/19までに回答します。」
未決のまま先に進むと、後で作り直しになることがあります。誰がいつ決めるかを、その場で決めておきます。
一件の仕事を順番にたどる
画面を一枚ずつ眺めるだけでなく、「注文を受けてから請求を出すまで」を一件分たどります。架空の品目や数量を使い、どの画面で何を入力し、その情報が次の画面や帳票にどう渡るかを説明してもらいます。
モックがある場合も、実際に保存や計算ができる完成品とは限りません。動く部分と説明だけの部分を最初に確認し、操作できないことだけを不具合と判断しないようにします。入力ミスの訂正や注文の取り消しも、設計上どう扱うかを質問します。
確認は担当部署ごとに分けても、部署をまたぐ受け渡しは一緒に見ます。営業から経理へ渡す情報が不足していれば、各画面が個別には正しくても日々の仕事が止まるためです。
画面名だけでは分からない表示条件を聞く
架空例です。設計書にある「受注一覧」の画面を、開発会社は「今日の注文」のつもりで設計し、営業は「まだ出荷していない注文すべて」を思い浮かべていました。
画面の名前だけで分かった気にならず、表示される内容と条件を確かめます。分からない言葉は、遠慮せずに質問します。「この画面は、いつ、誰が使う想定ですか」と聞くだけでも、ずれが見つかることがあります。
コメントの残し方と再確認
コメントは、次の形にそろえると、開発会社が直しやすくなります。
- 場所
- 資料名、版、ページ
- 種類
- 質問／修正のお願い／確認済み
- 内容
- 何が困るか、その理由
- 担当と期限
- 誰が、いつまでに答えるか（開発会社と相談して決める）
記入例：
「基本設計書 第3版 p.8｜修正のお願い｜入力欄を注文書の順にしたい。転記のときに迷うため｜回答：開発会社の設計担当、11/15。業務上の確認：営業課長」
修正が返ってきたら、次の版で直っているかを再確認します。直っていれば「確認済み」と記録します。合意した内容と未決の内容は分けて、一覧に残しておきます。返し方の形は、最初に開発会社と決めておくとやりとりが楽になります。
なお、できあがった後に動きを確かめる作業は、このレビューとは別です。受入テストの進め方を参考にしてください。レビュー中に要望が増えたときは仕様変更の伝え方と進め方、費用の考え方は見積もりの比べ方にまとめています。
ここで紹介したコメントの形は一般的な一例です。実際の進め方は、案件ごとに開発会社と決めます。
Ouverの設計段階での確認と技術支援
Ouverの開発の流れでは、工程04が「要件定義・設計」です。業務や課題を理解したうえで要件を整理し、必要に応じて画面のモックを用意します。業務上の判断と使い方の確認はお客さま、技術面の支援はOuverが担います。範囲・成果物・費用は案件ごとに確認します。
まとめ
- 仕事の流れ、画面、帳票、権限、未決事項の5つを業務の目線で見る
- コメントは資料名・版・ページ、種類、理由、担当と期限をそろえて返す
- 修正は次の版で再確認し、合意と未決を分けて残す
最初から専門用語をすべて理解する必要はありません。毎日の仕事に関わるところから部署ごとに分けて読み、受け渡しは一緒に確かめましょう。読み切れない部分は開発会社に説明を頼みます。
出典
出典の確認日：2026年11月7日
よくある質問
設計書が専門的で読めません。どこから見ればよいですか？
専門用語を最初からすべて理解する必要はありません。毎日の仕事に関わる画面、帳票、権限の表から見て、分からない言葉はそのまま質問します。業務に合うかどうかが、発注者が見る主なところです。
画面の見た目だけ確認すれば十分ですか？
色や配置の好みを伝えても構いませんが、それだけでは足りません。入力の順番、探し方、取り消しなど例外の仕事の流れといった、毎日の使いやすさに関わる点を優先して確かめると安心です。
権限は、どこまで細かく決めればよいですか？
まずは部署ごとに、見るだけか、変えられるかを分けるところから始めます。細かい設定やセキュリティの対策は、運用のしやすさも含めて開発会社と相談して決めます。
レビューのコメントは、どんな形で返せばよいですか？
資料名・版・ページ、質問か修正のお願いか、困る理由、回答する人と期限をそろえると伝わりやすいです。返し方の形を最初に開発会社と決めておくと、やりとりが楽になります。
基本設計のレビューと受入テストは何が違いますか？
基本設計のレビューは、作る前に設計の内容が仕事に合うかを確かめる作業です。受入テストは、できあがったシステムが決めた通りに動き、実際の仕事で使えるかを確かめる作業です。時期と対象が違います。
