システム設計とは？基本設計・詳細設計の違いもわかりやすく解説

システム開発を進めるとき、「要件定義」「基本設計」「詳細設計」といった言葉が出てきます。開発会社との打ち合わせや見積書の中で見かけても、発注側からすると、それぞれの違いが分かりにくいことがあります。

システム設計は、開発会社だけが内部で行う専門作業ではありません。自社の業務をどのようにシステムへ落とし込むかを整理し、発注側と開発側の認識を合わせるための大切な工程です。

この記事では、システム設計の基本、要件定義・基本設計・詳細設計の違い、発注側が確認すべきポイントを、非IT担当者にも分かる言葉で整理します。

システム設計を理解しておくと、画面や機能だけでなく、データ、権限、運用ルールまで含めて確認しやすくなります。

システム設計とは、要件を画面・機能・データ・運用に落とし込む工程

システム設計とは、要件定義で整理した「何を実現したいか」を、実際に使えるシステムの形へ具体化する工程です。

言い換えると、システム設計は「業務上の目的」を、画面・機能・データ・権限・業務フロー・運用ルールへ落とし込む作業です。

たとえば、「受発注業務を効率化したい」という要望がある場合、それだけではまだシステムとして作る内容は決まりません。どの画面が必要か、誰が入力するのか、どのデータを管理するのか、誰が確認・承認するのか、運用後に誰が管理するのかを整理する必要があります。

この整理が曖昧なまま進むと、画面や機能は作れても、現場の業務の流れと合わないことがあります。システム設計では、こうしたズレを減らすために、業務上の目的を具体的な仕組みへ変換していきます。

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

システム設計で整理する内容は、開発するシステムの規模や目的によって変わります。中小企業の業務システム開発であれば、主に次のような項目を確認します。

• どの業務をシステム化するか
• どの画面が必要か
• どの機能を作るか
• どのデータを登録・更新・検索するか
• 誰がどの操作をできるようにするか
• 承認や確認の流れをどうするか
• 既存のExcelや外部ツールとどう関係するか
• 運用開始後に誰が管理するか

ここで大切なのは、機能をたくさん並べることではありません。実際の業務で迷わず使える形になっているかを確認することです。

システム設計は、機能一覧を作るだけの工程ではなく、業務課題を実際に使える仕組みへ変換する工程です。

要件定義・基本設計・詳細設計の違い

システム開発では、要件定義、基本設計、詳細設計という工程がよく使われます。どれも似た言葉に見えますが、役割は異なります。

大まかに分けると、要件定義は「何を実現したいか」を整理する工程、基本設計は「利用者から見てどう使うか」を整理する工程、詳細設計は「開発者がどう作るか」を具体化する工程です。

要件定義について詳しく知りたい場合は、システム要件定義で決めることも参考になります。

要件定義は「何を実現したいか」を整理する工程

要件定義では、自社が何に困っているのか、何を改善したいのか、どの業務をシステム化したいのかを整理します。

たとえば、次のような内容です。

• 受注情報を一元管理したい
• Excelの二重入力を減らしたい
• 担当者ごとの進捗を見えるようにしたい
• 承認状況を確認しやすくしたい
• 顧客対応履歴を残したい

この段階では、まだ具体的な画面や処理の細部までは決まっていないこともあります。まずは「何を実現したいのか」を整理することが目的です。

要件定義を丁寧に行うと、開発会社に伝える内容が明確になりやすくなります。ただし、最初からすべてを完璧に決める必要はありません。業務の流れや困っていることを言葉にするだけでも、設計に必要な材料は見えやすくなります。

基本設計は「利用者から見た使い方」を整理する工程

基本設計では、要件定義で整理した内容をもとに、利用者から見える画面や操作の流れを具体化します。

たとえば、次のような内容を整理します。

• ログイン後にどの画面を表示するか
• 受注情報をどの項目で入力するか
• 一覧画面で何を確認できるようにするか
• 担当者、管理者、承認者で操作できる範囲をどう分けるか
• ステータスや通知をどのように扱うか

基本設計は、発注側が特に確認しやすい工程です。実際の業務と画面の流れが合っているか、現場の使い方に無理がないかを確認します。

