基本設計書のサンプル【2026年版】画面・機能・帳票・テーブル定義まで、記載例をそのまま写せる形で公開

「基本設計書のサンプルが見たい。空欄のテンプレートではなく、埋まっている実物が」——開発の発注担当になった方から、こうした相談をよく受けます。

検索して出てくるのは、大半がダウンロード用のテンプレートです。解凍してExcelを開くと、列名だけが並んだ真っ白なシートが出てきます。そこに何を、どの粒度で書けばよいのかは、どこにも書いてありません。結果として、空欄を眺めたまま半日が過ぎます。

理由ははっきりしています。基本設計(外部設計)の工程には、業界として標準とされる成果物が存在しないからです。IPAが公開している「機能要件の合意形成ガイド」は、この点を原文でそう明記したうえで、6つの技術領域それぞれについて作るべき成果物を「想定」として並べています(2026年9月16日確認)。標準がないのですから、テンプレートの空欄を見ても粒度は決まりません。決まるのは、実際に埋まった1枚を見たときです。

そこでこの記事では、ダウンロードを挟まずに、画面一覧・画面遷移図・画面設計書・機能一覧・帳票設計・テーブル定義・ER図・外部インターフェース一覧・バッチ一覧・非機能要件一覧の記載例を、この記事の中に表として全部書きます。あわせて、各ドキュメントで「これが書いてなければ差し戻し」という欠落例と、規模別にどこまで作れば十分かの線引きも示します。基本設計とは何か、詳細設計とどう違うかといった工程論は扱いません。そちらは別記事に譲ります。

筆者は人材業界からIT業界に移り、2018年からホーチミンで約100社の開発体制づくりを支援してきました。ERPのプライム案件を上流から下流まで担当した経験もあり、「この設計書では実装できない」と現場が止まる瞬間を何度も見ています。設計書の良し悪しは、文書の厚さではなく、実装者が迷わない欄が埋まっているかで決まる、というのが実情です。

基本設計書は1冊ではない——IPAが想定する27種の成果物と、規模別に何枚作るか

サンプルを探し始めた人が最初につまずくのは、「基本設計書」という1冊の文書を探してしまうことです。そんな文書はありません。基本設計書とは、画面・機能・帳票・データ・外部接続・バッチ・非機能に関する複数の成果物をまとめた呼び名です。ですからサンプルを探す作業は、正しくは「どの成果物を、何枚作るかを決める作業」から始まります。

業界標準の成果物リストは存在しない——だから「何枚作るか」は自分で決める

IPA(独立行政法人情報処理推進機構)が公開している「機能要件の合意形成ガイド(ver.1.0)」の概要編には、次の趣旨が明記されています。外部設計工程には、現時点で業界として標準とされる「工程成果物」が存在しない。そのうえで同ガイドは、6つの技術領域それぞれについて成果物を「想定」として並べています。2010年3月31日公開の資料で、2026年9月16日時点でもIPAのアーカイブから全編がPDFで入手できます。

つまり、どこかに正解の様式表があって、それを知らないのは自分だけ、という状況ではありません。標準がないのですから、「全部埋めなければ不合格」という基準も存在しません。判断の軸は1つだけです。実装する人が迷わずに作れて、発注した人が合否を判定できるか。この軸から逆算して、必要な成果物を必要な粒度で作ります。

なお、基本設計という工程そのものの位置づけ、要件定義や詳細設計との境目、承認が持つ意味については、『基本設計とは』の記事で扱っています。本記事は、その工程で実際に書く1枚1枚の中身に絞ります。要件定義の段階から整理し直したい場合は『要件定義の進め方』と『要件定義書のサンプル』の記事を、工程全体の並びを確認したい場合は『ウォーターフォール開発』の記事をご覧ください。

成果物一覧の記載例——6領域27種を、作る優先度つきで並べる

IPAガイドが6領域で想定している成果物は、合計27種です。下の一覧は、その27種をガイドの表記どおりに並べ、当社が実務で使っている「作る優先度」を添えたものです。優先度Aは規模を問わず作る、Bは中規模以上で作る、Cは必要な案件だけ作る、という意味です。

• システム振舞い
  • システム化業務一覧——システム利用作業または機能の一覧表 / 優先度: A
  • システム化業務フロー——業務全体の流れのうちシステム化する部分を識別した図 / 優先度: B
  • システム化業務説明——システム利用作業と機能の内容 / 優先度: B
  • システム振舞い共通ルール——図表の記述ルールと構成要素の整理分類ルール / 優先度: C
