基本設計書の書き方｜要件定義書から作る5つの手順と、実案件の設計書サンプル

結論から書きます。基本設計書は、白紙から書き起こす文書ではありません。要件定義書に書いた要件を1行ずつ取り出し、「どのデータに持たせるか」「どの画面で入力するか」「どの帳票に出すか」「どの順番で誰に渡すか」の4つに置き換えていく文書です。要件定義書が「業務として何を実現するか」を発注側の言葉で書いたものだとすれば、基本設計書は、それをシステムの部品の言葉に翻訳したものだといえます。

 

作り方の要点は、次の3つに集約されます。

 

1. 要件定義書の要件に番号を振り、基本設計書のすべての記述が、どの要件から来たのかをたどれるようにする
2. 現行の帳票から項目を抜き出し、1項目ずつ型・桁数・値域を決める
3. 要件定義書で未決だった事項は消さずに引き継ぎ、設計の段階で変えた内容は理由とともに残す

 

反対に、避けたい失敗も3つあります。

 

1つ目は、画面のレイアウトから描き始め、データの持ち方が決まらないまま見た目の議論に時間を使ってしまうこと。

 

2つ目は、要件定義書にない機能を設計の段階で足してしまい、範囲と費用が膨らむこと。

 

3つ目は、設計の途中で変えた内容を記録せず、要件定義書・基本設計書・実際のシステムの3つが食い違ったまま運用が始まることです。

 

3つ目の失敗は、けっして珍しくありません。当社が2026年4月に情シス実務担当者221人に行った調査では、主要なシステムのドキュメントと実際の状態について「ほぼ完全に乖離している」が43.9%、「部分的に一致していない」が29.1%、「ドキュメントは存在しない」が5.6%でした（出典：【2026年調査】レガシーシステムの実態調査）。合わせると8割近くが、設計書をそのまま信用できない状態にあることになります。

 

基本設計書は、書き上げた時点で役目を終える文書ではありません。運用が始まってから、改修や引き継ぎのたびに読み返される文書です。だからこそ、要件とのつながりと、変えた理由が後から追える形で作っておく必要があります。

基本設計書とは、要件定義書で決めた要件を、システムでどう実現するかを決める文書です。外部設計書とも呼ばれ、利用者から見える部分、つまりデータの項目、画面、帳票、処理の流れを対象にします。これに対して詳細設計書（内部設計書とも呼ばれます）は、プログラムを作る人に向けて、内部の処理の手順や構造を決める文書です。

3つの文書の違いを比較表で整理します

比較項目	要件定義書	基本設計書	詳細設計書
主に書く人	発注側（業務部門）が主体	設計側（ベンダー、社内の構築担当）	開発者
書く言葉	業務の言葉	システムの部品の言葉	プログラムの言葉
決めること	何を実現するか、どこまでやるか	データ、画面、帳票、処理の流れ	処理の手順、内部の構造、プログラムの分け方
主に読む人	経営層、業務部門、設計側	業務部門、設計側、開発者	開発者、テスト担当
書き方の例（見積番号）	見積番号が重複しないこと	見積番号を自動採番の項目とし、登録時に振る	採番処理の実装方法、桁があふれたときの扱い

※一般的な整理です。開発の進め方や組織によって、呼び方や分け方は変わります。

 

表の最下行のとおり、同じ「見積番号」でも、要件定義書では「重複しないこと」という業務上の条件を書き、基本設計書では「自動採番の項目にする」という実現方法を書きます。詳細設計書になると、その採番をどう実装するかまで降りていきます。

 

業務部門の担当者にとって大事なのは、基本設計書は「設計側が書くから自分には関係ない」文書ではないという点です。要件定義書の言葉が、設計の言葉に正しく翻訳されたかを確かめられるのは、業務を知っている発注側だけです。基本設計書のレビューには、発注側が必ず加わってください。

ノーコードやパッケージで作る場合は、基本設計書がそのまま設定書になります

