当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内(広告)を含みます。
『来月から基本設計書を書いて』と言われて、何から手をつければいいか分からない。そんな方も多いはずです。
結論から言うと、基本設計書は利用者から見たシステムの動きを決める文書です。「画面」「帳票」「データ」「外部との連携」「非機能」の5つの部品に分けて書けば、抜けの少ない形にまとまります。
この記事を読めば、基本設計書に書く項目と、書き始めるまでの順番が分かります。

基本設計とは?基本設計書で決めること
基本設計とは、要件定義で決めた「何を作るか」を、利用者から見える形に具体化する工程です。基本設計書は、その結果をまとめて発注側と開発側で確かめ合うための文書です。
『要件定義書があるのに、なぜもう一つ文書が必要なの?』と感じる方もいますよね。要件定義書は「できるようにしたいこと」を書く文書なので、画面の形やデータの持ち方まではまだ決まっていないことが多いんです。
IPAのDX SQUARE「要件定義とは?」では、基本設計を「要件定義でまとめた要件を具体化し、業務フローを明確にする工程」と説明しています。必要な機能やソフトウェア構成を決め、外部インタフェースを整理する工程とされています。
デジタル庁のDS-100(デジタル・ガバメント推進標準ガイドライン)でも、「画面、帳票等の利用者にとって直接的に理解することができる基本設計を行った後に、機能を実現するための詳細設計を行う」と順番が示されています。
job tagに書かれている基本設計の中身
厚生労働省の職業情報提供サイト job tag(2025年時点の掲載)では、受託開発のSEの仕事として、要件定義をもとにデータベースの設計や外部システムとの連携、画面構成などを固めるのが基本設計だと紹介されています。
基本設計書は、言いかえると「このシステムを使う人が、何を見て、何を入れて、何が出てくるか」を決めた文書です。中の処理をどう組むかは、次の詳細設計で決めます。
| 工程 | 決めること | まとめる文書 |
|---|---|---|
| 要件定義 | 何ができればよいか | 要件定義書 |
| 基本設計 | 利用者から見た画面・帳票・データ・連携 | 基本設計書 |
| 詳細設計 | 中の処理の作り方 | 詳細設計書 |
要件定義書との違いは要件定義書と仕様書の違い、設計書全体の種類は設計書とは?システム開発の設計書の種類と役割で紹介しています。
外部設計・内部設計という呼び方
現場では、基本設計を「外部設計」、詳細設計を「内部設計」と呼ぶことがよくあります。利用者から見える外側を決めるのが外部設計、プログラムの内側を決めるのが内部設計、という分け方です。
ただ、この対応を定めた公的な資料は、編集部では確認できませんでした。会社によっては、基本設計の中に外部設計と内部設計の両方を含めることもあります。
- 利用者から見える画面や帳票を決める
- 発注側も読んで確かめる
- 外部システムとのやり取りを決める
- プログラムの中の処理を決める
- 主に開発側が読む
- モジュールの分け方やデータの受け渡しを決める
『うちの会社の「基本設計」は、どこまでのこと?』と迷ったら、社内の過去の基本設計書の目次を見てみてください。それがいちばん確かな答えです。
基本設計書は「5つの部品」で組み立てる
基本設計書は、「画面」「帳票」「データ」「外部との連携」「非機能」の5つの部品に分けて書くと抜けが減ります。部品ごとに、誰が何を確かめるかまで決めておくのがコツです。
基本設計書を書き始めると、『どこまで書けば終わりなの?』と不安になりますよね。そこで編集部がおすすめしたいのが、部品に分けて考える方法です。
デジタル庁のDS-100では、要件定義書の機能要件として「機能」「画面」「帳票」「データ」「外部インタフェース」に関する事項を挙げています。基本設計書は、この要件を一つずつ形にしていく文書なので、同じ切り口で分けると対応がたどりやすくなります。

