基本設計はどこまでする？概要や基本設計書の内容などを紹介

システム開発にはさまざまな工程が含まれています。

その中の一つが基本設計であり、開発において重要な作業です。

エンジニアとして上流工程に携わりたいと考えているならば、基本設計を深く理解していることが求められます。

しかし、これまで実装にしか携わったことがないエンジニアは、基本設計がどういうものなのかよく理解していないケースが多いでしょう。

そこで、今回は基本設計とは何なのか、基本から失敗しないためのポイントまで解説します。

どこまでが基本設計？

・基本設計は要件定義の次のフェーズ ・目的は具体的な機能を決めること ・基本設計では基本設計書を作成する ・次のフェーズの詳細設計につなげる

基本設計にはどのような工程までが含まれているのか解説していきます。

基本設計は要件定義の次のフェーズ

要件定義の次に行うのが基本設計です。

要件定義ではクライアントにヒアリングをして要望を聞き出します。

どのような機能を実装したいのか、どのくらいの性能が必要なのかなど正確にヒアリングをした上で整理します。

そして、要件定義の結果を見ながら基本設計を進めていきます。

要件定義のフェーズでは要件定義書が作成されるため、それを正確に基本設計へと落とし込むことが重要です。

目的は具体的な機能を決めること

基本設計では具体的な機能を決定します。

要件定義書はあくまでもシステムの機能や性能を定めたものであり、それを実現するための詳細な内容は含まれていません。

そこで、基本設計のフェーズではクライアントの要望を実現するための具体的な機能を定めていきます。

画面レイアウトや表示するデータ、表示する情報など細かな点を決定していくのです。

その際には、モジュール単位で分割して設計していくことが多いです。

基本設計では基本設計書を作成する

基本設計では最終的に基本設計書という成果物を作成します。

基本設計書には下記のようなものを含めるのが一般的です。

• ・機能一覧
• ・テーブル定義
• ・システム構成図
• ・画面レイアウト設計
• ・帳票レイアウト設計
• ・ER図

 

文章だけで作成するのではなく、図を用いて視覚的にわかりやすくすることが重要です。

クライアントに正確に理解してもらえるような基本設計書を作成しましょう。

次のフェーズの詳細設計に繋げる

基本設計の成果物は次のフェーズである詳細設計に渡されます。

詳細設計は基本設計の内容に基づいて作業が進められます。

このため、基本設計で十分な内容の成果物を作成できなければ、以降のフェーズに影響を及ぼします。

システム開発において基本設計は重要なフェーズなのです。

要件定義や詳細設計との違い

基本設計は、要件定義や詳細設計と何が違うのかを詳しく見ていきましょう。

このため、上記のような基本設計と詳細設計の違いが明確ではないケースがあります。

要件定義	システムにどのような役割が期待されているのかを明確にする最初のフェーズ
基本設計	ユーザーが直接目で見て触れる部分を扱うのが特徴。 ユーザーが求める機能などを設計するフェーズ
詳細設計	システムの機能を実現させるためにシステムの内側まで細かく設計するフェーズ

「基本設計」と「要件定義」の違い

要件定義の対象はクライアントからの要望の把握です。

クライアントからの要望事項をまとめて整理をし、要件定義書を作成します。

最終的な目的は、システムにどんな役割が期待されているのかを明確にすることです。

一方、基本設計の対象となるのは要件定義書やクライアントの業務を元に、要求される機能や非機能要件などを定義することです。

これらに基づいてシステムに求められる機能や画面、帳票などを設計していきます。

最終的な目的は、クライアントの要望を実現するために、どのように機能を実装すれば良いのかを決定することです。

また、要件定義の際にはクライアントとのコミュニケーションが中心になりますが、基本設計のフェーズでは開発メンバーとのコミュニケーションも重要になるということが大きな違いです。

基本設計に基づいて実際に開発を進めていくことになり、現実的に機能実装が可能なのかなど、開発メンバーの意見も参考にしていくためです。

「基本設計」と「詳細設計」の違い

基本設計は、要件定義の内容からシステムを具体的に練り上げていくフェーズです。

一方、詳細設計では、実装する直前の状態まで徹底的に設計して、システム内部の構造までを含めた細かい点を決めていきます。

また、現場によっては基本設計を外部設計と呼び、詳細設計を内部設計と呼ぶ場合があります。

外部設計はユーザーが直接目で見て触れる部分を扱うのが特徴で、ユーザーが求める機能などを設計するフェーズです。

内部設計は、システムの機能を実現させるためにシステムの内側まで細かく設計していきます。

ただし、小さな案件の場合は、基本設計と詳細設計がほとんど区別されずに行われる場合があります。

このため、上記のような基本設計と詳細設計の違いが明確ではないケースがあります。

「外部設計」と「内部設計」の違い

外部設計はユーザーが直接目で見て触れる部分を扱うのが特徴で、ユーザーが求める機能などを設計するフェーズです。

