開発会社から要件定義書が届き、「ご確認のうえ承認をお願いします」と言われたものの、何をどう確認すればいいのか分からない。要件定義のチェックリストを探している方の多くは、この状況にいるのではないでしょうか。
先に大事なことをお伝えすると、要件定義書の承認は単なる手続きではありません。承認した内容が、以降の開発の仕様、費用、納期、そして完成後の検収の基準になります。つまりここが、発注側が内容に意見を言える実質的に最後の安全なタイミングです。
この記事では、発注側が要件定義書を承認する前に確認すべき観点を、目的・機能・非機能・業務フロー・費用の5分類のチェックリストとして整理しました。レビューの進め方と参加者の決め方、確認に使える質問例もあわせて解説します。専門知識がなくても使える形にしてあるので、届いた要件定義書を横に置きながら読んでみてください。
この記事のポイント
- 要件定義書の承認は以降の仕様・費用・納期・検収の基準になる重要な意思決定
- チェックリストは目的・機能・非機能・業務フロー・費用の5分類で確認する
- 専門知識が要る項目はそのまま質問に変換すれば非エンジニアでもレビューできる
- レビューには利用部門を必ず巻き込み、業務に合うかを現場の目で確認する
目次
要件定義書レビューの進め方とチェックリスト活用
発注側レビューが必要な理由と承認の重み
要件定義書は開発会社が作成することが多いため、「専門家が書いたものを素人が確認しても意味がない」と感じるかもしれません。しかし実際は逆で、発注側にしか確認できないことがこの文書には詰まっています。
開発会社は技術の専門家ですが、あなたの会社の業務には詳しくありません。業務の実態と合っているか、例外的な処理が漏れていないか、現場がその運用を受け入れられるか。これらは発注側にしか判断できず、ここを確認しないまま承認すると、テスト段階や本番稼働後に「業務に合わない」と発覚して大きな手戻りになります。
また、承認後の変更は基本的に追加費用と納期延長を伴います。要件定義書に書かれていないことは作られませんし、書かれたとおりに作られたものは契約上「完成」です。承認とは、その線引きに合意する意思決定だと理解しておきましょう。
レビューの進め方と参加者の決め方
レビューの基本的な流れは、受領、観点を分担しての確認、質問リストの作成、レビュー会議、修正確認、承認です。受領した当日に会議で「その場で読みながら確認」するのは避けてください。読み込む時間がないまま雰囲気で承認することになります。最低でも3営業日から1週間程度の確認期間を取り、会議の前に各自が観点を持って読んでおくのが鉄則です。
参加者は、取りまとめ担当だけにしないことが重要です。少なくとも次の3つの視点を揃えましょう。
- 取りまとめ担当（情シス・DX担当）：全体の整合と契約・費用の観点
- 利用部門の代表者：業務の実態・例外処理・使い勝手の観点
- 決裁者（または予算責任者）：投資判断・優先順位の観点
特に利用部門を外すと、現場しか知らない例外業務が漏れたまま承認され、あとから必ず噴き出します。全員が全部を読む必要はなく、この記事の5分類を分担して確認すれば負担は抑えられます。
レビュー会議は1回で終わらせようとせず、2回に分けるのが現実的です。1回目で質問と指摘を出し切り、開発会社が修正・回答したものを2回目で確認して承認する流れにすると、その場の勢いで承認してしまう事故を防げます。会議時間はそれぞれ1〜2時間が目安で、それを超える量の指摘が出るなら、そもそも要件のすり合わせが足りていないサインです。
チェックリストを使うときの注意点
次の章のチェックリストを使う際は、3つの心構えを持ってください。1つ目は、すべてに○が付く必要はないということです。プロジェクトによっては該当しない項目もあります。大事なのは「確認したうえで該当なしと判断した」のか「見ていない」のかを区別することです。
2つ目は、判断できない項目はそのまま質問に変換することです。「非機能要件の性能値が妥当か分からない」なら、「この応答速度の根拠と、超えた場合の扱いを教えてください」と開発会社に聞けばよいのです。レビューは発注側がすべてを判定する場ではなく、不明点を承認前に潰す場です。
3つ目は、形骸化させないことです。チェックリストを埋めること自体が目的になると、何も守ってくれません。気になった項目こそ、要件定義書のどのページの記述を根拠に○を付けたのかを言えるようにしておきましょう。要件定義書そのものの構成や成果物の標準形は要件定義書の作り方と成果物サンプルで解説しているので、見比べながら確認すると判断しやすくなります。
観点別に見る要件定義書チェックリスト
目的とスコープの確認観点
最初に確認するのは、個別の機能ではなく「このプロジェクトは何のためで、どこまでやるのか」です。ここがずれていると、以降のどの確認も意味を失います。
目的・スコープの確認
- システム化の目的と解決したい業務課題が自社の認識と一致している
- 今回の開発範囲（やること）と対象外（やらないこと）が両方明記されている
- 対象外の項目について、いつ・どう扱うかの方針が書かれている
- 成功の判断基準（何ができれば完成か）が読み取れる
- 関係部署・利用者の範囲が業務の実態と合っている
特に重要なのは「やらないこと」の明記です。発注側は書かれていないことも「当然やってくれる」と思いがちですが、開発会社は書かれていないことはやりません。スコープ外の一覧がない要件定義書は、その時点で追記を依頼しましょう。
機能要件の確認観点
機能要件は、システムが「何をできるか」の一覧です。技術的な記述の正しさではなく、業務との対応を確認します。
機能要件の確認
- 自社が依頼した要望が一覧に反映されている（依頼時のメモと突き合わせる）
- 各機能が業務の言葉で説明されており、利用部門が読んで理解できる
- 機能ごとに優先度（必須か、あれば良いか）が区別されている
- イレギュラー時の扱い（入力ミス、締め後の修正、権限のない操作など）が書かれている
- 既存システムやExcel業務からの移行・連携の扱いが明記されている
見落としやすいのは例外処理です。通常パターンは誰でも気づきますが、月末の締め処理、年に数回の特殊な承認ルート、担当者不在時の代理操作といった例外は、現場の人にしか分かりません。利用部門のレビューが効くのはまさにここです。
画面や帳票のイメージが要件定義書に含まれている場合は、文章よりも先にそちらを現場の目で見てもらいましょう。文章の要件は読み流されがちですが、画面の絵を見ると「この項目が足りない」「この順番では入力しにくい」という具体的な気づきが出てきます。イメージがまだ無い場合は、どの工程で確認できるのかを聞いておくと安心です。
非機能要件の確認観点
非機能要件は、性能やセキュリティといった「どれくらいちゃんと動くか」の条件です。専門用語が多く読み飛ばされがちですが、稼働後の不満の大半はここから生まれます。
非機能要件の確認
- 同時に使う人数と、画面表示や処理の速さの目安が数値で書かれている
- 利用時間帯と、メンテナンスで止まる時間の想定が業務に支障ないか確認した
- 障害が起きたときの復旧目標と、データのバックアップ方針が書かれている
- 誰がどのデータを見られるかの権限設計が、組織の実態と合っている
- セキュリティ要件（ログイン方式、ログ、外部公開の範囲）に不安がない
数値の妥当性が判断できなければ、「この値はどんな前提で決めたものですか」と聞けば十分です。怖いのは数値が書かれていないことで、その場合は「遅い」「すぐ止まる」と感じても契約上は問題なしとされかねません。
すべての非機能項目を細かく詰める必要はありません。業務への影響が大きいのは、利用時間帯、復旧目標、権限設計の3つです。社内システムなら夜間停止が許容できることも多く、逆に顧客向けサービスなら停止時間がそのまま機会損失になります。自社の業務にとって「止まると困る度合い」から優先順位を付けて確認しましょう。
業務フローと運用の確認観点
システムは導入して終わりではなく、現場の業務の中で回り続ける必要があります。現状の業務フローと構築後のフローが両方描かれているか、その差分を現場が受け入れられるかを確認します。
業務フロー・運用の確認
- 現状の業務フローが実態と合っている（理想化されていない）
- 構築後フローで、誰の作業がどう変わるかが追える
- 移行期間中の業務（並行運用・データ移行）の扱いが書かれている
- 稼働後の問い合わせ窓口・保守体制・利用者教育の計画がある
現状フローが「あるべき姿」で描かれているケースは要注意です。実態と違うフローを前提に作られたシステムは、現場で使われなくなります。ここも利用部門の目で必ず確認してください。
もうひとつの落とし穴がデータ移行です。既存システムやExcelのデータをどこまで新システムへ持っていくのか、誰がデータを整備するのか、移行リハーサルはあるのか。ここが「別途協議」のまま承認されると、稼働直前に発注側へ大量のデータ整備作業が降ってきます。移行の作業分担と費用の扱いは、承認前に必ず文章で確認しておきましょう。
費用・スケジュール・契約の確認観点
最後に、お金と納期の前提を確認します。要件定義書とあわせて見積書・契約書も机に並べ、3点セットで突き合わせるのがコツです。
| 確認項目 | 見るポイント | 見落とすと起きること |
|---|---|---|
| 見積もりの前提 | どの要件を前提にした金額か | 要件追加のたびに想定外の追加費用 |
| 変更の扱い | 仕様変更時の手続きと費用の決め方 | 変更のたびに交渉でもめる |
| スケジュール | 発注側の作業（確認・データ準備）の期日 | 自社起因の遅延で納期が崩れる |
| 検収条件 | 何をもって完成・合格とするか | 不満があっても検収を求められる |
スケジュール表には開発会社の作業だけでなく、発注側の宿題（確認、決裁、データ提供）も含まれているはずです。自社のタスクの期日が現実的かどうかも、この段階で見ておきましょう。見積もり金額そのものの妥当性を判断したい場合はシステム開発の見積もり根拠をチェックする方法が参考になります。
承認前に効く質問例
チェックリストで気になった点は、レビュー会議で質問として開発会社にぶつけます。答えにくい質問ほど、承認前に聞く価値があります。そのまま使える質問例を5つ挙げておきます。
- この要件定義書に書かれていないことで、後から追加費用になりやすいものは何ですか
- 私たちの業務を聞いて、まだ要件が固まりきっていないと感じる部分はどこですか
- このスケジュールで一番リスクが高い工程はどこで、遅れたらどう扱いますか
- 同じ規模の過去案件で、承認後に揉めた変更にはどんなものがありましたか
- 承認後に私たちが決める・用意するものを、期日つきで一覧にしてもらえますか
誠実な開発会社ほど、こうした質問に具体的に答えてくれます。逆に曖昧な回答しか返ってこない場合は、その曖昧さ自体がプロジェクトのリスクです。要件定義の進め方そのものから見直したい場合は要件定義の進め方と失敗しない準備もあわせて確認してください。