• 画面
  • 画面一覧——システムで使用する画面の一覧 / 優先度: A
  • 画面遷移——画面間の遷移関係と、遷移のキッカケとなるイベント / 優先度: A
  • 画面レイアウト——項目・イベント発生オブジェクト名とその配置 / 優先度: A
  • 画面入出力項目一覧——画面に入出力する項目の外部仕様 / 優先度: A
  • 画面アクション明細——画面遷移に伴って起動させる動作 / 優先度: B
  • 画面遷移・レイアウト共通ルール——画面群が準じる典型的なレイアウトや遷移のポリシー / 優先度: B
• データモデル
  • ER図——エンティティとリレーションシップの図 / 優先度: A
  • エンティティ一覧——エンティティの一覧 / 優先度: A
  • エンティティ定義——エンティティ名およびエンティティごとの属性の一覧 / 優先度: A
  • CRUD図——業務とエンティティの関係 / 優先度: C
• 外部インタフェース
  • 外部システム関連図——システム間のデータ送受信関係の図 / 優先度: B
  • 外部インタフェース一覧——外部インタフェースを一覧化したもの / 優先度: A
  • 外部インタフェース項目説明——やりとりする項目に関する定義 / 優先度: A
  • 外部インタフェース処理説明——データのやりとり方式の概要 / 優先度: B
• バッチ
  • バッチ処理一覧——バッチ処理機能とバッチ実行単位の一覧 / 優先度: A
  • バッチ処理フロー——ジョブの流れとジョブステップの流れ / 優先度: B
  • バッチ処理定義——ジョブごとの入力・処理内容・出力 / 優先度: B
  • バッチ処理共通ルール——処理時間・運用に関する制約や分類のルール / 優先度: C
• 帳票
  • 帳票一覧——作成する帳票を一覧化したもの / 優先度: A
  • 帳票概要——帳票の概要、物理的な属性、動作環境、運用要件 / 優先度: B
  • 帳票レイアウト——データの出力位置と大きさ / 優先度: A
  • 帳票項目説明——印字されるデータ項目の属性情報 / 優先度: A
  • 帳票編集定義——データの転記・編集、改ページ、ヘッダ/フッタの編集要件 / 優先度: C

この27種に加えて、実務ではシステム構成図(サーバ・ネットワーク・ミドルウェアの構成)と非機能要件一覧を足します。IPAのガイドが機能要件に絞っているため、非機能はガイドの対象外だからです。合計29枚が、基本設計書の最大構成だと考えてください。

規模別にどこまで作るか——小規模で省略してよいもの、絶対に省けないもの

29枚を全部作る案件は、実際には多くありません。当社が2018年から約100社の開発体制づくりに関わってきた範囲では、開発費で3,000万円を超える案件でようやく20枚台になる、という感覚です。開発費ベースの目安を挙げます。

• 小規模(〜300万円)——作る枚数の目安: 8〜10枚 / 画面一覧/画面レイアウト/画面入出力項目一覧/機能一覧/エンティティ定義(テーブル定義)/非機能要件一覧 / システム化業務フロー、CRUD図、各種共通ルール、帳票編集定義、バッチ処理フロー
• 中規模(300万〜3,000万円)——作る枚数の目安: 14〜18枚 / 上記+画面遷移/ER図/外部インタフェース一覧/外部インタフェース項目説明/帳票一覧/帳票レイアウト/帳票項目説明/バッチ処理一覧 / CRUD図、バッチ処理共通ルール、帳票編集定義
• 大規模(3,000万円〜)——作る枚数の目安: 22〜29枚 / 上記+システム化業務フロー/画面アクション明細/各種共通ルール/バッチ処理定義/外部システム関連図 / 該当機能がない領域のみ

省略の判断で外してはいけない考え方が1つあります。「その成果物が無いことで、誰かが勝手に決めることになるか」で判断する。枚数や工数で判断すると必ず間違えます。たとえばCRUD図は、無くても実装者が困ることは少ないので省略できます。一方で画面入出力項目一覧は、無いと実装者が桁数と必須条件を自分で決めてしまうので、どんなに小さな案件でも省略できません。

省略したものは「作らない」と明記して残してください。空欄のまま消すと、後から「作り忘れたのか、意図的に省いたのか」が分からなくなります。当社では成果物一覧の行を消さず、「対象外(理由)」と書いて残す運用にしています。

あなたの案件では、29枚のうち何枚が必要でしょうか。次の章から、優先度Aの成果物を1枚ずつ、記載例そのものとして書いていきます。