内部設計は、システムの機能を実現させるためにシステムの内側まで細かく設計していきます。

ただし、小さな案件の場合は、基本設計と詳細設計がほとんど区別されずに行われる場合があります。

このため、上記のような基本設計と詳細設計の違いが明確ではないケースがあります。

基本設計書はどこまで記載する？

基本設計書にはさまざまな項目を用意して、システムの概要がわかるような内容になっています。

それでは、一般的によく作成される基本設計書の各項目について紹介しましょう。

業務フロー図

業務フロー図とは業務の内容や処理の方法などを視覚的に表現したものです。

業務の開始から完了までの各プロセスを記号や図形で示して矢印で結ばれていることが一般的です。

各プロセスでどのような処理を行うのか分かりやすく示せるのがメリットです。

システムを利用する際の全体的な処理の流れを把握するのに役立ちます。

システム機能設計

システム機能設計は、システムに必要な機能を決定して整理する項目です。

システムの構成要素を決めて、わかりやすく図で表現します。

各システムの処理の種類や処理結果を格納する場所まで詳細に決めることが大切です。

最終的にはハードウェア構成図やソフトウェア構成図、ネットワーク構成図などとして資料をまとめます。

画面設計

システムの画面レイアウトを具体的に設計していくのが画面設計です。

画面ごとの番号や名称、IDを定めて、画面の種類を分類した上で、各画面に備える機能を決めます。

機能の目的から画面上での動きまで詳細を決めることが大切です。

画面ごとに、画面名や機能を表としてまとめておくと分かりやすいでしょう。

他の画面に移動する流れが分かる資料として、画面遷移図を作成することが多いです。

帳票設計

情報システムの開発で欠かせない帳票について、形式や書式、扱う情報の種類、出力の仕方などを決めるのが帳票設計です。

レイアウトを決定して、出力項目一覧を整理し、編集定義の決定をするのが主な作業です。

関連する機能と一緒に設計していくことが重要です。

資料として開発する帳票の一覧表や帳票概要、帳票レイアウトなどをまとめます。

バッチ設計

バッチ設計ではバッチ処理の設計を行うのが主な作業です。

バッチ処理とは、システムの裏で働く処理のことで情報システムに欠かせない要素となります。

どのようなバッチ処理があり、どんな情報をどんなタイミングで入出力するのかといった内容を決めていくのです。

バッチ設計ではシステム全体の視点で考えることが大切です。

さまざまなバッチ処理を組み合わせて、一つの処理結果を導けるように設計します。

バッチ機能をまとめた資料や、バッチ処理フロー、バッチ処理定義などを資料として用意します。

テーブル・ファイル設計

システムで扱うデータについてどのようにして保存し、どのように提供するのか設計するのがテーブル・ファイル設計です。

システムで扱うテーブルとテーブル内の主要なデータについて設計します。

最終的にはテーブル関連図(ER図)やテーブル・ファイルの一覧資料を作成するのが目的です。

インターフェース設計

システムは外部システムと連携することでユーザーが利用できるようになります。

そこで、具体的にどのように外部システムと連携させるのかを設計するのがインターフェース設計です。

資料としては、連携先や連携方法、連携時の参照データなどをまとめます。

外部システム関連図や外部インターフェース一覧を作成すると良いでしょう。

CRUD図

CRUD図とは、システムが扱うデータと機能の関係性を一覧にしたものです。

CRUD図はデータの整合性を担保し、機能の抜け漏れを防ぐ目的で作成されます。

具体的には、縦軸に機能、横軸にデータを配置し、各機能がデータに対して「Create（生成）」「Read（参照）」「Update（更新）」「Delete（削除）」のどれを行うのかを示します。

これによりデータと機能の関連性が明確になるため、設計の品質向上につながります。

コード一覧表

コード一覧表は、システム内で使用するコードとその意味を定義したものです。

コードの標準化を図り、開発者による表記ゆれを防ぐことで、システムの品質とメンテナンス性を向上させます。

あらかじめコードを定義しておくことで、開発者間の認識齟齬がなくなり、正確なデータ処理を実現できます。

非機能要件

要件定義で決められた要件以外にも、非機能要件について検討することが大切です。

非機能要件とは可用性や性能、拡張性、移行性、セキュリティなどが含まれます。

システムの使い勝手がよく、安定稼働するために求められている機能などを指します。

要件定義で非機能要件について検討されていない場合も多いため、その場合は基本設計のフェーズでしっかりと非機能要件を整理して資料にまとめると良いでしょう。

基本設計で失敗しないためのポイント

基本設計で失敗しないために意識したいポイントを解説します。

必要となる資料を見極める

基本設計で作成する資料には表記の基準が決まっていません。

業界内で明確な基準がないため、設計者が独自の表記をする場合があり、属人化するリスクがあります。

このため、基本設計書を作成する際には、ユーザーなど読む人への配慮を意識する必要があります。

