システム設計とは？流れと基本設計・詳細設計、発注者の確認点

システム設計とは？

システム設計は、要件定義で決めた内容をもとに、画面・機能・データ・外部連携・処理の流れなどを具体化する工程です。発注者にとっては、開発会社が作ろうとしているシステムが、自社の業務に合っているかを確認する場でもあります。

システム設計の意味

システム設計とは、システムを実際に開発できる状態にするため、必要な情報を設計書としてまとめる作業です。たとえば、以下のような内容を決めます。

 

• どの画面が必要か

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

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

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

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

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

 

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

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

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

 

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

 

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

要件定義との違い

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

 

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

 

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

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

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

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

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

 

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

システム設計が必要な理由

システム設計が必要なのは、開発前に認識違いや抜け漏れを見つけるためです。設計段階で画面や機能を確認しておけば、実装後に「この入力項目が足りない」「この業務では別の承認者が必要だった」といった問題に後から気づく可能性を減らせます。

 

特に発注者は、以下の内容を設計段階で確認しておくと、完成後の修正や追加対応を減らしやすくなります。

 

• 実際の業務の流れと画面の順番が合っているか

• 必要な機能が抜けていないか

• 利用者ごとの権限が業務に合っているか

• 通知や承認の条件が決まっているか

• 外部システムとの連携内容が明確か

 

システム設計は、開発会社だけが行う作業ではなく、発注者も業務とのズレを確認するために関わる重要な工程なのです。

システム設計の流れ

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

 

ここでは、初めてシステム開発に関わる方が全体像をつかみやすいように、代表的な流れで見ていきましょう。

 

 

発注者が特に確認したいのは、画面、機能、データ項目、権限、外部連携など、業務に直接関わる内容が多く含まれる基本設計です。詳細設計は開発会社中心になりますが、業務に影響する変更が出る場合は共有してもらう必要があります。

要件定義

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

 

この段階で発注者が確認したいのは、自分たちが困っていることや優先したい業務が、開発会社にそのまま伝わっているかどうかです。たとえば「紙の申請を減らしたい」「承認に時間がかかっている」といった現場の課題が、具体的な要望として整理されているかを見ます。

 

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

方式設計

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

 

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

 

発注者がサーバーの種類やネットワーク構成を細かく判断する必要はありません。ただし、「営業担当が外出先からスマホで使いたい」「夜間バッチ処理がある」「社内の既存システムと連携したい」といった利用条件や制約は、開発会社に具体的に伝えておくことが重要です。

基本設計

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

 

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

 

発注者が重点的に確認したいのは、この基本設計です。たとえば「営業担当が顧客を登録して、上長が承認する」という流れであれば、その順番どおりに画面が用意されているか、入力する項目や承認の操作が足りているかを確認します。

 

実際の業務の流れと画面の順番が合っているか、必要な項目や機能が抜けていないかを具体的な利用シーンを思い浮かべながら見ていきましょう。利用部門の担当者にも見てもらうと、普段の業務とのズレに気づきやすくなります。

詳細設計

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

 

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

 

詳細設計は開発会社が中心となって確認する資料です。発注者はすべてを理解しようとするより、基本設計で決めた画面や機能に変更が出る場合は、事前に説明してもらえるようにしておきましょう。

実装・テスト

設計が固まると、開発会社は設計書をもとに実装へ進みます。実装後は、設計どおりに動くかをテストし、発注者は完成したシステムが業務で使えるかを確認します。

 

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

 

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

基本設計と詳細設計で発注者が確認するポイント

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

 

基本設計は、画面や機能、業務の流れ、データ項目、権限、外部連携など、実際の利用イメージに直結する内容を整理したものです。発注者や利用部門の担当者も、日々の業務を思い浮かべながら内容を確認しやすい資料になります。

 

一方で詳細設計は、開発会社がプログラムを作るための内部処理やデータベース構成など、技術的な内容が中心になります。発注者は基本設計で合意した内容に変更が生じた場合に、開発会社から説明を受けられるようにしておきましょう。

基本設計で確認したいこと

基本設計を見るときは、実際の業務で使う場面を思い浮かべながら確認します。たとえば、日々の業務でシステムを使う担当者が「朝ログインしてから、どの順番で操作するか」「どのタイミングで入力や確認をするか」を頭の中でなぞりながら見ていきます。

 

特に確認したいのは、以下の内容です。

 

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

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

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

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

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

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

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

 

発注者は、画面や機能を見ながら「自社の業務でそのまま使えるか」「現場の担当者が迷わず操作できるか」を確認します。普段の業務手順と違う部分や、現場で困りそうな点があれば、設計段階で開発会社に伝えます。

詳細設計で確認したいこと

詳細設計は、開発会社が中心となって確認する資料です。発注者が内部処理やデータベースの細かい内容まで理解する必要はありません。ただし、次のような内容は発注者にも関係します。

 

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

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

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

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

 

