システム開発を外注すると、要件定義書のあとに基本設計書、さらに仕様書といった文書が次々と届きます。どれも似たような書類に見えて、何が違うのか、自分はどこまで確認すればいいのか分からず戸惑う方は多いはずです。
違いをひとことで言うと、要件定義は「何を作るか（What）」を決める工程、基本設計は「どう作るか（How）」を決める工程です。要件定義書は開発を始める前に作られ、仕様書は開発を進める中で作られるという時間差もあります。この役割の違いが分かると、発注側として各書類で何を確認すべきかも見えてきます。
この記事では、要件定義と基本設計の違い、要件定義書と仕様書の違いを発注側の目線で整理し、それぞれの書類で発注側が確認・承認すべきポイントまで解説します。開発会社から届く書類に振り回されず、要点を押さえて関われるようになる形でまとめました。
この記事のポイント
- 要件定義は「何を作るか」、基本設計は「どう作るか」を決める工程
- 要件定義書は開発前、仕様書は開発中に作られるという時間差がある
- 発注側が深く関わるのは要件定義で、基本設計以降は確認と承認が中心
- 各書類で見るべき観点が違うので、どこを確認するかを事前に押さえる
目次
要件定義と基本設計の違い
要件定義は「何を作るか」を決める
要件定義は、システム化で解決したい課題を整理し、必要な機能や条件を決める工程です。「問い合わせ対応の手間を減らしたい」「在庫の数を正確に把握したい」といった発注側の要望を、開発できる形の要件にまとめていきます。
ここで決めるのは、あくまで「何を実現するか」というレベルです。たとえば「よくある質問を自動表示する機能をつける」「在庫数をリアルタイムで確認できるようにする」といった、業務の言葉で語れる内容が中心になります。技術的にどう実装するかには、まだ踏み込みません。
要件定義書には、システム化の目的、機能要件、非機能要件、対象とする業務範囲、おおまかなスケジュールや予算感などが記載されます。発注側が読んで意味が分かる、業務寄りの言葉で書かれているのが特徴です。逆に言えば、要件定義書を読んでも理解できない場合は、開発会社に業務の言葉で書き直してもらう余地があります。
要件定義は発注側の関与が最も濃い工程です。業務を知っているのは発注側だけなので、ここでの意思決定がプロジェクト全体の土台になります。進め方の全体像は要件定義の進め方の解説で確認できます。
もう一つ要件定義の特徴は、要件定義書という成果物が、発注側と開発会社の「契約上の合意内容」に近い重みを持つことです。ここに書かれた範囲が開発の対象であり、書かれていないことは基本的に作られません。だからこそ、要件定義の段階で発注側がやりたいことを出し切ることが重要になります。基本設計以降で「これも欲しかった」と気づいても、それは追加の要望として扱われ、費用や納期に影響します。
基本設計は「どう作るか」を決める
基本設計は、要件定義で決めた「何を作るか」を、「どう作るか」に落とし込む工程です。要件定義書をもとに、開発会社が画面のレイアウト、画面の遷移、機能の一覧、データの持ち方、外部システムとの連携などを具体的に設計していきます。
たとえば要件定義で「在庫をリアルタイムで確認できるように」と決めたなら、基本設計では「どんな画面で、どの項目を、どう表示するか」を形にします。発注側にとっては、要望が実際の画面や操作としてどう実現されるのかが初めて見える段階です。
基本設計は技術的な判断が増えるため、主導するのは開発会社です。発注側は一から作るのではなく、提示された設計が自分たちの要望と業務に合っているかを確認する立場になります。要件定義から基本設計に進むにつれて、発注側の役割は「決める」から「確認する」へと移っていきます。
基本設計書には、画面イメージや帳票のレイアウトが含まれることが多く、ここは発注側が最も具体的に「使えるかどうか」を判断できる部分です。文章で書かれた要件はピンと来なくても、画面の絵を見れば「この項目が足りない」「この操作順では使いにくい」といった気づきが現場から出てきます。基本設計のレビューに利用部門を巻き込むと、実際の運用に合わないシステムになるリスクを大きく減らせます。
WhatとHowで役割が分かれる
両者の違いは、WhatとHowという言葉で整理すると分かりやすくなります。要件定義はWhat（何を）とWhy（なぜ）、基本設計はHow（どうやって）を扱う工程です。
| 観点 | 要件定義 | 基本設計 |
|---|---|---|
| 決めること | 何を作るか・なぜ作るか | どう作るか |
| 主な内容 | 目的・機能要件・非機能要件 | 画面・機能一覧・データ・連携 |
| 主導する人 | 発注側（開発会社が支援） | 開発会社（発注側が確認） |
| 発注側の関与 | 濃い（意思決定の中心） | 確認と承認が中心 |
この順序が逆になることはありません。何を作るかが決まっていないのにどう作るかは決められないため、要件定義が固まってから基本設計に進みます。要件定義が曖昧なまま基本設計に入ると、設計のやり直しが発生し、費用も納期も膨らみます。
料理にたとえると、要件定義は「誰のために、どんな料理を、どんな目的で出すか」を決める段階、基本設計は「その料理をどんな材料と手順で作るか」を決める段階です。出したい料理が決まっていないのに調理法から考え始めても意味がないのと同じで、順序には必然性があります。発注側は前半の「何を出すか」に責任を持ち、後半の「どう作るか」はプロである開発会社に委ねる、という分担で考えると関わり方を間違えません。
なぜ発注側が違いを知るべきか
「工程の違いは開発会社が分かっていればよいのでは」と思うかもしれません。しかし発注側が違いを理解していないと、関わり方を間違えます。
よくあるのが、要件定義の段階で「ボタンの色は青で」といった設計レベルの細かい指定をしてしまい、肝心の業務要件が固まらないケースです。逆に、基本設計で画面が見えてから「そもそもこの業務が抜けている」と要件レベルの指摘をすると、大きな手戻りになります。各工程で議論すべきレベルが違うと知っていれば、適切なタイミングで適切な意見を出せます。
もう一つ、違いを知っておくとスケジュールの見通しも立てやすくなります。要件定義に時間がかかっているのに「早く開発に進んでほしい」と急かすと、土台が固まらないまま設計に入り、かえって後で時間を失います。要件定義と基本設計はどちらも開発前の準備段階であり、ここを丁寧にやることが結果的に開発全体を速くする、という関係を理解しておくと、開発会社との認識も揃いやすくなります。
要件定義書と基本設計書・仕様書の違いと関わり方
要件定義書と仕様書は作られる時期が違う
要件定義書と仕様書も混同されやすい書類です。最大の違いは、作られる時期と目的です。要件定義書はシステム開発を始める前に、発注側と開発会社が「何を作るか」の認識を合わせるために作られます。
一方、仕様書（詳細仕様書）は、開発を進める中で、実際にプログラムを書く開発者やテストする担当者に向けて作られる、より技術的な文書です。要件定義書が「発注側と開発会社の合意書」だとすれば、仕様書は「開発チーム内の設計図」に近い位置づけです。
そのため、発注側がすべての仕様書を細かく読み込む必要はありません。仕様書は技術者向けの文書であり、発注側が見るべきは、その手前にある要件定義書と基本設計書が中心になります。
用語の使われ方は開発会社によって幅があり、「仕様書」が要件定義書に近い意味で使われることもあれば、詳細設計書を指すこともあります。名前の違いに振り回されるより、「この書類は開発前の合意なのか、開発中の技術文書なのか」「発注側の確認が必要なのか」を聞いて確かめるほうが実務的です。書類の名前ではなく、その書類が果たす役割で判断する習慣をつけておきましょう。
発注側が書類ごとに確認すべきこと
届く書類の順に、発注側が確認すべき観点を整理すると次のようになります。専門用語の正しさではなく、自社の業務と要望に合っているかを見るのが基本です。
書類ごとの確認観点
- 要件定義書：解決したい課題とやりたいことが正しく反映されているか
- 基本設計書：画面や操作が業務の流れに合っていて、現場が使えるか
- 仕様書：原則は開発会社に任せ、業務に関わる部分だけ説明を求める
特に基本設計書は、要件定義の内容が初めて目に見える形になる段階なので、利用部門の担当者にも確認してもらうのが効果的です。要件定義書の承認時に何を見るべきかは要件定義書レビューのチェックリストに観点をまとめています。
書類を確認するときのコツは、自分が分かる言葉に置き換えながら読むことです。専門用語が出てきたら、「これは普段の業務でいうと何にあたるか」を開発会社に確認しながら進めると、理解が追いつきます。分からない用語を放置したまま承認してしまうのが一番危険で、後で「そういう意味だったのか」と気づいても手遅れになりがちです。確認の場では、分からないことを分からないと言える関係をつくっておくことも、良い書類レビューの前提になります。
関与が薄れる境界を意識する
発注側の関与は、要件定義をピークに、基本設計、詳細設計、仕様書と進むにつれて徐々に薄くなります。これは自然な流れで、技術的な深さが増すほど開発会社の領域になっていくからです。
大事なのは、その境界を意識することです。要件定義と基本設計までは発注側がしっかりレビューして合意し、それ以降の詳細な仕様は開発会社に委ねる。この線引きができていると、開発会社の専門性を活かしつつ、発注側として押さえるべき要所は外さずに済みます。すべてに口を出すのも、すべてを丸投げするのも、どちらもうまくいきません。
なお、要件定義書や基本設計書で合意した内容は、以降の開発・検収の基準になります。後から「やっぱり違う」と覆すと追加費用につながるため、確認は各書類が届いた段階で丁寧に行うのが結局いちばん早道です。
書類の違いがわからないときの進め方
それでも書類の違いや自分の確認範囲に迷うときは、開発会社に率直に聞くのが一番です。「この書類は何を確認すればいいですか」「私たちが見るべき部分はどこですか」と質問すれば、誠実な会社なら分かりやすく説明してくれます。
むしろ、書類の意味を発注側に説明できない、あるいは「専門的なので任せてください」とだけ言う会社は注意が必要です。発注側が理解できる言葉で書類の役割を説明できることは、良い開発パートナーの条件のひとつです。誰がどの書類を作り、発注側がどこに関わるのかという役割分担は要件定義書は誰が作るかの解説もあわせて読むと整理できます。
書類が増えてくると不安になりますが、覚えておくべきことはシンプルです。要件定義書で「何を作るか」を合意し、基本設計書で「どう作るか」を確認する。この2つさえ自分の目で見ておけば、残りの技術的な書類は開発会社に任せて問題ありません。書類の数ではなく、押さえるべき2つの節目に集中することが、発注側にとって現実的な関わり方です。