画面の記載例——画面一覧・画面遷移図・画面設計書(項目定義)

ここからは記載例そのものです。題材は受発注管理システム(小売)に統一します。自社の案件に置き換えるときは、画面名と項目名を入れ替えるだけで使えるようにしてあります。画面まわりは、実装者が最も多く参照し、最も多く質問が飛ぶ領域です。逆に言えば、ここが埋まっていれば質問の総数は目に見えて減ります。

画面一覧の記載例——7列で足りる

画面一覧は、システムで使う画面をすべて並べた表です。列は7つで足ります。増やしても運用されません。

画面IDは、後で必ず他の文書から参照されます。機能一覧、テスト仕様書、課題管理表、そして海外チームとのチャットでも「SCR-110の話です」と言えるようになります。連番は10刻みにしておくと、後から画面が増えたときに枝番で挟めます。

画面遷移図の記載例——図が描けないなら遷移表で書く

画面遷移図は、画面から画面への移動と、そのキッカケになるイベントを表した図です。IPAガイドの例示でも、遷移の矢印に「[検索]」「[戻る]」といったイベント名が添えられています。作図ツールがなくて手が止まっているなら、遷移表で代用して構いません。図でなければならない理由はありません。

遷移表にすると、図では描き落としやすい2か所が自然に埋まります。「条件」の列と、「引き継ぐ情報」の列です。No.4とNo.7のように、うまくいかなかったときにどこへ行くのかを書いた行が入っているかどうかで、実装者の手戻りが変わります。当社が海外チームへ設計書を渡すときは、遷移表の行数の3割以上が異常時・条件分岐の行になっているかを目安にしています。

画面設計書(画面入出力項目一覧)の記載例——ここが基本設計書の心臓部

画面レイアウトと並んで、画面入出力項目一覧が基本設計書のいちばん重要な1枚です。画面の絵だけでは、桁数も必須条件も入力形式も分かりません。ここを埋めないまま実装に渡すと、実装者が全部自分で決めます。

SCR-110(受注登録)を例にします。

この表で意識してほしいのは、次の3点です。第一に、単位と税の扱いを書いています(円・税抜)。第二に、空欄の意味を書いています(納品希望日の「空欄可(未定の意味)」)。第三に、エラーと警告を区別しています(在庫超過は警告、廃番はエラー)。この3点は、書かなければ実装者が推測で決める箇所です。

介護記録SaaSのCareViewerでは、日本語対応のブリッジSE1名とフルスタックエンジニア2名という体制で、この項目定義を毎週更新しながら開発を進めました。項目定義が先に決まっていれば、実装は止まりません。止まるのは、絵だけ渡して「あとはよしなに」と言ったときです。

これが書いてなければ差し戻し——画面まわりの欠落例5つ

当社では、次の5つが欠けている画面設計書は海外チームへ渡さず、書き足してから渡します。

1. 桁と型がない。「氏名」とだけ書いてある。全角何文字までなのか、半角が混ざってよいのかが分からない
2. 必須/任意がない。必須にした場合、空欄で登録しようとしたときのメッセージ文言まで書く
3. 権限による表示制御がない。「管理者だけが単価を変えられる」は画面の絵には現れない
4. 異常時の遷移がない。チェックNGのときにどこへ戻り、入力値が保持されるのかされないのか
5. 一覧の既定値がない。初期表示の絞り込み条件、並び順、1ページの件数。これが無いと全件表示の実装になり、本番で性能問題が出ます

5つのうち3つ以上が埋まっていない設計書を渡した案件では、実装開始から2週間で仕様確認の質問が50件を超えます。埋めてから渡した案件では、同じ規模で10件前後です。差は質問の数ではなく、その回答を待つ間に止まっている時間のほうにあります。

機能一覧・帳票設計・バッチ一覧の記載例

画面の次に手が止まるのが、この3つです。画面は目に見えるので想像しやすいのですが、機能・帳票・バッチは目に見えません。特にバッチは、動いているところを誰も見ないまま本番を迎えます。ここでも記載例をそのまま書きます。

機能一覧の記載例——機能IDの振り方で後工程の手間が変わる

機能一覧は、システムが提供する処理を並べた表です。画面一覧と重複するように見えますが、役割が違います。画面一覧は「入れ物」の一覧、機能一覧は「処理」の一覧です。1つの画面に複数の機能が載ることも、画面を持たない機能(バッチ、API)もあります。

