外部設計とは?基本設計・詳細設計との違いとSES案件の工程の読み方|案件票の「工程」欄チェックとスキルシート例文つき
公開日:2026年9月30日更新日:2026年9月30日
外部設計とは?
外部設計とは、システムを使う人から見える部分を決める設計のことです。具体的には、画面の見た目や項目、帳票(印刷する書類)の形、ほかのシステムとのデータのやりとりを決めます。
外部設計は、お客様(発注者)と一緒に決める工程です。お客様が「この画面で、この項目を入力したい」と確認しながら進めます。そのため、技術の知識に加えて、お客様と話して合意をとる力が求められます。
外部設計で作る書類をまとめて「外部設計書」と呼びます。検索でよく探される「システム外部設計書のサンプル」は、次のような書類の集まりです。
| 書類の名前 | 中身 | お客様が確認すること |
|---|---|---|
| 画面設計書(画面仕様書) | 画面の配置、入力項目、ボタンの動き | 使いやすいか、項目に漏れがないか |
| 帳票設計書 | 印刷する書類や出力ファイルの形 | 必要な情報が載っているか |
| 外部インタフェース設計書 | ほかのシステムとやりとりするデータの形 | つなぎ先の仕様と合っているか |
| 画面遷移図 | どの画面からどの画面へ移るか | 操作の流れが自然か |
IPA(情報処理推進機構)は、国のIT政策を支える独立行政法人です。IPAの「機能要件の合意形成ガイド」も、お客様と決める対象に画面・帳票・外部インタフェースなどを挙げています。
外部設計・基本設計・概要設計・詳細設計の違い
外部設計と基本設計と概要設計は、現場ではほぼ同じ工程を指します。詳細設計と内部設計も、ほぼ同じ工程を指します。言葉が多いのは、会社やお客様ごとに呼び方がちがうためです。
| 呼び方 | ほぼ同じ意味の言葉 | 決めること | 見る相手 |
|---|---|---|---|
| 外部設計 | 基本設計、概要設計 | 画面・帳票・外部とのやりとり | お客様(使う人) |
| 内部設計 | 詳細設計 | プログラムの分け方、処理の手順、データベースの細かい形 | 開発チーム(作る人) |
| 方式設計 | アーキテクチャ設計 | サーバー構成や使う技術の組み合わせ | お客様と開発チーム |
基本設計とは
基本設計とは、要件定義で決めた「やりたいこと」を、システムの形に落とす最初の設計のことです。多くの現場で外部設計と同じ意味で使われます。会社によっては、外部設計に加えて方式設計まで含めて「基本設計」と呼ぶことがあります。
概要設計とは
概要設計とは、システム全体の大まかな形を決める設計のことです。「システム開発の概要設計」は、主に基本設計と同じ意味で使われます。ただし一部の現場では、基本設計より前に全体像を描く工程を指すこともあります。
詳細設計とは|内容と成果物
詳細設計とは、外部設計で決めた画面や機能を、プログラムで作れるところまで細かく決める設計のことです。内部設計とも呼ばれます。詳細設計の主な内容は次のとおりです。
機能をプログラムの単位(モジュール)に分ける
それぞれの処理の手順や計算方法を決める
データベースの表の形や項目の型を細かく決める
エラーが起きたときの動きを決める
詳細設計書は、プログラマーが読んで作業する書類です。お客様が直接読むことは少なくなります。
呼び方がちがう理由
設計の呼び方が会社ごとにちがうのは、国の法律などで決まった用語ではないためです。IPAは2013年に「共通フレーム2013」を出しています。関係者が「同じ言葉を話す」ための共通の枠組みです。そこでは「システム方式設計」「ソフトウェア詳細設計」などの名前を使っています。
ただし、現場の案件票では「基本設計」「詳細設計」という呼び方が一番多く使われます。営業は言葉の定義を議論するより、「その工程で何をするか」を確認する方が実務に役立ちます。
システム開発の工程の流れ|上流工程と下流工程
システム開発は、要件定義から始まり、設計・製造・テストを経て、運用・保守へ進みます。SI(システムインテグレーション。システムの企画から開発・運用までまとめて請け負う仕事)の工程も、基本はこの流れです。
| 順番 | 工程 | すること | 上流・下流 |
|---|---|---|---|
| 1 | 要件定義 | お客様のやりたいことを決める | 上流 |
| 2 | 基本設計(外部設計) | 画面・帳票など見える部分を決める | 上流 |
| 3 | 詳細設計(内部設計) | プログラムの作り方を細かく決める | 中流(会社により上流) |
| 4 | 製造(実装) | プログラムを書く | 下流 |
| 5 | 単体テスト | 部品ごとに正しく動くか確かめる | 下流 |
| 6 | 結合テスト | 部品をつないで確かめる | 下流 |
| 7 | 総合テスト(システムテスト) | システム全体を確かめる | 下流 |
| 8 | 運用・保守 | 動かし続け、直す | ― |
V字モデルで見る設計とテストの関係
V字モデルとは、設計の工程とテストの工程を左右に並べ、対応を示した図のことです。左側を上から下へ設計し、右側を下から上へテストします。
要件定義 ─────────────────── 総合テスト(システムテスト)
基本設計(外部設計)─────── 結合テスト
詳細設計(内部設計)─── 単体テスト
製造(実装)この図では、外部設計で決めた内容を主に結合テストで確かめます。そのため「基本設計〜結合テスト」までを担当する案件がよくあります。ただし、設計とテストの対応のさせ方は会社によってちがいます。基本設計を総合テストで確かめ、要件定義を受け入れテスト(お客様が行う最終確認)で確かめる形もあります。案件票のテスト工程の範囲は、案件元に確認しましょう。
上流工程とは
上流工程とは、要件定義や基本設計など、開発の前半でお客様と一緒に「何を作るか」を決める工程のことです。案件票で「上流経験者」と書かれていたら、少なくとも基本設計の経験を求められていると考えます。詳細設計まで含めて上流と呼ぶ現場もあります。
SES営業の現場での使い方
SES営業が設計の用語を使うのは、主に「案件票を読むとき」「人材を提案するとき」「単価を話すとき」の3つの場面です。ここでは、そのまま使える読み方と例文をまとめます。
使う場面1:案件票の「工程」欄を読む
案件票の「工程」欄は、エンジニアがどの工程から担当するかを表します。書き出しの工程が前であるほど、求められる経験は重くなります。次の表は、よくある書き方と、営業が確認するポイントです。
| 案件票の書き方 | 意味 | 営業が確認すること |
|---|---|---|
| 工程:要件定義〜基本設計 | お客様と話して決める仕事が中心 | お客様と直接話した経験があるか |
| 工程:基本設計〜結合テスト | 設計してテストまで見る | 画面や帳票を自分で設計した経験年数 |
| 工程:詳細設計〜単体テスト | 決まった設計を細かくして作る | 詳細設計書を書いた経験があるか |
| 工程:製造〜単体テスト | 設計書どおりにプログラムを書く | 使う言語の経験年数 |
案件票の書き方は会社ごとにちがいます。判断に迷うときは、案件元に次の3点を聞くと、あとのずれを防げます。
「基本設計」は画面・帳票の設計ですか、それとも方式設計も含みますか
設計書を書く人ですか、レビュー(確認)する人ですか
お客様と直接打ち合わせをしますか
使う場面2:経験年数と単価の差を読む
一般的に、上流工程から入る案件ほど単価は高くなる傾向があります。お客様と決める力や、全体を見渡す力が必要で、できる人が少ないためです。一方で、求められる設計の経験年数も長くなります。
単価の具体的な目安は、職種・言語・地域・商流で大きく変わります。この記事では金額の目安は出しません。相場の調べ方は「SESの単価相場|職種別の月額目安と公的データの使い方」を見てください。
上流案件は「単価:スキル見合い」と書かれることも多いです。提示額の決め方は「スキル見合いとは?SES案件の単価の意味と提示額の決め方」で解説しています。高い単価を狙う進め方は「SESの高単価案件を獲得する方法|商流・工程・希少性の3軸で狙う手順」が参考になります。
案件票を読むときは、次のように整理すると、提案する人を絞りやすくなります。
| 見る項目 | 下流中心の案件 | 上流から入る案件 |
|---|---|---|
| 必須スキルの書き方 | 「〇〇言語の経験3年以上」など言語中心 | 「基本設計の経験〇年以上」など工程中心 |
| 面談で聞かれること | 書いたプログラムの内容 | 設計書の種類、お客様との調整の経験 |
| 提案で強調すること | 言語・フレームワークの経験 | 設計した画面数や機能数、業務知識 |
使う場面3:人材を提案するときのスキルシートの書き方
上流ができる人を提案するときは、スキルシートの工程欄に丸をつけるだけでは伝わりません。「何を・どの規模で・誰と」決めたかを一文で書き足します。スキルシートとは、エンジニアの経歴や技術をまとめた提案用の書類のことです。
書き方の手順は次の4つです。
担当した工程を「基本設計(外部設計)」のように正式な呼び方と言いかえの両方で書く
作った設計書の種類を書く(画面設計書、帳票設計書など)
規模を数字で書く(画面数、機能数、チームの人数)
お客様との打ち合わせの有無と、自分の役割を書く
悪い例
工程:基本設計〇、詳細設計〇、製造〇
よい例
基本設計(外部設計):販売管理システムの受注まわり画面15画面、帳票5種の画面設計書・帳票設計書を作成。お客様の業務担当者と週1回の定例で仕様を合意。チーム5名中、設計リーダーを担当。
よい例なら、案件元は「基本設計を自分で書ける人」だとすぐにわかります。スキルシート全体の書き方は「SESスキルシートのフォーマットと書き方|15項目の記入例付き」にまとめています。
使う場面4:案件元やBPとの会話
営業どうしの会話でも、設計の用語はよく出ます。そのまま使える例文を3つ紹介します。
案件元に確認するとき:「工程が基本設計からとなっていますが、画面設計書を書く役割でしょうか。レビュー中心でしょうか」
BPに人材を聞くとき:「基本設計の経験が2年以上あり、お客様との打ち合わせに出た方を探しています」
体制で提案するとき:「基本設計はリーダー1名、詳細設計〜テストはメンバー2名の3名体制でご提案します」
提案メールで:「詳細設計〜テストの経験が4年あり、直近1年は基本設計(外部設計)も担当しています」
上流から入る案件は、リーダーとメンバーを組み合わせた複数名で求められることもあります。体制の組み方は「SESのチーム提案のやり方|複数名の体制の組み方と単価の出し方」で解説しています。
注意点
「上流経験あり」だけで提案しない。どの工程を何年やったかを必ず確かめる
設計書を「書いた」のか「読んだだけ」なのかを、本人に聞いて区別する
案件ごとに「基本設計」の範囲がちがうため、方式設計を含むかを確認する
経歴を実際より大きく書かない。面談で説明できない内容はトラブルのもとになる
案件元やBPから「上流経験ありにしてほしい」と頼まれたときの断り方は「SESで経歴を盛る指示の断り方|例文と営業が負う法的リスク」にまとめています。面談で設計経験を確かめる質問は「SES面談の質問内容|営業が聞くべき深掘り質問27と見極め方」から選べます。
上流工程ができる人材を早く見つける方法
上流工程の案件は、条件に合う人が少ないため、提案のスピードで決まることがよくあります。まずは自分で人材の情報を整理し、そのうえでツールで楽にする方法を紹介します。
自分でやる方法
自社エンジニアとBPの人材を1つの表にまとめる
列に「経験した工程」を足し、要件定義・基本設計・詳細設計・製造・テストに分けて年数を書く
基本設計の経験がある人には「お客様との打ち合わせ経験」の列も足す
案件が来たら、工程の列で絞り込んでから言語やスキルで絞る
Excelで管理する方法は「SESの案件・人材管理をExcelで無料で行う方法|テンプレ付き」で詳しく紹介しています。
チョータツで楽にする方法
人材が増えると、Excelの表は担当者ごとにばらばらになりがちです。チョータツは、SES営業のための案件・人材の管理・共有ツールです。
案件と人材の情報を1か所で管理し、チームで共有できる
AIが入力を手伝うので、登録の手間を減らせる
他社と連携すると、他社の営業中案件・営業中人材をデータベース化できる
パートナーへのメール配信機能で、「基本設計から入れる方を探しています」と一斉に知らせられる
3,000社以上が利用しており、無料で始められます。
よくある質問
- Q. 外部設計と基本設計は同じですか?
- 現場ではほぼ同じ意味で使われます。ただし、会社によっては基本設計にサーバー構成などの方式設計も含めます。案件票で迷ったら、担当する範囲を案件元に確認しましょう。
- Q. 概要設計とは何ですか?
- システム全体の大まかな形を決める設計のことです。多くの現場で基本設計・外部設計と同じ意味で使われます。
- Q. 詳細設計ではどんな内容を決めますか?
- 機能をプログラムの単位に分け、処理の手順やデータベースの細かい形を決めます。プログラマーがそのまま作業できるところまで細かくします。
- Q. システム設計とは何ですか?
- 要件定義で決めたことを、作れる形に落とす作業全体のことです。基本設計(外部設計)と詳細設計(内部設計)の両方を含む言葉として使われます。
- Q. SES案件で「工程:基本設計〜」とあれば、未経験の人は提案できませんか?
- 必須条件に基本設計の経験があれば、提案は難しいです。詳細設計の経験が長く、基本設計の補助をしたことがある人なら、その内容を具体的に書いて相談する価値はあります。
まとめ
外部設計とは、画面・帳票・外部とのやりとりなど、使う人から見える部分を決める設計のこと
外部設計=基本設計=概要設計、内部設計=詳細設計とほぼ同じ意味で使われる
工程は要件定義→基本設計→詳細設計→製造→テストの順。前の方ほど上流工程
案件票の工程欄は「どこから入るか」を見て、設計の経験年数と役割を確認する
上流の人材は、スキルシートに「何を・どの規模で・誰と」決めたかを書いて提案する
運営:チョータツSES研究所(株式会社DrivenX)|編集方針|公開日:2026年9月30日|更新日:2026年9月30日
参考資料(2026年9月30日確認)
独立行政法人情報処理推進機構(IPA)「SEC BOOKS:共通フレーム2013」(2013年3月4日発行。ソフトウェア・システム・サービスの関係者が「同じ言葉を話す」ための共通の枠組み)
独立行政法人情報処理推進機構(IPA)「機能要件の合意形成技法」(2010年3月公開の「機能要件の合意形成ガイド」。画面・システム振舞い・データモデル・帳票・バッチ・外部インタフェースを対象)
独立行政法人情報処理推進機構(IPA)「システム構築の上流工程強化 関連情報」