hiro1120_writer

システム開発経験（Java, PHPによる開発及びリーダー経験あり）

企業が、現在の業務をシステム化するときに外部企業にシステム開発を依頼します。開発は、要件定義・基本設計・詳細設計・開発・運用を行います。ここでは、何を基本設計ですべきかを紹介します。

現在、業務を自動化するためのシステム化を考えている企業は、本記事で解説している情報を理解し、自社に合ったシステムの導入に役立ててください。

基本設計とは

システム開発の初期段階で行う設計作業が基本設計で、顧客の要件を収集しシステム内で必要な機能を明確にする作業です。この段階では、顧客が満足する機能を具体的に設計します。

基本設計の概要

システム開発時の設計フェーズには、要件定義、基本設計、詳細設計、開発、テスト、リリース、運用・保守、新規・拡張開発があり、要件定義と基本設計は、その後の開発時の作業工数、費用に多大な影響を与えます。

特に基本設計では、これ以降の作業への影響範囲が大きいため基本設計で機能漏れは許されません。

顧客の必要な要件を機能別に整理します。システム開発を成功させるために、基本設計は大まかに次の4つに分かれます。画面、インターフェース、データ（テーブル・ファイル）、帳票出力です。これらの4つの要素を、顧客のニーズに適した形で設計し、途中で顧客に確認しながら、システムをできる限り顧客の要求に合致する形に仕上げていきます。

基本設計を失敗すると、次の作業で大きな失敗を招いてしまう恐れがあります。システム開発時に、基本設計でのミスはその後の開発に大きく影響するので、システムエンジニアの力量が問われます。

基本設計の重要性

基本設計はシステム開発において非常に重要な段階といえるため、この段階で顧客の要求を完全に理解し、それを設計に反映することがプロジェクトの成功に直結していきます。

開発の流れとして、まず顧客との打ち合わせを通じて必要な要件を明確にして要件定義書を作成します。この要件定義書を基に、顧客が求める機能を満たす基本設計を行います。

基本設計が確定すると、それをもとに社内で開発チームとのさらなる詳細なすり合わせを行い、開発への落とし込みを進めます。

この工程では、顧客だけでなく開発チームのニーズにも合致した設計が求められます。

基本設計が適切に行われれば、その後の詳細設計や開発工程もスムーズに進行して全体の開発プロセスが円滑に進むため、どのシステム開発案件においても重要な工程となります。

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

システム開発プロジェクトにおいて中心的な役割を担うのが、「基本設計」、「要件定義」、「詳細設計」の3つのステージで、各フェーズで具体的な技術的要件を明確化し、システムの構造を形作っていきます。

要件定義でプロジェクトの基本的な要望と目標が決定され、基本設計でシステムの大枠と構造が設計され、詳細設計ではそれを具体化し、プログラムレベルでの細かな仕様が作り上げられます。

これらの段階をしっかりと実行することで、効率的かつ効果的なシステム開発が実現されます。

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

システム開発工程の重要な工程が基本設計で、顧客の要件を機能別に具体的な案を定義する作業になります。要件定義は、顧客と共に現在の問題点と潜在的なシステム改善ポイントを検討し、システム案の作成作業を行います。これはシステム開発において重要で、顧客の主要な目標を明確にする役割を果たします。

顧客の要求項目を要件定義で整理して、システム化のための要求事項に具現化します。すべての顧客の要求事項を完璧に把握し要件定義が終わると、次は基本設計に進みます。画面設計、データ設計、およびインターフェース設計などを通じて、顧客の要求を達成するためのシステム全体の設計作業なのです。

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

基本設計は顧客の要件を明確にするもので、詳細設計は開発者向けに設計します。顧客の要件を機能別に設計をするのが基本設計で、詳細設計は、基本設計の下流工程になります。機能設計からデータ設計まで完了すれば、システム開発の30％ほど完成したことになります。

詳細設計は、基本設計をもとに機能別の設計作業です。詳細設計では、入力・処理・出力を明確にするためにIPOという設計手法を使います。IPOとは、入力（Input）・処理（Process）・出力（Output）の3ステップに分けて記述するものです。IPOで基本設計の機能をより明確化し細かな作業を書いていけば、プログラマーが設計書通りにコーディングできます。