機能IDの振り方には、後で効いてくる決め事があります。分類を上2桁に持たせること、そして一度振ったIDを再利用しないことです。受注が「02」なら、受注に関する機能は全部F-02xxになります。この一貫性があると、テスト仕様書・課題管理表・検収書・請求の単位がすべて同じIDで並びます。逆に、途中で振り直した案件は、最後まで「旧ID/新ID」の対応表を持ち歩くことになります。ERPのプライム案件を上流から下流まで担当したときに、これで一度痛い目を見ました。

「優先度」の列に「次期」と書いた行を残しているのも意図があります。作らないと決めたものを表から消すと、なぜ無いのかが分からなくなります。残したうえで「次期」と書くのが正解です。

帳票設計の記載例——帳票一覧・帳票項目説明・帳票編集定義の3枚

帳票は、紙に印刷するものだけではありません。IPAガイドも、PDFやCSVで電子的に出力され後から印字できる出力物を帳票の一種として扱っています。請求書、納品書、月次レポートのCSV出力はすべて帳票です。

まず帳票一覧です。

次に帳票項目説明です。納品書(RPT-001)を例にします。印字される1項目ずつ、どこから取ってくるかを書きます。

帳票編集定義(改ページ条件やヘッダ・フッタの制御)は、明細が複数ページにわたる帳票でだけ作ります。納品書のように明細が20行を超えると改ページする、といった規則を書く1枚です。小規模案件では、上の表の「編集内容」の列に吸収して構いません。

バッチ一覧の記載例——起動条件と異常時の再実行を必ず書く

バッチは、動作が目に見えない分、設計書の記述がそのまま運用手順になります。

バッチで必ず書くのは、右端の「異常時」の列です。ここが空欄だと、実装者は「たぶんロールバックでいいだろう」と自分で決めます。受注取込のように、翌日に再実行するのか、当日中に手動で流し直すのかで実装も運用も変わる処理では、決めておかないと本番で必ず問題になります。

これが書いてなければ差し戻し——機能・帳票・バッチの欠落例4つ

1. 機能一覧と画面一覧が対応していない。画面にしか存在しない処理、機能一覧にしか存在する処理がある
2. 帳票の「空のときの扱い」がない。マスタ未登録、金額0、商品名が長すぎる場合に何を印字するか
3. バッチの二重実行防止がない。手動起動のバッチで、締め処理を2回流したときに何が起きるか
4. 税と端数処理がない。税抜か税込か、1円未満を切り捨てるか四捨五入するか。金額を扱う帳票では必ず書きます

枚数を増やすより、機能IDと画面IDの対応が最後まで崩れないほうが、はるかに効きます。

テーブル定義・ER図・外部インターフェース一覧の記載例

データの設計は、発注者がふだん目にすることのない領域です。IPAガイドも、データモデルについて「日常発注者が見ることのない設計法であり、システムを利用するだけの発注者には理解しにくい性質がある」という趣旨を述べています。だからこそ、発注者が読める形で書くことに意味があります。ここでは、専門用語を減らして書ける記載例を示します。

テーブル定義書の記載例——10列と、埋まらない欄の意味

テーブル定義書は、データを保存する表の設計です。IPAガイドの分類では「エンティティ定義」にあたります。受注テーブルを例にします。

右端の「業務ルール」の列が、この表のいちばん大事な部分です。型と桁だけならプログラマが決められます。決められないのは、取消から元に戻せるのか、NULLが何を意味するのか、日時をどのタイムゾーンで持つのかといった業務の判断です。

テーブル定義を書き始めると、必ず埋まらない欄が出ます。その空欄は「作業が遅れている」のではなく、「まだ誰も決めていない業務ルールが見つかった」というサインです。当社では、テーブル定義の空欄に色を付けて残し、週次の打ち合わせで発注者に決めてもらう運用にしています。空欄を実装者が埋めたら、その時点で設計書は合意文書ではなくなります。

保持期間と件数の見積もりも、テーブル一覧のほうに書いておきます。

ER図の記載例——作図ツールがなくても「関連一覧」で代用できる

ER図は、エンティティ(データのまとまり)同士の関係を図にしたものです。IPAガイドの例示では、顧客・受注・受注明細・製品・製品分類が線で結ばれ、外部キーには(FK)が付いています。作図ツールが手元になくても、関連を表で書けば同じ情報が伝わります。

図を描くなら、この表をそのまま線に置き換えるだけです。表のほうが優れている点も1つあります。「親が消えたら子はどうなるか」を書く欄が自然に用意されることです。図だけでは、この判断はほぼ記録されません。