スクラッチ開発（要件に合わせて一から作る開発）では、基本設計書の後に詳細設計書を書き、プログラムを作ります。一方、ノーコードツールやパッケージ製品に載せる場合、内部の処理はツール側が持っているため、詳細設計書にあたる部分はほとんど発生しません。そのかわり、基本設計書に書いた項目名・型・参照先が、そのままツールに入力する設定値になります。

 

つまり、ノーコードで作る場合は、基本設計書の細かさがそのまま構築の質を決めます。設計書に「金額」としか書いていなければ、構築する人が整数にするか文字列にするかをその場で決めることになり、作った人にしか分からない設定が生まれます。開発手法ごとの違いや選び方はノーコード開発の進め方で比較しています。

ここからは、基本設計書に書く項目を具体的に説明します。

基本設計書の標準的な目次

業務システムの基本設計書は、次の章立てで書けば大きな漏れは出ません。はじめて書く場合は、この順番をそのまま目次にしてください。

 

1. 業務概要（現行フロー、新業務フロー、課題とシステム化の利点）
2. 要件一覧（要件定義書の要件と、設計での対応箇所）
3. データ設計（マスタとトランの一覧）
4. 項目定義（項目ごとの型、桁数、値域、参照先）
5. 画面設計（入力画面、一覧画面、検索の条件）
6. 帳票設計（出力する書類の様式と、項目との対応）
7. 処理・連携設計（データの受け渡し、自動計算、外部システムとの連携）
8. 権限・承認設計（利用者の区分、閲覧と編集の範囲、承認ルート）
9. 未決事項・設計変更の記録

 

要件定義書の章立てと比べると、1と2は要件定義書から引き継ぐ章、3から8が新しく書く章、9は要件定義書の未決事項一覧を引き継いで育てていく章です。基本設計書を作る作業の大半は、3から8を埋めることだと考えてください。

実案件の基本設計書は、何でできていたか

当社が導入前検証で作成した基本設計書のうち、要件定義書の記事で紹介した2件の構成を紹介します。どちらも要件定義書と基本設計書を1つのExcelブックにまとめ、シートごとに章を分けていました。

 

	案件A：見積から請求までを1つのデータでつなぐ	案件B：取引先の署名を伴う伝票を電子化する
業種・規模	ソフトウェア開発業、従業員100〜200名規模	商社、従業員300〜500名規模
シート構成	業務概要／要件一覧／マスタ設計（項目定義）／項目タイプの定義／帳票出力（見積書、注文書、受領書・納品書、請求書、検収書の5シート）	業務概要／要件一覧／マスタ設計（項目定義）／マスタに入れる値の見本／帳票（2シート）／メール通知の見本
シート数	9シート	7シート
データの構成	伝票データ3つ（見積・納品・請求）、合計304項目	マスタ5つ、伝票データ5つ
要件の種別	自動採番、データ入力、帳票出力・保存、起案申請・承認の4種別	マスタ管理、データ入力、帳票出力・保存、起案申請・承認、帳票送付、帳票受領、外部連携の7種別

出典：導入前検証で作成した要件定義・基本設計書（2件）をもとに一般化して整理

 

この2件には、共通する特徴があります。独立した「画面設計」のシートがないことです。ノーコードツールでは、項目を定義すると入力画面がほぼ自動で組み上がるため、画面の設計は項目定義の並び順と型で代替できました。その分、項目定義のシートが最も行数の多いシートになっています。設計書の重心が「画面」ではなく「データ」にあることは、ノーコードで作る場合の大きな特徴です。

 

反対に、案件Bにだけある「マスタに入れる値の見本」と「メール通知の見本」のシートは、取引先や支店といったマスタの中身と、取引先とのやり取りが要件に含まれていたために追加されたものです。目次は固定ではなく、要件の種別に合わせて足し引きしてかまいません。

 

要件定義を終えた後、実際の現場でどんな課題に突き当たり、何を決めて何を見送ったのかは、業務カタログで紹介しています。業務カタログは、当社が導入前検証（PoC）で取り組んだ業務ごとに、課題の整理から解決の進め方までをまとめた記事です。基本設計で判断が必要になる場面を、業務の流れとあわせて読むことができます。

 

