「開発会社から基本設計書が届いたが、どこを見て承認すればよいのか分からない」——システム開発を外部に依頼した企業の担当者から、こうした相談をよく受けます。100ページを超えるPDFに、画面レイアウトと構成図と項目一覧が並んでいる。全部読む時間はない。かといって読まずに承認して、後から「それは仕様変更です」と言われるのは要注意です。
先に用語を1つ限定しておきます。「基本設計」は建築や製造の分野でも使われる言葉ですが、本記事で扱うのはシステム開発(ソフトウェア)の基本設計です。結論から言うと、基本設計とは、要件定義で合意した「何を作るか」を、利用者から見える形——画面、帳票、扱うデータ、外部システムとの連携、そして性能やセキュリティの実現方式——に具体化し、基本設計書として発注者と合意する工程です。別名を外部設計といいます。
よくある誤解が「基本設計は大雑把な設計で、詳細設計は細かい設計」というものです。これでは線が引けません。2つを分けるのは粒度ではなく、設計の対象と読者です。基本設計書は発注者が読んで承認する文書、詳細設計書はプログラマーが読んで実装する文書です。この区別が分かると、設計書のどこを自分が見るべきかも決まります。
本記事では、基本設計の定義と外部設計との関係、要件定義との境目と詳細設計との違い、基本設計書に含まれる成果物、発注者がレビューで見るべき5点と承認が持つ意味、期間と工数の目安、オフショア開発での扱いと当社の体制、よくある質問の順に解説します。3工程の分担と成果物の全体像は図解にしました。要件定義という工程そのものの解説は「要件定義とは」の記事に、基本設計書の記入例は別の記事に譲ります。
私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。相談で多いのが「設計書が出てこないまま実装が始まってしまった」という話です。海外チームに任せる場合、基本設計書は唯一の共通言語になります。読み終えるころには、届いた設計書のどこに赤を入れるべきかが分かるようになっているはずです。
目次
- 基本設計(外部設計)とは
- 基本設計の定義
- 「基本設計」と「外部設計」は同じものを指す。呼び方が分かれる理由
- 工程の前後——要件定義を受け取り、詳細設計へ渡す
- 要件定義との境目と、詳細設計との違い
- 3工程の比較
- 「基本設計=大雑把、詳細設計=細かい」では線が引けない
- 境目が曖昧になりやすい3か所
- 基本設計書に含まれるもの
- 成果物は6つの分類で捉える
- 画面と帳票——利用者が直接触る部分
- データ・外部連携・非機能の実現方式
- 発注者が基本設計レビューで見るべき5点と、承認が持つ意味
- レビュー観点5つ
- 承認は「次工程へ進む許可」
- 期間と工数の目安
- オフショア開発での基本設計と、当社の体制
- 海外チームに渡すとき、基本設計書が唯一の共通言語になる
- 当社は日本人PMが設計の文書化とレビューを担う
- 向く案件と向かない案件
- 基本設計に関するよくある質問
- Q1. 「基本設計」と「外部設計」は違うものですか
- Q2. 基本設計は英語で何と言いますか
- Q3. 基本設計書を作らない開発は問題がありますか
- Q4. 非機能要件は要件定義と基本設計のどちらで決めるのですか
- Q5. 発注者は基本設計にどこまで口を出してよいのですか
- まとめ: 基本設計とは、作るものの姿を発注者が判定できる最後の工程
基本設計(外部設計)とは——要件で決めた「何を」を、利用者から見える形に具体化する工程
まず言葉の範囲を限定します。本記事で扱うのは、システム開発(ソフトウェア)の基本設計です。同じ言葉は建築や製造の分野でも使われますが、そちらの意味には触れません。ここで説明するのは、システムを外部の会社に発注したときに、要件定義の次にやってくる工程のことです。
基本設計の定義——外から見たシステムのふるまいを確定させる作業
本記事では、基本設計を「要件定義で決まった要求を、外から見えるシステムのふるまいとして確定させる設計工程、およびその成果物」という意味で使います。情報システム開発では、要件定義と詳細設計の中間に位置する工程です。この「外から見えるふるまい」という範囲は、IPA(情報処理推進機構)の「機能要件の合意形成ガイド」が、発注者と開発者が合意すべき領域として画面・システム振舞い・データモデル・帳票・バッチ・外部インタフェースの6つを挙げていることに対応しています(確認日2026年9月21日)。
もう少し実務に寄せて言い換えます。要件定義が「何を実現するか」を明確にする工程であるのに対し、基本設計では「どのようなシステムとして実現するか」を、利用者の視点から検討します。主な検討対象は、ハードウェアやソフトウェアの全体構成、実装すべき機能、画面や帳票、入出力インターフェースの概要、データの構造や外部システムとの連携方法です。近年はセキュリティ要件や可用性、性能、拡張性といった非機能要件についても、この段階で基本方針を定めることが多くなっています。
家づくりでたとえると分かりやすいと思います。「日当たりがよく、家族4人が快適に暮らせる家がほしい」というのが要件です。これを受けて、「南向きに大きな窓のある15畳のリビング、対面式のキッチン、子供部屋は2つ、収納は各部屋にクローゼット」と決めるのが基本設計です。壁の裏をどの経路で配線するかは、まだ決めません。それは次の工程の仕事です。
もう1つ、システムの例を出します。要件定義で「利用者が商品を購入できること」と決まったとします。基本設計では、これを商品検索・商品詳細・カート・注文情報入力・決済という機能に分解し、それぞれの画面に何を表示して何を入力させるかを決め、クレジットカード決済システムとどのようにデータをやり取りするかの方式を定めます。ここまで決まって初めて、開発者は「作れる」状態になります。
「基本設計」と「外部設計」は同じものを指す。呼び方が分かれる理由
現場では「外部設計」という呼び方も使われます。この2つは、ほぼ同じものを指すと理解して差し支えありません。
なぜ2つの呼び方があるのかというと、どこに着目するかの違いです。「基本設計」は、開発工程全体を見渡したときに、この設計が後続工程の基本になるという位置づけを強調した呼び方です。「外部設計」は、システムの外部——つまり利用者や他システムから見たときのふるまいとインターフェースを設計する、という対象の範囲を強調した呼び方です。どちらを使うかは、会社やプロジェクトが準拠している開発標準によって変わります。
大事なのは、この「外部設計」と対になるのが「内部設計」であり、それが次工程の詳細設計にあたる、という対応関係です。ここを押さえておくと、打ち合わせで「外部設計は終わりましたので、来週から内部設計に入ります」と言われたときに、何が終わって何が始まるのかが分かります。
工程の前後——要件定義を受け取り、詳細設計へ渡す
基本設計の入力は要件定義書、出力は基本設計書です。前の工程の成果物が次の工程の入力になるという関係は、開発工程の全体を通して変わりません。
システム開発の工程全体(企画、RFP・発注先の選定、要件定義、基本設計、詳細設計・実装、テスト、運用・保守)のうち、企画・要件定義・基本設計の3つをまとめて上流工程と呼びます。基本設計は、上流工程の最後に位置します。言い換えれば、発注者が業務の知識で判断できる最後の工程です。ここを越えると、決定の中身は技術判断に移っていきます。
工程全体の地図と、要件定義という工程そのものの中身については「要件定義とは」の記事で詳しく扱っています。本記事は、その次の工程である基本設計に絞って進めます。では、要件定義と基本設計、基本設計と詳細設計は、どこで線を引けばよいのでしょうか。
要件定義との境目と、詳細設計との違い——3つの工程は「読者」で分かれる
「基本設計 詳細設計 違い」という検索が多いのは、現場でこの線引きが揺れているからです。会社によって工程の切り方が違うのは事実ですが、揺れない基準が1つあります。その文書を誰が読むのか、という基準です。
3工程の比較——目的・視点・読者・成果物
要件定義、基本設計、詳細設計の3つを並べると、次のようになります。
観点 | 要件定義 | 基本設計(外部設計) | 詳細設計(内部設計) |
|---|---|---|---|
決めること | 何を実現するか(WHAT) | 外から見てどう動くか(外部のHOW) | 内部でどう作るか(内部のHOW) |
視点 | ビジネス・業務の視点 | 利用者の視点 | 開発者の視点 |
主な読者 | 発注者と開発会社の双方 | 発注者(業務担当者を含む) | プログラマー |
代表的な成果物 | 要件定義書 | 基本設計書、機能一覧、画面レイアウト、ER図、システム構成図 | 詳細設計書、クラス図、シーケンス図、テーブル定義 |
発注者の関与 | 主体的に決める | レビューして承認する | 原則として関与しない |
次工程への役割 | 基本設計ができる状態にする | 詳細設計ができる状態にする | 実装ができる状態にする |
表の最下段に注目してください。開発工程とテスト工程の対応関係を表したVモデルでは、前の工程の出力が次の工程の入力になります。この関係から言えることは単純で、基本設計は「詳細設計ができるように」するための文書であり、詳細設計は「プログラミングができるように」するための文書だということです。目的が違うので、書く内容も自動的に変わります。
「基本設計=大雑把、詳細設計=細かい」では線が引けない
初学者がよくつまずくのが、基本設計を「大雑把な設計」、詳細設計を「細かい設計」と粒度で捉えてしまうことです。近からず遠からずではあるのですが、この理解では「どこまでが基本設計か」を決められません。実際、この曖昧な定義のせいで、設計書の分量が担当者ごとにばらつくのが実情です。
具体例で見ます。社員の安否確認システムを作るとしましょう。
工程 | 同じ機能をどう書くか |
|---|---|
要件定義 | 災害時に全社員の安否を1時間以内に集計できるようにする |
基本設計 | 社員全員にアンケート付きのメールを送る。アンケートは1人1回しか回答できない。メール開封状況と回答状況を一覧で確認できる。未回答者だけにメールを再送できる |
詳細設計 | メール送信は指定のサービスのAPIを使う。回答ステータスが「完了」の場合は回答不可とする。回答状況は回答状況テーブルから指定の条件で抽出する |
基本設計の行は、業務担当者が読んで「そうそう、そういうことです」または「いや、再送は部署単位にしたい」と言える書き方になっています。詳細設計の行は、業務担当者が読んでも判定できません。これが読者で線を引くということです。
境目が曖昧になりやすい3か所——非機能要件、画面項目の粒度、外部連携
理屈は分かっても、実務では次の3か所で境目が揺れます。発注側としては、ここに注意しておくと話が噛み合います。
1つ目は非機能要件です。要件定義では「平常時の画面応答は3秒以内」という目標値を決めます。基本設計では、それをどう実現するか——サーバーの構成、キャッシュの使い方、同時アクセス数の想定——という方式を決めます。要件定義で目標値まで決まっていない場合、基本設計の段階で決め直すことになり、そのぶん見積もりがぶれます。
2つ目は画面項目の粒度です。要件定義では画面の一覧とおおまかなイメージまで、基本設計では入力桁数・データ型・必須かどうか・エラー時のメッセージまで決めます。「要件定義で画面の話は終わったはず」と思っていると、同じ画面の話が蒸し返されたように感じますが、決める深さが違うだけです。
3つ目は外部システムとの連携です。要件定義では「どのシステムと何のデータをやり取りするか」まで、基本設計では送受信の手段・頻度・形式・エラー時の扱い・再送回数まで決めます。ここは相手システム側の都合も絡むので、確認に時間がかかります。連携先が多い案件ほど、基本設計の期間は延びると考えておいてください。
3つの工程の分担が見えたところで、次は基本設計書そのものの中身に入ります。
基本設計書に含まれるもの——機能一覧・画面・帳票・データ・外部連携・非機能
基本設計書は1冊の本というより、複数の文書の束です。開発会社から届くPDFが100ページを超えるのはそのためで、中身は種類の違う文書が並んでいます。まず分類を頭に入れると、どこを読めばよいかが決まります。
成果物は6つの分類で捉える
分類の下敷きになるのが、IPAが公開している「機能要件の合意形成ガイド」です。このガイドは、発注者と開発者の合意形成が不十分だと下流工程で手戻りが起きるという問題意識から、画面・システム振舞い・データモデル・帳票・バッチ・外部インタフェースという6つの技術領域ごとに、伝え方と書き方のコツをまとめたものです(IPA、2010年3月公開)。実務の基本設計書は、この6領域に「全体像」と「非機能の実現方式」を加えた形になっていると考えると整理しやすくなります。
分類 | 代表的な成果物 | そこで決まること | 発注者の関与 |
|---|---|---|---|
全体像 | システム概要、システム化の範囲、システム構成図 | 今回作る範囲と作らない範囲、サーバーやクラウドサービスの構成 | 中(範囲の確認) |
機能 | 機能一覧、業務フロー図 | 実装する機能の一覧と階層、業務の流れとシステムの対応 | 高 |
画面・帳票 | 画面一覧、画面遷移図、画面レイアウト、画面入出力項目一覧、帳票レイアウト、帳票出力項目一覧 | 画面の並びと遷移、表示・入力する項目、出力する帳票の書式 | 高 |
データ | ER図(テーブル関連図)、テーブル・ファイル一覧、CRUD図 | システムが扱うデータの種類と関係、どの機能がどのデータを作り・見て・更新し・消すか | 中 |
外部連携 | 外部システム関連図、外部インターフェース一覧・定義書 | 連携先、やり取りするデータ、送受信の手段・頻度・形式、エラー時の扱い | 中〜高 |
非機能 | 非機能要件の実現方式(可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境) | 目標値をどう満たすかの方式、運用の前提 | 中(目標値の確認) |
バッチ | バッチ処理一覧、バッチ処理フロー | 夜間や定期で自動実行する処理の内容とタイミング | 中 |
規模が小さければ作る文書も減ります。1画面のフォームと1つの通知メールだけのシステムに、CRUD図やバッチ処理フローは要りません。ただし分類そのものは変わらないので、「今回はこの分類を作らない」と決めた記録が残っているかどうかが、あとで効いてきます。なお、非機能の6項目はIPA「非機能要求グレード2018」の6つの大項目(可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー)に対応しています。
画面と帳票——利用者が直接触る部分
6分類のうち、発注者が最も判定しやすく、かつ判定しなければならないのが画面と帳票です。専門用語が並ぶので、1行ずつ言い換えておきます。
- 画面一覧: システムに何画面あるかの目次
- 画面遷移図: どの画面からどの画面へ移動できるか、その条件は何かを線でつないだ図。要件定義では正常な流れだけを書きますが、基本設計ではエラーになったときの移動先まで決めます
- 画面レイアウト: 画面の見た目。どこに何を置くかの配置図
- 画面入出力項目一覧: 項目ごとに、入力できる最大桁数、データ型(文字か数字か)、全角か半角か、必須かどうか、初期表示する値、計算式などを一覧にした表
- 帳票レイアウト: 請求書や納品書など、印刷またはファイル出力する書類の書式
- 帳票出力項目一覧: 帳票に載る項目ごとの、フォント、文字揃え、桁数、日付の書式、計算の出し方
帳票は特に注意が必要です。企業の公式な書類として扱われることが多く、法令で様式が決まっていたり、取引先が既存の書式を前提に運用していたりします。1ミリのずれも許されないケースがあるのはこのためです。当社が手がけた決済アプリの開発でも、Stripeを使った決済処理と並んで、PDFで出力する明細の項目と体裁の確定に相応の時間をかけました。
データ・外部連携・非機能の実現方式
残りの3分類は、発注者が細部まで判定するのは難しい領域です。ただし、判定すべき点はあります。
データ設計の中心はER図です。「顧客」「商品」「注文」といった、システムが管理する対象(エンティティ)と、その間の関係を図にしたものです。基本設計の段階では、特定のデータベース製品に依存しない論理的なER図を作り、実際のテーブル定義などの物理設計は詳細設計で行います。発注者が見るべきなのは、自社の業務で使っている概念が漏れなく載っているか、という1点です。たとえば「1つの注文に複数の納品がぶら下がる」という自社の商習慣が、図の上で1対多の関係として表現されているかを確認します。
外部連携は、連携先のシステムごとに、やり取りするデータの中身と、送受信の手段(APIか、ファイル転送か)、頻度、エラーが出たときの再送回数などを決めます。相手システムの担当者との調整が必要になるため、ここが遅れると基本設計全体が止まります。発注者の役割は、社内の連携先システムの担当部署をつなぐことです。
非機能は、要件定義で決めた目標値を、どう実現するかの方式です。「ページ表示は3秒以内」に対して、どんなサーバー構成でどう処理を分けるのか。「個人情報は暗号化して保存する」に対して、どの方式を使うのか。ここは技術判断の比重が高いので、発注者は方式そのものより、目標値の前提——同時に使う人数、データ量の伸び、止まってはいけない時間帯——が自社の実態と合っているかを確認してください。
なお、基本設計書のテンプレートや項目ごとの記入例については、別の記事で扱います。本記事で押さえてほしいのは、成果物には分類があり、そのどれを自分が判定すべきかが決まっている、という点です。
発注者が基本設計レビューで見るべき5点と、承認が持つ意味
ここが本記事の中心です。基本設計書のすべてを発注者が読む必要はありません。読むべきなのは、業務を知っている人にしか判定できない箇所です。開発会社は要件定義書に書かれた範囲でしか判断できず、書かれていない業務上の例外は補えません。逆に言えば、そこだけは発注者が引き受けるしかないということです。
レビュー観点5つ——画面遷移、権限、例外処理、帳票項目、非機能の実現方式
優先順に5つ挙げます。この順で見てください。
観点 | 具体的に確認する質問 | 見落としたときに起きること |
|---|---|---|
1. 画面遷移が業務の流れと合っているか | 実際の担当者が1日に何度も行う操作が、最短の手数でできるか。途中で中断して後から再開する運用はあるか。前の画面に戻ったとき入力内容は残るか | 画面数は足りているのに現場で使われない。Excelでの二重管理が残る |
2. 権限——誰にどの操作を許すか | 役割ごとに、見られる範囲と操作できる範囲は分かれているか。他部署のデータは見えてよいか。金額の修正や削除は誰まで許すか。承認を挟む操作はどれか | 本来見えてはいけないデータが見える。承認なしに金額が書き換わる。あとから権限を足すと画面の作り直しになる |
3. 例外処理——想定外が起きたときの扱い | 締め処理の途中で失敗したらどうなるか。重複して登録されたらどう扱うか。取消・訂正の操作はあるか。過去分をさかのぼって直す運用はあるか | テスト工程や本番稼働後に発覚し、設計に戻る手戻りになる。運用でカバーする約束が現場の負担になる |
4. 帳票の出力項目 | 取引先へ出す書類に、必要な項目がすべて載っているか。但し書き、振込先、担当者名、印影の扱いはどうするか。既存の書式と並べて違いがないか。消費税や端数の計算方法は合っているか | 取引先から差し戻される。法定の様式を満たさない。印刷してから気づき、リリース直前に修正が入る |
5. 非機能の実現方式の前提 | 想定している同時利用者数とデータ量は自社の実態と合っているか。止まってはいけない時間帯はいつか。バックアップからどこまで戻せるか。誰が運用を担うか | 繁忙期に動かない。障害からの復旧に想定外の時間がかかる。運用の手間が社内に残る |
1と2と3は、開発会社には絶対に分かりません。たとえば在庫の引当を誰が解除できるかは、その会社の業務ルールです。月末の締め処理が走っている最中に受注が入ったらどう扱うかも、社内の取り決めです。設計書に書かれていなければ、開発会社は一般的な作りにします。そして一般的な作りは、たいてい自社の運用と合いません。
進め方のコツを1つ挙げます。120ページを1人で読まないことです。画面遷移と権限と例外処理は現場の業務担当者、帳票は経理や営業事務、非機能は情報システム部門というように、分担してレビューしてください。判断できない箇所は無理に決めず、質問としてまとめて返すほうが早く進みます。
承認は「次工程へ進む許可」——その後の変更は仕様変更になる
基本設計の完了とは、発注者から正式な承認を得た時点を指します。これは形式的な手続きではありません。次の詳細設計工程に進むための公式な許可であり、後の仕様変更に関するトラブルを防ぐための記録にもなります。
言い換えると、承認前と承認後では、同じ「画面の項目を変えたい」という要望の扱いが変わります。承認前はレビューでの指摘であり、修正は基本設計工程の中で吸収されます。承認後は、合意した仕様との差分、つまり仕様変更として扱われ、追加の工数と納期の再調整の対象になります。
これは開発会社が意地悪をしているのではなく、そうしないと見積もりが成立しないからです。ただし発注者としては、承認するまでは遠慮せずに指摘してよい、という理解が大事です。「もう決まったことだから」と感じる必要はありません。決まったことにするのが承認です。仕様変更の線引きと追加費用の考え方については「仕様変更 追加費用」の記事で詳しく扱っています。
期間と工数の目安——工数で約16%、工期で約20%
レビューに時間をかけてよいのか、という疑問には数字で答えます。IPA「ソフトウェア開発データ白書2018-2019」の原典(図表7-1-16・図表7-1-3、いずれも新規開発・開発5工程)によれば、基本設計の比率の中央値は、実績工数で15.5%、実績月数(工期)で19.8%です。参考までに、詳細設計は工数16.7%・工期17.5%、製作(製造)は工数32.6%・工期23.3%(いずれも中央値)です。
つまり基本設計は、開発期間の5分の1を占める工程です。「設計書のレビューに2週間もらえませんか」という依頼は、全体から見て過大な要求ではありません。ただしこの比率は工程の切り方によって変わるため、自社のプロジェクトに当てはめて考え直す必要があります。同じ白書の数値でも、要件定義工程を含めた場合の比率は別の集計になっており、単純に足し引きできない点にも注意してください。工程別の見積もりの読み方は「システム開発 見積もり 内訳」の記事にまとめています。
私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。相談で多いのが「設計書が出てこないまま実装が始まってしまった」という話です。画面のデモを見せられて進捗を確認していたが、権限も例外処理も決まっていなかった、というパターンが典型です。では、開発チームが海外にいる場合、基本設計はどう変わるのでしょうか。
オフショア開発での基本設計と、当社の体制
開発チームが海外にいる場合、基本設計の重みは国内開発より増します。ここでは当社がどう進めているかを、向かない案件も含めて書きます。
海外チームに渡すとき、基本設計書が唯一の共通言語になる
国内の開発会社であれば、設計書に書かれていない部分を、日本の商習慣や過去の類似案件から補って作ってくれることがあります。良くも悪くも「察して」埋まる部分です。海外チームにはこれがありません。書かれていないことは、そのまま抜けます。
具体例を挙げます。請求書に「消費税の端数は切り捨て」と書かなければ、四捨五入で作られます。「営業日」の定義を書かなければ、ベトナムの祝日で計算されることもあります。承認者が不在のときの代理承認を書かなければ、その機能は存在しません。どれも日本国内なら口頭で済んでいた部分です。基本設計書が唯一の共通言語になる、というのはこういう意味です。
逆に言えば、設計をきちんと文書にする体制さえ作れば、オフショアの品質は「人」ではなく「仕組み」で担保できます。海外チームの品質問題として語られるものの多くは、設計の粗さが原因です。
当社は日本人PMが設計の文書化とレビューを担う
当社はベトナム・ホーチミンを拠点に、2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインするラボ型開発を提供しています。体制は2パターンあり、日本人PMまたはブリッジSEをフロントに置くパターンAを推奨しています。基本設計を伴う案件では、このパターンAが前提になると考えてください。
日本人PMが担うのは、発注者からのヒアリングの設計、決まったことの文書化、そして設計レビューです。当社の品質担保は3点——日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェック——で構成しており、最初の1つが基本設計の工程にあたります。時差は2時間なので、日本の午前中に出した質問はその日のうちに返ってくるのが通常です。
介護記録SaaSのCareViewerでは、日本語のできるブリッジSE1名とフルスタックエンジニア2名という体制で、週次で開発の優先順位を判断しながら継続開発しています。要件が動き続けるプロダクトでも、決めたことを文書に残す運用を挟めば、認識のずれは抑えられます。費用は、最小構成の日本人PMフロント+2〜3人月で月額約80万円からです。公開単価は実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年目安・ブリッジSEで3,000USD(1USD=150円換算が目安)としています。
向く案件と向かない案件
向くのは、業務の内容が社内で言語化されており、画面や帳票の仕様を発注者側で判定できる案件です。基幹業務システムの刷新、SaaSの継続開発、既存システムの機能追加は相性が良いと考えています。
向かないのは、発注者側に業務を判定できる人がいない案件です。基本設計書を出しても、誰もレビューできないまま承認されると、テスト工程で全部が噴き出します。この場合は、業務の整理から伴走できる国内のコンサルティング会社を先に入れるほうが結果的に安く済みます。また、本番の個人データを海外に出せない案件や、対面での日次調整が必須の案件も、当社の体制には向きません。合わない案件には、その旨を率直にお伝えしています。
基本設計に関するよくある質問
最後に、発注側の担当者から実際によく受ける質問を5つ取り上げます。いずれも本文で触れた内容の補足ですが、打ち合わせの場で言葉に詰まりやすい論点なので、独立させて答えておきます。
Q1. 「基本設計」と「外部設計」は違うものですか
ほぼ同じものを指します。違うのは着目点で、「基本設計」は開発工程の中で後続工程の基本になるという位置づけを、「外部設計」はシステムの外側から見たふるまいを設計するという対象の範囲を、それぞれ強調した呼び方です。どちらを使うかは会社やプロジェクトの開発標準によります。ただし、相手がどちらの言葉を使っているかによって成果物の範囲が微妙に違うことがあるので、契約前に「基本設計の成果物として何を納品するか」を一覧で確認しておくと安全です。
Q2. 基本設計は英語で何と言いますか
最も一般的なのは Basic Design です。詳細設計を Low-Level Design と呼ぶ場合の対として High-Level Design(HLD)が使われることもあり、こちらも同義に近い使われ方をします。システムの骨格を決める側面を強調するときは Architectural Design、外部から見える部分という範囲を強調するときは External Design が使われます。海外のエンジニアと話す場合は、Basic Design または High-Level Design と言えばおおむね通じます。
Q3. 基本設計書を作らない開発は問題がありますか
規模と体制によります。1〜2名の小規模な改修や、発注者と開発者が同じ場所で毎日会話できる体制であれば、正式な基本設計書を省いて画面のモックアップと箇条書きの仕様で進めることはあります。問題になるのは、承認の記録が残らないことです。何を合意したかが曖昧だと、追加費用の線引きも検収の判定もできません。文書の形式を軽くするのはかまいませんが、「画面遷移」「権限」「例外処理」「帳票項目」の4点だけは、どんな形でも記録を残してください。
Q4. 非機能要件は要件定義と基本設計のどちらで決めるのですか
原則は、要件定義で目標値を決め、基本設計でその実現方式を決めます。「画面表示は3秒以内」が要件定義、「そのためにどのサーバー構成でどう処理を分けるか」が基本設計です。ただし実務では、要件定義の段階で非機能が詰め切れていないプロジェクトが少なくありません。その場合は基本設計の工程で目標値から決め直すことになり、見積もりがぶれる原因になります。要件定義書を受け取ったら、非機能の欄に測定できる数字が入っているかを先に確認してください。
Q5. 発注者は基本設計にどこまで口を出してよいのですか
「何を実現するか」に関わる部分は、遠慮なく指摘してください。画面の並び、誰にどの操作を許すか、帳票に載せる項目、例外時の扱いは、業務を知っている発注者にしか判定できません。一方、そのために内部でどんな処理方式を使うか、どのテーブル構成にするかは、開発会社の技術判断に委ねる領域です。線引きの目安は「それは業務の決めごとか、作り方の決めごとか」という問い。
まとめ: 基本設計とは、作るものの姿を発注者が判定できる最後の工程
システム開発における基本設計(外部設計)とは、要件定義で合意した「何を作るか」を、利用者から見える形——機能、画面、帳票、扱うデータ、外部システムとの連携、非機能要件の実現方式——に具体化し、基本設計書として発注者と合意する工程です。詳細設計(内部設計)との違いは粒度ではありません。基本設計書は発注者が読んで承認する文書、詳細設計書はプログラマーが読んで実装する文書という、読者の違いで線が引かれます。
発注者がレビューで優先して見るべきなのは5点です。画面遷移が実際の業務の流れと合っているか。誰にどの操作を許すかという権限。想定外が起きたときの例外処理。取引先へ出す帳票の出力項目。そして非機能の実現方式が前提としている利用者数やデータ量が、自社の実態と合っているか。このうち最初の4つは、業務を知っている発注者にしか判定できません。基本設計書の承認は次工程へ進む公式な許可であり、承認後の変更は仕様変更として追加費用と納期の再調整の対象になります。期間の目安は、IPAの白書の中央値で工数15.5%、工期19.8%。レビューに2週間を求めるのは、過大な要求ではありません。
前の工程である要件定義そのものの中身と、開発全体での位置づけは要件定義とはにまとめました。承認後の変更がどこから追加費用になるかは仕様変更の追加費用をご覧ください。海外チームに開発を任せる場合、基本設計書は唯一の共通言語になります。書かれていないことは補ってもらえません。当社は日本人PMが設計の文書化とレビューを担い、決めるのは御社という線引きで進めています。現在の体制と要件をお聞かせいただければ、どこから手をつけるべきかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。