ここで確認が不足すると、画面は分かりやすく見えても、実際の入力順や承認の流れが現場と合わないことがあります。発注側は、見た目だけでなく、実際の作業順に沿って使えるかを確認することが大切です。

詳細設計は「開発者が実装できる内容」に落とし込む工程

詳細設計では、開発者が実装できるように、内部の処理やデータの扱いを具体化します。

たとえば、データベースの項目、処理条件、エラー時の動き、権限ごとの処理分岐、外部システムとの連携方法などを整理します。

発注側が詳細設計のすべてを理解する必要はありません。ただし、例外的な業務の流れや、誰がどのデータを扱うのかといった前提がずれていないかは確認しておくと安心です。

要件定義、基本設計、詳細設計の違いを整理すると、発注側がどこを確認すべきかも見えやすくなります。

基本設計で発注側が確認すべきこと

基本設計では、発注側が確認すべき内容が多くあります。画面や操作の流れは、現場の業務と直結するためです。

開発会社が画面案を作ったとしても、実際に使う人の流れと合っていなければ、導入後に使いづらさが残ることがあります。

画面と操作の流れ

まず確認したいのは、画面と操作の流れです。

たとえば、受注管理システムであれば、次のような流れを確認します。

• 受注情報を登録する
• 担当者が内容を確認する
• 必要に応じて承認する
• ステータスを更新する
• 請求や出荷など次の業務へ進む

画面の見た目だけではなく、誰がどの順番で操作するのかを確認することが大切です。

現場では、紙のメモ、Excel、チャット、電話確認などが組み合わさっていることもあります。基本設計では、現在の流れをそのまま置き換えるのではなく、どの作業をシステムに寄せ、どの確認を人が行うのかも整理しておくと進めやすくなります。

機能と業務フローのつながり

基本設計では、作る機能が実際の業務フローと合っているかを確認します。

たとえば、「検索機能がある」だけでは不十分です。何を検索したいのか、どの条件で絞り込みたいのか、検索結果から次にどの操作をするのかまで考える必要があります。

業務システム開発では、機能を作る前に業務フローや必要機能を整理することが重要です。詳しくは業務システム開発で整理しておきたいことでも解説しています。

機能を増やせば便利になるとは限りません。現場の作業に合わない機能が増えると、入力や確認の負担が増えることもあります。業務フローと機能のつながりを見ることが、使いやすい設計につながります。

権限・承認・通知などの運用ルール

基本設計では、権限や承認、通知のルールも確認します。

たとえば、次のような点です。

• 一般担当者はどこまで編集できるか
• 管理者だけが変更できる項目はあるか
• 承認が必要な操作はどれか
• 通知は誰に送るか
• ステータス変更のタイミングはいつか

高機能なシステムよりも、現場が迷わず使える設計になっているかを確認することが大切です。

権限や承認のルールは、あとから変更できる場合もあります。ただ、最初の設計で大きくずれていると、導入後に「誰が何をできるのか分からない」「確認の責任が曖昧になる」といった混乱が起きやすくなります。

詳細設計で整理することと、発注側が見ておきたいポイント

詳細設計は、基本設計で決めた内容を、開発者が実装できる形へさらに具体化する工程です。

発注側にとっては、基本設計よりも専門的に見える部分が増えます。ただし、まったく関係がないわけではありません。

データ項目や処理の流れ

詳細設計では、どのデータをどのように保存し、どの条件で処理するかを整理します。

たとえば、顧客管理システムであれば、顧客名、担当者、連絡先、対応履歴、次回対応日などの項目が必要になるかもしれません。

このとき、発注側は技術的なデータベース構造を理解する必要はありません。ただし、業務で必要な項目が漏れていないかは確認した方がよいです。

必要な項目が抜けていると、運用開始後に別のExcelで補助管理をすることになったり、集計したい情報が取れなかったりすることがあります。技術的な設計をすべて見るのではなく、業務上必要な情報が反映されているかを確認する視点が大切です。

エラー時の動きや例外処理

実際の業務では、例外的なケースが発生します。

たとえば、次のようなケースです。

• 承認者が不在のとき
• 入力内容に不備があるとき
• 同じ顧客情報が重複して登録されたとき
• 締切を過ぎたデータを修正したいとき
• 担当者が退職・異動したとき

こうした例外処理を後回しにすると、運用開始後に現場で対応に迷いやすくなります。