ここからが本題です。要件定義書を手元に置き、次の5つの手順で基本設計書を作っていきます。要件定義書のどの章が、基本設計書のどの章に置き換わるのかを示したものが以下の図です。

 

手順1 要件一覧に番号を振り、設計の起点にする

最初に、要件定義書の機能要件を「要件一覧」として1行1要件の表にし、番号を振ります。基本設計書のあらゆる記述は、この番号のどれかから来ている状態を目指します。

 

番号を振る理由は、レビューを機械的にできるようにするためです。どの要件にもつながらない設計は「頼まれていない機能」、どの設計にもつながらない要件は「設計漏れ」です。番号があれば、この2つを一覧の突き合わせだけで見つけられます。

 

案件Bの要件一覧は、7つの種別に分けて14行で書かれていました。たとえば「起案申請・承認」の種別には、「起案申請できること」「階層は5階層まで指定できること」「差戻しができること」の3行が並んでいます。1行は短くてかまいません。「〜できること」で終わる、できたかどうかを確かめられる形で書くのがコツです。

手順2 現行の帳票から項目を抜き出し、マスタとトランに分ける

次に、データの入れ物を設計します。出発点は、いま使っている帳票の実物です。帳票に印字されている欄を1つずつ書き出すと、それがほぼそのまま項目の候補になります。

 

書き出した項目は、2種類の入れ物に分けます。1つは、取引先や商品のように何度も繰り返し参照される情報を持つ「マスタ」です。もう1つは、伝票1枚ごとに1件ずつ発生する情報を持つ「トラン」（トランザクションデータの略で、伝票データのことです）です。案件Bでは、取引先、支店、得意先、商品、勘定科目の5つをマスタとし、確認書や伝票ごとのデータを5つのトランに分けました。

 

 

分け方の判断基準は、「同じ値を、複数の伝票に何度も書いているか」です。毎回同じ取引先名を手で打っているなら、それはマスタに切り出す候補です。マスタにしておけば、伝票側ではコードを選ぶだけで名称や単価が自動で入り、表記のゆれもなくなります。案件Bの特価承認申請書では、商品を選ぶと品名・規格・色・仕入単価が自動で入り、手で入力するのは数量と特価の単価だけになる設計にしました。

 

ただし、すべてをマスタにする必要はありません。外装リフォームの検証では、元請や施工店の名称を当面は文字列のまま持ち、設計書の備考に「マスタ化を検討？」と書いて判断を先送りしています。登録する件数が少ないうちは、マスタを保守する手間のほうが大きくなることがあるためです。

 

また、1枚の伝票に明細の行が複数ある場合は、伝票の見出し部分（鑑）と明細を別のデータに分けるかどうかも、この手順で決めます。案件Bでは、明細の行数が伝票によって変わる特価承認申請書は鑑と明細を分け、明細が最大3行で決まっている確認書は1つのデータに3行分の項目を並べる形にしました。行数が決まっているかどうかが、分け方の分かれ目です。

手順3 項目ごとに型・桁数・値域を決める

項目が出そろったら、1項目ずつ「型」を決めます。型とは、その項目に入る値の種類のことで、文字列、整数、小数、日付、選択肢、ファイル、自動採番などがあります。案件Aでは、使う型を8種類に絞り、設計書の冒頭に「項目タイプ」として一覧で定義していました。型の種類を先に決めておくと、項目ごとの判断がぶれにくくなります。

 

項目定義は、次のような表で書きます。2件の設計書から抜粋し、一般化したものです。

 

#	項目名	型	参照先	桁数・値域	備考
1	見積番号	自動採番	－	－	重複を防ぐため登録時に自動で振る
2	見積日	日付	－	－
3	数量	文字列	－	－	「一式」など単位付きで書くため整数にしない
4	単価	整数	－	－
5	消費税金額	整数	－	－	計算式で小数を扱えないため手入力
6	見積有効期限	選択肢	－	1か月〜3か月	選択式で入力
7	取引先コード	参照	取引先マスタ	5桁	選ぶと取引先名が自動で入る
8	金額	整数	－	1〜9,999,999	3桁区切り、円記号あり
9	発注番号	文字列	－	仮置き7桁	桁数は未確認。判明したら見直す

