Column お悩み解決コラム

サービスに関するご相談は
こちらのフォームより受け付けております。

システム開発における基本設計とは?進め方から成果物まで解説

システム開発における基本設計とは?進め方から成果物まで解説

公開日:2026年1月15日

 

システム開発の基本設計は、要件定義から詳細設計へと進む重要な工程です。本記事では、初心者から中級者向けに基本設計の役割や進め方、特徴的な設計書の種類や作成のポイントをわかりやすく解説します。

 

目次

1.詳細設計との違いと基本設計の役割

-詳細設計の目的と特徴

-チーム内での設計フェーズの役割分担

2.基本設計の進め方のポイントとコツ

-関係者との認識合わせの重要性

-効率的な設計書の作成方法

3.基本設計とは何か?基礎から理解する

-基本設計の定義と位置づけ

-設計書に含まれる主な成果物

4.基本設計の課題と属人化を防ぐ工夫

-設計の属人化がもたらすリスク

-成果物の標準化と基準作りの工夫

5.実践で役立つ基本設計のポイントまとめ

-関係者の立場を切り替える視点力

-基本設計書を活かした円滑な合意形成

6.まとめ:システム開発における基本設計を成功させるために

7.基幹システム開発・導入支援はエイ・エヌ・エスへ

 

◆詳細設計との違いと基本設計の役割

システム開発における基本設計と詳細設計は、いずれも設計フェーズですが、その目的や対象が異なります。基本設計は、「何をどう実現するのか」の全体像を描き、お客様や開発チーム双方の合意形成を重視するフェーズです。一方、詳細設計はその基本設計を具体的に落とし込み、実装に必要な技術的な手順や要素を詳細に決める工程といえます。これらの工程は互いに密接ですが、その役割の違いを理解することが、プロジェクト成功のカギと言えるでしょう。

 

詳細設計の目的と特徴

詳細設計の目的は、基本設計で決まったシステムの全体構造を元に、個々の機能や処理の実装詳細を明確にすることにあります。基本設計で「この画面はこういう役割」、「この機能はこう働く」と体系化された後、詳細設計では具体的な処理フローやアルゴリズム、データベースのテーブルとカラムの定義、UI要素の配置、API連携などを細かく設計します。言わば「設計の設計」と呼べる工程です。詳細設計では、プログラマがそのままコーディングに入れるだけの技術資料としての意味も大きく、巧妙な記述が求められます。また、エラー処理やパフォーマンスチューニングもこの段階で考慮します。基本設計は”システムがどう動くか”を決めるのに対し、詳細設計は”どのように動かすか”を鮮明に決定するプロセスです。ここで精度を高めることで開発の手戻りを減らし、工数の節約につながる重要な段階でもあります。一方で、詳細設計が行き過ぎて高度化すると、柔軟な変更が難しくなる場合もあり、適切な範囲と粒度で設計を完遂することが重要です。

 

チーム内での設計フェーズの役割分担

システム開発に携わる多くのメンバーが役割を分担しながら作業を進める体制において、設計フェーズごとの役割分担はチームの生産性や品質向上に直結します。基本設計は、大まかな機能分割から始まり、要件定義書から受け取った要求を具体的にシステム企画に反映する役割を担います。比較的顧客とも対話しやすいポジションで、鉛筆書きの設計図を関係者全員で評価・調整し、認識合わせをするようなイメージで実施します。一方、詳細設計は、プログラムレベルやデータ設計、外部連携の技術仕様の策定に責任を持つ職能が主役です。各機能の担当者は工数とリスクを具体的に評価しつつ、開発チームと密にコミュニケーションをとります。また、基本設計で複雑な仕様を抽出しきれなかった部分も、詳細設計で検討することが多くあります。さらに、QAやテスト、運用メンバーもこの設計情報にアクセスして頻繁に確認し、トレーサビリティを保ちます。設計フェーズの連携不足や情報不足は後工程で不具合の原因となってしまうため、プロジェクトマネージャーは役割の明確化と円滑なコミュニケーションを欠かすことなくすすめていく必要があります。

 

 

◆基本設計の進め方のポイントとコツ

 

基本設計は、仕様の具体化と全体的一貫性を確立する重要なフェーズです。ただし、多くの担当者や関係者が参加する中で、業務要件から技術仕様への橋渡し役を果たすため一筋縄ではいきません。ここでは、進める上で押さえたいポイントと効率的な設計書作成方法について解説します。

 

