基本設計と詳細設計の違いは？システム設計で書き分ける7項目

システム設計とは？

システム設計は、要件定義で決めた内容をもとに、画面・機能・データ・外部連携・処理の流れなどを具体化する工程です。このうち顧客が読んで判断できる内容は設計書に載せ、自社の業務に合っているかを確認してもらいます。

システム設計の意味

この内容は、開発者が実装するための材料になるだけではありません。顧客に「この内容で作って問題ないか」を確認してもらう資料にもなります。

 

• どの画面が必要か

• 各画面で何を入力・表示するか

• どの機能をどのタイミングで使うか

• どのデータを保存・更新するか

• ほかのシステムとどの情報を連携するか

• 利用者ごとにどの操作を許可するか

 

この内容は、開発者が実装するための材料になるだけではありません。顧客に「この内容で作って問題ないか」を確認してもらう資料にもなります。

システム設計で決めること

システム設計では、業務上の要望をそのまま文章で残すのではなく、画面・機能・データ・処理の形に置き換えます。主に決める内容は、以下のとおりです。

 

決める内容	顧客に確認してもらうこと
画面	業務で使う順番と画面の流れが合っているか
機能	必要な操作や処理が抜けていないか
データ	入力・保存・出力する項目が足りているか
権限	利用者ごとに見られる情報や操作できる内容が分かれているか
外部連携	ほかのシステムと連携する情報やタイミングが決まっているか
通知	誰に、どの条件で通知するかが決まっているか

 

顧客に、すべての技術的な内容を理解してもらう必要はありません。業務の流れや利用者の動きに関わる内容から確認してもらうと、認識を合わせやすくなります。

要件定義との違い

要件定義は「何を作るか」を決める工程です。それに対してシステム設計は、その内容を「どのような画面・機能・データで実現するか」に落とし込む工程です。

 

たとえば、要件定義で「顧客情報を管理したい」と決めたとします。すると、システム設計では「どのような画面や機能で、誰がどのように顧客情報を扱うのか」を、以下のように具体的に決めていきます。

 

• 顧客一覧画面に表示する項目

• 顧客詳細画面で編集できる情報

• 顧客情報を登録・更新できる利用者

• 顧客情報を検索する条件

• 他システムと連携する項目

 

要件定義のままでは、開発者が画面や処理を作るには情報が足りません。システム設計で具体化すると、顧客と開発会社が同じ完成イメージを持ちやすくなります。

 

設計の段階で画面や機能を見てもらえば、実装後に「この入力項目が足りない」「この業務では別の承認者が必要だった」と言われる回数を減らせます。

システム設計の流れ

システム開発では、要件定義→方式設計→基本設計→詳細設計→実装→テストの順で、システム設計を進めます。工程名や分け方は、開発会社や案件の規模によって異なります。

 

ここでは代表的な流れで、どの工程で何が決まるのかを見ていきましょう。

 

 

顧客と合意する内容は、基本設計に集まります。画面、機能、データ項目、権限、外部連携といった、利用者の操作や業務の判断に直接かかわる内容が決まるのが、この工程です。詳細設計は開発会社の中で進めますが、基本設計で合意した内容に影響が出るときは顧客に確認します。

要件定義

要件定義では、システムで解決したい課題や、作る機能の範囲を決めます。たとえば、「紙で管理している申請をシステム化したい」「顧客情報を部署ごとに分けずに管理したい」といった目的を整理します。

 

この段階で確かめるのは、顧客が困っていることや優先したい業務を、こちらが取り違えていないかどうかです。たとえば「紙の申請を減らしたい」「承認に時間がかかっている」といった現場の課題を、具体的な要望の形に書き直して顧客に読み返してもらいます。

 

要件定義が曖昧なまま次の設計に進むと、「どの画面で何をするのか」「どの機能が必要なのか」といった前提がずれやすくなります。

方式設計

方式設計では、システム全体の構成や技術方針を決めます。

 