出典：導入前検証で作成した基本設計書（2件）から抜粋・一般化

 

ポイントは、型を「項目名から想像して」決めないことです。3の数量は、名前だけを見れば整数にしたくなります。しかし案件Aの見積書の実物には「一式」「2ライセンス」といった書き方があったため、文字列にしています。型は、帳票の実物に書かれている値を見て決めてください。

 

桁数と値域も同じです。8の金額の上限は、現行の伝票の欄に収まる桁から決めています。「念のため大きめに」ではなく、実物の欄と過去のデータを根拠にすると、後から利用者に説明しやすくなります。

 

一方で、9の発注番号のように、どうしても桁数が確認できない項目もあります。案件Bの設計書では、こうした項目に「★何ケタ？、仮置き7桁」と書き、仮の値を入れて設計を先に進めていました。空欄にしておくより、印を付けて仮置きしておくほうが、後から探しやすく、構築も止まりません。この印の付いた項目は、手順5で未決事項として引き継ぎます。

手順4 データのつなぎ方と、次の工程へ渡すきっかけを決める

データの入れ物と項目が決まったら、データ同士のつなぎ方を決めます。要件定義書の業務フローに「見積から納品、納品から請求へ」と書かれていれば、それを、どの番号でつなぐかという設計に置き換えます。

 

案件Aでは、見積・納品・請求の3つの伝票データを見積番号でつなぎました。納品データは見積番号を、請求データは見積番号と納品番号を引き継ぎます。前の工程のデータを引き継ぐので、取引先名や明細を書き写す必要がなくなります。

 

あわせて決めておきたいのが、「いつ、次の工程にデータを渡すか」というきっかけです。案件Aでは、見積データに「納品書データへ連携」という選択式の項目を置き、初期値を「0：未連携」としました。担当者が内容を確かめて「1：連携」に切り替えたときだけ、納品データが作られます。

 

自動で次の工程に流す設計にすることもできましたが、あえて人が切り替える形にしています。確認していない見積がそのまま請求まで流れることを防ぎ、誰がいつ次の工程に進めたのかを記録に残すためです。どこを自動にし、どこを人の判断に残すかは、要件定義書には書かれていないことが多いため、基本設計の段階で決めて理由を残してください。

 

見積書・納品書・請求書の転記を見積番号でなくす取り組みは、PoCで整理した課題や、次の工程へ渡す操作をあえて手作業に残した判断とあわせて、業務カタログで紹介しています。

 

手順5 帳票・承認・連携を設計し、未決事項を引き継ぐ

最後に、帳票、権限と承認、外部連携の3つを設計し、未決事項を整理します。どれも要件定義書に「〜できること」と書かれている要件を、具体的な設定に置き換える作業です。

 

帳票は、出力する書類ごとに様式を用意し、帳票の欄と項目の対応を決めます。案件Aでは、見積書、注文書、受領書・納品書、請求書、検収書の様式を、それぞれ1シートずつ設計書に収めていました。要件の「出力したPDFを保存できること」は、伝票データの中にファイル型の項目を設け、出力したPDFをそこに保存する形に置き換えています。要件の1行が、設計では項目1つに対応している例です。

 

権限と承認は、要件の数字を「設定できる上限」と「いまの運用」に分けて書きます。案件Bの要件は「階層は5階層まで指定できること」でしたが、実際の承認は上長、支店長、仕入責任者、本社の業務部門の4段です。設計書には両方を書き、組織変更で1段増えてもシステムを直さずに済むようにしました。あわせて、取引先には社内の承認状況を見せないこと、帳票出力用のデータは一部の項目を除いて読み取り専用にして承認後の書き換えを防ぐことも、権限の設計として決めています。

 