関係者との認識合わせの重要性

基本設計がスムーズに進むかどうかは、関係者同士の認識合わせがどこまで徹底されているかによって、大きく左右されます。システム開発に関与する立場は多様で、発注者や利用者は業務上の課題解決を期待し、開発者側は実現可能で適切な方法を模索します。さらにインフラ担当者やテスターも異なる視点を持ち寄った意見があります。これらの利害や期待が折り合わないと、基本設計のズレや曖昧さが生じるかもしれません。したがって、基本設計を策定する際は設計書のレビューや定期的なミーティングで、用語の理解、設計意図、前提条件、成果物の内容をステークホルダー全員で共有し、ズレを最小限に抑える必要があります。要件定義書とは内容が変わることが多いため、変更箇所はさらに重点的に説明と合意形成を図る必要があります。また、利用者視点にたつユーザビリティやUXを反映することも忘れず、ときには外部のUI/UX専門家を招いてチームに中立的な立場から意見を聞くこともおすすめです。こうした認識合わせの質こそが、質の高い基本設計書につながり、その後の詳細設計や開発の効率性を大きく左右するのです。

 

効率的な設計書の作成方法

設計書はプロジェクトのバイブル・羅針盤ともいえる存在ですが、多くのトラブルは設計書の品質や見やすさ、完成度の差に起因しています。効率よく基本設計書を作成するには、まずプロジェクトにとって何が必須の設計情報かを絞ることです。全てを書き連ねると膨大、かつ、読みづらくなり、結果として現場が設計書を活用できません。必要な設計情報の粒度と範囲を決めたら、分かりやすい表現や図解を多用して伝達力を高めましょう。画面遷移図や業務フロー図は例外なく備え、複雑な処理にはフローチャートやデータフロー図なども活用が効果的です。さらに、関係システムとのインターフェース情報は一覧化し、変更に追従しやすい形で管理するのがポイントです。また、GoogleドキュメントやConfluenceなどクラウドツールの活用で共同編集やコメント共有を行い、チーム全体で内容をブラッシュアップすると属人化もしにくくなります。あまりこだわりすぎず、記述形式に左右されることなく、必要十分かつ移行しやすい整理方法に心掛けると、設計書は自然と強い支援ツールに変わっていくでしょう。

 

 

◆基本設計とは何か?基礎から理解する

基本設計とはシステム開発の上流工程の一つで、要件定義から受け取ったシステム要求を具体的な機能に分割し、それらが何をし、どう繋がるかを決める重要なプロセスです。ここで設計される内容は詳細設計や開発に直接影響を与えるため、プロジェクトの成否を左右します。

 

基本設計の定義と位置づけ

基本設計は、システム開発の要件定義と詳細設計の間に位置し、システム開発における”設計”の中心的段階です。要件定義では「何が求められているか」、つまりシステムの目的や要望を抽出しますが、基本設計はその内容を技術的に解釈し、「どの機能を使ってどう実現するか」というアウトラインを決定します。たとえば、要件定義で「顧客情報を管理できる」とあるとすると、基本設計は「顧客データの登録画面、一覧表示画面、更新・削除機能が必要」と具体化します。さらに画面遷移やデータベース設計の初稿を作ります。位置づけとしては、基本設計書は要件定義書に続く段階であり、以降の詳細設計、プログラミングへスムーズに引き渡す橋渡し役です。さらに多くの関係者に見せる代表的成果物であり、システム開発の設計方針や全体感を示す役割を果たします。全体像を作る「骨組みづくり」と例えられ、ここで誤りやズレがあると、詳細設計後の工程で齟齬やコスト増が発生しやすくなります。

 

設計書に含まれる主な成果物

基本設計で作成される設計書の成果物は、そのプロジェクトの規模と要件により多少異なりますが、一般的に以下の要素が含まれます。

まず、システム全体の大まかな機能を示す「機能一覧」。次にシステムの画面設計にあたる「画面一覧表」「画面遷移図」で、これによってユーザーの操作イメージや画面間の繋がりが理解しやすくなります。加えて、「業務フロー図」や「データフロー図」などの図表も充実させ、業務の流れと情報の動きを俯瞰できる工夫がなされます。帳票出力がある場合は「帳票一覧」および「帳票設計書」が用意され、どのようなデータをどのタイミング・形式で出力するのかを規定します。バッチ処理が関与する場合は「バッチ処理一覧」図や、データベース設計のための「テーブル定義書」「ER図」、「コード一覧」「CRUD図」も忘れてはなりません。さらに、外部システムとの連携に関しては「外部インターフェース仕様書」などが作成されることが多いです。これらの成果物は、後続の詳細設計・プログラミングに活かすため重要であり、更新時には最新状態の共有を徹底します。






 

 

 

 

