基本設計書の書き方｜項目一覧・粒度の判断基準と詳細設計書との違い
最終更新日：2026/09/10
基本設計書とは、システム開発の設計工程で「外部から見た機能仕様」を、顧客や開発メンバーが同じ認識を持てる粒度で整理する成果物です。項目が多い上に案件ごとに粒度の正解が違い、フリーランスが参画先で最初にとまどう工程でもあります。この記事では、基本設計書の書き方（項目一覧・粒度の判断基準・作成順）を中心に、対になる詳細設計書との違いや参画先ルールへの合わせ方までを実務目線で整理します。基本設計書の書き方を一言でいうと、要件定義で決まった内容を、画面・機能・データ・外部連携・非機能要件に分けて、読み手ごとに必要な情報が揃った状態に整えることです。
先に結論
基本設計書は「顧客と合意する外部仕様」、詳細設計書は「実装者が迷わない内部仕様」を書く成果物です
基本設計書には業務フロー・機能一覧・画面・帳票・バッチ・DB・外部IF・非機能要件の8領域を、詳細設計書にはクラス図・モジュール構造・アクティビティ図・シーケンス図・IPO・処理定義の6領域を含めることが多い標準的な構成です（採用範囲は開発手法や現場によって差があります）
粒度は「実装チームのスキル・使用言語の習熟度・案件フェーズ」で判断します。特に新規開発で若手比率が高い場合は変数名・関数名まで、中堅以上中心なら処理概要と入出力まで、が実務上の目安です
フリーランスは自己流で書かず、まず参画先の既存設計書のフォーマットと粒度に寄せるのが安全です
生成AIによるドラフト作成は有効ですが、機密情報の扱いとレビュー工数の見積もりを最初に押さえる必要があります
この記事でわかること
基本設計書と詳細設計書に含める全項目と、それぞれで押さえる観点
チーム・案件別に「どこまで詳しく書くか」を判断する基準
参画先の設計書ルールに合わせる4ステップと、生成AI活用の勘所
ウォーターフォール・アジャイル・PoC・保守案件のケース別対応
提出前にセルフレビューできる実践チェックリスト
目次
基本設計書と詳細設計書の位置づけ
基本設計書の書き方｜8つの成果物と項目
詳細設計書の書き方｜6つの成果物と項目
粒度の判断基準｜チーム・案件別の合わせ方
フリーランスが参画先の設計書ルールに合わせる手順
生成AI（LLM）を使った設計書ドラフト作成
ケース別解説｜あなたの案件では何を書く？
よくある失敗と対策
実践チェックリスト｜設計書提出前セルフレビュー
まとめ
よくある質問
基本設計書と詳細設計書の位置づけ
基本設計書と詳細設計書は、V字モデルの設計工程で作成する成果物です。両者の役割は「読み手が誰か」で分けると理解しやすくなります。
V字モデルでの工程マッピング
システム開発のV字モデルでは、要件定義→基本設計→詳細設計→実装、と進みます。基本設計は要件定義で合意した「何を作るか」を、システムの外側から見える機能・画面・データとして具体化する工程です。詳細設計はそれを実装者が迷わず組めるレベルまで内部処理として落とし込みます。
一般的には、基本設計は結合テスト、詳細設計は単体テストの観点と対応づけて扱われます（現場によっては基本設計をシステムテスト・受け入れテストと紐づけるケースもあります）。設計書が甘いとテストで検証すべき仕様が曖昧になり、後工程の手戻り工数が跳ね上がります。
「基本＝外部設計」「詳細＝内部設計」の実務的な意味
基本設計書は「顧客・PM・営業・テスト担当が読む」ドキュメントです。画面レイアウトや業務フロー、機能一覧など、システムの振る舞いを外側から見える形で記述します。読み手にコードを書かない人が含まれるため、図と表を中心に、非エンジニアでも理解できる粒度に整えます。
詳細設計書は「実装者・レビュワー・後任の保守担当が読む」ドキュメントです。クラス設計・処理フロー・シーケンスなど、実装に必要な内部仕様を記述します。ウォーターフォール型の業務システムではソースコードと近い粒度まで落とし込むことが多い一方、アジャイル・Web系では処理概要とインターフェース定義に留めるケースもあります。書き手はコードを書くことを前提にしています。
フリーランスが設計工程に入ると案件の選び方はどう変わるか
設計書を書ける・レビューできるフリーランスは、実装のみの案件より上流フェーズを任される案件が選択肢に入りやすくなります。フェーズ別の案件条件については後述のケース別解説と単価相場の記事にゆずり、まずは項目一覧と粒度の基準に進みます。
ミニFAQ
Q. 基本設計と詳細設計の両方を書けないと上流案件に入れない？
A. 両方は必須ではありません。まずは基本設計のレビュー観点を押さえ、既存設計書を読み解ける状態になれば上流案件の入口としては十分です。
Q. 要件定義書と基本設計書の違いは？
A. 要件定義書は「何を実現したいか（業務要件）」を、基本設計書は「それをどう実現するか（システム機能）」を書きます。要件定義書のほうがビジネス寄り、基本設計書のほうが実装寄りです。
基本設計書の書き方｜8つの成果物と項目
基本設計書は複数のドキュメントの集合体です。案件によって濃淡はありますが、標準的には以下の8領域に分けて作成します。作成順は通常「業務フロー→機能一覧→画面／帳票／バッチ→DB→外部IF→非機能要件」の順で固めると、後工程での手戻りを減らしやすくなります。
業務フロー図と機能一覧
システム化する業務の流れを図（BPMN・スイムレーン）で表し、各業務にシステム側の機能を紐づけます。機能一覧は「ログイン」「商品検索」「注文登録」など数十件〜数百件の粒度で並べ、優先度・実装担当・関連画面IDを列に持たせるのが実務的です。
画面設計（一覧・遷移図・レイアウト・入出力）
画面一覧・画面遷移図・画面レイアウト・入出力項目定義・アクション定義の5点セットで構成します。項目定義は「項目名・データ型・必須／任意・桁数・初期値・入力チェック内容」を最低限含めます。モックアップやFigmaを使う場合も、項目定義は別途表形式で残すのが標準です。
帳票・バッチ設計
帳票は「一覧・レイアウト・出力項目・編集条件」を、バッチは「処理一覧・実行タイミング・処理フロー・入出力ファイル・エラー時挙動」を書きます。夜間バッチが多いシステムでは、実行順序・依存関係・タイムアウト条件の記載を忘れがちなので注意します。
DB設計（ER図・テーブル定義）
ER図・テーブル一覧・テーブル定義書・CRUD図を作成します。テーブル定義書には「カラム名・データ型・桁数・NULL可否・キー種別・デフォルト値・説明」を持たせます。CRUD図は「どの機能がどのテーブルをC/R/U/Dするか」のマトリクスで、権限設計や結合テスト設計の元になります。
外部インターフェース設計
他システムとの連携仕様を「関連図・IF一覧・IF定義書・処理概要」で整理します。REST APIならエンドポイント・HTTPメソッド・リクエスト／レスポンススキーマ・認証方式・エラーコード体系を、ファイル連携なら配置場所・ファイル名規約・レコードレイアウト・タイミングを記載します。
非機能要件（性能・可用性・セキュリティ）
代表的には、IPAの非機能要求グレードを参考に、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境の6項目を整理します。基本設計フェーズでは「レスポンス目標値3秒以内」「稼働率99.5%以上」といった数値目標を明示することが重要です。IPAが公開する非機能要求グレードは業界で広く参照されている枠組みで、参画先が独自の観点を持つ場合はそちらに合わせます。
業務要件セクション（背景・目的・対象範囲）
システム化の背景・目的・対象業務範囲・システム化業務一覧・新業務フローを、基本設計書の冒頭に配置します。要件定義書の要旨を再掲する形式が多く、後工程で「なぜこの設計になっているか」を追える起点になります。
提出物一覧（基本設計書の全体像）
領域 | 主な成果物 | 粒度の目安 |
|---|---|---|
業務要件 | 背景・目的・業務フロー・機能一覧 | 機能単位で数十〜数百件 |
システム方式 | ハード・ネットワーク・アプリ構成図 | 論理構成＋物理構成の2層 |
画面設計 | 一覧・遷移図・レイアウト・項目定義 | 画面1つにつき1〜数ページ |
帳票設計 | 一覧・レイアウト・出力項目・編集条件 | 帳票1つにつき1〜2ページ |
バッチ設計 | 処理一覧・フロー・入出力・エラー処理 | バッチ1つにつき1〜2ページ |
DB設計 | ER図・テーブル定義・CRUD図 | テーブル1つにつき1ページ |
外部IF | 関連図・IF定義・処理概要 | IF1つにつき1〜2ページ |
非機能要件 | 性能・可用性・セキュリティ・運用 | 6項目それぞれ数値目標付き |
※ 上の粒度は中小〜中規模の業務システム案件でよく見られる目安です。テンプレート・分冊方針・図の充実度で大きく変わります。
ミニFAQ
Q. 基本設計書のページ数はどれくらいが標準？
A. 分冊方法やテンプレート次第で大きく変わるため一律の目安は置けません。中規模の業務システムでは数百ページ規模になることが多い一方、テンプレートで冗長箇所を圧縮している現場ではより薄くなります。ページ数より「レビュワーが判断できる情報が揃っているか」を優先します。
詳細設計書の書き方｜6つの成果物と項目
詳細設計書は「実装者が仕様確認のためにコードから離れて読むドキュメント」です。静的構造と動的な処理フローの2軸で整理します。
クラス図
クラス名・属性・メソッド・関連（継承・集約・依存）を図示します。オブジェクト指向言語での実装が前提の場合、クラス図がないと責務の割り振りがコードレビューでしか判定できなくなります。UMLの表記に厳密に従う必要はなく、参画先で使われている記法に合わせます。
モジュール構造図
関数・モジュール単位で処理を階層化し、共通化候補を可視化します。バッチ処理やメインフレーム系の詳細設計で多用され、Web系のオブジェクト指向設計ではクラス図で代用されるケースもあります。
アクティビティ図・フローチャート
ユーザー操作とシステム処理を時系列で並べます。分岐条件・例外パスを明示的に書くのが実装者に喜ばれるポイントです。フローチャートは処理単位の詳細フローを、アクティビティ図はユーザー視点のフローを描くと使い分けやすくなります。
シーケンス図
クラス・オブジェクト間のメッセージ交換を時系列で表現します。特にAPI呼び出しの多い機能や、非同期処理・イベント駆動のフローで威力を発揮します。シーケンス図があると、実装者は「どの順で何を呼ぶか」で迷いません。
IPO（入力・処理・出力）
バッチや帳票出力のように「入力→加工→出力」が明確な処理では、IPO表が最も読みやすい形式です。入力データの構造・処理ロジック（擬似コードまたは自然言語）・出力データの構造を1枚にまとめます。
画面詳細と処理定義
基本設計の画面設計を1階層深掘りし、「ボタン押下時の内部処理・バリデーション詳細・DB更新順序・エラー時の画面遷移」まで記載します。実装者が仕様書を見ながらそのままコードに落とせる粒度が理想です。
ミニFAQ
Q. 詳細設計書とソースコードのコメント、どちらまで書けばよい？
A. ソースコードから機械的に読み取れる情報（メソッド呼び出し順など）は詳細設計書に書きすぎない方が保守が楽です。「なぜその処理順にしたか」「業務ルールの根拠」など、コードから読み取れない意図を優先して書きます。
粒度の判断基準｜チーム・案件別の合わせ方
詳細設計書の粒度は「実装チームのスキル・使用言語の習熟度・案件フェーズ」で決まります。「詳しく書けばよい」わけではなく、書きすぎると保守コストが跳ね上がります。
判断軸
粒度を決める判断軸は主に3つです。実装チームのスキルレベル（若手多め／中堅以上／混成）、使用言語・フレームワークへの習熟度（新規言語導入／習熟済み）、そして案件フェーズ（新規開発／保守・追加開発）です。
ケース別粒度マトリクス（このページにしかない整理）
以下は多くの現場で使いやすい実務上の目安です。特に規制業界（金融・医療）や高リスク領域（決済・個人情報）では、チーム構成に関係なく詳細化する側に振ることが多い点は補足しておきます。
チーム構成 | 言語習熟度 | 推奨する詳細設計の粒度 |
|---|---|---|
若手中心（実装経験3年未満が過半） | 習熟済み | 変数名・関数名・DB物理名まで指定 |
若手中心 | 新規導入言語 | 変数名・関数名＋処理ロジックの擬似コードまで |
中堅以上中心 | 習熟済み | 処理概要・入出力仕様・分岐条件まで（実装詳細は任せる） |
中堅以上中心 | 新規導入言語 | 処理概要＋主要な設計パターン（例外処理方針・データアクセス方針） |
混成チーム | 習熟済み | 中堅向けに標準粒度＋新人向けにサンプル実装1本を別添 |
「書きすぎ」の失敗パターン
詳細設計書に変数名・IF文の条件式・ループ内の処理まで全部書くと、実装者は仕様書を読む時間だけで数日消費します。さらに、実装中の仕様変更で設計書とコードの二重メンテが必要になり、どちらかが陳腐化します。中堅以上のチームでは「処理概要と入出力」までで止め、実装詳細はコードに任せるのが実務的です。
「書かなさすぎ」の失敗パターン
逆に「大まかな流れ」だけで詳細設計を切り上げると、実装者ごとに解釈がぶれます。特にエラー処理・トランザクション境界・排他制御は書かれていないと事故が起きやすい領域です。ここは粒度を落とさず、条件分岐と例外時の振る舞いを明記します。
ミニFAQ
Q. 参画先が「粒度は任せる」と言ってきたらどうする？
A. 既存の設計書を1〜2本サンプルとしてもらい、その粒度に寄せます。「任せる」は「既存に合わせて」の意味であることが多く、自己流で始めると後で書き直しになります。
フリーランスが参画先の設計書ルールに合わせる手順
フリーランスとして新規プロジェクトに参画する場合、最初の1〜2週間で参画先の設計書ルールを把握することが最重要です。以下の4ステップで進めます。
STEP1：既存設計書のフォーマットと粒度を掴む（着任1週間）
過去に納品済みの設計書を最低3本もらい、フォーマット（テンプレート・記法・章立て）と粒度（どこまで詳しく書いているか）を掴みます。この段階で「うちはこう書く」の暗黙ルールを言語化しておくと、後の手戻りが減ります。
STEP2：レビュー履歴とNG例を確認する
既存設計書のレビューコメントや、過去に差し戻された箇所を確認します。レビュワーが何にこだわるかは案件ごとに違い、「命名規則の統一」「非機能要件の数値化」「エラーパスの明記」などNG例を先に把握するとレビュー通過率が上がります。
STEP3：疑問はレビュー前に個別確認
設計書を書いている途中で判断に迷ったら、レビュー会議を待たずにPMや設計リーダーに個別確認します。レビュー会議で初出の疑問を投げると、他メンバーの時間を消費するうえ、その場で結論が出ないケースが多いです。
STEP4：まずは既存に寄せて書き、追加改善提案は後で
参画初期は既存フォーマット・既存粒度に寄せて書きます。「もっと良い書き方がある」と思っても、まずは既存に合わせ、信頼を得てから改善提案を出す順序が安全です。フォーマット改善提案はプロジェクト後半のレトロスペクティブで出すのが実務的です。
参画後の立ち回り全般については『エンジニアの設計力・上流スキルの磨き方｜段階別ロードマップと単価アップ』でも段階別に整理しています。
ミニFAQ
Q. 既存設計書が古い・雑な場合はそれに合わせる必要ある？
A. 既存が明らかに不足している場合は、PMに「この案件では非機能要件の数値化を追加してよいか」など単発の改善提案を出す形が現実的です。全面的な刷新提案は反発を招きやすいので避けます。
生成AI（LLM）を使った設計書ドラフト作成
設計書のドラフト作成に生成AIを活用する現場が増えています。ただし、実務で使うには使える範囲と使えない範囲を分ける必要があります。
使える範囲
要件定義書や画面モックアップを入力に、機能一覧のたたき台・画面項目定義の初稿・非機能要件チェックリスト・CRUD図のたたき台などをLLMに生成させることで、初稿作成時間を短縮できることがあります。特に「決まった項目を埋める」作業（テーブル定義書の各カラムの説明文など）はAIの得意領域です。効果量は案件・利用ツール・入力データの整い方で大きく変わるため、社内検証で自案件の効果を計測してから見積もりに反映するのが安全です。
使えない範囲
業務ロジックの妥当性判断・レビュワーの暗黙ルールへの追従・過去プロジェクトの事故を踏まえた注意点付与は、AIには任せられません。ここは人間が最終判断する前提で使います。
プロンプト設計の型
設計書ドラフト生成のプロンプトは「要件→制約→出力形式」の順で書くのが実務的です。要件（何を作りたいか）・制約（使用フレームワーク・命名規則・既存設計書のスタイル）・出力形式（表形式・見出し構成）を明示すると、初稿の使える率が上がります。
機密情報の扱いと社内LLM要件
顧客情報・業務ロジック・アーキテクチャ図を外部LLMに投入することを禁止している参画先が多いです。事前に「どのLLMなら業務データを入れてよいか」を確認します。企業向けに社内LLM・オンプレLLMを導入するケースも見かけるようになっています。この領域は『社内LLM導入案件とは｜構成・要件・単価とフリーランスの参画実務』で詳しく整理しています。
レビューでハネられるパターン
AI生成そのままのドラフトはレビューでハネられがちです。よくあるNGパターンは「一般論すぎて業務の固有事情が反映されていない」「用語が参画先の命名規則と揃っていない」「実現不可能なアーキテクチャ提案が混ざる」の3点です。AIドラフトは「たたき台」として使い、人間が業務ロジックと命名規則を反映させる工程を必ず挟みます。
ケース別解説｜あなたの案件では何を書く？
案件タイプによって、設計書の分量と粒度は大きく変わります。参画前に案件タイプを把握し、必要な準備を整えます。
ウォーターフォール案件（SIer・官公庁）
ドキュメント文化が強く、基本設計書と詳細設計書を全項目フルセットで作成するのが標準です。テンプレート・記法・章立てまで細かく決まっているケースが多く、既存フォーマット厳守が求められます。レビュー会議も複数回設定され、承認プロセスが重い分、設計フェーズでの手戻りは少ないのが特徴です。
官公庁案件の実務は『官公庁・公共系のフリーランスエンジニア案件｜単価相場・契約形態・セキュリティ要件を徹底解説』でも詳しく整理しています。
アジャイル案件（Web系・スタートアップ）
軽量ドキュメントが主流で、基本設計書は「機能一覧・画面設計・DB設計」程度に絞られるケースが多いです。詳細設計書は書かず、Pull Requestやコードコメントで代替する現場もあります。ただし外部API仕様・DB設計・非機能要件は文書化しないと後で困るため、この3点は最低限残します。
アジャイル案件の相場感は『アジャイル案件のフリーランス単価相場｜求められる経験と参画条件』を参照してください。
PoC・小規模案件（軽量ドキュメント）
期間1〜3か月のPoCや小規模案件では、設計書はA4数枚〜数十枚に凝縮します。全項目網羅より「後任が引き継げる最小限」を意識します。画面イメージ・データ構造・外部連携仕様の3点があれば最低限の保守は可能です。
保守・追加開発案件（既存設計書の追記）
既存設計書があるケースでは、追加機能分の差分設計書を作成します。既存の章立て・記法に合わせ、変更履歴（改訂日・変更箇所・変更理由）を必ず残します。既存設計書とコードが乖離している場合は、乖離状況をPMに報告してから作業に入ります。
よくある失敗と対策
失敗1：粒度を合わせず自己流で書く
前職や別プロジェクトの粒度で書くと、レビューで大量の修正指摘を受けます。着任1週間は既存設計書のフォーマット掴みに投資し、既存に寄せる姿勢を最初に示します。
失敗2：画面・DB・APIの命名がバラバラ
画面IDと機能IDの体系が違う、テーブル名の英語規則がバラつく、APIエンドポイントの命名がキャメルケース／スネークケース混在、といった命名の不統一は実装工程で必ず問題になります。設計着手前に「命名規則ドキュメント」の有無を確認し、なければ最初に作ります。
失敗3：レビュー観点を把握せず出す
レビュワーが何を見ているかを把握しないままレビューに出すと、指摘の予想がつかず何度も差し戻されます。過去の設計書レビューコメントを事前に見せてもらい、レビュワーの重視ポイントを把握します。
失敗4：AIドラフトをそのまま提出
生成AIのドラフトを業務固有事情への反映なしで提出すると、レビュワーから「一般論すぎる」と差し戻されます。AIドラフトは「たたき台」として使い、命名規則・業務ルール・過去の事故履歴を反映させてから提出します。
失敗5：工数見積もりで設計書作成時間を過小評価
実装工数だけ見積もり、設計書作成時間を含めないと、後半で残業が続きます。設計書作成時間は実装工数とは別建てで見積もるのが基本です。比率のラフな目安は案件規模・品質要求・レビュー回数・既存資産の有無で幅が大きく変わるため、参画先の過去案件の実績値をヒアリングしてから数値を置くのが安全です。工数見積もりの手法は『工数見積もりのやり方｜手法4種・根拠の作り方とバッファ設計・失敗パターン』で整理しています。
実践チェックリスト｜設計書提出前セルフレビュー
以下は設計書を提出する前に自分でチェックする観点です。このリストで漏れをつぶすと、レビュー通過率が上がります。
参画先の既存設計書のフォーマット・章立てに合わせている
命名規則（画面ID・機能ID・テーブル名・API名）が全体で統一されている
画面・帳票・バッチ・DB・外部IFの各領域で「一覧」と「詳細」の両方がある
非機能要件に数値目標（レスポンス時間・稼働率・同時接続数）が入っている
エラー処理・例外パス・トランザクション境界が明記されている
変更履歴（改訂日・変更箇所・変更理由）が最新化されている
用語集または略語一覧があり、社内独自用語が定義されている
外部システムとのIF仕様に認証方式・エラーコード体系が含まれる
レビュワーが過去に指摘した観点（既存レビュー履歴から）が反映されている
生成AIドラフトを使った場合、業務ロジック・命名規則の反映が済んでいる
このチェックリストと合わせて、基本設計の分量が多い場合は工数見積書も更新します。見積書の書き方は『見積書の書き方｜フリーランスエンジニア向け記載項目とテンプレート』を参照してください。
まとめ
基本設計書を書くときは、まず外部仕様を読み手別に整理し、次に画面・データ・外部連携・非機能要件を抜け漏れなく定義する、という順で進めるのが基本です。詳細設計書はそれを実装者が迷わず組める粒度まで内部処理として落とし込みます。
基本設計書と詳細設計書は「読み手が誰か」で書き分ける成果物です。基本設計書は顧客・PM・営業・テスト担当が読む外部仕様、詳細設計書は実装者・保守担当が読む内部仕様を書きます。
基本設計書は業務要件・機能一覧・画面・帳票・バッチ・DB・外部IF・非機能要件の8領域
詳細設計書はクラス図・モジュール構造・アクティビティ図・シーケンス図・IPO・処理定義の6領域
粒度は「実装チームのスキル・言語習熟度・案件フェーズ」で判断する
フリーランスは自己流で書かず、参画先の既存フォーマット・粒度に寄せる
生成AIによるドラフト作成は有効だが、業務ロジックと命名規則の人間反映を必ず挟む
案件タイプ別（ウォーターフォール／アジャイル／PoC／保守）で分量と粒度を変える
設計書作成時間は実装工数とは別建てで見積もる（比率は案件差が大きいため参画先の実績値を確認）
設計書を書けるフリーランスは実装のみの案件より単価レンジが上がる傾向があります。まずは既存設計書をレビューできる状態を目指し、段階的に基本設計・詳細設計と守備範囲を広げていくのが実務的なキャリアパスです。
参考にした一次情報：
よくある質問
基本設計書と詳細設計書は必ず両方作らないといけない？
案件タイプによります。ウォーターフォール型SIer案件では両方フルセットが多い一方、アジャイル・Web系ではDB設計と外部IF仕様のみに絞られ詳細設計書は書かないケースもあります。参画先のドキュメント文化を事前に確認します。
設計書を書ける・書けないで単価はどれくらい変わる？
傾向としては上流を任される案件の方が単価レンジが上がりやすいです。実際のレンジは職種・地域・稼働で変わるため、単価レンジ別のスキル要件は『フリーランスエンジニアの単価レンジ別スキル要件｜60・80・100万の壁』を、自分の現在の市場単価の目安は無料のフリーランスエンジニア単価診断や単価相場ハブ記事で確認できます。
UMLの記法を厳密に守らないとダメ？
参画先のスタイル次第です。JIS/IEEE準拠のUML厳密記法を求める現場もあれば、簡易記法（矢印と四角）で通る現場もあります。既存設計書を見て記法を判断します。UML初学者は「クラス図・シーケンス図・アクティビティ図」の3種の基本記法だけ押さえておけば多くの現場で通用します。
詳細設計書の代わりにコードのコメントで済ませてよい？
アジャイル・Web系案件では代替されているケースがあります。ただし「なぜその処理順にしたか」「業務ルールの根拠」など、コードから読み取れない意図はドキュメントに残す方が保守が楽です。テストコードで仕様を表現する（BDDスタイル）ケースも増えています。
設計書のテンプレートはどこで入手できる？
参画先の既存フォーマットに従うのが基本です。ゼロから作るケースでは、IPAが公開する共通フレーム・非機能要求グレードなどのドキュメントや共通フレーム2013に沿った標準テンプレートが参考になります。
図はどのツールで書くのが標準？
現場によります。マイクロソフト系（Visio・PowerPoint）、Atlassian系（draw.io・Confluence）、コード管理系（PlantUML・Mermaid）、専用ツール系（Enterprise Architect・astah*）が主要選択肢です。テキストベースで管理したい現場ではPlantUMLやMermaidが増えています。参画先のリポジトリと親和性の高いものを選びます。
設計書レビューで何度も差し戻される時の対策は？
差し戻し理由をカテゴリ別に集計し、頻出パターンをつかみます。「命名規則違反」「非機能要件の数値欠落」「エラー処理未記載」などパターンが見えたら、次回設計時のセルフチェックリストに追加します。レビュワーの重視ポイントは案件ごとに違うため、着任時に過去のレビュー履歴を見せてもらうのが効果的です。
設計書とテストケースはどう連動させる？
基本設計書の機能一覧・画面設計から結合テストケースを、詳細設計書のクラス・メソッドから単体テストケースを導出します。トレーサビリティマトリクス（機能ID×テストケースIDの対応表）を作ると、要件〜設計〜テストの追跡が容易になります。
生成AIで設計書を作る場合、参画先に事前確認は必要？
必要です。顧客情報や業務ロジックを外部LLMに投入することを禁止している参画先が多いため、事前確認なしで使うと契約違反になるリスクがあります。「どのLLMなら業務データを入れてよいか」「入力してよい情報の範囲」を確認します。
設計書作成のスキルはどこで学べる？
現場で先輩の設計書をレビューしながら覚えるのが最短です。書籍では『はじめよう！要件定義』『増補改訂版 図解でよくわかる ITプロマネの基本』『UML表記法』などが定番です。IPAが公開する共通フレーム・非機能要求グレードも一次情報として押さえておきます。設計スキル全体の磨き方は『エンジニアの設計力・上流スキルの磨き方｜段階別ロードマップと単価アップ』にまとめています。
上流案件を探すにはどうすればいい？
エージェント面談で「基本設計」「詳細設計」「上流工程」のキーワードと担当希望フェーズを伝えると、設計フェーズから任される案件を紹介されやすくなります。市場でどのような設計工程案件が公開されているかは、まずは案件一覧で確認できます。
