システム開発において、不要なドキュメントやコードを書いている人はいないと信じたいですが、開発工程の前半に位置する設計工程および成果物である設計書は、プロジェクトを成功に導くために非常に重要です。
第1回では、システム開発における設計書の役割を改めて振り返ります。
設計書の目的
今回は運用保守ではなく、開発に主軸を置き、開発時に重要な部分に焦点を当てて説明します。
要件の明確化と共有
設計書はシステムの要件や仕様を明確にし、チーム内外の関係者と共有するための文書です。これにより、開発者、テスト担当者、プロジェクトマネージャー、クライアントなどがシステムの理解を共有し、同じ方向性で進めることができます。
開発の指針
設計書は開発の具体的な指針となる文書です。システムの構造、機能、画面遷移、データベースの設計など、開発に必要な詳細が記載されているため、開発者が設計書を基にして実装作業を行います。
品質の確保
設計書を通じてシステムの仕様が明確になることで、バグや仕様漏れを防ぎ、品質の高いシステムを作ることができます。また、設計書を元にレビューや検証を行うことで、問題の早期発見が可能になります。
テストの基準
テスト工程では設計書を基にしてテストケースを作成します。設計書に記載された仕様や要件が正しく実装されているかを確認するための基準となります。
保守・運用の支援
システムが稼働した後の保守や運用の際にも設計書は重要です。設計書があれば、システムの構造や処理内容を理解しやすく、修正や機能追加を行う際の参考資料となります。
変更管理
システム開発中や運用中に仕様変更が発生することがありますが、設計書を管理しておくことで、どこに変更が必要かを明確にし、変更内容を追跡できます。
契約やコンプライアンスの遵守
特に大規模プロジェクトでは、設計書が契約書の一部として扱われることもあります。設計書に基づいて開発が進むため、契約条件やコンプライアンスに沿ったシステムが構築されることを保証します。
開発における設計行程
要件定義
- 目的:
クライアントやユーザーのニーズを把握し、システムに求められる機能や性能を明確にします。システムがどのようにビジネスの課題を解決し、どのような価値を提供するかを具体化する最初のステップです。要件定義が不十分だと、開発されたシステムが期待通りに動かない可能性があります。また、要件定義の段階でおおよそのコストやスケジュールが決定されます。 - 作業内容:
- ヒアリングやワークショップを通じて要件を収集。
- 要件定義書の作成。
基本設計（外部設計）
- 目的:
システム全体の構成や外部からの見え方を設計し、システムの大まかな仕様を決定します。この工程ではお客様にも参加していただき、要件定義が具現化されているかを確認します。文章だけでなく、イメージしやすいように図やモデルを活用すると誤解を避けやすくなります。 - 作業内容:
- システム全体のアーキテクチャ設計。
- 画面設計（UI/UX設計）、機能設計。
- データベース設計（ER図、データモデル）。
- インターフェース設計（外部システムとの連携）。
詳細設計（内部設計）
- 目的:
基本設計で決定した仕様を基に、より詳細な設計を行い、開発に必要なすべての情報を定義します。この工程は設計行程の中でも特に多くの人が関わるため、設計書のフォーマットや記載の粒度を事前にルール化しておくことが重要です。詳細設計の初期段階では、設計が迷走しやすく、全体の統一仕様の調整や横展開が必要になることが多いです。そのため、影響範囲や特定の要素（テーブル、カラムなど）がどの機能で参照されているかを迅速に把握できるようになっていることが求められます。 - 作業内容:
- モジュール設計（機能を細かく分けた設計）。
- プログラム設計（具体的な処理の流れ、アルゴリズムの設計）。
- テーブル定義書の作成。
- 各画面やレポートの詳細設計。ER図やデータモデルの詳細化。
- 正規化などによるデータの整理。
コメント