システム開発の基本設計とは？その位置付け・重要性・発注者としての関わり方を解説【2024年最新版】

システムを開発するためには、さまざまな作業工程があります。そのなかでも「基本設計」は、発注者が関わるべき大切な工程。「設計する作業なのだから、開発会社に任せておけばいいのでは？」システム開発の経験のない人なら考えがちですが、そうではありません。

基本設計は、システム開発の方向性がブレないように、発注側と開発側が認識を擦り合わせていく重要なフェーズ。発注者として積極的に関わっていくべき作業工程が、基本設計なのです。

本記事では、システム開発における基本設計の位置付け・重要性とともに、発注者としてどのように基本設計に関わるべきなのかを解説します。

開発会社とともに納得のいくシステムを開発するヒントにしてください。

※システム幹事では専任のコンサルタントがあなたのご要望をヒアリングし、ご予算にあった最適な会社をご紹介します。相談料などは一切かかりません。

【無料】おすすめのシステム開発会社を紹介してもらう

システム開発の基本設計とは？

システム開発の基本設計（Basic Design）とは、要件定義でまとめた自社ニーズを実現させるため、システムに実装する機能を明確化・具体化していく作業工程のこと。

開発するシステムの機能・構成などの基本的な仕様を大枠で策定する作業工程で、開発会社が発注者にもわかりやすくシステムのアウトラインを決めていきます。

外（利用者）から見たときにどのような動作になるのかを決めるので「外部設計」「概要設計」と呼ばれる場合もあります。

システム開発における基本設計の位置付け

システム開発の流れには、下の図のようなものがあります。

一般的な開発工程の流れのなかで、基本設計は「要件定義」のあと、「詳細設計」の前に位置付けられています。要件定義から導入までの各工程には、下記のような役割があります。

1.「要件定義」…「何を求めているか？」開発するシステムの目的をハッキリさせる
2.「基本設計」…「どのようにつくるか？」概要をまとめる
3.「詳細設計」…「どうやって実現するか？」開発者側の具体的な設計
4.「開発」…実際に作成、プログラムの実装
5.「導入」…テスト、レビューを重ね運用開始

基本設計は、要件定義の内容をチェックし、具現化していくための大切な工程の一つです。

システム開発の流れについて詳しく知りたい方は、以下の記事も参考にしてください。

システム開発の手法4つの特徴・メリット・デメリットを解説！【比較表付き】

基本設計のインプット・アウトプットとは？

要件定義の後工程となる基本設計では、要件定義書をインプットして、システムをどのように作ればいいのかを決定していきます。要件定義書は、システム開発の目的・ゴールを示したもの。

基本設計では、要件定義書をインプットし、システムの骨組みを決定します。要件定義書を受けて基本設計で行う作業内容は以下の通り。

・機能の洗い出し
・扱うデータを整理
・画面のレイアウトを決める
・必要となるデータを明確化

基本設計の成果物は、基本設計書としてアウトプットされます。アウトプットされた基本設計書は、詳細設計の工程に使用され、エンジニア向けの具体的な設計書に落とし込まれます。

関連記事：システム開発の要件定義とは？受託開発における重要性や進め方を解説！

※システム開発全体の流れや進め方についておさらいしたい方は、こちらもあわせてご活用ください。

システム開発依頼前にチェック！ 中小企業向けシステム開発の進め方をまとめました。
無料でダウンロードする

【無料】システム開発の依頼について相談する

システム開発の基本設計はなぜ重要？

システムの基礎・大枠・全体像（Basic、Outline）を決定する基本設計は、システム開発工程のなかでも要件定義と並ぶ重要な作業。では、基本設計のどんな部分が重要なのかみていきましょう。

発注者・開発者の意見のすり合わせをするため

基本設計書としてアウトプットされるドキュメントでは、発注者側から見てもわかるものになっています。発注者や、開発会社の連携先企業などが、システム開発の概要を理解し工程や仕上がりをイメージできるので、意見の擦り合わせが可能です。

一方で、システム構成図・データベース設計・開発アーキテクチャ（設計思想）など、開発者側から見た設計書も作成する必要があります。

基本設計工程は、発注者にシステムの完成イメージを提示する役割と、開発者にシステムを構築する方法を提示する役割を担う重要なフェーズなのです。

発注者が携われる最後のチャンス!?

基本設計工程は、発注者がシステム開発工程に携われる、最後のチャンスともいえる重要なフェーズ。この後のプログラマー向けの設計書を作成する詳細設計工程からは、作業の中心が委託先のシステム開発会社になるからです。

社内SEの在籍する企業であれば、詳細設計以降の工程に発注者側から関わることも可能ですが、中小規模の企業は人的リソースが不足している場合がほとんど。受け入れテストとも呼ばれる総合テストフェーズまでは、作業を開発会社に一任することが一般的です。

基本設計工程が重要なのはこのため。システムが完成してから「こんなはずではなかった」といった事態にならないよう、基本設計フェーズでシステムの完成イメージを共有し、発注側・受託側の細かな認識のズレをなくしておかなければならないのです。

関連記事：システム開発の詳細設計とは？プロジェクトの位置付け・役割をわかりやすく解説！

基本設計の段階に発注者はどう関わるべきか？

基本設計の段階で発注者が意識すべきことは、開発会社との認識のずれを無くすこと。基本設計書を確認して、自社の要望とずれている部分、不明な部分などがあれば必ず開発会社とすり合わせて認識を合わせておきましょう。

基本設計の内容をしっかり詰めておけば、開発工程の手戻りを最小限にとどめられます。結果的に追加費用の発生や納期遅延を避けられるため、開発会社に丸投げせず積極的に関わりましょう。