5部品の構成表
次の表は、編集部が基本設計書の中身を5つの部品に分けてまとめたものです。どの部品から書いてもかまいませんが、画面とデータは早めに固めると後が楽になります。
| 部品 | 書く項目の例 | 主に確かめる人 | 決まっていないと困ること |
|---|---|---|---|
| 画面 | 画面一覧、画面レイアウト、入力項目、ボタンの動き、画面遷移 | 発注側の利用者 | 使い勝手のズレが後から見つかる |
| 帳票 | 帳票一覧、出力項目、配置、出力のタイミング | 発注側の担当者 | 印刷して初めて足りない項目に気づく |
| データ | 扱うデータの一覧、主な項目、データ同士の関係 | 開発側・発注側 | 画面ごとに項目名がばらばらになる |
| 外部との連携 | 連携先、やり取りするデータ、タイミング、エラー時の扱い | 連携先の担当者 | 結合テストで初めて形が合わないと分かる |
| 非機能 | 性能、使える時間帯、セキュリティ、運用の方法 | 発注側の情報システム担当 | 動くけれど遅い、止まった時に困る |
画面と帳票の部品
画面の部品では、まず画面一覧を作り、そのあと1画面ずつレイアウトと項目を書いていきます。画面遷移図があると、発注側の方も全体の流れをつかみやすくなります。
画面設計書の細かい書き方は画面設計書・画面仕様書の書き方で紹介しています。
データの部品
データの部品では、システムで扱う情報(顧客、注文、商品など)の一覧と、それぞれの主な項目を書きます。テーブルの細かい定義は詳細設計で決めることも多いので、基本設計では「どんな情報をどう関係づけて持つか」までで大丈夫です。
外部との連携の部品
他のシステムとデータをやり取りするなら、連携先ごとに一枚ずつまとめておきましょう。ここが抜けると、結合テストの段階で慌てることになりがちです。
- 連携先のシステムと担当の窓口
- やり取りするデータの項目と形式
- 送る・受け取るタイミング(その都度か、まとめてか)
- 相手が止まっている時やエラーの時の扱い
非機能の部品
非機能は、機能以外の「どれくらい速く」「どれくらい止まらず」「どう守るか」の話です。IPAの非機能要求グレード2018では、大項目を可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つに分けています。
要件定義の段階で決めた非機能要件を、基本設計で実際の方式に落としていくイメージです。くわしくは非機能要件とは?で紹介しています。
基本設計書の書き方と目次の例
基本設計書は、目次を先に作ってから中身を埋めると進めやすくなります。最初から完成させようとせず、半分ほど書いた段階で読み手に見てもらうのがコツです。
『目次ってどう作ればいいの?』という方のために、編集部が作った目次の例を載せますね。実在の会社の基本設計書ではなく、5部品の考え方に沿った架空の例です。
| 章 | 見出しの例 | 中身 |
|---|---|---|
| 1 | はじめに | 文書の目的、対象の範囲、用語の説明 |
| 2 | システムの全体像 | システム構成の図、業務の流れ、機能の一覧 |
| 3 | 画面 | 画面一覧、画面遷移図、画面ごとのレイアウトと項目 |
| 4 | 帳票 | 帳票一覧、帳票ごとの項目と配置 |
| 5 | データ | データの一覧、データ同士の関係 |
| 6 | 外部との連携 | 連携先の一覧、連携ごとのデータとタイミング |
| 7 | 非機能 | 性能、運用、セキュリティなどの方式 |
| 8 | 未決事項 | まだ決まっていないことと、決める期限 |
最後の「未決事項」は、意外と大事な章です。DS-100でも、要件定義書について、未確定な要件はリスク要因になり得ることに留意してその旨を明らかにするよう定めています。基本設計書でも同じ考え方で、決まっていないことを隠さずに書いておきましょう。
書き始めるまでの手順
- 要件定義書を読み、機能の一覧を書き出す
- 社内の過去の基本設計書やテンプレートから目次を決める
- 画面一覧とデータの一覧を先に作る
- 画面・帳票・連携・非機能を一つずつ書く
- 決まっていないことを未決事項に集める
- 半分ほど書けたら、発注側と開発側の両方に見てもらう
画面一覧の記入例
例えば、社内の備品を貸し出すシステムなら、画面一覧はこんな形になります。編集部が作った架空の記入例です。
| 画面ID | 画面名 | 使う人 | できること |
|---|---|---|---|
| G01 | ログイン | 全員 | 社員番号とパスワードで入る |
| G02 | 備品の検索 | 社員 | 名前や分類で備品を探す |
| G03 | 貸出の申込 | 社員 | 借りたい日と返す日を入れる |
| G04 | 申込の承認 | 総務の担当 | 申込を見て承認か差し戻しを選ぶ |
画面IDを振っておくと、画面遷移図やテストの文書から「G03の画面」と呼べるので、やり取りがぐっと楽になります。
1画面分の項目の記入例
画面一覧ができたら、1画面ずつ項目を書いていきます。G03の貸出の申込なら、例えばこんな形です。
| 項目名 | 入力か表示か | 必須か | 決まりごと |
|---|---|---|---|
| 備品名 | 表示 | なし | G02で選んだ備品を表示する |
| 借りる日 | 入力 | 必須 | 今日より前の日は選べない |
| 返す日 | 入力 | 必須 | 借りる日より前の日は選べない |
| 使う目的 | 入力 | 任意 | 自由に書ける欄にする |
| 申込ボタン | 操作 | なし | 押すとG04の承認待ちに回る |
「決まりごと」の欄に、エラーになる条件まで書いておくのがポイントです。ここが空いていると、詳細設計やテストの担当者が『この時はどうするの?』と毎回聞きに来ることになります。
発注側にも伝わる書き方のコツ
基本設計書は、システムに詳しくない発注側の担当者も読みます。開発側だけで通じる言葉で書くと、確認してもらったつもりで中身が伝わっていない、ということが起きがちです。
- 専門用語に、最初の1回だけ説明を添えたか
- 画面や帳票は、言葉より図や表で見せたか
- 「など」「適宜」で終わる文が残っていないか
- 要件定義書のどの項目に当たるか、番号でたどれるか
基本設計書のテンプレートを使う時の注意
基本設計書のテンプレートを使うと、目次や表の形をゼロから考えずに済みます。ただ、テンプレートの項目を全部埋めることが目的になると、読み手にとって要らない情報まで増えてしまいます。
テンプレートの欄を埋めるために、要件定義書の文章をそのまま貼りつけてしまうケースがあります。基本設計書では「要件をどう形にしたか」を書くので、貼った文の下に、画面や項目として決めたことを書き足しましょう。
テンプレートの選び方は設計書のテンプレート・サンプル|Excel・Markdownの使い分けで紹介しています。
機能仕様書と基本設計書の違い
機能仕様書は「システムが何をしなければならないか」を書いた文書で、基本設計書は「それを利用者から見てどういう形で実現するか」を書いた文書です。会社によっては同じ文書を指すこともあります。
『機能仕様書と基本設計書って、何が違うの?』という疑問もよく聞きます。実は、名前の使い方が会社ごとにばらばらなので、迷うのは自然なことなんです。
ソフトウェアの用語を集めた ISO/IEC/IEEE 24765:2010 では、functional specification を「システムやコンポーネントが果たさなければならない機能を定めた文書」としています。そのうえで、要求仕様の一部であることが多いと注記しています。
つまり国際規格の言葉で見ると、機能仕様書は「要求」の側に近い文書です。一方、基本設計書は「設計」の側の文書です。
| 比べる点 | 機能仕様書 | 基本設計書 |
|---|---|---|
| 答える問い | 何をしなければならないか | 利用者から見てどう実現するか |
| 近い工程 | 要件定義から基本設計の入り口 | 基本設計 |
| 書き方の例 | 「備品の貸出を申し込めること」 | 「G03の画面で、借りる日と返す日を入れて申し込む」 |
| 会社での呼び方 | 基本設計書の一部として扱うことも | 外部設計書と呼ぶことも |
機能仕様書の書き方は機能仕様書とは?でくわしく紹介しています。社内でどちらの言葉を使っているか分からない時は、先輩に「機能仕様書と基本設計書は別に作りますか?」と一度聞いてみてください。
基本設計書でよくある相談
よく読まれている相談は「基本設計書の書き方が分からない」「パラメータシートとの違い」「基本設計書が読めない」の3つです。どれも、基本設計書が利用者から見た形を決める文書だと押さえると整理できます。
知恵袋には、基本設計書についての相談も多く寄せられています。閲覧の多いものを要約してお答えしますね。
相談1:機能を分析したのに、基本設計書の構成がまとまらない
『機能を分析して条件を盛り込んだのに、構成がいまいちで、分析しきれていない所も見つかって頭を抱えている』という相談です。
これは、機能の単位だけで書こうとした時によく起きます。機能ごとに書くと、同じ画面やデータの話があちこちに散らばってしまうんです。
そんな時は、5部品の構成表に一度並べ替えてみてください。「画面」「データ」の章に集めると、重なりや抜けが見えてきます。
相談2:パラメータシートと基本設計書は何が違う?
『サーバーの設定で、パラメータシートと基本設計書を比べると言われた。何が違うの?』という相談です。
インフラの現場では、基本設計書は「どういう方針で設定するか」を決めた文書、パラメータシートは「実際にどの値を設定したか」を一覧にした文書として使い分けることが多いです。設計で決めた方針どおりに設定されているかを、二つを並べて確かめるわけですね。
相談3:基本設計書が読めない
『詳細設計から仕事を始めたので、基本設計書を渡されても読み方が分からない』という相談です。2年目くらいで、こうした壁に当たる方は少なくありません。
読む時は、いきなり本文から入らず、目次と画面一覧、データの一覧を先に見るのがおすすめです。全体の地図をつかんでから、自分が担当する画面の章に進むと迷いにくくなります。
分からない用語や、書かれていない動きはメモしておき、まとめて書いた人に聞きましょう。「G03で、返す日が借りる日より前だったらどうなりますか?」のように、画面や項目を指して聞くと答えてもらいやすくなります。
基本設計書を書ける人になるには
基本設計書は、詳細設計やプログラムの経験を積んだあとで任されることが多い文書です。まずは読む側として基本設計書に慣れ、部分的に書く機会を増やしていくのが近道です。
『いつかは基本設計を任されるようになりたい』という方もいますよね。job tag(2025年時点の掲載)では、受託開発のSEは一般的に3年目頃には一人で詳細設計を書けるようになり、5年目頃には基本設計を含め開発全体ができるようになると紹介されています。
焦らなくて大丈夫です。今の仕事の中でも、基本設計に近づく練習はできます。
- 詳細設計を書く前に、元の基本設計書の画面と項目を読み込む
- 基本設計書の分かりにくい所を、メモで書き直してみる
- 発注側との打ち合わせに、記録係として入らせてもらう
- 画面一覧やデータの一覧だけでも、自分で作る担当を引き受ける
基本設計書を書いた経験は、要件定義や設計といった上流工程を任される職場で評価されやすい経験です。今の担当工程から一歩進みたい方は、求人の仕事内容で「基本設計」「外部設計」がどう書かれているかを比べてみると、道が見えてきます。
今の職場で少しずつ担当を広げていく道も、もちろん十分ありです。上流工程への進み方は上流工程とは?でまとめています。
IT・Webエンジニアの転職(PR)
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
よくある質問
基本設計とは何ですか?
要件定義で決めたことを、利用者から見える画面・帳票・データ・外部との連携などの形に具体化する工程です。その結果をまとめた文書が基本設計書です。
外部設計と内部設計は、基本設計と詳細設計のことですか?
現場では、基本設計を外部設計、詳細設計を内部設計と呼ぶことがよくあります。ただ、この対応を定めた公的な資料は編集部では確認できておらず、会社によって範囲が違うこともあります。社内の過去の設計書の目次で確かめてみてください。
基本設計書のテンプレートはどれを使えばいいですか?
まずは社内で使っている形式があればそれに合わせましょう。無い場合は、画面・帳票・データ・外部との連携・非機能の5部品が入る目次を作り、表で管理する部分はExcel、説明が多い部分はWordやMarkdownで書くと進めやすくなります。
機能仕様書と基本設計書の違いは何ですか?
機能仕様書は「何をしなければならないか」を書いた文書で、基本設計書は「利用者から見てどう実現するか」を書いた文書です。会社によっては同じ文書を指すこともあります。
基本設計書は誰が書きますか?
一般的には開発側のSEが書き、発注側が内容を確かめます。発注側の担当者も読む文書なので、専門用語には説明を添えておくと親切です。
まとめ
- 基本設計書は、利用者から見たシステムの動きを決める文書
- 画面・帳票・データ・外部との連携・非機能の5部品で組むと抜けが減る
- 目次を先に作り、未決事項の章を設けて決まっていないことを隠さない
- 外部設計・内部設計という呼び方は現場の慣習で、範囲は会社ごとに確かめる
- 機能仕様書は「何をするか」、基本設計書は「どう見せるか」の文書





コメント