外部連携は、要件定義の時点で相手側の仕様が分かっていないことがよくあります。案件Bでも、基幹システムへのデータ連携は要件として確定していましたが、連携方式の詳細は基本設計の段階でも決まりませんでした。そこで、基幹システムへ渡すデータをどこに置くかだけを先に決め、方式は未決事項として残しています。

 

ここまでの手順で出てきた未決事項は、要件定義書の未決事項一覧と1つにまとめます。要件定義書で未決だった項目は消さずに引き継ぎ、手順3の「仮置き」のように設計で新たに生まれた未決を追加します。案件Bの設計書には、桁数の確認待ち、連番のルールの検討中、マスタの持ち方の要検討といった印が複数残っていました。未決が残っていること自体は問題ではありません。どこに残っているかが一覧で分かる状態にしておくことが大切です。

 

手書きの伝票と取引先の署名を一続きにする取り組みは、伝票から伝票への書き写しや紙の回覧をどう減らしたのか、システム化しなかった範囲とあわせて業務カタログで紹介しています。

 

基本設計に進むと、要件定義書で決めた内容が、そのままの形では作れないと分かる場面があります。当社の設計書に残っていた記録から、代表的な4つを紹介します。

 

場面	要件定義での想定	基本設計で変えた内容	変えた理由
消費税の計算	計算式で自動計算する	消費税額を手入力の項目に変更	計算式で小数を扱えなかった
伝票番号の入力	整数で手入力したい（現場の要望）	振替伝票のデータを参照する項目に変更	番号を選ぶと伝票の発行日を自動で入れられるため
申請書番号の形式	選択式で入力する（当初の案）	6桁の文字列に変更	選択式にすると、明細を含む登録のときに保存できなかった
申請画面の自動計算	計算する項目をそのまま配置する	計算用の項目を別に追加	自動計算に使える項目数の上限に達した

出典：導入前検証で作成した基本設計書・設計メモ（3件）をもとに整理。4行目は食品製造業の燃料費申請の設計

 

このほかにも、案件Bでは、支店ごとの単価を持たない商品について、差額の計算で支店別単価が0として扱われてしまうことが設計の途中で分かりました。マスタのすべての商品に支店別の単価を入れたうえで、使うかどうかを印で切り替える案を検討しています。計算式の落とし穴は、実際のデータを入れてみて初めて見つかることが多いものです。

 

こうした変更に対して、基本設計書で守ってほしいことは2つあります。1つは、変えた内容を備考欄に理由とともに残すことです。案件Bの設計書には、伝票番号の項目について「伝発日の自動入力のため、本項目をトラン参照に」と、変更の理由が1行で書かれていました。この1行があるだけで、後から設計書を読んだ人が「なぜ整数ではないのか」を迷わずに済みます。

 

もう1つは、変わったのが「要件」なのか「実現方法」なのかを区別することです。消費税の例でいえば、「消費税額を記録する」という要件は変わっておらず、変わったのは計算式か手入力かという実現方法だけです。要件そのものが変わる場合は、要件定義書の側も直し、関係者の合意を取り直してください。この区別をしないまま設計だけを変えていくと、冒頭の調査にあった「設計書と実態の乖離」が生まれます。

基本設計書が一通りできたら、次の7つの観点でレビューします。すべてを満たしていれば、未決事項が残っていても次の工程（詳細設計、またはノーコードの場合は構築）に進んでかまいません。

 

#	確認する観点	確認の方法
1	要件一覧のすべての行に、設計の対応箇所が書かれている	対応箇所が空欄の要件がないか（設計漏れ）
2	設計のすべてが、要件一覧のどれかにつながっている	要件番号のない機能や項目がないか（頼まれていない機能）
3	すべての項目に、型と桁数（または仮置きの印）がある	型が空欄の項目がないか
4	番号の振り方と、データ同士のつなぎ方が決まっている	どの番号で前の工程を引き継ぐかが書かれているか
5	帳票ごとに、項目と欄の対応が取れている	出力するすべての様式がそろっているか
6	承認ルート、閲覧と編集の権限、読み取り専用の範囲が決まっている	上限と現在の運用が分けて書かれているか
7	未決事項と設計の変更が、理由とともに記録されている	印だけで理由のない変更がないか

 