外部インターフェース一覧の記載例——相手・方向・方式・タイミングの4点

外部インターフェースは、自分のシステムと他のシステムとの間でやりとりするデータのことです。IPAガイドは、検討すべき要素として(1)相手先システムとやりとりの特性、(2)やりとりされるデータの名称と内容、(3)やりとりの方向と手段・方法、(4)やりとりのタイミング、の4つを挙げています。この4つがそのまま列になります。

IF-001とIF-002の備考欄に、文字コードと改行コードを書いていることに注目してください。外部連携の事故は、機能ではなく文字コードで起きます。相手が古い会計システムならShift_JIS、EC側はUTF-8、という混在は珍しくありません。設計書に書いていなければ、実装者は自分の環境の既定値で作ります。

これが書いてなければ差し戻し——データと外部接続の欠落例4つ

1. NULL可否と既定値がない。特に日付と金額。NULLと0は別の意味です
2. 削除の方式がない。物理削除か論理削除か。参照されているデータを消したときに何が起きるか
3. 文字コード・改行コード・タイムゾーンがない。外部連携と日時を扱うすべてのテーブルで必要です
4. 件数と保持期間がない。性能設計と保存コストの前提になります。「年間何件増えるか」は発注者しか答えられません

いま手元に設計書があるなら、まず空欄に印をつけてください。その印の数が、発注前に決めるべき事項の数です。

非機能要件一覧の記載例と、表紙・改訂履歴・ツールの選び方

最後の1枚が非機能要件一覧です。ここで必ず手が止まります。「可用性を書け」と言われても、根拠になる数字を持っていないからです。あわせて、どの成果物にも共通する表紙と改訂履歴、そして何で作るかというツールの話をします。地味ですが、この3つが揃っていない設計書は、半年後に「最新版はどれか」で揉めます。

非機能要件一覧の記載例——IPA非機能要求グレードの6大項目を軸にする

非機能要件を自分でゼロから分類する必要はありません。IPAが公開している「非機能要求グレード2018」が、非機能要求項目を6つの大項目に階層的に整理しています。2018年4月に公開され、利用ガイド[活用編]は2019年3月に第2版へ改訂されました(2026年9月16日にIPAのページで確認)。構成は、項目一覧・グレード表・樹系図・活用シート・利用ガイドです。社会的影響度に応じた3つのモデルシステムごとに要求レベルの目安も示されています。

なお、IPAの公開ページに書かれているのは「6つの大項目ごとに階層的に示した」という構成の説明までで、大項目の名称そのものはページ上に列挙されていません。名称と項目一覧は、本体のZIPをダウンロードして確認してください。本記事では、実務で広く使われている区分(可用性/性能・拡張性/運用・保守性/移行性/セキュリティ/システム環境・エコロジー)を軸にします。

以下が記載例です。数値は受発注管理システム(社内利用・1日あたり利用者60名)を想定しています。

• 可用性
  • 稼働時間——平日 7:00〜22:00、土曜 8:00〜18:00 / 業務時間+締め作業の時間帯 / 計画外停止は1回2時間以内
  • 稼働率——月間 99.5%以上 / 計画停止を除く。月間停止許容は約4.5時間 / 2か月連続未達で構成を見直す
  • 障害復旧目標——RTO 4時間、RPO 24時間 / 日次バックアップ前提 / 一次切り分けは30分以内に連絡
• 性能・拡張性
  • 画面応答時間——一覧検索 3秒以内、登録 2秒以内 / 同時接続20、データ量3年分(受注21.6万件)での測定 / 5%の超過は許容。10%超で改善対応
  • バッチ処理時間——受注取込 15分以内、月次締め 60分以内 / 想定最大件数(取込600件、締め12,000件)での測定 / 業務開始時刻までに完了しない場合は即時連絡
  • データ増加への対応——5年分のデータ量で性能要件を満たす / 年間7.2万件×5年=36万件 / 3年目に見直しを実施
• 運用・保守性
  • 監視——死活監視5分間隔、エラーログの日次確認 / 測定条件・根拠: — / 検知から15分以内に通知
  • バックアップ——日次フルバックアップ、14世代保持 / 深夜1:00に取得 / 取得失敗は当日中に再取得
  • 保守対応時間——平日 9:00〜18:00(日本時間) / 障害連絡はメールで24時間受付 / 時間外の重大障害は翌営業日9:00から着手
