システムを作り上げていく工程には、大きく分けて設計工程と開発工程があります。
最初はまず設計工程から入り、どんな機能が求められるのかをクライアントと打ち合わせ、全体の仕様を決めて開発工程に進みます。
今回はシステム設計の流れとポイント、そしてシステム設計のプロセスである外部設計と内部設計のそれぞれの違いについてご紹介します。
システム設計とは？
システム設計とは、システムの開発工程に入る前に、システムの機能や仕様を決める設計工程のことを指します。
システム設計では基本的に、発注側であるクライアントと開発側が打ち合わせを行い、現状の業務における課題や悩みをヒアリングして、システム開発によって解決するべき課題をまとめて、実際に開発に必要な程度まで詳細を詰めていきます。
システム開発の全体的な工程を川の流れに例えて、上流工程、下流工程とそれぞれ呼びますが、設計工程は前半の部分にあたるため、上流工程に該当します。
システム設計の流れ
システム設計は上流工程として、要件定義、外部設計(基本設計)、内部設計(詳細設計)という3つのプロセスに分けて進みます。
一方、開発工程は下流工程として、開発、テスト、システム移行、運用のプロセスへと進みます。
それぞれの詳細は以下の通りです。
1. 要件定義
要件定義は、クライアント側の業務上の悩みをヒアリングして、どのようなシステムを開発していくか、仕様を打ち合わせてまとめる工程です。
システムの仕様を決めると同時に、どういった開発手法で進めていくのか、また予算や納期、リリース後の運用方法等も、要件定義の段階で打ち合わせます。
システム設計が今後スムーズに進むかどうかは、要件定義でどれだけシステムについての内容を詰めることが出来たかで大きく決まります。
外部設計以降の工程を進めていく中で、認識の齟齬による仕様変更や手戻りが発生しないように、クライアント側との認識をここでしっかりと合わせておく必要もあるため、要件定義は極めて重要な工程と言えます。
2. 設計
要件定義でシステムについての仕様を決めた後は、外部設計、内部設計へと進んでいきます。
外部設計と内部設計は、それぞれ設計する内容に少し違いがあります。
2-1. 外部設計
外部設計(基本設計)では、要件定義で決めたシステムの全体的な仕様を、今度は機能毎に分けてより細かくまとめていきます。
システムを実現させるためには、画面はどんなものを作るか、やり取りされるデータの形式はどうするか等、実装すべき機能について決めていきます。
外部設計はさらに、方式設計、機能設計、その他の設計へと細分化されます。
・方式設計
開発手法やプロセスをまとめた開発標準や、テスト方式等を設計します。
・機能設計
システムとして実装する機能の詳細や、データベース、画面等を設計します。
・その他の設計
システムのパフォーマンスや、セキュリティについての設計を行います。
外部設計では、クライアント側にも見える部分についても設計するため、システム完成イメージにお互いが納得いくよう、設計書のレビューを重ねて認識を合わせましょう。
2-2. 内部設計
内部設計(詳細設計)では、外部設計でまとめた機能毎の仕様を実際にプログラミング出来るように、システム内部に特化した設計へと落とし込んでいきます。
内部設計はさらに、機能設計、物理データ設計、入出力詳細設計へと細分化されます。
・機能設計
機能をモジュール毎に分割した際のそれぞれの実装内容や、機能間でのデータの流れを明確化して設計します。
実装内容の明確化は実装時のコーディング作業をやりやすく、データの流れの明確化は、設計時のバグを洗い出すことが出来ます。
・物理データ設計
クライアント側には見えない、システム内部で扱うファイルやデータの流れに関する部分を設計します。
・入出力詳細設計
入出力のインターフェースを、どのようにプログラムで実装するかを細かく設計します。
エラー時に表示するメッセージや、データの初期値の定義、データの入力チェック等もここで設計します。
3. 開発
設計工程が終われば、次は開発工程に進みます。
開発工程では、内部設計で定義した設計書に書かれている機能について、コーディングしてプログラムに反映させていきます。
開発工程をスムーズに進めるためには、設計書が分かりやすいものであることは前提ですが、開発担当者には設計書の内容を読み解く理解力と、それを実現するコーディングスキルも必要となってきます。
4. テスト
コーディング後は、プログラムの動作を確認するテスト工程に入ります。
テスト工程は一般的に、単体テスト、結合テスト、統合テストに分けて進めていきます。
・単体テスト
プログラムの関数やメソッド毎の細かい単位でテストします。
基本的には、開発担当者がコーディングを行いながら都度単体テストを行い、プログラムの動作を確認していきます。
ここで正しく動作しなければ、以降の結合テストには進むことが出来ませんので、単体テストはしっかりと終わらせる必要があります。
・結合テスト
結合テストは、単体テストで確認した機能を複数結合させて、正しく動作するかを確認するテスト工程です。
結合テストについては、こちらの記事でも詳しく紹介しているのでぜひご確認ください。(https://pengi-n.co.jp/softwaretest/archives/216)
・統合テスト
統合テストでは、システムを実業務に沿った流れで実際に動作させてテストを行います。
テスト時に利用するデータも本番環境と同等のデータを利用する場合が多く、本番で発生しうるイレギュラーな不具合をここで探ります。
テスト工程にてバグが見つかった場合は、デバッグを行ってバグを取り除きます。
デバッグについては、こちらの記事でも詳しく紹介しているのでぜひご確認ください。(https://pengi-n.co.jp/softwaretest/archives/98)
5. システム移行
テスト終了後は、システムを開発環境から本番環境へ移行する、リリース作業に進みます。
システム移行の前に本番環境では、システムを受け入れるための環境整備を整えておき、開発環境からはどのデータを本番環境へ移行させればよいのか、ミスがないよう慎重に準備を行います。
6. 運用
リリース後は、システムが正しく稼働しているか、不具合が発生していないかを監視する運用業務を行います。
システムの予期せぬ停止や、不具合が発生した場合は、その原因を特定して、リカバリ、再発防止に向けて対応を行います。
システム設計をスムーズに行うためのポイント
システム設計をスムーズに行うために重要となるポイントについてご紹介します。
認識のズレがないようにする
開発側とクライアント側の両方で、認識のズレがないようにしましょう。
特に、要件定義の時点で、お互いの認識は合わせておくことが重要です。
認識のズレがあるまま設計工程・開発工程へと進んでしまうと、仕様変更や仕様漏れが発覚した場合の手戻りのコストが膨大になってしまう恐れがあります。
実装するべき機能や各設計書は、クライアントとのヒアリングやレビューを重ねて、お互いの認識を明確にしてから作業を進めましょう。
開発者と発注者が適度なコミュニケーションをとる
開発側と発注者側は、適度にコミュニケーションを取りましょう。
設計時に少しでも不明瞭な部分が出てきた場合は適宜相談して、明確にしましょう。
コミュニケーションを適度に取ることで、認識のズレを防ぐことができ、また万が一、ズレが生じた場合でも最小限のリスクで抑えることが可能となります。
【まとめ】システム設計を正しく理解し、進めよう
システム設計を進めるためには、各工程で何をどこまで設計するべきか、システム設計の流れを正確に理解することが重要です。
クライアント側とも適度にコミュニケーションを重ねて、仕様漏れが発生しないような設計を行いましょう。