レビューには、その業務を毎日触っている担当者を必ず加えてください。項目名を現場で使っている呼び方で読み上げてもらうと、「この欄は実際には別の名前で呼んでいる」「この値は月末だけ入る」といった、設計書だけでは見えない違和感が出てきます。

 

ノーコードで作る場合は、基本設計書がまとまった段階で、一部を実際に作って試すことをおすすめします。項目定義をツールに入力してみると、前の章で紹介したような型の制約や上限が、本番の構築を始める前に見つかります。試す範囲や合否の基準の決め方はPoC設計の進め方でまとめています。

 

要件定義書の記事で紹介した2件とは別の業種で、要件を基本設計に置き換えた事例を2つ紹介します。

事例1 外装リフォーム業｜案件と見積を親子2層に分けた設計

1つ目は、外装リフォームの工事を請け負う会社の事例です。元請から届く案件を複数の経路で受け付け、共有のExcelの台帳で管理していました。見積はExcelとマクロで自動計算していましたが、1行に1案件を記録する台帳では、1つの案件に複数の見積プランを持たせることができず、プランを作るたびに転記が発生していました。

 

初回の打合せでは、懸念が3つ挙がりました。見積で考慮する要素が案件ごとに変わるため、どこまでマスタにできるか分からないこと。それに伴い、項目の数が上限を超えるかもしれないこと。用意する帳票の様式のパターンが見えないこと、です。

 

基本設計では、最終的な目標である「案件管理から見積、承認、発注、工程管理、計上まで一気通貫で管理する」ことは要件として残しつつ、最初に作る範囲を、現在のExcelで最も負荷の高い案件管理と見積管理に絞りました。そのうえで、案件を親、見積を子とする2層のデータ構造にしています。

 

親の案件データは18項目で、案件番号を自動で振り、進捗を「受付、現調中、見積中、商談中、成約、施工中、完工、失注」の8つの状態で管理します。子の見積データは27項目で、案件番号で親を参照し、顧客名・住所・連絡先を親から自動で取得します。どのプランで契約したかを示す「採用フラグ」と、見積書を出力するきっかけになる「PDF作成フラグ」も、子の側に置きました。

 

この事例で基本設計の核心になったのは、「1つの案件に複数の見積を持ちたい」という要件を、親子2層というデータの構造に置き換えた判断です。要件定義書に書かれた1行が、設計では入れ物の形そのものを決めることがあります。

 

案件と見積を分けて管理し、見積書の転記や取り違えを防ぐ取り組みは、自動化を見送った判断とあわせて業務カタログで紹介しています。

 

事例2 食品製造業｜承認ルートを所属と職位で分けた燃料費申請の設計

2つ目は、正社員約520名の食品製造業の事例です。私有車を業務で使ったときの燃料費を申請する仕組みを作りたいという要望から、検証が始まりました。既存のワークフローのツールでは、申請者によって承認ルートを分けることができず、申請画面に必要な入力欄を出すこともできませんでした。

 

要件は「所属や職位によってルートを分岐できること」の1行です。基本設計では、これを「グループと職位の組み合わせでルートを決める」という設定に置き換えました。申請画面は、現場が使い慣れた元のExcelの申請書と同じ並びにしています。検証用には、管理部・営業部・SCM（供給網の管理）事業部の3つのグループを用意し、管理部と営業部には一般社員・主任・課長・部長の4つの職位を設けて、ルートが正しく分かれるかを確かめています。

 

設計の途中では、前の章で紹介したとおり、自動計算に使える項目数の上限に達しました。計算用の項目を別に追加して回避し、その経緯を設計メモに「解消済み」として残しています。

 

承認の要件を「誰が承認するか」という人の名前ではなく、「どの属性で分岐するか」に置き換えて設計したことが、この事例のポイントです。人の名前で設計すると、異動のたびにルートを直す必要がありますが、属性で設計しておけば、利用者の所属と職位を変えるだけで済みます。承認ルートの決め方は承認ルートの設計で詳しく解説しています。

 