たとえば、「社内だけで使うのか、外出先からも使うのか」「同時に何人くらいが利用するのか」「既存の販売管理システムとデータを連携する必要があるのか」といった前提をもとに、サーバーやネットワークの構成、利用するサービス、セキュリティの考え方などを整理します。

 

顧客に、サーバーの種類やネットワーク構成を判断してもらう必要はありません。ただし、「営業担当が外出先からスマホで使いたい」「夜間バッチ処理がある」「社内の既存システムと連携したい」といった利用条件や制約は、方式設計に入る前に顧客から聞き出しておきます。

基本設計

基本設計では、利用者から見える画面や機能を具体化します。主に、画面一覧、画面レイアウト、機能一覧、データ項目、権限、外部連携、通知条件などを設計します。

 

たとえば、営業担当が顧客情報を登録する画面や、上長が承認する画面、一覧で検索する画面など、実際の業務で使う場面をイメージしながら内容を決めていきます。

 

この工程で決めた内容を、顧客に確認してもらいます。たとえば「営業担当が顧客を登録して、上長が承認する」という流れなら、その順番どおりに並べた画面と、入力する項目・承認の操作を書き出したものを確認してもらいましょう。

 

見てもらうときは、利用部門の担当者にも同席してもらいます。画面の順番や項目の抜けは、日々その業務をしている人でなければ気付けません。

詳細設計

詳細設計では、基本設計で決めた画面や機能をもとに、開発者が実際にプログラムを作れるように内部の動きを細かく決め、設計書としてまとめます。

 

たとえば、「登録ボタンを押したときにどの順番で処理が動くか」「入力されたデータをどのように保存するか」「エラーが出たときにどの画面に戻すか」といった、利用者からは見えない部分の動きを具体化します。

 

詳細設計は、開発会社の中で確認する資料です。顧客にすべてを読んでもらう必要はありません。ただし、詳細設計を進めるうちに基本設計で決めた画面や機能を変えることになったら、その時点で顧客に確認します。

実装・テスト

設計が固まると、開発会社は設計書をもとに実装へ進みます。実装後は設計どおりに動くかをテストし、そのうえで業務で使えるかを顧客に確認してもらいます。

 

たとえば、申請システムであれば、「申請画面で必要な項目を入力して登録する」「承認者が承認ボタンを押す」「申請者に通知が届く」といった一連の流れを実際に操作して確認します。

 

動作確認では、「どの画面で」「どの操作をして」「どの結果になれば完了か」を事前に決めておくことが大切です。確認内容が曖昧だと、担当者ごとに判断が分かれ、「ここまでできていればOKなのか」がはっきりしなくなります。

利用者が触る部分は基本設計、内部の動きは詳細設計で決まる

利用者が操作するときに目に入るのは、画面に並ぶ入力項目や承認の順番です。そのため、基本設計に書いて、顧客に確認してもらいましょう。また、入力された値をどの順番で保存するかは、利用者の操作には出てきません。この部分は、詳細設計で決めます。

 

ただし、この分け方だけでは決まらない項目もあります。たとえば「顧客名は全角50文字まで」という制限は、画面を見ただけではわかりません。利用者が51文字目を入力して、初めて気付きます。

 

こういう項目をどちらで決めるかは案件ごとに違い、同じ「基本設計書」でも書かれている細かさは異なります。

 

案件によって分かれ方が変わるのは、次の7項目です。

 

• 画面の流れ
• 入力・表示項目
• 機能
• 権限
• 通知・承認
• 外部連携
• 帳票・CSV

 

自分の案件でどちらに入っているかは、顧客に承認してもらう設計書を開いて、その項目が書いてあるかどうかで確かめられます。書いてなければ、その項目は詳細設計で決まります。

文字数を決めるのは基本設計か詳細設計か

7項目のうち、案件によって分かれやすいのが入力・表示項目です。

 