基本設計のフロー

要件定義書に基づいて基本設計を行うが、要件定義書と基本設計の作成者が異なることもあります。基本設計作業をスムーズに行うための進め方を見ていきましょう。

要件定義書の確認

すべての顧客の要望が書かれているとは限りません。要件定義書に書かれていない部分もあるので、その点に関しても把握してから基本設計を行わなければいけません。

要件定義書内に顧客の要望を全て書き切られていない場合も多いです。基本設計にどう反映するかを考えて、要件定義書を何度も読み返します。また、基本設計を外注に依頼することもあるので、その場合、作成した要件定義では書ききれていない部分に関して、基本設計書の作成者と細かな打ち合わせを行い完成させます。顧客の要望をまとめた要件定義書をできるだけ理解しましょう。

設計する機能一覧の作成

Web系システムの基本設計には、画面・帳票設計・データベース（テーブル・ファイル）設計・バッチ処理設計・インターフェース設計があります。システム設計には、これらの機能とは別に、開発する内容に合わせた追加の機能が必要な時があります。

開発するシステムではどの機能が必要で、隠された機能には何が必要なのかの洗い出しが重要です。機能一覧作成時は、漏れがないように洗い出していかなければ、その後の作業が間違った方向へと進む可能性があります。

設計書の作成

要件定義をもとに機能一覧を洗い出した後、機能ごとの詳細設計をします。機能設計では、機能間のつながりを考慮して各機能設計書を作成しなければいけません。機能設計では、画面、データベース、インターフェースなど別の人が設計することもあります。その時は、基本設計さえしっかりできていれば問題なく作業できて、機能間の整合性も取れます。

また、業務フローも考慮した設計書を作成しなければいけません。基本設計段階では、運用する顧客の協力を得た設計が必要不可欠です。機能毎の詳細設計者は、作成作業を行う前に、機能確認を怠らないようにしてください。

基本設計書の記載内容・成果物一覧のサンプル

参画する現場によって基本設計書の書き方や粒度はまちまちです。

しかし、一般的に基本設計ではどのような点が重要で考慮していくべきなのか、必要な項目がわかっているだけでも成果物の作りやすさは変わってくるでしょう。

ここでは一般的な基本設計書の紹介と記載内容について紹介していきます。

基本設計書のテンプレート・例

システム開発の基本設計書のテンプレートを作成するには、プロジェクトの要件や目的に合わせて調整することが重要です。

ここでは、一般的なビジネス向けの顧客管理システム（CRMシステム）の基本設計書テンプレート例を紹介します。

このシステムは、顧客情報の管理、連絡履歴の記録、セールスオポチュニティの追跡、サポートケースの管理などの機能を含むものとしています。

システム概要

• 目的: 顧客情報を一元管理し、効果的な顧客関係の維持とビジネス機会の最大化を図る。
• 対象ユーザー: 営業部門、マーケティング部門、カスタマーサポート部門。

機能概要

• 顧客情報管理: 顧客の基本情報、取引履歴、連絡情報を管理。
• 連絡履歴管理: 顧客とのコミュニケーション記録の詳細を追跡。
• セールスオポチュニティ管理: 売上機会の追跡と評価。
• サポートケース管理: カスタマーサポートのリクエストと対応の追跡。

システムアーキテクチャ

• アーキテクチャ図: 主要なシステムコンポーネントとその相互作用を示す図。
• データモデル: エンティティ関係図（ER図）を使用してデータベースの構造を示す。

インターフェース設計

• 外部システムとの連携: 他のビジネスシステムとのデータ連携方法。
• API仕様: 外部開発者が利用可能なAPIの詳細。

ユーザーインターフェース

• 画面設計: 各機能に対するUIのモックアップ。
• ユーザーエクスペリエンス: ナビゲーションフローとインタラクションデザイン。

性能要件

• レスポンスタイム: 各種操作の目標応答時間。
• 同時アクセスユーザー数: サポートする同時ユーザー数。

セキュリティ要件

• データ保護: 機密情報の暗号化とアクセス制御。
• 監査ログ: システムの操作履歴の記録とレビュー。