なお、記載している業務内容および設計情報は架空のものではなく、弊社が実際に携わった複数の業務経験がベースとなっています。特定の企業や案件を識別できないよう一般化・再構成したうえで整理しています。

Q1 基本設計書と詳細設計書の違いは何ですか

基本設計書は、データの項目、画面、帳票、処理の流れといった、利用者から見える部分を決める文書です。詳細設計書は、プログラムを作る人に向けて、内部の処理の手順や構造を決める文書です。業務部門の担当者がレビューに加わるのは主に基本設計書で、詳細設計書は開発者どうしで確認するのが一般的です。

Q2 基本設計書は誰が書くものですか

ベンダーや社内の構築担当といった設計側が書くのが一般的です。ただし、要件が正しく翻訳されているかを確かめられるのは発注側だけなので、発注側はレビューと承認に必ず加わります。ノーコードで社内で作る場合は、業務部門の担当者が自分で書くこともあります。その場合も、書く人とは別の人がレビューする体制を作ってください。

Q3 基本設計書はWordとExcelのどちらで書くべきですか

項目定義やデータ設計のように表が中心になる部分は、Excelが向いています。本記事で紹介した2件も、要件定義書と基本設計書を1つのExcelブックにまとめ、シートごとに章を分けていました。処理の流れや判断の経緯など、文章での説明が多くなる部分だけをWordで補う形でもかまいません。大切なのは、要件一覧と項目定義を同じファイルの中で突き合わせられることです。

Q4 ノーコードで作る場合も、基本設計書は必要ですか

必要です。ノーコードでは画面がすぐに作れるため、設計書を書かずに作り始めてしまいがちです。しかし項目の型や参照先の理由が残っていないと、作った人が異動したときに、誰も設定の意味を説明できなくなります。ノーコードの場合は、項目定義と変更の記録の2つだけでも、必ず残してください。

Q5 基本設計書のサンプルやテンプレートは、どこで手に入りますか

本記事の「標準的な目次」と「項目定義」の表を、そのまま雛形として使えます。要件定義書の記事で配布しているテンプレートには項目定義のシートが含まれているため、要件定義書で書いた項目定義を引き継いで、型や参照先の列を足していく使い方もできます。ほかの会社が要件定義の後にどんな判断をしたのかを知りたい場合は、PoCでの取り組みを業務ごとに紹介した業務カタログも参考になります。

Q6 上司や情報システム部門にレビューを頼むとき、何を添えればよいですか

要件一覧と設計の対応表、未決事項の一覧、設計で変えた内容の記録の3点を添えると、レビューが進みやすくなります。あわせて、見てほしい観点を絞って伝えてください。情報システム部門には権限と外部連携、上司には対象外とした範囲と未決事項の影響、というように相手ごとに分けると、短い時間でも判断に必要な指摘をもらえます。

基本設計書は、要件定義書で決めた要件を、システムの部品の言葉に翻訳する文書です。白紙から書くのではなく、要件定義書の1行ずつを「データ・画面・帳票・流れ」に置き換えて作ります。ノーコードやパッケージで作る場合は、基本設計書がそのまま設定書になるため、項目定義の細かさが構築の質を決めます。

 

作る手順は、要件一覧に番号を振る、帳票の実物から項目を抜き出してマスタとトランに分ける、項目ごとに型・桁数・値域を決める、データのつなぎ方と次の工程へ渡すきっかけを決める、帳票・承認・連携を設計して未決事項を引き継ぐ、の5つです。

 

設計の段階で要件から内容が変わることは珍しくありません。変えた内容は理由とともに残し、要件そのものが変わったのか、実現方法が変わっただけなのかを区別してください。そうしておけば、運用が始まってからも読み返せる基本設計書になります。

 

自社の要件定義書や帳票が、どこまでそのまま設計に置き換えられるかは、実際のデータで試すと判断しやすくなります。具体的な内容が知りたい場合は、お問い合わせページからご連絡ください。