基本設計フェーズで作成される成果物一覧

カテゴリ 成果物名 内容・目的
機能設計 機能一覧 システム全体の機能構造を整理し、俯瞰的に把握するための一覧。
画面設計 画面一覧表 全画面のリスト。画面IDや画面名を整理して管理。
画面設計 画面遷移図 画面間の遷移・操作の流れを視覚的に表現。
業務フロー 業務フロー図 業務手順の流れを図式化し、システム化範囲を明確化。
データフロー データフロー図(DFD) データがどこからどこへ流れるかを整理し、処理の流れを可視化。
帳票設計 帳票一覧 システムで出力される帳票の種類を一覧で整理。
帳票設計 帳票設計書 帳票のレイアウト、出力データ、タイミングを規定。
バッチ設計 バッチ処理一覧 バッチ実行タイミング、内容、依存関係を整理。
DB設計 テーブル定義書 テーブル名、項目、型、制約など、DB設計の基本情報。
DB設計 ER図 データ構造とリレーションを視覚化する図。
機能詳細 コード一覧 ステータスコード・区分コードなどの定義リスト。
機能詳細 CRUD図 各機能が DB のどのテーブルに対して Create/Read/Update/Delete を行うか整理。
外部連携 外部インターフェース仕様書 外部システムとの連携方式、データ形式、送受信方式を整理。

 

 

◆基本設計の課題と属人化を防ぐ工夫

基本設計の工程は、仕様と設計の橋渡し役でありながら、多くの関係者や多様な視点を通すため、課題も少なくありません。特に、設計内容の属人化は多くのプロジェクトで見られ、体系的・効率的な進行の妨げとなることも。以下ではそのリスクと対策を紹介します。

 

設計の属人化がもたらすリスク

属人化とは、設計書の内容や設計ノウハウが特定の設計者の頭の中に閉じた状態を指し、第三者が理解・引き継ぎしにくい状況を生み出します。基本設計書の記述が不統一であったり、用語や設計手法にばらつきがある場合、他のチームメンバーがその設計意図を読み解くのに手間取ります。いざ担当者が不在になれば、対応の遅れ、誤解による仕様変更、バグ誘発の原因となりリスクが増大します。属人化は特に中長期プロジェクトや複数人で携わる大規模開発において、作業効率を落とし、不安定な品質にしかねません。作成者の主観的なコード名称や設計ルール、細かいノウハウが共有されないことで、お客様や開発チーム全体の信頼を損ねる可能性もあります。結果的に後続工程で抜け漏れや混乱を招き、開発コスト増や納期遅延を引き起こす大きな要因になるのです。

 

成果物の標準化と基準作りの工夫

属人化の防止策として、基本設計書の標準化と一貫した記述基準の確立が不可欠です。まず、プロジェクト内で用いる用語集を作成し、用語の統一化を図ります。次にドキュメントのフォーマット自体を統一する手法も有用ですが、一律にテンプレートにこだわらず、プロジェクトの特性に合わせた柔軟なカスタマイズを行うことがポイントです。また、設計内容に関してはレビュー体制を導入し、複数の設計者が互いのアウトプットをチェックすることで内容の整合性と透明性を保ちます。さらに、小規模なドキュメントや図表を活用し、情報を細分化することで情報の可読性を高める工夫も効果的です。近年では、設計支援ツールやCADツールを用いた設計書作成を推奨しており、これによりフォーマットの自動整形や修正履歴管理、参照性の向上などが実現しやすくなっています。チーム内での知識共有基盤としてのWikiやチャットツール連携も欠かせません。これらの施策が連鎖し、属人化を減らし、品質の高い基本設計の確立に寄与します。

 

 

◆実践で役立つ基本設計のポイントまとめ

基本設計は、単なる作業フェーズにとどまらず、システム開発の成功を左右する判断や合意の場でもあります。ここで押さえておきたいポイントは、関係者それぞれの立場に立って設計を理解する視点力と、その基本設計書を活かしてチーム全体の合意を作り上げるプロセスの深堀りです。

 

関係者の立場を切り替える視点力