例えば、プロジェクトによって必要となる項目が異なる旨を書いておきます。

また、必要のない資料を作成してもクライアントを混乱させてしまうため、必要となる資料を見極めることも重要です。

基本設計書でCADツールを活用する

基本設計書を作成する際に属人化してしまうことを避けるため、CADツールを活用するケースが増えています。

CADツールであれば決まったフォーマットがあり、成果物の基準化を図ることができるためです。

CADツールを利用すると、設計情報の一元管理や変更履歴の管理ができるといったメリットもあります。

他にもシステム設計に役立つ機能が多く搭載されているため、設計業務の効率化を図り、成果物の質を高めることにつながるでしょう。

管理方法やフォーマットを統一する

基本設計書を作成する際には、管理方法やフォーマットの統一化を図ることをおすすめします。

管理方法が統一されていないと、仕様変更の際に手間がかかってしまいます。

さらに、管理方法が統一されていないために大事な設計書が削除されるという場合もあります。

また、フォーマットが異なるとチェック作業が煩雑になり、見逃しも増えてしまうかもしれません。

これらのような問題を避けるためにも管理方法やフォーマットの統一化は重要です。

あらかじめ明確にルールを策定しておくと、設計業務をスムーズに進められるようになり、さまざまなリスクの回避も実現できるでしょう。

システム構成図を作成する

基本設計で失敗しないためには、システム構成図の作成が重要でしょう。

システム構成図とは、サーバーやネットワークといった各ハードウェアやソフトウェアが、それぞれどのように連携しているかの全体像を視覚的に表現したものです。

システム構成図を作成することで、開発メンバーやクライアントなど関係者全員が共通認識を持てます。

これにより設計時の矛盾や抜け漏れを防ぎ、後の工程における手戻りをなくし、プロジェクトを円滑に進めることができるでしょう。

実現できるかどうか定期的に確認する

設計内容が技術的に実現可能か、定期的に確認することも失敗を避ける上で重要でしょう。

机上の空論で設計を進めると、後の実装段階で問題が発覚し、大きな手戻りを生む原因になります。

これを防ぐには、開発チームとレビュー会を開き、技術的なフィードバックをもらうことが有効です。

早い段階で実現可能性を検証するサイクルを設けることでリスクを早期に発見し、精度の高い基本設計にすることができるでしょう。

要件定義とずれないようにする

基本設計は、必ず要件定義の内容に沿って進めることが必要です。

基本設計はクライアントの要望をまとめた要件定義書をもとに、システムの仕様を決定する工程です。

そのため、設計の軸となる要件定義からずれると、クライアントが求めるシステムにはなりません。

常に要件定義書に立ち返り、要件との一貫性を保つことが、プロジェクトを成功に導くために重要でしょう。

成果物の確認と分析を行う

作成した成果物の確認と分析を徹底することも、失敗を防ぐ上で重要です。

基本設計書は、後続のすべての工程の土台となるため、不備や曖昧な点があるとプロジェクト全体に悪影響を及ぼします。

これを防ぐため、チーム内レビューやチェックリストを活用し、多角的な視点で品質を確認しましょう。

このような地道な確認と分析のプロセスが、システム全体の品質を左右するのです。

関連記事：要件定義と基本設計がプロジェクトを左右する！成功するコツなどを紹介

基本設計において成果物を作成する際の注意点

基本設計の成果物には、品質を客観的に評価する共通の指標がないことを認識する必要があります。

共通の指標がない分、成果物は設計者に依存しやすく、属人化を招きやすいため、プロジェクト開始時にフォーマットや記載ルールを定義することが重要でしょう。

チーム内で合意形成し、誰が作成しても一定の品質を保てる仕組みを構築しましょう。

基本設計には明確な指標がないからこそ、誰が見てもわかりやすい成果物を作成することが求められます。

エンジニアはどこまでを基本設計で行うか理解をすることが大切

上流工程を担当するエンジニアにとって、基本設計はとても重要です。

基本設計は、クライアントとシステムについて最後の確認をするタイミングであり、次の詳細設計につながる重要なフェーズでもあります。

基本設計書にどのような項目を含めるべきなのかを良く理解しておきましょう。

また、基本設計を失敗しないために管理方法やフォーマットの統一を図ることも意識すると良いです。

そうすればクライアントの要望を満たした基本設計を実現できます。

上流工程について十分なスキルや経験を身に付ける、全行程工程を一人称で対応できるスキルを身に付ければ、フリーランスとして活躍することも可能です。

IT・テクノロジー領域特化型エージェントサービス「HiPro Tech」なら、さまざまな案件を扱っており、基本設計など上流工程の案件を営業活動の手間を省いて獲得するサポートを行ないます。

当サービスは、企業と直接契約できるため、高単価な案件や中長期的に契約ができる案件などを効率的に獲得する可能性を高められます。

ぜひ登録してみてください。