詳細設計の内容そのものを細かく読むより、「現場の担当者が実際に使うときに困らないか」という視点で、基本設計で合意した内容と変わる点があるかを確認します。

すべてを理解するより、業務に関わる変更を確認する

発注者が重点的に見るべきなのは、基本設計に含まれる画面、機能、業務の流れ、データ項目、権限、外部連携などです。たとえば、日々の業務で使う画面の項目が増減していないか、入力の手順が変わっていないか、承認フローが追加されていないかといった点は、実際の運用に直結します。

 

詳細設計は、開発会社が実装のために使う資料です。発注者はすべての技術的な内容を理解しようとするより、自社の業務に影響する変更が出たときに説明を受けられる状態にしておきましょう。

 

「画面や機能が変わるのか」「業務手順に影響するのか」「利用者の操作が変わるのか」を確認できれば、詳細設計の段階でも発注者として必要な判断をしやすくなります。

システム設計で作られる主な設計書

システム設計では、決めた内容を設計書として残します。設計書は、開発会社が実装するための資料であると同時に、発注者が合意内容を確認するための資料でもあります。ここでは、発注者が目を通す機会の多い設計書を中心に紹介します。

基本設計書

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

 

たとえば、あなたが「受注から請求までをシステムで管理したい」と考えている場合、どの画面で受注を登録し、誰が承認し、どのタイミングで請求データが作られるのか、といった流れがここに整理されます。

 

基本設計書には画面、機能、データ、外部連携、権限など、発注者が確認したい内容が多く含まれます。基本設計書を見るときは、以下を確認します。

 

• 要件定義で決めた内容が反映されているか
  （「この機能を入れたい」と話した内容が、ちゃんと画面や機能として書かれているか）

• 業務の流れに合っているか
  （実際の仕事の順番どおりに操作できるか、無理な手順になっていないか）

• 利用者ごとの操作範囲が分かれているか
  （営業、経理、管理者など、それぞれが触れる範囲が適切に分かれているか）

• 必要なデータ項目が抜けていないか
  （顧客名、金額、日付など、普段使っている情報がきちんと入力できるか）

• 外部システムとの連携内容が明確か
  （会計ソフトや既存システムと、どのデータをどうやり取りするのかが分かるか）

 

基本設計書は、「このシステムはこう動く」という完成イメージを、発注者と開発会社で共有するための資料になります。

画面設計書

画面設計書は、画面ごとのレイアウトや入力項目、ボタン、表示内容をまとめた資料です。

 

発注者は、たとえば「朝一番に受注データを登録する」「午後に一覧から対象データを探して更新する」といった、実際の業務の流れを思い浮かべながら確認します。特に、以下の点を見ます。

 

• 入力する項目が足りているか（紙の帳票や既存システムと見比べながら確認する）

• 表示される情報が業務判断に使えるか（この画面だけで判断できるかを考える）

• ボタン名や画面名が利用者に伝わるか（現場で使っている言葉になっているか）

• 入力ミスが起きやすい箇所がないか（桁数や必須項目の抜け漏れを想像する）

• 一覧画面で検索・絞り込みが必要か（毎回スクロールして探すことにならないか）

 

画面設計書は、完成後の使いやすさに影響しやすい資料です。実際にその業務を担当している人に「この順番で操作できるか」「迷わず使えそうか」を見てもらうと、業務とのズレに気づきやすくなります。

機能設計書

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

 

発注者は、機能名だけで判断せず、誰が・どの画面で・どのタイミングで操作し・その結果どうなるのかを具体的に追いながら確認します。

 

承認や通知のように業務ルールが関わる機能は、担当者やタイミングの認識違いが起こりやすいため、実際の業務の流れを思い浮かべながらチェックすることが重要です。

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

データ項目に関する設計書では、システムで扱う情報の種類や形式を確認します。

 

たとえば、営業担当者が日々入力する顧客名や担当者名、見積金額、受注日、進捗ステータス、商談メモなど、実際の業務で使う項目が過不足なく含まれているかを見ます。

 

外部連携に関する設計書では、たとえば営業管理システムから会計システムへ売上データを渡す場合など、どの情報を、どのタイミングで連携するのか、また連携に失敗したときに誰がどう気づき、どう対応するのかを確認します。

 

発注者は、APIや通信方式といった技術的な詳細よりも、「営業が入力した情報がそのまま請求処理に使えるか」「二重入力が発生しないか」といった、日々の業務がスムーズに回るかどうかの視点で確認します。

システム設計で失敗を防ぐために確認したいこと

システム設計では、開発会社に任せる部分と、発注者が確認すべき部分を分けて考えます。

 

たとえば、営業担当が外出先から顧客情報を確認したい、経理担当が月末にまとめて処理している作業を減らしたい、といった日々の業務を思い浮かべながら、「この設計で本当に使いやすいか」「今のやり方とズレていないか」を確認することが重要です。

業務の流れと画面が合っているか

画面の順番や操作の流れが、実際の業務と合っているかを確認します。

 