基本設計に携わる技術者は、「発注者」「開発者」「利用者」といった多様な関係者の視点を意識して設計に取り組む必要があります。発注者視点では、仕様が求める業務の現実的な課題を解決できるかに焦点が当たり、ビジネス要件の再確認が求められます。開発者視点は、提示された設計が実装可能でメンテナンス性や性能面で無理がないかを見ます。利用者がおもに関わるUI/UXの視点も見逃せません。これら複数の視点を切り替えながら作業を進めるには、抽象化と具体化のバランスが鍵となります。たとえば、技術用語ではなく実務的な言葉で仕様のなぜを問い直すこと、また逆に利用者の要求から技術的実現性の検証、あるいは将来的な拡張性やコスト面の兼ね合いにまで視野を広げることが求められます。これにより、利害関係の齟齬を極力削り、最終的に誰にも納得のゆく基本設計を練り上げられます。コミュニケーション力と俯瞰的な思考が両輪となるところが、エンジニアリングの面白さでもあるでしょう。

 

基本設計書を活かした円滑な合意形成

基本設計書は、関係者間の意志疎通と合意のための重要なツールとして機能します。そのため、作成後は単なるガイドラインではなく継続的に見直し、議論に活用しながら進めることが効果的です。合意形成は設計の評価ミーティングやレビュー会議と結び付いて進行し、設計内容の誤解や認識の食い違いを早期に発見します。この時、レビューでは設計文書の論理的一貫性はもちろん、要件定義とのズレ、利用者視点での使いやすさ、実現性や開発期間・工数の過不足に目を配るべきです。また、修正すべき点、問題点の洗い出しの際は具体的かつ建設的な指摘を行い、全体で修正案をすること、さらに関係者全ての了承が得られたらサインオフや議事録の作成など記録形式も忘れずに行います。こうしたプロセスを通じて、基本設計書は単なる文書から強固な契約書のごとく、プロジェクトの羅針盤として役割を果たします。これによって、後続工程が円滑かつ計画的に遂行されるのです。

 

 

まとめ:システム開発における基本設計を成功させるために

システム開発における基本設計は、“何を作るか”という全体イメージと大まかな実現の方向性を定める要といえます。ここで定められる成果物は、詳細設計や開発を進める上での基礎資料となり、後工程の手戻りを低減し、品質の高いシステムを実現する支えになります。成功させるポイントは、詳細設計との違いを明確に理解し、関係者間で徹底した認識合わせを行うことです。また、設計の属人化を防ぐための基準策定やドキュメントの標準化にも注力すべきです。さらに、多視点で物事を捉え、システム構築全体を俯瞰できる視点力を涵養することが重要です。こうした意識をもって基本設計の設計書を丁寧に作成し、関係者全員の合意を固めていきましょう。システム開発の骨組みを揺るぎないものとし、プロジェクトを円滑に推進していくためには、まずこのフェーズの成功が不可欠です。基本設計の段階からしっかり備えて、理想のシステムを共に作り上げていきませんか。

 

◆基幹システム開発・導入支援はエイ・エヌ・エスへ

株式会社エイ・エヌ・エスは、オーダーメイドの基幹システム開発を主軸に、創業35年以上にわたり多様な業界・業種のシステム開発に携わってきました。
スクラッチ開発による柔軟なカスタマイズ対応に加え、既存システムの再構築や運用支援、保守引継ぎサービスなど、上流から下流まで一貫した体制で企業のIT基盤を支えています。

 

 

 

 

 

  • 株式会社エイ・エヌ・エス 常務取締役

    システムインテグレーション事業部 第1グループ長 プロジェクトマネージャー

    H.W

    1989年、株式会社エイ・エヌ・エスに入社。
    入社後、SEとしての技術力と営業力を磨き、多くのプロジェクトに参画。
    要件定義から設計・開発、運用まで、上流から下流工程を幅広く経験する。
    現在はプロジェクトマネージャーとして、大規模プロジェクトを数多く成功に導く。
    「システムの導入効果を最大限感じてもらうこと」をモットーに、
    顧客特性に応じた最適なシステム提案を心がけている。









 

 

 

 

 

お客様の業界・課題に合った事例や支援内容も個別にご提案可能です。
まずはお気軽にご連絡ください。

「システム開発における基本設計とは?進め方から成果物まで解説」に関連する記事

DXの推進を実現させるオーダーメイドの業務システム開発

DXの推進に求められている現代において
必要不可欠な”システム”業務に合った
最適なオーダーメイドのシステムを導入することで、
DX推進を支援します。