すべての例外を最初から細かく決める必要はありませんが、よく起きるケースや、業務上止まると困るケースは、設計段階で確認しておくと安心です。

発注側は業務上の前提ズレを確認する

発注側が詳細設計のすべてを細かく確認する必要はありません。ですが、業務上の前提がずれていないかは見ておくと安心です。

たとえば、「承認後は修正できない」と設計されていても、実際の業務では修正が必要な場面があるかもしれません。あるいは、管理者だけが編集できる想定でも、現場では担当者が一部修正する必要があるかもしれません。

詳細設計では、こうした業務上の例外や前提を、開発側と確認しておくことが大切です。

システム設計が不十分なまま進めると起きやすい失敗

システム設計が曖昧なまま開発を進めると、開発中だけでなく、運用開始後にも問題が出やすくなります。

ここでは、起きやすい失敗を整理します。

画面はできても現場の流れに合わない

画面が完成していても、現場の業務フローと合っていないと使いづらさが残ります。

たとえば、入力の順番が実際の作業順と違う、確認したい情報が別画面に分かれている、承認までの流れが現場の体制と合っていない、といった状態です。

このようなズレは、画面や機能だけを見ていると気づきにくいことがあります。

実際の業務では、「誰が最初に情報を受け取るか」「どのタイミングで確認するか」「承認後に何が変わるか」といった流れがあります。画面単位ではなく、業務の一連の動きとして確認することが重要です。

データ項目や権限が足りず、手作業が残る

設計段階でデータ項目や権限を十分に整理していないと、システム導入後もExcelや手作業が残ることがあります。

たとえば、必要な項目が登録できない、集計に必要なデータが不足している、担当者ごとの編集権限が曖昧、といったケースです。

Excel管理の課題がある場合は、Excel管理の限界とシステム化すべきタイミングも合わせて確認すると、どの業務をシステム化すべきか整理しやすくなります。

システム化の目的は、すべてを一気に置き換えることとは限りません。Excelで残す業務、ルールを整えればよい業務、先にシステム化した方がよい業務を分けると、設計の優先順位も決めやすくなります。

運用ルールが決まっておらず、導入後に混乱する

システムは、作って終わりではありません。運用開始後に誰が使い、誰が管理し、誰が変更するのかまで決めておく必要があります。

たとえば、マスターデータの更新担当、権限変更の申請方法、退職者のアカウント管理、入力ミスがあったときの修正ルールなどです。

設計不足は、開発中の問題だけでなく、運用開始後の迷いや二重管理として表れやすいです。

運用ルールは、導入後に現場で自然に決まるとは限りません。設計段階で最低限の管理方法を確認しておくことで、導入後の混乱を減らしやすくなります。

中小企業がシステム開発を相談する前に整理しておきたいこと

システム開発を相談する前に、完璧な仕様書を作る必要はありません。

ただし、自社の業務について最低限整理しておくと、開発会社との打ち合わせが進めやすくなります。

現在の業務フローと困っている作業

まず整理したいのは、現在の業務フローです。

たとえば、次のように書き出すだけでも十分です。

• 誰が最初に情報を受け取るか
• どの情報をどこに入力しているか
• 誰が確認しているか
• どこで承認しているか
• どの作業に時間がかかっているか
• どこでミスや確認漏れが起きているか

ここが整理できると、システムで改善すべき範囲が見えやすくなります。

要件が固まっていない段階でも、現場の流れや困っている作業を整理できれば、相談の入口は作れます。最初から専門的な設計書を作るよりも、業務の実態を言葉にすることが大切です。

管理したいデータと使う担当者

次に、どのデータを管理したいのか、誰が使うのかを整理します。

たとえば、顧客情報、案件情報、受注情報、在庫情報、請求情報、対応履歴などです。

同じシステムでも、営業担当者が使うのか、管理者が使うのか、現場担当者が使うのかによって、必要な画面や権限は変わります。

また、今あるExcelや外部ツールをすべてなくす必要があるとは限りません。どのデータをシステムで管理し、どの情報を既存の運用に残すのかを整理すると、無理のない設計に近づきます。

運用開始後の管理方法

システムを使い始めた後の管理方法も、設計段階で考えておきたいポイントです。