基本設計では、画面ごとに「顧客名」「受注日」「金額」といった項目名と、必須か任意か、画面のどこに並べるかを決めます。ここまでは顧客が読んで判断できる範囲です。

 

一方、「顧客名は全角50文字まで」「金額は半角数字だけ」「桁を超えたときに出すメッセージの文面」は、基本設計書に書かれないことがあります。画面の見た目には出てこないので、詳細設計で開発会社が決める扱いになりやすい項目です。

 

ところが、文字数は業務に直結します。例えば、全角50文字までにしたら、正式名称の長い取引先を登録できないということが起こりました。こういったことは、顧客に確認してもらわないまま決めると、テストの段階で「うちの取引先名が入らない」と言われてしまいます。

 

自分の案件ではどうなっているのかを確かめる方法は、基本設計書の項目一覧に「文字数」「文字種」の列があるかを見ることです。列がなければ、その値は詳細設計で決まります。取引先名や商品名のように業務で長さが変わる項目だけでも、基本設計の段階で文字数を書いて顧客に見てもらいましょう。

7項目それぞれで基本設計と詳細設計が分かれる場所

項目	基本設計側で決めること	詳細設計側で決めること	どちらに置くかを決める判断材料
画面の流れ	使う画面の一覧と、業務の順番どおりの画面の移り方	エラーで止まったときに戻る画面、前の画面から値を引き継ぐ動き	その移り方が変わると、利用者の操作手順も変わるか
入力・表示項目	項目名、必須か任意か、画面のどこに並べるか	入力できる文字数と文字種、入力を断るときのメッセージの文面	基本設計書の項目一覧に、文字数と文字種の列があるか
機能	機能の一覧と、誰がどの画面で使うか	処理の順番、同じデータを同時に更新されたときの扱い	機能一覧が機能名だけか、「登録済みの顧客は登録させない」まで書いてあるか
権限	利用者の種類ごとに、見える画面と行える操作	権限のない利用者にボタンを隠すか、押した後に断るか	権限のないときの画面の見え方が、顧客に見せる資料に書いてあるか
通知・承認	誰に、どの条件で通知するか。承認は何段あるか、代理で承認できるか	通知を送る手段、送信に失敗したときの再送、通知文の作り方	通知文の実物が基本設計書にあるか
外部連携	連携する相手、渡す情報、連携する時点、失敗に誰が気付くか	項目どうしの対応づけ、文字コード、再送の回数	相手システム側で決まる条件が混じっていないか。混じっていれば方式設計で先に決まる
帳票・CSV	出す帳票の種類、載せる項目、誰がいつ出力するか	用紙の中の配置、改ページ、ファイル名、区切り文字	いま使っている帳票と同じ見た目にする必要があるか

「外部設計」「内部設計」は基本設計・詳細設計の言い換えとは限らない

開発会社によっては、基本設計・詳細設計ではなく「外部設計」「内部設計」という名前を使います。外部設計が基本設計、内部設計が詳細設計、と読み替えたくなりますが、そうならないことがあります。

 

例えば情報サービス産業協会が公開しているモデル契約書では、「外部設計書」は、画面や帳票などの利用者が触る部分と、ほかのシステムとのデータの受け渡しを定めた設計書と書かれています。ここは基本設計書とほぼ同じ中身です。

 

ところが「内部設計」のほうは、詳細設計ではなく「システム方式設計に相当するもの」と定義されています。この記事の「システム設計の流れ」で2番目に挙げた方式設計のことで、基本設計より前の工程です。

 

つまり、工程名を対応させても、自分の案件には当てはまるとは限らないのです。見積書や契約書を開いて、どの設計書を顧客に承認してもらうことになっているかを見ましょう。承認してもらう資料に書く内容が基本設計、書かない内容が詳細設計です。

基本設計は顧客が読んで判断できるように細かく書く