• 移行性
  • 既存データ移行——得意先1,800件、商品12,000件、過去2年の受注 / CSVで受領し、移行ツールで投入 / 移行エラー0件を稼働条件とする
  • 並行稼働——1か月間の並行稼働 / 旧システムと結果を突合 / 差分が出た場合は稼働を延期
• セキュリティ
  • 認証——ID・パスワード+既存SSO連携 / パスワードは12文字以上、90日更新 / 未達時の扱い: —
  • 権限——ロール4種(営業/倉庫/管理者/参照のみ) / 機能一覧の権限列と一致させる / 未達時の扱い: —
  • 通信・保管——通信はTLS 1.2以上、保管時はディスク暗号化 / 測定条件・根拠: — / 未達時の扱い: —
  • 監査ログ——更新系の操作を全件記録、13か月保持 / 誰が・いつ・どのデータを変更したか / 未達時の扱い: —
• システム環境・エコロジー
  • 動作環境——Chrome / Edge の最新版と1つ前のバージョン / 測定条件・根拠: 社内標準ブラウザ / 他ブラウザは動作保証外
  • 構成——クラウド(東京リージョン)、単一構成 / 冗長構成は費用対効果で見送り / 可用性99.5%を下回る場合に再検討

ここで守っている作法は1つだけです。数値と、その数値を測る条件をセットで書く。「画面応答3秒以内」だけでは合否を判定できません。何件のデータで、何人が同時に使っている状態で測るのかを書いて、はじめて検収の基準になります。金融系のマッチングサービスを構想段階から支援した案件では、この「測定条件」の列を先に埋めたことで、性能試験の前提でもめる場面がなくなりました。

なお、非機能要件を要件定義と基本設計のどちらで決めるかという論点は、『基本設計とは』の記事で扱っています。要件定義書の側でどう書くかは『要件定義書の書き方』の記事をご覧ください。

表紙と改訂履歴の記載例——「最新版はどれか」で揉めないために

IPAガイドに収録されている成果物の例では、どのドキュメントにも同じヘッダ項目が付いています。プロジェクト名、システム名、工程名、ドキュメントID、ドキュメント名、バージョン、作成者、作成日付、更新者、更新日付。この10項目をすべての成果物の先頭に置いてください。

• プロジェクト名——受発注管理システム刷新
• システム名——受発注管理システム
• 工程名——記載例: 基本設計
• ドキュメントID——BD-SCR-001
• ドキュメント名——画面入出力項目一覧(受注登録)
• バージョン——記載例: 1.2
• 作成者 / 作成日付——中元 / 2026-08-04
• 更新者 / 更新日付——中元 / 2026-09-10

改訂履歴は、成果物ごとに末尾へ置きます。

「変更理由」の列を省く現場が多いのですが、ここが後で効きます。半年後に「なぜこうなっているのか」を聞かれたとき、理由が書いてあれば議論が5分で終わります。書いていなければ、当時の議事録を探すところから始まります。承認欄の日付も入れてください。承認の日付が入った版から先は、変更が仕様変更として扱われます。

Excel・Markdown・設計ツールの選び分け——判断軸は3つ

「Excelはもう古いのでは」という質問をよく受けます。結論から言うと、古いかどうかではなく、次の3つで選びます。(1)表が多いか文章が多いか、(2)差分を見る必要があるか、(3)誰がレビューするか。

当社の実務では、表はExcel、文章はMarkdown、図は作図ツール、という混在で運用しています。混在させるときの条件が1つあります。成果物一覧の表に、1枚ごとの保管場所(URLまたはファイルパス)を書いておくこと。これが無いと、ツールを分けた瞬間に「最新版がどこにあるか分からない」状態になります。ツールを統一するより、所在を1か所にまとめるほうが効きます。

IPAガイドも、設計書は発注者と開発者の間で合意した表記方法や様式で作られるため、作成単位や構成がガイドの想定と一致しないことがある、という趣旨を述べています。様式は現場で決めてよい。決めたことを記録しておく、それだけが条件です。

オフショアに渡す基本設計書で落ちやすい項目と、当社の体制

同じ設計書でも、日本国内のチームに渡すのと、海外のチームに渡すのとでは、落ちる場所が違います。国内では「言わなくても分かる」で通っていた欄が、そのまま空白として実装に流れていくからです。ここでは、当社が海外チームへ設計書を渡す前に必ず見る4か所を挙げ、そのうえで当社の体制を説明します。

落ちやすい4類型——曖昧語、例外系、文字コードとタイムゾーン、桁と単位