• 誰がユーザーを追加するか
• 誰がマスターデータを更新するか
• 権限変更は誰が行うか
• 入力ルールをどう共有するか
• 変更要望が出たときに誰が判断するか

相談前に整理する項目をもう少し広く確認したい場合は、システム導入を相談する前に整理すべきことも参考になります。

システム設計は「作る前」だけでなく「使い続けるため」に考える

システム設計は、開発前の準備だけではありません。運用開始後に使い続けられる形を考える工程でもあります。

システムは、完成した瞬間ではなく、日々の業務で使われて初めて意味があります。

小さく始める場合でも、最低限の設計は必要

小規模なシステム開発であっても、最低限の設計は必要です。

すべてを細かく決める必要はありませんが、画面、機能、データ、権限、運用ルールの基本部分を整理しておくと、開発後の手戻りを減らしやすくなります。

特に、最初は小さく始める場合でも、後から機能を追加する可能性があるなら、データの持ち方や権限の考え方は早めに整理しておくと安心です。

運用を見据えた設計が、手戻りを減らす

運用を考えずに作ると、使い始めてから「この項目も必要だった」「この権限では困る」「この承認フローでは現場に合わない」といった問題が出やすくなります。

要件定義から設計、開発、導入、運用までの全体像を確認したい場合は、要件定義から運用までのシステム開発の流れも参考になります。

システム設計は、作る前の準備だけでなく、運用後に使い続けられる形を考える工程でもあります。

開発前に整理した内容は、完成後の運用にもつながります。誰が使うのか、誰が管理するのか、変更や追加が出たときにどう判断するのかまで考えておくと、長く使いやすいシステムに近づきます。

まとめ

システム設計は、要件定義で整理した内容を、実際に使える画面・機能・データ・権限・運用ルールへ落とし込む工程です。

基本設計では、利用者から見える画面や操作の流れを整理します。詳細設計では、開発者が実装できるように内部処理やデータの扱いを具体化します。

発注側がすべての技術仕様を理解する必要はありません。ですが、業務の流れ、必要なデータ、権限、運用ルールが自社の実態と合っているかは確認しておくことが大切です。

要件が固まりきっていない段階でも、業務の流れや困っている作業を整理すれば、相談の入口は作れます。自社だけで整理しきれない場合は、業務課題の整理から相談できる相手に相談するのも一つの方法です。

よくある質問

システム設計と要件定義の違いは何ですか？

要件定義は「何を実現したいか」を整理する工程です。システム設計は、その内容を画面・機能・データ・権限・運用ルールなどに落とし込む工程です。要件定義で目的を整理し、設計で実際に使える形へ具体化します。

基本設計では何を決めますか？

基本設計では、利用者から見える画面、操作の流れ、機能、権限、承認フローなどを整理します。発注側が、現場の業務と合っているかを確認しやすい工程です。

詳細設計では何を決めますか？

詳細設計では、開発者が実装できるように、内部処理、データの持ち方、処理条件、エラー時の動きなどを具体化します。発注側がすべてを理解する必要はありませんが、業務上の前提にズレがないかは確認しておくと安心です。

発注側はシステム設計で何を確認すべきですか？

画面や機能だけでなく、誰が使うのか、どのデータを管理するのか、権限や承認の流れが業務に合っているかを確認するとよいです。運用開始後に誰が管理するかも、早めに整理しておくと進めやすくなります。

小規模なシステム開発でも設計は必要ですか？

小規模な開発でも、画面・機能・データ・運用ルールの最低限の整理は必要です。すべてを細かく決める必要はありませんが、認識ズレや手戻りを減らすための設計は役立ちます。

システム設計が不十分だと何が起きますか？

画面はできても現場の流れに合わない、必要なデータ項目が足りない、権限や運用ルールが曖昧になる、といった問題が起きやすくなります。結果として、Excel管理や手作業が残ることもあります。

要件が固まっていない段階でも相談できますか？

相談できます。完璧な仕様書がなくても、現在の業務フロー、困っている作業、管理したいデータを整理しておくと、設計の話を進めやすくなります。

設計だけ相談することはできますか？

開発前の整理や設計方針だけを相談したいケースもあります。どこまで決めるべきか分からない場合は、まず業務課題や現状の流れを整理するところから相談すると進めやすいです。