基本設計と詳細設計は、どちらもシステム設計に含まれます。顧客は、すべての設計書を細かく読み込む必要はありません。たとえば業務の流れや画面の使い勝手など、自分たちの業務に直結する部分を中心に確認すれば十分です。

 

基本設計書をどこまで細かく書くかは、顧客がそれを読んで「この内容で作ってよい」と答えられるかで決めます。項目名だけを並べると、顧客は自分の業務で足りているかを判断できません。かといって処理の順番まで書くと、判断に関係のないところまで読ませることになってしまいます。

 

目安は、顧客が「この画面で自分の業務が回るか」に答えられるかどうかです。答えられない書き方になっていたら、直すのは顧客の読み方ではなく基本設計書の方です。

顧客が自分の業務で足りているかを答えられる書き方にする

基本設計書を書いたら、顧客がその場で答えられるかを自分で読み返します。画面の順番なら「朝ログインしてから、この順番で操作して業務が終わるか」、入力項目なら「この項目だけで現場の記録が残るか」に答えられる形になっているかを見ます。

 

読み返すのは、次の7つです。

 

• 画面の流れが実際の業務手順と合っているか
  　（例：申請→承認→完了の順番が、現場の運用とズレていないか）

• 画面ごとの入力項目・表示項目が足りているか
  　（例：現場で必ず確認している情報が抜けていないか）

• 必要な機能が抜けていないか
  　（例：検索・絞り込み・履歴確認など、日常的に使う操作ができるか）

• 利用者ごとの権限が業務に合っているか
  　（例：担当者・上長・管理者で見える情報や操作が適切に分かれているか）

• 通知や承認の条件が決まっているか
  　（例：誰に、どのタイミングで通知が届くかが明確か）

• 外部システムとの連携内容が業務に合っているか
  　（例：既存システムとのデータの受け渡しにズレがないか）

• 帳票やCSV出力に必要な項目が含まれているか
  　（例：現場で実際に使っている帳票と同じ情報が出せるか）

 

一方、答えられる書き方になっていないのは、次の3つです。

 

• 項目名だけで例が書かれていない
• 画面の名前が現場で使っていない言葉になっている
• 帳票やCSVの出力が機能名だけで書かれている

 

どれも、顧客は自分の業務に当てはめられません。

基本設計で決めた内容を変えるときは、理由と影響を添えて提案する

詳細設計を進めると、基本設計で決めた内容を変えないと作れない、という場面が出てきます。処理の取り違えを防ぐために、同じデータを同時に編集できる人を1人に絞る、といった変更です。

 

このとき顧客に渡すのは、直した設計書ではありません。「同時に更新されたときの取り違えを防ぐには、編集できる人を1人に絞る必要がある」というように、変える理由と変えた後で利用者の操作がどう変わるかを書いて、変更してよいかを確認してもらいます。

 

確認してもらうかどうかは、次の4つで決めます。

 

• 基本設計で合意した画面や機能に変更が出るか
  　（例：入力項目が減っている、操作手順が変わっているなど）

• 業務の流れや承認条件に影響があるか
  　（例：承認ルートが変わる、承認タイミングがずれるなど）

• 入力チェックやエラー表示が利用者に分かる内容になっているか
  　（例：現場の担当者が見て理解できるメッセージになっているか）

• 外部システムとの連携条件が業務に影響しないか
  　（例：データの反映タイミングが遅れて業務に支障が出ないか）

 

どれかに当てはまったら、顧客に確認してもらいます。そのとき書き添えるのは、変更の理由・変える内容・費用がかかるならその額・作業のスケジュールと納期に与える影響の4つです。情報サービス産業協会が公開しているモデル契約書も、設計書の内容を変えるときは「変更の内容、理由等を明記した書面」を相手方に渡して提案し、この4つを記載した書面で協議すると書かれています。

主な設計書は4種類あり、顧客に見せる内容は資料ごとに決まる