第一に、曖昧語です。「適切に」「必要に応じて」「等」「原則として」。これらは日本語の設計書に非常に多く出てきますが、翻訳しても判断の材料になりません。悪い例と良い例を並べます。

• 曖昧語——検索結果は適切な件数で表示する / 1ページ50件。51件目以降はページ送り。並び順は受注日の降順
• 曖昧語——エラー時は必要に応じてメッセージを出す / 入力チェックNG時、該当項目の直下に赤字でメッセージを表示し、フォーカスを移す
• 例外系——在庫がない場合は警告する / 在庫数<受注数のとき、「在庫不足(現在庫: N個)」を表示し、登録は許可する。引当は可能な数量のみ
• 例外系——通信エラー時はリトライする / 3回までリトライ(間隔2秒)。3回目も失敗したら画面にエラー表示し、受注は保存しない
• 文字コード——悪い例: CSVで連携する / UTF-8(BOMなし)、改行LF、区切りカンマ、囲み文字はダブルクォート
• タイムゾーン——登録日時を保持する / DBはUTCで保持。画面表示・帳票・CSV出力はJST(UTC+9)へ変換
• 桁と単位——悪い例: 金額を表示する / 円・税抜・整数(小数なし)。3桁区切りカンマ、マイナスは△表記
• 桁と単位——悪い例: 重量を入力する / キログラム、小数第1位まで。0.1〜999.9の範囲外はエラー

第二に、例外系です。設計書の大半は正常系で埋まります。しかし実装工数の半分以上は例外系です。「うまくいかなかったとき、何が起きて、誰が何をするのか」が書かれていない設計書は、そのまま渡すと実装者が自分で決めます。

第三に、文字コードとタイムゾーンです。ベトナムは日本との時差が2時間(日本が進んでいます)。開発機のOSロケールもタイムゾーンも日本とは違います。「日付」と書かれた欄が、UTCで保存されるのかローカル時刻で保存されるのかは、書いていなければ環境の既定値で決まります。日をまたぐ処理、月次締め、有効期限の判定で、後から必ず問題になります。

第四に、桁と単位です。金額の税抜/税込、通貨(円かUSDか)、重量や長さの単位、小数の桁数と丸め方。日本の商習慣では自明でも、海外チームには自明ではありません。

この4つは、全部を書き直す必要はありません。既存の設計書に対して、この4類型で検索をかけるだけで9割は見つかります。オフショアに渡す文書の粒度をもう少し体系的に整理したい場合は、『オフショア開発の仕様書の書き方』の記事で種類別の粒度と原則を扱っています。

当社は日本人PMが設計書の粒度を引き取る

当社(TALENTBASE VIETNAM)は、ホーチミンを拠点にベトナムオフショア開発を行っています。グループで2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)を持ち、そこから直接アサインします。協力会社や紹介を経由しないので、仲介マージンが乗りません。公開している単価は、実務3年目安で1,500USD(約22.5万円/1USD=150円換算目安)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです。

体制は2パターンあります。パターンAは日本人PM/ブリッジSEとエンジニアの組み合わせで、当社が推奨しているのはこちらです。パターンBはエンジニアのみの構成になります。設計書の粒度に不安がある場合は、パターンAを選んでください。日本人PMが、本記事で挙げた4類型を渡す前に潰します。当社の品質担保は、(1)日本人PMによる設計レビュー、(2)Gitのプルリクエストによるコードレビューの標準化、(3)リリース前のダブルチェック、の3点です。(2)は、設計書に書かれていない判断が実装に紛れ込んだときに検出するための仕組みです。

介護記録SaaSのCareViewerでは、日本語対応ブリッジSE1名とフルスタックエンジニア2名の体制で開発を進め、コストは従来の半分以下になりました。設計書の空欄は週次の打ち合わせで潰し、優先順位もその場で判断しています。時差が2時間なので、午前中に投げた質問への回答が同日の午後に返ります。お客様からは「想像以上にエンジニアのレベルが高い」という声をいただいています。

最小構成は、日本人PMがフロントに立ち、エンジニア2〜3人月で月額約80万円からです。1名から開始でき、最短2週間でスタートできます。増員は約1週間、縮小や交代は1か月単位で対応します。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

向く案件と向かない案件

向くのは、画面と機能の輪郭が決まっていて、継続的に開発を回していく案件です。基本設計書が完成していなくても構いません。当社の日本人PMが、記載例レベルまで粒度を引き上げる作業から入れます。