たとえば、経費申請を行う場合、申請画面で入力したあと、上長が承認画面で内容を確認し、問題があれば差し戻し、問題なければ承認して完了する、といった一連の流れを具体的にイメージしましょう。そのとき、それぞれの担当者が迷わず操作できる画面になっているかを見ます。

 

紙やExcelで行っている業務をシステム化する場合、現在の業務手順をそのまま画面に置き換えるだけでは使いにくくなることがあります。実際に操作する人の立場で、「この順番で入力しやすいか」「このタイミングで確認できるか」を考えながら、残すべき手順と見直せる手順を分けて確認しましょう。

必要な機能が抜けていないか

設計書では、機能名だけでなく、実際に自分がその画面を使う場面を思い浮かべながら確認します。

 

たとえば「検索機能」がある場合でも、普段の業務でどんな条件で探しているかを思い出すと、「日付で絞りたい」「担当者で探したい」など、必要な条件が見えてきます。条件が足りなければ、実際の業務では使いにくくなります。

 

以下のように、日々の業務の流れを頭の中でなぞりながら確認します。

 

• 新しいデータを登録する場面はあるか

• 登録した内容をあとから修正することはあるか

• 間違えたデータを削除する必要はあるか

• どんな条件で検索することが多いか

• 上司や別部署に承認してもらう流れはあるか

• 差し戻しが発生するケースはあるか

• 誰にどのタイミングで通知が届くべきか

• Excelで加工するためにCSV出力することはあるか

 

機能の有無だけでなく、「自分（または担当者）が、どの画面で、どんな状況のときにその操作をするのか」を具体的に思い浮かべると、抜けている機能に気づきやすくなります。

権限・通知・データ・外部連携に抜けがないか

権限、通知、データ、外部連携は、設計段階で抜けやすい項目です。

 

権限では、管理者、一般利用者、承認者など、利用者ごとに見られる情報や操作できる内容を確認します。

通知では、誰に、どのタイミングで、何を知らせるかを確認します。通知が多すぎると見落とされやすく、少なすぎると必要な作業に気づけません。

 

データ項目では、業務判断や集計に必要な情報が入っているかを見ます。外部連携では、ほかのシステムと受け渡しする情報や、連携に失敗したときの扱いを確認しましょう。

仕様変更の扱いが決まっているか

たとえば、画面デザインがほぼ固まったあとに「やっぱりこのボタンの位置を変えたい」「この機能も追加したい」といった要望が出ることは珍しくありません。

 

こうした変更が出たときに、どこからが仕様変更として扱われるのかが曖昧だと、「これは追加費用がかかるのか」「納期は延びるのか」といった点で認識のズレが生まれやすくなります。設計段階では、以下を確認しましょう。

 

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

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

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

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

 

口頭だけで「じゃあそれでお願いします」と進めてしまうと、後から「そこまでの変更だとは思っていなかった」「費用が増えるとは聞いていない」といったトラブルにつながりがちです。

 

変更内容は課題管理表や議事録などに残し、あとから誰が見ても経緯が追える状態にしておきましょう。

テストや受け入れ確認の範囲が決まっているか

テストや受け入れ確認では、「自社で実際に使える状態かどうか」をどこまで確認すれば完了とするかを決めておきます。発注者は、開発会社が行う動作テストとは別に、現場の担当者が日々の業務で問題なく使えるかを確認しましょう。

 

たとえば、営業担当や事務担当が実際に操作する場面をイメージすると、以下のような観点になります。

 

• いつも行っている業務の流れを、最初から最後まで迷わず操作できるか

• 入力した顧客情報や申請内容が、正しく保存・反映されるか

• 担当者や役職ごとに、見える画面や操作できる内容が適切に分かれているか

• 承認や対応が必要な人に、通知がきちんと届くか

• 会計ソフトや既存システムと、必要な情報が正しく連携されるか

 

受け入れ確認の範囲が曖昧だと、「どこまで確認すれば完了なのか」が判断しにくくなり、現場で使い始めてから問題が見つかる原因になります。設計段階から、誰がどの業務をどの画面で確認するのかまで具体的に決めておきましょう。

まとめ：システム設計は業務に合うかを確認しながら進めよう

システム設計の内容を確認する際は、「仕様として正しいか」だけでなく、「実際の業務でそのまま使えるか」という視点で見ていくことが大切です。

 

画面の流れや操作手順を追いながら、自分の業務をそのまま当てはめてみてください。「このボタンを押してよいのか」「次にどの画面へ進めばよいのか」と迷う場面があれば、設計段階で見直す候補になります。

 

入力項目、権限、データの受け渡し、通知、外部連携は、日々の運用とズレが出やすい部分です。細かい違和感でも、課題管理表や議事録に残して開発会社と確認しておくと、完成後の認識違いを減らしやすくなります。

 

細かい違和感でも、そのままにせず都度共有していくことで、完成後の使いにくさを防ぐことができます。気づいたことを積み重ねていくことが、結果的に使いやすいシステムにつながります。