システム設計では、決めた内容を設計書として残します。設計書の名前は開発会社ごとに違いますが、どの資料に何を書くかを押さえておくと、基本設計と詳細設計のどちらで決まる内容かを見分けられます。

 

ここで挙げるのは、顧客に見せる機会の多い4種類です。

基本設計書

基本設計書は、システム全体の構成や主要な機能をまとめた資料です。

 

たとえば顧客が「受注から請求までをシステムで管理したい」と考えているなら、どの画面で受注を登録し、誰が承認し、どのタイミングで請求データが作られるのかを、この資料に書きます。

 

基本設計書は、「このシステムはこう動く」という完成イメージを顧客と開発会社でそろえるための資料です。顧客が読んで「この内容で作ってよい」と答えられるかどうかが、書く細かさの目安になります。

画面設計書

画面設計書は、画面ごとのレイアウトや入力項目、ボタン、表示内容をまとめた資料です。入力項目の名前と並び順までを画面設計書に書き、文字数と文字種は別の資料に書くこともあります。

 

画面設計書は、完成後の使いやすさに直結する資料です。実際にその業務を担当している人に、「この順番で操作できるか」「迷わず使えそうか」を見てもらいましょう。

機能設計書

機能設計書は、各機能がどのように動くかをまとめた資料です。登録、編集、削除、検索、承認、通知、CSV出力などの処理内容を書きます。

 

機能名だけを並べると、顧客は自分の業務で足りているかを判断できません。誰が、どの画面で、どのタイミングで操作し、その結果どうなるかまで書きます。承認と通知は業務のルールが絡むので、担当者とタイミングを明記します。

データ項目・外部連携に関する設計書

データ項目に関する設計書に載せるのは、システムで扱う情報の種類や形式です。営業担当者が日々入力する顧客名や担当者名、見積金額、受注日、進捗ステータス、商談メモなど、業務で使う項目が過不足なく入っているかを顧客に確認してもらいます。

 

外部連携に関する設計書が扱うのは、営業管理システムから会計システムへ売上データを渡す場合など、どの情報をどのタイミングで連携するかです。連携に失敗したときに誰がどう気付き、誰がどこまで戻して直すかも、この資料に記載します。

 

APIや通信方式、項目どうしの対応づけは、詳細設計に回ることがあります。ただし「営業が入力した情報がそのまま請求処理に使えるか」「二重入力が発生しないか」は顧客の業務に直結するので、基本設計の段階で確認してもらいましょう。

基本設計の確定前に、どこからを仕様変更として扱うかを決める

例えば、画面のデザインがほぼ固まったあとに「このボタンの位置を変えたい」「この機能も追加したい」という要望が出ることがあります。この場合、どこからを仕様変更として扱うかを決めていないと、追加費用と納期の話が設計の終盤まで残ってしまいます。

 

基本設計を確定させる時点で、顧客と次の4つを決めておきましょう。

 

• どの時点から変更扱いになるか（基本設計確定後なのか、詳細設計の完了後なのか）

• 変更時に見積もりや納期を再確認するか（その場で判断するのか、正式な再見積もりを出すのか）

• 変更内容をどの資料に反映するか（基本設計書、画面設計書など）

• 変更の承認者は誰か（担当者でよいのか、上長の承認が必要か）

 

口頭で「ではそれでお願いします」と進めると、後から「そこまでの変更だとは思っていなかった」「費用が増えるとは聞いていない」という話になってしまいます。決めた内容は課題管理表や議事録に残し、誰が見ても経緯を追える状態にしておきましょう。

まとめ

今担当している案件の基本設計書を開いて、入力できる文字数、権限のないときの画面の見え方、通知文の実物の3つが書かれているかを見てください。この3つは、どちらの設計で決めるかが案件によって分かれます。

 

書かれていなければ詳細設計で決まるので、顧客の目に触れないまま固まってしまいます。書かれていなかったものを1つだけ、次の打ち合わせまでに基本設計書へ足してみてください。