開発環境

• 使用技術: ソフトウェアの開発に使用されるプログラミング言語、フレームワーク、ツール。
• 開発チーム構成: 開発に関わるチームメンバーと役割。

その他

• バージョン管理: ソースコードのバージョン管理方法。
• ドキュメントポリシー: 開発中に作成されるドキュメントの標準とポリシー。

基本設計書の記載内容

基本設計書には以下のような内容を記載するのが一般的です。

• システム概要
• アーキテクチャ図
• 機能仕様
• ER図
• ビジネスロジック
• ユーザーインターフェース
• セキュリティ要件
• インフラストラクチャ
• 外部インターフェース
• テスト要件
• 変更管理

基本設計書の書き方・注意点

基本設計書作成時は、注意点があります。ここでは、どのような注意点があり、どう対処しなければいけないのかを具体的に解説します。

要件定義書との整合性に気を付ける

システム基本設計は、その後のすべての作業工程に影響するもので、要件定義を忠実に実践しなければいけません。要件定義書はシステムが達成すべき目標や機能を明確に定義した文書で、基本設計書はその要求を基にシステムの設計方法を具体化させたものです。要件定義書の内容から逸脱しているシステム設計書は、意味がありません。

要件定義書との整合性が重要であり、要件定義書との整合性を取りながらクライアントのニーズに合った、システム設計以下の作業をスムーズに行えるようにしなければいけません。そのためには、要件定義書との整合性を第一に考えて基本設計を行います。

具体的かつ完結に記載する

要件定義書との整合性を取りながら、冗長な書き方をしてはいけません。

機能設計は、明確で具体的かつ簡潔な表現を用いて、要件を理解し作成しなければいけません。システムの構造、処理の流れ、データベースの設計、インターフェースの設計をより詳細に記述すれば、具体的な設計ができます。完結とは、不必要な情報は混乱を招く可能性があるので、必要な情報だけを網羅し、その情報を明瞭にしなければいけません。

また、要件を正確に実現するだけでなく、コスト面もよく考えて、できるだけ安く開発するための工夫も基本設計で行わなければいけません。

実際に作成できる内容か

要件定義から基本設計を行う時に、実現可能な機能なのかが重要になります。要件定義ではできそうだと感じて顧客に提案していても、開発段階で実現不可能であると判断したときは、速やかに顧客へ別のやり方を提案して納得してもらわなければいけません。

要件定義で決まった業務を基本設計段階で、実現可能なのかを具体的に見極めていく必要があります。実現できないことが分かっていて、そのまま基本設計を行うと、顧客に多大な迷惑をかけることになります。基本設計の段階で、実現可能な機能なのかを判断するのも重要な役割になります。

ドキュメントのルールは適切か

基本設計段階で複数のドキュメントを作成します。ドキュメントの作成時には、それぞれのドキュメントで作成ルールがあります。ルールに沿った作成ができていなければ、その後の詳細設計で作成ができない可能性が出てきます。基本設計を行う時に作成ルールに沿った設計書を作ることは、開発を行っていくうえで重要です。

例えばIPOを作成するときは、左側にはインプットの図と入力項目を書いて、中央のボックスにはプロセス（処理）を書きます。その結果のアウトプットの図と出力項目を左側のボックスに書きます。このように、ルールに沿って書かなければいけません。

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

基本設計は、要件定義で確定した内容を基に、システム全体の構造や振る舞いを設計する工程です。

モジュール分割、データフロー、基本アーキテクチャ、画面遷移など、システムの大まかな骨格を決めていきます。非機能要件に基づいたセキュリティ対策や、将来の拡張性を見据えた設計も行われます。

また、基本設計が必要な作業範囲や要件定義では触れられることの少ない非機能要件も重要です。機能要件のみを意識して設計を行うと、パフォーマンスが悪かったり、障害に脆弱だったり、保守が困難になる可能性が高くなります。

もし、独自システムを開発したいと考えているたり、基本設計はできているけど受託できるベンダーをどう選定するか悩んでいたりするならばJiteraへお問い合わせください。

要件定義や基本設計を行うパートナーとして、企業様の視点からお手伝いさせていただきます。