システム開発における設計とは、要件定義で定めた要件を実現するためのシステムを設計する工程であり、システムで実際に動作するため、要素の仕様（画面のレイアウト、ボタンの配置、機能の動作など）を決定します。この記事では基本設計と詳細設計から成る設計について、目的や役目を具体的に説明するのとあわせてよくある設計のミスについても触れていきます。
この記事の目次
1.システム開発における設計とは
・基本設計と詳細設計
システム開発における設計とは、要件定義で定めた要件を実現するためのシステムを設計します。実際にシステム上で機能する要素の仕様（画面のレイアウト、ボタンの配置、機能の動作など）を決定する工程です。設計はシステム開発の流れの中で上流工程に位置し、基本設計と詳細設計の２つから成り立ちます。
基本設計も詳細設計のいずれも要件定義の内容に基づいて行われますが、それぞれ設計する対象と内容が異なります。基本設計はシステム全体の概要や操作方法など、ユーザーから見える外部の部分について設計します。一方、詳細設計はシステムの内部構造やデータの流れなど、ユーザーに見えない部分を設計します。
2.基本設計とは
基本設計とは、要件定義でまとめた自社ニーズの実現に向けて、システムに実装する機能を明確化していく工程です。この章では「基本設計の目的」「基本設計の役目」「開発のフローのどこで作成されるのか」について説明します。
3.詳細設計とは
詳細設計とは、システムの内部構造について設計を行う工程です。そのため「内部設計」とも呼ばれます。
4.システム開発に関わる担当者は各設計について、どこまで分かっている必要があるのか
システム開発に関わる発注者と、システムエンジニアやプログラマーの開発担当者は、基本設計と詳細設計の内容についてどこまで理解しておく必要があるのでしょうか。それぞれ説明します。
システム開発の発注者は基本設計の内容について理解し、開発側のシステムエンジニアと認識を一致させて目線合わせを行っておくことが極めて重要です。
基本設計の目的はユーザーから見える外側の部分について設計することにあるためです。システム開発の発注者はシステム全体の概要や操作方法、UI（User Interface：ユーザーインターフェース）などについては実際にシステムを利用する立場から、そもそものユーザーニーズを満たしているか、入出力のプロセスや画面遷移などに問題はないかなど、想定できるタイプのユーザー目線で確認しておく必要があります。
一方、詳細設計はプログラマーへの指示書となる設計図を作成するプロセスのため、システム開発の発注者は必ずしも理解しておく必要はありません。ただし詳細設計の役割やどのような作業が行われているのか、全体像を把握しておくとよいでしょう。
特に詳細設計は基本設計で定義した内容をプログラマーに伝えることが目的で、伝わった内容を元にプログラミングを行い、ユーザーニーズを実現するための機能を実装できるようにするため、重要な工程となります。詳しい役割としては、主に基本設計がフロントエンジニア、詳細設計がバックエンドエンジニアで分担されることが多いので、連携時のミスコミュニケーション等には細心の注意が必要です。
5.各設計における成果物と管理方法
基本設計と詳細設計の工程では、それぞれ設計書を成果物として作成します。
a．基本設計書に載っている内容一覧
基本設計書の成果物として基本設計書があり、その内容は以下の7つの要素から構成されます。
| 要素 | 詳細 |
| ①システム設計 | ハードウェア構成図、ソフトウェア構成図、ネットワーク構成図、システム機能構成図などが該当します。 |
| ②画面設計 | 画面一覧、画面レイアウト、画面遷移図、入出力項目、画面アクション定義図などのドキュメントになります。 |
| ③帳票設計 | 帳票一覧、帳票レイアウト、入出力項目一覧、帳票編集定義図などが該当します。 |
| ④API・バッチ（一括処理）設計 | バッチ処理一覧、処理フロー図、バッチ処理定義書が該当します。 |
| ⑤データベース設計 | テーブル・ファイル一覧、ER図（実体関連図）、テーブル・ファイル定義、CRUD図が該当します。CRUD図とはデータベース管理システムでCreate（作成）、Read（参照）、Update（更新）、Delete（削除）によるデータの操作種別を表す情報分析図です。 |
| ⑥ファイル設計 | ファイル一覧、ファイルレイアウト図などが該当します。 |
| ⑦外部インターフェース設計 | 外部インターフェース一覧、外部インターフェースレイアウト図などが該当します。 |
b．詳細設計書に載っている内容一覧
詳細設計書の成果物として詳細設計書があり、以下の7つの要素から構成されています。
| 要素 | 詳細 |
| ①クラス図 | クラスとはオブジェクト指向プログラミングにおける「プロジェクトの設計図」を意味します。クラス図ではシステムを構成するクラスの関係性を表現しています。クラス図では基本設計書をもとに、システムに必要なクラスを抽出し、それぞれクラスの関係性を整理してまとめています。 |
| ②モジュール構成図 | プログラムのまとまり単位で分解したモジュールについて、各モジュールにはどのような機能があるのか、各々のモジュールがシステムをどのように構成しているのかを示した静的な資料です。 |
| ③アクティビティ図 | アクティビティ図とは、システムのユーザーの行動（アクティビティ）によって発生するユーザー操作やシステム処理の流れがわかる動的な資料です。システムの処理や実行の流れを順番に記述し、条件による分岐を図式化したドキュメントです。 |
| ④シーケンス図 | シーケンス図とは、時間軸の流れに沿ってプログラムの処理の流れや連続・順序（シーケンス）について表した図式です。シーケンス図はクラス・オブジェクト（データ構造）間のやり取りを表した動的な資料になります。 |
| ⑤IPO（処理機能記述） | IPOとは「入力（Input）」「処理（Process）」「出力（Output）」の流れを表した動的資料です。バッチ処理などについて記述しています。 |
| ⑥開発方針・ルール | ライブラリ・プログラミング言語の指定、記述ルール書など開発に伴う方針やルールについて記述しています。 |
| ⑦単体・結合テスト設計 | 単体・結合テストの計画書・仕様書・設計書などのドキュメントです。 |
c.【参考】成果物の管理方法
設計のプロセスにおける成果物の管理は、システム開発のプロジェクトを円滑に進めるために重要な項目です。WordやExcelといった汎用ツールを使用する場合は下記に記載したような問題が発生しやすくなるので、注意が必要です。成果物の管理において起こりうる課題と対応について記します。
| 要素 | 詳細 |
| ①セキュリティリスク | 詳細設計書を社外に持ち出したり、誤って送信することで情報漏洩のリスクが発生します。機密保持の明確なルールの設定や情報セキュリティに関する社内教育の実施、専用ツールの活用によって情報漏洩リスクを予防します。 |
| ②即時の情報共有 | 詳細設計書を開発メンバーに手作業で配布しているケースでは、修正や調整があった際は再配布が必要になります。このような方法では手間と時間がかかるだけでなく情報共有のタイムラグが発生します。そのため設計書はデータベースで一元管理し、リアルタイムで共有できるようにすることが必要です。 |
| ③属人化 | ドキュメントに対する明確な基準がない場合、作成や管理方法などが設計者の裁量に依存し属人化しやすくなります。ドキュメントの作成ルールを明確に定義し、共有化することが必要です。 |
6.よくある設計ミス
設計の工程でよくあるミスの事例や、ミスを出さない工夫、万が一ミスが発生した場合について解説します。
a.よくある設計ミス
①コミニュケーション不足のケース
要件定義、基本設計、詳細設計の工程において、コミニュケーション不足によって認識のずれや内容が曖昧な場合は、担当者が本来と意図と異なる解釈をしてしまう場合があります。その結果、誤った内容で設計書が作成されるミスが発生します。
②考慮不足や確認不足によって必要な機能が実装されないケース
担当者の考慮不足や確認不足によって、必要な機能が設計書に盛り込まれず、漏れてしまうケースです。特に要件定義書で記載漏れや考慮漏れがあった場合は、広範囲に影響がおよびます。
③レビューの不足とチェック体制の不備
成果物に対するレビューが不十分な場合、記載漏れや考慮漏れに気づかずに次の工程に進んでしまいます。設計ミスが開発・テスト工程で発覚した場合は、設計工程の成果物に対するレビューの不足やチェック体制の不備が考えられます。
b.ミスを出さない工夫
上述の様なミスが発生しないようにするためには、担当者間で認識の齟齬や理解の不一致が発生しないようなコミニュケーションを行う必要があります。また、要件定義や基本設計、詳細設計の工程で必要な要件や機能の抜け漏れや類似のミスが発生していないか、しっかりとレビューを行う必要があります。
また、詳細設計では細かな仕様を中心に検討を進めるため、知らず知らずに要件からずれてしまう可能性があります。要件定義の内容と突き合わせを行い、ずれが発生していないか定期的に確認しましょう。
c.ミスが起きてしまった場合の工夫
システム開発の工程では確認やレビューを行ったにも関わらず、万が一ミスが起きてしまった場合の対応について下記に記します。
①システム開発側と話し合う
システム開発の失敗が明らかになった場合、発注者は開発会社と直接話し合い、問題点の確認と解決策を模索します。発注者側は要求水準を満たしていない点や開発プロセスのどの段階で問題が発生したのかを伝えます。一方、開発会社側は、問題の原因や背景を説明し、改善策を提案します。
②契約書の内容を確認する
ミスが起きてしまい、修正ややり直しが工程の中で収まり切れない場合、契約書の内容を確認しましょう。契約書に記載されたシステムの仕様や納期、費用、検収条件などと、実際に納品されたシステムや開発プロセスを突き合わせ、問題点を洗い出します。リカバリーについて、協議が必要になる場合があります。
7.まとめ
本記事ではシステム開発における設計の工程について解説しました。要件定義で定めた仕様などを実際にシステム上で機能するように反映する設計のプロセスは、システム開発の核ともなる大切な工程です。設計の工程について理解を深めてシステム開発を進めていきましょう。
情シスNavi.では、本コラム以外にも、情報システムの開発に関わるさまざまなコンテンツを提供しています。是非確認してみてください。
関連記事
