要件定義書と基本設計書の違いと役割分担

受託開発のプロジェクトに関わると、「要件定義書」と「基本設計書」という2つの文書が登場します。どちらも開発の初期段階で作成される重要な文書ですが、「結局どちらを確認すればよいのか」「同じような内容が書かれているように見えるが、何が違うのか」と戸惑う発注者は少なくありません。

この2つの文書は、実は役割がまったく異なります。要件定義書は「何を実現するか」を定義するものであり、基本設計書は「それをどう作るか」を定義するものです。この違いを理解していないと、本来確認すべきタイミングで確認すべき内容を見落とし、開発が進んだ後に「思っていたものと違う」という手戻りにつながりかねません。

この記事では、要件定義書と基本設計書それぞれの役割と、発注者がどの段階で何を確認すべきかを整理して解説します。

この記事の要点（30秒でわかるまとめ）

• 要件定義書は「何を実現するか」、基本設計書は「どう作るか」を定義する文書
• 要件定義書は発注者と開発会社が合意形成する文書、基本設計書は開発会社が実装方針を具体化する文書
• 発注者が重点的に確認すべきは要件定義書だが、基本設計書も業務フローとの整合性は確認すべき
• 両者の間で認識のズレが生まれやすいポイントを把握しておくと手戻りを防げる

要件定義書の役割：「何を実現するか」を定義する

結論：要件定義書は、システムによって解決したい課題と、実現すべき機能・性能を発注者と開発会社の間で合意するための文書です。

要件定義書には、プロジェクトの背景・目的、業務フロー、必要な機能要件（画面・処理内容など）、非機能要件（性能・セキュリティ・運用方針など）が記載されます。この文書の最大の目的は、発注者と開発会社の間で「作るべきもの」の認識を一致させることにあります。現場を巻き込む要件定義のやり方でも触れているように、要件定義の段階では現場の業務担当者を巻き込み、実際の業務に即した要件を洗い出すことが重要になります。

基本設計書の役割：「どう作るか」を具体化する

結論：基本設計書は、要件定義書で合意した内容を、開発会社がどのように実装するかという技術的な方針に落とし込む文書です。

基本設計書には、画面レイアウト、データベースのテーブル構成、システム間の連携方式、処理フローの詳細などが記載されます。要件定義書が「What（何を作るか）」を定義するのに対し、基本設計書は「How（どう作るか）」を定義する文書と整理すると分かりやすいでしょう。基本設計書の作成は主に開発会社側の作業となりますが、発注者側が内容を一切確認しなくてよいわけではありません。特に画面構成やデータの持ち方が、実際の業務の使い勝手に直結する場合は、基本設計の段階でも確認しておくべきポイントがあります。

両者の違いを表で整理する

結論：要件定義書と基本設計書は、作成の目的・主な記載内容・確認すべき立場がそれぞれ異なります。

要件定義書のレビューで確認すべきチェックポイントで紹介している観点は、主に要件定義書のレビューを想定したものですが、基本設計書を確認する際にも「業務フローとの整合性」という観点は共通して重要です。

発注者が確認を見落としやすいポイント

結論：基本設計書は専門的な内容が多いため、発注者が「技術的な話だから」と確認を飛ばしてしまい、後の使い勝手に関わる部分を見落とすケースがあります。

特に画面のレイアウトや入力項目の並び順は、基本設計書の段階で確定されることが多く、ここで「現場の業務フローと合っているか」を確認しないまま進めてしまうと、リリース後に「使いにくい」という声が出やすくなります。画面設計は現場の使い勝手に直結するため、基本設計書の中でも画面に関する部分は、技術的な詳細を理解できなくても「この並び順で実際の業務が回るか」という観点で目を通しておくことをおすすめします。

要件定義と基本設計の間で起きやすい認識のズレ

結論：要件定義書の記載が抽象的すぎると、基本設計の段階で開発会社が独自に解釈し、発注者の意図とズレた仕様になってしまうことがあります。

たとえば要件定義書に「顧客情報を一覧で確認できること」としか書かれていない場合、開発会社は一覧に表示する項目や並び順を自社の判断で決めることになります。この解釈が発注者の想定と異なると、基本設計の段階、あるいはそれ以降の工程で修正が必要になり、追加の時間やコストが発生する可能性があります。こうしたズレを防ぐには、要件定義の段階で可能な限り具体的な記述を心がけるとともに、基本設計書が提出された際に「自分たちの意図通りに解釈されているか」を確認する姿勢が重要です。

よくある質問（FAQ）

Q. 要件定義書と基本設計書、どちらが先に作られますか？ A. 一般的には要件定義書が先に作成され、合意形成された内容をもとに基本設計書が作成されます。両工程を並行して進める場合もありますが、基本的な流れとしては要件定義が先行します。

Q. 基本設計書の内容が専門的で理解できない場合はどうすればよいですか？ A. 技術的な詳細をすべて理解する必要はありませんが、画面構成やデータの持ち方など、業務に直結する部分については開発会社に分かりやすい言葉での説明を求めることをおすすめします。

Q. 要件定義書の内容を後から変更することはできますか？ A. 可能ですが、基本設計や実装が進んだ後の変更は、スケジュールや追加費用に影響する可能性があります。変更が発生した場合の進め方は事前に確認しておくとよいでしょう。

Q. 基本設計書がない開発会社もあると聞きましたが、問題ないのでしょうか？ A. プロジェクトの規模や開発手法によって、文書の分け方や粒度は異なります。文書の名称にかかわらず、「何を作るか」と「どう作るか」がそれぞれ明確になっているかを確認することが重要です。

まとめ

要件定義書は「何を実現するか」、基本設計書は「どう作るか」を定義する文書であり、それぞれ役割が異なります。発注者としては要件定義書の確認を最も重視すべきですが、基本設計書についても業務フローや使い勝手に関わる部分は目を通し、認識のズレがないかを確認することが、後の手戻りを防ぐポイントになります。

Irwin&co株式会社では、フォーム回答から約3分で要件定義書のドラフトを自動生成し、初回の商談時点で実際に動くデモとともに要件・設計のイメージを共有しています。要件定義や基本設計の進め方に不安がある場合は、AI受託開発のサービス詳細やお問い合わせからお気軽にご相談ください。