システム開発の要件定義では、
「文章では合意していたのに、画面を作ったらイメージが違った」
「開発後に、こんな動きだと思っていなかったと言われた」
「現場担当者が実際の画面を見るまで必要な機能に気づかなかった」
といった問題が起こることがあります。
こうした認識ズレを減らす方法の一つが、要件定義の段階でプロトタイプを作ることです。
プロトタイプとは、本番システムを完成させる前に作る試作版や画面イメージのことです。
例えば顧客管理システムなら、
- ログイン
- 顧客一覧
- 顧客詳細
- 顧客登録
- 案件一覧
などの主要画面を簡易的に作り、実際の利用者に確認してもらいます。
文章で、
顧客を検索できる
と書くだけでは、
- 何で検索するのか
- 検索結果に何を表示するのか
- 詳細はどこから開くのか
- CSV出力はどこにあるのか
までイメージできません。
一方、簡単な画面があれば、
顧客名だけでなく担当者でも検索したい
この一覧には最終対応日も欲しい
新規登録ボタンはここでは使いにくい
といった具体的なフィードバックが出やすくなります。
この記事では、プロトタイプを使って要件定義を進める方法、どこまで作り込むべきか、レビューで確認する項目、よくある失敗まで解説します。
要件定義で使うプロトタイプとは
要件定義で使うプロトタイプとは、システムの完成イメージを確認するための試作品です。
必ずしも実際にデータベースへ保存できる必要はありません。
例えば、
- Figmaで画面を作る
- PowerPointで画面イメージを作る
- HTMLで簡易画面を作る
- ノーコードツールで操作できるモックを作る
といった方法があります。
重要なのは、本番レベルのシステムを作ることではなく、
利用者が完成後の操作をイメージできる状態にすること
です。
なぜ要件定義でプロトタイプが有効なのか
要件定義では、発注者・利用者・開発者が同じ言葉を使っていても、頭の中のイメージが違うことがあります。
例えば、
顧客一覧画面
という言葉だけでも、人によって想像するものが異なります。
ある人は、
- 顧客名
- 担当者
- 電話番号
だけの一覧を想像します。
別の人は、
- 顧客名
- 担当者
- 案件状況
- 最終対応日
- 売上
- タグ
まで表示する画面を想像しているかもしれません。
文章だけでは、この違いに気づきにくいのが問題です。
プロトタイプを見せることで、
曖昧な言葉を具体的な画面へ変換できます。
プロトタイプを使うメリット
1．発注者と開発者の認識を合わせやすい
例えば要件定義書に、
案件を一覧表示できる
と記載されていたとします。
プロトタイプを作ると、
- 顧客名
- 案件名
- 担当者
- 金額
- ステータス
- 更新日
など、具体的な表示内容まで確認できます。
2．現場担当者から意見を得やすい
現場担当者に、
必要な機能はありますか？
と聞いても、すぐには答えられないことがあります。
しかし画面を見せて、
この画面で毎日の案件管理ができますか？
と聞くと、
担当者で絞り込みたい
完了案件は非表示にしたい
など、実際の業務に基づく意見が出やすくなります。
3．要件漏れを早く発見できる
例えば予約システムのプロトタイプを操作すると、
予約変更はどこでするのか？
キャンセル処理がない
満席時の表示は？
と気づくことがあります。
設計・開発後ではなく、要件定義段階で発見できれば手戻りを減らせます。
4．優先順位を付けやすい
実際の画面を見ると、
この機能はなくてもよい
これは初回リリースに必要
と判断しやすくなります。
Must・Should・Couldなどの優先順位付けにも利用できます。
プロトタイプ・ワイヤーフレーム・モックアップの違い
似た言葉なので整理しておきます。
ワイヤーフレーム
画面の構造を簡易的に表したものです。
例えば、
- ヘッダー
- 検索エリア
- 一覧
- ボタン
など、レイアウト中心に確認します。
モックアップ
ワイヤーフレームより見た目を具体化したものです。
- 色
- フォント
- ボタン
- アイコン
- UIデザイン
なども確認できます。
プロトタイプ
画面間の遷移など、実際の操作をある程度再現したものです。
例えば、
顧客一覧
↓ クリック
顧客詳細
↓ 編集
顧客編集
と操作できます。
要件定義では、必ずしも高精度なデザインが必要なわけではありません。
確認したい要件に応じて必要な粒度を選ぶことが重要です。
プロトタイプを使った要件定義の進め方7ステップ
おすすめは次の流れです。
STEP1｜業務・課題を整理する
いきなりプロトタイプを作り始めないことが重要です。
まず、
- 現在の業務
- 課題
- 利用者
- システム化の目的
を整理します。
例えば、
営業担当者ごとにExcelで顧客・案件を管理しており、管理者が状況を把握できない
という課題があるとします。
ここから、
顧客・案件情報を一元管理する
という業務要件を整理します。
STEP2｜必要機能を整理する
次に機能一覧を作ります。
例えば、
- ログイン
- 顧客管理
- 顧客検索
- 案件管理
- 対応履歴
- CSV出力
- ユーザー管理
などです。
この段階で、すべて細かく決める必要はありません。
STEP3｜画面一覧を作る
機能から必要画面を洗い出します。
例えば、
| ID | 画面名 |
|---|---|
| SCR-001 | ログイン |
| SCR-002 | ダッシュボード |
| SCR-003 | 顧客一覧 |
| SCR-004 | 顧客詳細 |
| SCR-005 | 顧客登録 |
| SCR-006 | 顧客編集 |
| SCR-007 | 案件一覧 |
| SCR-008 | 案件詳細 |
まずシステム全体の画面を整理します。
STEP4｜重要画面からプロトタイプを作る
すべての画面を最初から作り込む必要はありません。
まず、
利用頻度が高い画面
要件が曖昧な画面
業務上重要な画面
から作ります。
例えば顧客管理システムなら、
- 顧客一覧
- 顧客詳細
- 案件登録
などです。
パスワード変更画面など、一般的で要件差が小さい画面は後回しでもよいでしょう。
STEP5｜実際の業務シナリオで操作する
単に、
この画面でよいですか？
と確認するだけでは不十分です。
実際の業務を想定します。
例えば、
新規顧客から問い合わせが来ました。登録して案件を作成してください。
と操作してもらいます。
すると、
顧客検索
↓
既存顧客か確認
↓
新規登録
↓
案件登録
↓
対応履歴入力
という一連の流れを確認できます。
このとき、
顧客登録後に案件登録へそのまま進みたい
といった要件が見つかることがあります。
STEP6｜フィードバックを要件へ戻す
プロトタイプの修正だけで終わらせないことが重要です。
例えばレビューで、
顧客一覧で担当者検索が必要
と決まったら、機能要件にも、
FR-015：顧客一覧で担当者を条件に検索できる
と反映します。
つまり、
プロトタイプは要件定義書の代わりではありません。
要件を発見・確認するための手段として使い、確定事項は要件資料へ戻します。
STEP7｜レビュー後に要件を確定する
最終的に、
- 業務担当者
- 管理者
- システム担当
- 開発会社
などで確認します。
そして、
この画面・業務フローを前提に設計へ進む
という状態を作ります。
プロトタイプで確認したい項目
画面を見ながら、次を確認します。
1．必要な情報が表示されているか
例えば顧客一覧なら、
- 顧客名
- 担当者
- 電話番号
- ステータス
などです。
2．不要な情報が多すぎないか
何でも一覧に表示すると使いにくくなります。
日常的に必要な情報を優先します。
3．検索条件は足りているか
例えば、
- 顧客名
- 担当者
- ステータス
- 登録日
などです。
4．操作の流れは自然か
例えば、
顧客詳細
↓
案件一覧
↓
案件登録
と進めるか確認します。
5．権限によって表示が変わるか
一般ユーザーには、
削除ボタンを表示しない
といった要件があります。
6．例外時の操作があるか
例えば、
- キャンセル
- 差し戻し
- 削除
- エラー
- 重複登録
などです。
プロトタイプはどこまで作り込むべき？
要件定義でありがちな失敗は、プロトタイプに時間をかけすぎることです。
例えば、
- 完璧な色
- アニメーション
- 細かなアイコン
- ピクセル単位の配置
まで作り込んでも、要件確認には不要な場合があります。
要件定義段階で重要なのは、
見た目より、情報・操作・業務フローが確認できること
です。
例えば、
顧客検索 → 顧客詳細 → 編集 → 保存
まで操作できれば、十分な場合があります。
プロトタイプに本番デザインは必要？
必須ではありません。
むしろ要件定義初期にデザインを作り込みすぎると、
すでに完成しているように見える
ため、利用者が仕様変更を言いにくくなることがあります。
初期段階では白黒・シンプルなワイヤーフレームでも構いません。
要件が固まってからUIデザインへ進めます。
プロトタイプを作るべき画面の優先順位
すべての画面を作る必要はありません。
優先度が高いのは次のような画面です。
1．利用頻度が高い画面
例えば、
- 顧客一覧
- 在庫一覧
- 予約一覧
です。
2．業務が複雑な画面
例えば、
- 承認
- 注文登録
- 在庫調整
- 請求処理
です。
3．認識ズレが起きそうな画面
例えば、
ダッシュボード
のように、人によってイメージが大きく異なるものです。
4．新しい業務フローになる画面
現在Excelだった業務をWebシステムへ変える場合などです。
業務システムのプロトタイプ例
例えば在庫管理システムなら、
在庫一覧
確認項目：
- 商品コード
- 商品名
- 拠点
- 現在庫
- 引当数
- 利用可能数
- 検索
- CSV
在庫詳細
確認項目：
- 現在庫
- 入出庫履歴
- 在庫調整
- 拠点別在庫
入庫登録
確認項目：
- 商品
- 数量
- 入庫日
- 拠点
- 理由
この段階で現場担当者へ見せると、
返品入庫を通常入庫と分けたい
在庫調整理由は必須にしたい
といった要件が見つかります。
プロトタイプレビューの進め方
レビューでは、
自由に意見をください
だけでは意見が出にくいことがあります。
実際の業務シナリオを用意します。
例えば、
シナリオ1
新規顧客を登録してください。
シナリオ2
過去に取引した顧客を検索してください。
シナリオ3
顧客の案件状況を確認してください。
シナリオ4
担当者を変更してください。
このように操作してもらい、
- 迷った箇所
- 足りない情報
- 不要な操作
- 必要な機能
を記録します。
【コピペ用】プロトタイプレビューシート
■ 基本情報
画面ID：
画面名：
レビュー日：
参加者：
■ 確認シナリオ
利用者：
実施する業務：
開始条件：
完了条件：
■ 画面確認
表示情報は十分か：
不要な情報はないか：
検索条件は十分か：
入力項目は十分か：
ボタン・操作は分かりやすいか：
画面遷移は自然か：
■ 業務確認
現在の業務を実行できるか：
例外処理に対応できるか：
承認・差し戻しに対応できるか：
権限による違いはあるか：
■ 指摘事項
指摘1：
対応方針：
要件変更：
優先度：
指摘2：
対応方針：
要件変更：
優先度：
■ 判定
□ OK
□ 修正後再レビュー
□ 要件再検討
プロトタイプで要件変更が増えるのは悪いこと？
必ずしも悪いことではありません。
むしろ要件定義段階で、
この機能も必要だった
と気づけるなら、プロトタイプの効果が出ています。
問題なのは、
開発後半で同じことに気づくこと
です。
例えば顧客一覧へ新しい検索条件を追加する場合でも、
要件定義中なら小さな修正で済みます。
一方、開発完了後なら、
- UI
- API
- DB
- テスト
まで変更になる可能性があります。
プロトタイプを使っても要件定義書は必要
プロトタイプは非常に分かりやすいですが、画面だけでは表現できない要件があります。
例えば、
- 100人同時利用
- バックアップ
- セキュリティ
- ログ保存期間
- API連携
- データ移行
- バッチ処理
- 障害対応
などです。
そのため、
画面で見える要件はプロトタイプで確認
見えない要件は要件定義書で管理
という使い分けが必要です。
プロトタイプと要件を紐付ける
例えば、
| 機能ID | 要件 | 画面ID |
|---|---|---|
| FR-001 | 顧客を検索できる | SCR-003 |
| FR-002 | 顧客を登録できる | SCR-005 |
| FR-003 | 案件を登録できる | SCR-008 |
と管理します。
このようにすると、
この画面は何の要件のためにあるのか
を追いやすくなります。
逆に、
要件はあるが対応画面がない
という漏れも見つけやすくなります。
プロトタイプを使った要件定義でよくある失敗
失敗1｜業務整理前に画面を作る
いきなりUIから考えると、本来必要な業務要件が抜けることがあります。
業務 → 要件 → 画面
の順で考えます。
失敗2｜デザインに時間をかけすぎる
要件確認が目的なら、見た目より操作・情報を優先します。
失敗3｜管理者だけでレビューする
実際の現場担当者にも操作してもらいます。
失敗4｜正常系だけ確認する
キャンセル・差し戻し・エラーなども確認します。
失敗5｜プロトタイプだけ修正する
変更内容を機能一覧・要件定義書にも反映します。
失敗6｜すべての画面を最初から作る
重要・複雑・認識ズレが起きやすい画面から作ります。
失敗7｜プロトタイプをそのまま仕様書と考える
画面で表現できない非機能・データ・運用要件があります。
プロトタイプを使った要件定義が向いているケース
特に有効なのは、次のような開発です。
業務システム
利用者が日常的に操作するため、UI・操作フローの確認が重要です。
管理画面
検索・一覧・登録・編集・権限などを具体化しやすくなります。
既存ExcelのWeb化
ExcelとWebでは操作方法が大きく変わるため、早めに画面を確認するメリットがあります。
新規Webサービス
完成イメージを文章だけで共有するのが難しいため、プロトタイプが有効です。
プロトタイプが必ずしも必要ではないケース
例えば、
- 単純なバッチ処理
- APIのみの開発
- 小規模な既存機能修正
- UIのないデータ連携
では、画面プロトタイプを作る意味が小さい場合があります。
重要なのは、
認識合わせにプロトタイプが有効な領域か
で判断することです。
プロトタイプを作るタイミング
おすすめは、
業務・主要機能がある程度整理された後、詳細設計へ入る前
です。
例えば、
業務ヒアリング
↓
As-Is業務整理
↓
To-Be業務整理
↓
業務要件
↓
主要機能
↓
画面一覧
↓
プロトタイプ
↓
レビュー
↓
要件確定
↓
基本設計・詳細設計
という流れです。
プロトタイプを作る前に、最低限「何を解決するシステムなのか」は整理しておきます。
プロトタイプによる要件定義のチェックリスト
【作成前】
□ システム化の目的を整理した
□ 現状業務を把握した
□ To-Be業務を整理した
□ 利用者を整理した
□ 主要機能を整理した
□ 画面一覧を作成した
【プロトタイプ】
□ 利用頻度の高い画面を作った
□ 複雑な業務画面を作った
□ 画面遷移を確認できる
□ 必要情報を表示している
□ 主要操作を試せる
【レビュー】
□ 現場担当者が確認した
□ 管理者が確認した
□ 実際の業務シナリオで操作した
□ 正常系を確認した
□ 例外系を確認した
□ 権限違いを確認した
【要件反映】
□ 指摘事項を記録した
□ 機能要件へ反映した
□ 画面一覧へ反映した
□ 対象範囲を更新した
□ 優先順位を更新した
□ 未決事項を管理した
プロトタイプとPoCの違い
プロトタイプとPoCも混同されやすい言葉です。
プロトタイプ
主に、
完成イメージ・操作・要件を確認する
ために作ります。
例えば、
この顧客管理画面で業務を進められるか
を確認します。
PoC
主に、
技術的・業務的に実現可能か
を検証します。
例えば、
AIでタイヤ画像から溝を測定できるか
社内文書から必要情報を正確に検索できるか
などです。
つまり、
プロトタイプ＝何を作るかの認識合わせ
PoC＝そもそも実現できるかの検証
と考えると分かりやすいでしょう。
プロトタイプを使った要件定義に関するよくある質問
プロトタイプは要件定義で必須ですか？
必須ではありません。
ただし、画面を多く持つ業務システムや新規Webサービスでは、認識ズレを減らすために有効です。
プロトタイプはどこまで動かす必要がありますか？
確認したい要件によります。
画面構成だけならワイヤーフレームで十分です。
操作フローを確認したいなら、主要画面間をクリックして移動できる程度まで作ると分かりやすくなります。
データベースまで作る必要がありますか？
要件確認だけが目的なら必須ではありません。
ダミーデータを表示して操作イメージを確認する方法があります。
誰にレビューしてもらうべきですか？
実際の利用者、業務管理者、システム担当者などです。
特に、現場担当者を外さないことが重要です。
プロトタイプで決まった内容は要件定義書に書くべきですか？
はい。
プロトタイプの修正だけで終わらせず、機能要件・画面一覧・業務ルールなどにも反映します。
hiro-dev-labの要件定義・プロトタイプ・システム開発支援
hiro-dev-labでは、Webシステム・業務システムについて、実装だけでなく業務整理・要件定義から対応しています。
例えば、
- 現状業務のヒアリング
- As-Is・To-Be業務整理
- 業務要件・機能要件整理
- 画面一覧作成
- ワイヤーフレーム・プロトタイプ整理
- 画面レビュー
- データ・権限設計
- 非機能要件整理
- Java・Python・TypeScriptによるWebシステム開発
などを検討できます。
例えば、
Excel業務をWebシステム化したいが、文章だけでは完成イメージが分からない
という場合でも、
業務整理 → 要件整理 → 画面一覧 → プロトタイプ → レビュー → 設計・開発
という順番で進められます。
プロトタイプの目的は「きれいな画面を作ること」ではなく「早く間違えること」
要件定義でプロトタイプを作る最大の価値は、
開発前に認識ズレを見つけられること
です。
例えば、
この画面では業務できない
この項目が足りない
この操作は不要
という指摘が10個出たとしても、それは失敗ではありません。
むしろ、本開発前に10個の問題を発見できたということです。
プロトタイプを使う場合は、
- 業務・課題を整理する
- 主要機能を整理する
- 画面一覧を作る
- 重要画面からプロトタイプ化する
- 実際の業務シナリオで操作する
- 現場担当者からフィードバックを受ける
- 指摘内容を要件へ反映する
- 合意後に設計・開発へ進む
という流れがおすすめです。
重要なのは、最初から正解の画面を作ることではありません。
小さく画面を作り、早い段階で認識ズレを発見し、要件を具体化することが、プロトタイプを使った要件定義の目的です。
「文章だけでは完成イメージを共有しにくい」
「開発後の手戻りを減らしたい」
「現場担当者にも画面を確認してもらいたい」
「業務整理からプロトタイプ・設計・開発まで相談したい」
といった段階からでも、画面イメージを使いながら要件を整理できます。
要件定義・プロトタイプ・業務システム開発について相談する