※現在、システム開発会社選びにお悩みの方はお気軽にお問い合わせください。

【無料】おすすめのシステム開発会社を紹介してもらう

基本設計で作成される設計ドキュメント

基本設計の工程をスムーズに進めるためには、チェック段階で戸惑ったりしないよう、基本設計書がどのようなものなのか、把握しておくことが肝心。以下は、基本設計フェーズで作成されるドキュメントです。

※CRUD図…業務名と設計する機能の対応を表した図

主に発注者向けに策定されるのが業務フロー、画面設計や帳票設計、非機能要件などです。要件定義で作成されるドキュメントと重複するものもありますが、改めて確認を行い、新たに作成される場合も。

一般的な基本設計では、機能要件の作り込み・追加ドキュメントの作成が主体となります。それぞれを簡単に解説していきましょう。

システム設計

用途に応じてオンプレミス型（自社の施設内に機器を設置して運用すること）、クラウド型が使い分けられるケースもありますが、システム開発では「クライアントサーバシステム（クライアントPCをサーバに接続して活用）」が採用されるケースが一般的。これを設計書としてまとめたものが「システム設計」です。

具体的には、要件定義で策定した機能要件・非機能要件を基に、どのようなソフトウェア・ハードウェア・ネットワークでシステムを構成するべきなのか、システム構成を設計します。

画像引用：富士通

システム構成図の見本は上の画像の通りですが、これだけ見ても複雑。要は、システム構成図は、これから開発するシステムとつなげる既存のシステムや外部のシステムとのデータの流れを説明するものです。

画面設計

要件定義である程度イメージされていた画面レイアウト・画面一覧・画面遷移図などを、明確化してまとめたものが「画面設計」です。

画像引用：情報処理推進機構（IPA）機能要件の合意形成ガイド

画面レイアウトは上記のように、画面のサンプルのこと。

画面遷移図は、上記の画像のように、どの画面からどの画面へ遷移できるのかを表した図。
おおまかなイメージだった画面レイアウトを最終形に詰めていく、正常時のパターンのみだった画面遷移図にエラーパターンを追加するなど。入力桁数や計算式などの出力形式を決めた入出力項目、マウスオーバー時の挙動などを明記したアクション定義などは新たに作成します。

画面アクション定義の例

帳票設計

要件定義で策定してある帳票レイアウト・帳票一覧をより具体的にし、帳票出力項目一覧、帳票編集定義などを作成し、設計書としてまとめたものが「帳票設計」です。

おおまかなイメージだった帳票レイアウトを、新たに作成する帳票出力項目一覧と付き合わせながら作り込んでいくなど、曖昧だった要素を確実に決め込んでいく作業になります。

帳票レイアウトの例

業務で使用する伝票や報告書などが「ひな形」として作成され、発注者側は、実際に使用するときのイメージをもって確認することができます。

帳票出力項目一覧の例

バッチ設計

要件定義で策定してあるバッチ（一括処理）一覧をもとに、バッチ処理フロー、バッチ処理定義を作成し、設計書としてまとめたものが「バッチ設計」です。

バッチ処理とは、あらかじめ登録した一連の処理を自動的に実行すること。大量のデータを処理するには膨大な時間がかかるため、勤務時間外に自動的にバッチ処理を開始・終了させることが多いです。

バッチ処理の入力・処理・出力の流れをまとめたものがバッチ処理フロー、それぞれのバッチ処理フローの入力・処理・出力を整理・定義したものがバッチ処理定義です。

バッチ処理フローの例

バッチ処理定義の例

テーブル・ファイル要件

テーブル・ファイル要件では、テーブル設計図・エンティティ（データーベースで処理する情報単位であるモノ・コト）一覧・定義をもとに、テーブル・ファイル一覧・定義、CRUD図などを作成し、設計書としてまとめます。

テーブル設計図の例

CRUD図の例

外部インターフェース設計

要件定義で策定してある外部システム関連図を基に、外部インターフェース一覧表、外部インターフェースレイアウトを作り込み、設計書としてまとめたものが「外部インターフェース設計」です。

ただひとつのシステムのみでビジネス全体をカバーすることはほとんどないため、生産性を高めるうえでも重要な項目。データ連携の手順・チェックを取り決めた、外部インターフェース処理概要ドキュメントが作成される場合もあります。

外部システム関連図の例

外部インターフェース処理概要の例

【無料】システム開発の依頼について相談する

システム開発の基本設計まとめ

本記事では、システム開発における基本設計の位置付け・重要性とともに、クライアントとしてどのように基本設計に関わっていくべきなのかを解説してきました。基本設計のアウトプットとして作成されるドキュメントが、要件定義書と密接に関わっていることに驚いた方も多いのではないでしょうか？

実際、基本設計フェーズは要件定義とセットで考えるべき重要なシステム開発工程であり、設計だから開発会社に一任していいというものではありません。システム開発プロジェクトを成功に導くためにも、基本設計の重要性を把握して、積極的に関与していくことがおすすめです。

システム開発の工程では、希望が反映されて具体化される「基本設計」が特に重要です。基本設計は、発注側の希望を開発側に細かに伝え、軌道修正ができる最後のチャンス。開発会社任せにせず積極的に開発に関わり、プロジェクトを成功に導きましょう。

スムーズに開発を進めるためには、システム開発会社選びも重要なポイント。コミュニケーションを円滑にとることができ、信頼できる開発会社に依頼することが大切です。

コンサルタントのご紹介 岩田 専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます！
初心者の方でも安心してご相談いただけます。

必ず開発会社に発注する必要はありません。システム開発の相場の情報から最適な会社選びまで無料でサポートします。お気軽にご相談ください。

【無料】おすすめのシステム開発会社を紹介してもらう