向かないのは、次の2つです。1つは、要件がまだ言語化されておらず、経営判断そのものを一緒に決めたい段階の案件。これは発注側の中で決めるべきことで、外部の開発会社が引き取ると判断の責任があいまいになります。もう1つは、1〜2週間で終わる単発の改修です。立ち上げのコストが見合いません。こうした案件は、その旨を率直にお伝えしています。

基本設計書のサンプルに関するよくある質問

記事の本文で拾いきれなかった実務の迷いを、5つにまとめて回答します。当社が発注検討中の方から実際に受ける質問のうち、頻度の高いものを選びました。

Q1. 無料のテンプレートをダウンロードして、そのまま使ってよいですか?

配布元が定める利用条件の範囲であれば問題ありません。ただし、公的機関の資料は利用条件が細かく定められている場合があり、たとえばIPAの資料には出典表示を求めるものや、図表・イラストの抽出使用を禁じているものがあります。使う前に配布元の使用条件ページを必ず確認してください。実務上の注意はもう1つあります。テンプレートの列をそのまま残すと、自社に不要な列が最後まで空欄で残ります。使わない列は最初に削除するのが、埋め切るコツです。

Q2. 基本設計書は何ページくらいが目安ですか?

ページ数で管理しないでください。管理すべきは枚数(成果物の数)です。本記事の目安では、小規模(開発費〜300万円)で8〜10枚、中規模(300万〜3,000万円)で14〜18枚、大規模(3,000万円〜)で22〜29枚です。1枚あたりのページ数は、画面数やテーブル数に比例して自動的に決まります。ページ数を目標にすると、埋めなくてよい欄を埋める作業が始まります。

Q3. ExcelとMarkdownのどちらで作るべきですか?

列が多い表(画面入出力項目一覧、テーブル定義、非機能要件一覧)はExcel、文章が多い文書(業務説明、共通ルール)はMarkdownが扱いやすいです。両方を使って構いません。条件は、成果物一覧の表に1枚ごとの保管場所を書いておくことだけです。ツールを統一することより、最新版の所在が1か所で分かることのほうが重要になります。

Q4. 画面設計書とワイヤーフレームは同じものですか?

違います。ワイヤーフレーム(画面レイアウト)は配置を示す絵で、画面設計書はそこに入出力項目の外部仕様を加えたものです。IPAのガイドでも、画面の成果物は「画面レイアウト」「画面入出力項目一覧」「画面アクション明細」などに分かれており、これらをまとめて1つの「ユーザインタフェース設計書」として作る現場もあると説明されています。絵だけを渡して実装が始まると、桁数・必須条件・権限による表示制御を実装者が決めることになります。

Q5. 基本設計書を発注者側で作れない場合、どうすればよいですか?

作れないまま発注して構いません。実際、当社への相談の多くは要件定義書か簡単な機能リストしかない状態から始まります。その場合は、開発会社側が基本設計を工程として請け負い、発注者は「合否を判定する側」に回ります。ただし、判定する側には必ず残る仕事があります。業務ルール(取消の可否、NULLの意味、保持期間、税と端数の扱い)は発注者しか答えられないからです。作る作業は渡せても、決める作業は渡せない、というのがこの工程の実情。

まとめ: サンプルは写す手本ではなく、自分の1枚を採点する物差し

基本設計書に業界標準の様式はありません。IPA「機能要件の合意形成ガイド」が原文でそう述べたうえで、6領域27種の成果物を想定として示しています。標準がないということは、全部作らなくてよいということでもあります。小規模(開発費〜300万円)なら8〜10枚、中規模で14〜18枚、大規模で22〜29枚。省略の判断は枚数ではなく、「それが無いことで誰かが勝手に決めることになるか」で行ってください。

本記事の記載例をコピーして埋めてみると、必ず空欄が残ります。その空欄は作業の遅れではなく、まだ誰も決めていない業務ルールです。取消から戻せるのか、NULLが何を意味するのか、税は抜きか込みか、日時はどのタイムゾーンで持つのか。これらは実装者には決められません。空欄に印をつけた数が、発注前に社内で決めるべき事項の数になります。

工程としての位置づけやレビューの観点を先に押さえたい方は基本設計とはをご覧ください。作った設計書を海外チームへ渡す段階に入るならオフショア開発の仕様書の書き方で粒度の原則を確認し、曖昧語・例外系・文字コードとタイムゾーン・桁と単位の4か所を最後に見直してください。ここまでやれば、実装開始後の質問は目に見えて減ります。

現在の体制と要件をお聞かせいただければ、必要な成果物の枚数と体制の概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。