目次
外部設計・内部設計とは？
外部設計では、要件定義後にシステムの仕様を決める段階になります。具体的な仕様にすることで、プログラムの入出力が可能な状態にします。内部設計では、外部設計をもとにプログラミングができるように詳細に設計をしていきます。
外部設計とは？
外部設計では、非機能要件・機能要件・制約条件・外部との入出力を行うために仕様を設計します。外部設計では、次の4つに分けて紹介します。
機能設計
機能設計では、システムを1つのモジュール単位として分割を行い、各モジュール毎に使用するDBを設計します。例えば、DB間の連携やデータの入出力、ユーザーによる操作、帳票出力が挙げられます。
画面設計
外部設計では、モジュール単位でシステムの仕様を決定する以外にも画面レイアウトやUI、UXの決定もあります。ユーザーが利用しやすい画面設計を行うことで、顧客満足度を上げることができます。
方式設計
方式設計では、プラットフォームの仕様やシステムの実装方式について設計します。どのようにして、ハードウェアが構成されているのかモジュール間の連携はどのようにすればよいのか、開発言語やフレームワークは何を使用するかなどを設計します。
その他設計
その他は、クライアントが求めるセキュリティ対策や運用監視、工数などを決定します。外部設計書や画面仕様書など外部設計で設計される仕様書をクライアントに提示して、合意を取ることも重要になります。
内部設計とは？
内部設計とは、システムの目に見えない部分の取り決めを行うことです。外部設計で決められた内容をいかに効率よく動作させるかという開発視点で各種取り決めを行うフェーズです。内部設計を次の3つに分けて紹介します。
物理データ設計
システムで使用するファイルやデータの構成・やり取り・保管方法などを取り決めます。データごとの保管期限や更新タイミングなどを考慮し、数年後にはどれくらいのデータ容量になっているのかなどを算出し設計要素に含めます。
使用するテーブルの定義もおこなう必要があります。テーブル定義では、テーブルのカラム名・データの型・桁数などを検討します。実際にどういった種類のファイルを使用して、それらがどれくらいの容量になるのかを検討しておく必要があります。ファイルには、データファイル・インデックスファイル・システムファイル・一時ファイル・ログファイルなどがあり、容量を考慮する必要があります。
入出力の詳細設計
主にユーザーインターフェース部分の取り決めを行います。ユーザーの入力方法や入力されたデータのチェック方法、入力エラー時のメッセージの出力方法などを取り決めます。ユーザーが画面に配置された各項目に入力する場合、各項目の入力可能桁数や入力されるデータの型、活性や非活性などを検討します。
入力項目の取り決めが終わったら、実際に入力されたデータをどのようにチェックを行うか検討します。入力桁数を超えた場合の扱いや、入力エラーの項目が複数あった場合のエラー表示の方法、表示するエラーメッセージの内容、入力項目どうしの整合性チェックのルールなどを検討し取り決めます。
機能分割
外部設計で取り決めたシステムを機能ごとに分割します。分割した各機能の起動順序や、機能間のデータのやり取りなどを取り決めます。機能ごとに分割したものはモジュールという単位になります。どういった区切りで機能分割しモジュールを作成するのかが重要なポイントになってきます。モジュールを作成する際は「モジュールの独立性」を考慮に入れるようにしましょう。
1つのモジュールに複数の機能が含まれている場合、「モジュールの独立性が低い」と言われます。1つのモジュールに1つの機能のみが含まれている場合、「モジュールの独立性が高い」と言われます。一般的には、モジュールの独立性は高いほうが良い設計であると言われています。
また、システムの異常系についての検討も行います。DBのエラーやファイルの読み込みエラー、書き込みエラーなどが発生した場合、ユーザーが想定外の操作を行った場合など、システムがハングアップや異常終了してしまわないように検討する必要があります。
万が一、想定外のエラーが出てしまった場合も、エラー原因を突き止められるようにエラーログを記録する機能を設けたり検討する必要があります。
外部設計と内部設計の違い
外部設計はユーザーから見える部分を取り決めることに対し、内部設計はユーザーから見えないシステム内部の取り決めを行うことです。外部設計では、システム全体の概要や開発スケジュール、システムの機能一覧、どんなハードウエアを使用し、ネットワーク構成はどのようにするのかなど、システムの全体的なことを取り決めています。画面の仕様を取り決める画面設計や、出力する帳票のレイアウトを取り決める帳票設計なども行います。
一方内部設計は、ユーザーから見えない部分のプログラム構造やデータの構成・データの流れなどを取り決めています。内部設計で取り決めた内容を基にプログラマがプログラミングできるレベルまで具体的に落とし込みます。
外部設計・内部設計に力を入れるメリット
外部設計や内部設計に力を入れるメリットについて紹介します。
外部設計
外部設計に力を入れることで、ユーザーにとって使い勝手が良く、運用しやすいシステムとなり、ユーザーの要望に限りなく近づけることができるメリットがあります。なぜなら外部設計では、システムの使い勝手やシステムの性能、セキュリティや運用方法など、ユーザーから見える部分の仕様を決定するからです。
逆に外部設計に力を入れない場合、使い勝手が悪く要望を満たしていないシステムになる可能性があるため、デメリットしかありません。ユーザーの満足度が高いシステムを構築するためにも、外部設計に力を入れるべきです。
内部設計
内部設計に力を入れることで、外部設計で取り決めた内容を実現することができ、機能拡張も容易に行えるメリットがあります。内部設計では、外部設計で取り決めたことをプログラムで実現するための仕組みを決めます。そのため、予め拡張機能などを追加しやすい形に設計しておくことで追記事項があっても容易に対応することが可能になります。
逆に内部設計に力を入れない場合、外部設計で取り決めたことが実現できなかったり、実現できたとしても拡張性のないシステムになってしまいます。
ただし、プロジェクトによっては内部設計の重視するポイントが変わってくる場合があるため注意が必要です。例えば、Webメディアの開発などは、スピード重視で開発を進める必要があるため、内部設計は最低限のことしか記載されない場合があります。案件によっては内部設計書を作成しない場合も考えられます。一方、品質重視のシステム開発の場合は、きちんと内部設計書が作られることが多いです。
このように、プロジェクトの特性によって内部設計の位置づけが変わってくることがあります。
「システム設計の流れ
設計を行う場合には以下の手順でおこなっていきます。
- 要件定義
- 外部設計
- 内部設計
要件定義
要件定義とは、企業がクライアントに対してシステムの仕様や機能をまとめて資料として提示することです。要件定義では、クライアントが求めている機能や信頼性、運用性、保守性などを業務フローや業務モデルなどを活用して簡潔にします。要件定義の設計が詳細なほど、外部設計後の手戻りを減らすことが可能です。
外部設計
外部設計は、基本設計とも呼ばれ要件定義で決定した仕様を機能や制約条件、性能の観点から設計書にしていきます。外部設計では、操作方法や操作画面、UI/UXについて設計します。
内部設計
内部設計では、外部設計を基にシステム内部の機能や物理データ、動作などを詳細に設計していきます。外部設計と詳細設計の間でおこなわれるため内部設計を詳細設計と同じ工程でおこなうこともあります。
外部設計書の書き方
外部設計書の書き方について紹介します。
前提条件
外部設計書の前提条件は、外部設計の1つ前の工程である「要件定義」で取り決めた内容に沿っているということです。要件定義からかけ離れてはいけません。
また、要件定義で取り決めた内容は、まだ「理想」の段階と言えます。外部設計では「理想」の段階から「現実」の段階に落とし込む必要があります。つまり、実現可能な内容に落とし込むということが前提条件となります。
外部設計はユーザーが見ても分かるレベルにするため、ユーザーが具体的な操作や使い勝手などを想像できるように記載する必要があります。
書き方
ユーザー視点でシステムの概要や流れを説明する必要があります。システムの業務フローを明確にし、ユーザーがシステムを使用している状況を具体的にイメージできるように表現します。
またシステムの全体像も記載する必要があります。どのようなハードウエアを使用して、ネットワークへの接続やソフトウエアの役割など、全体概要を記載します。ソフトウエアではOSやミドルウェアの存在も明記しておきます。
また、システムに必要な機能の一覧を明確にしておく必要もあります。なぜならこの機能一覧が実際の開発範囲となるからです。あとはセキュリティー面や速度など、目に見えない部分についても、被機能要件としてまとめておくのが一般的です。
作成時のポイント
ユーザーが閲覧するため、図や表を使用して分かりやすい表現になるよう記載するのがポイントです。エンジニアにとっては当たり前のことでも、ユーザーには分からない内容があるなら、注釈や説明を入れて理解できるようにします。
一方で、システム的に矛盾がないようにする必要もあります。なぜなら技術的に不可能な内容になっていると次のフェーズに進めず、手戻りになってしまうためです。
内部設計書の書き方
内部設計書の書き方について紹介します。
前提条件
内部設計書の前提条件は、内部設計の1つ前の工程である「外部設計」で取り決めた外部設計書に沿っているということです。外部設計書の内容からかけ離れてはいけません。
外部設計書では、主にユーザー視点で業務フローや操作方法、画面表示などを取り決めました。内部設計書では、その内容に沿ってプログラム視点でどのように実現させるかを記載します。つまり、プログラム視点で実現可能な内容に落とし込むということが前提条件となります。内部設計書を見ればプログラムが作成できるレベルまで落とし込む必要があります。
書き方
内部設計書は決まったフォーマットに従った書き方をする方が良いでしょう。内部設計担当者の独自の表現方法で記載すると、プログラマに意図が伝わらない可能性があるためです。例えば、システム間の関係性やシステム間の構造を表現する場合は「クラス図」を使い、モジュール間の構成やどのような機能をモジュール分けするのかを表現する場合は「モジュール構成図」を使います。
この他にも内部設計書で使われる一般的な図が多くあるので、可能な限り一般的な表現で記載するようにしましょう。
作成時のポイント
内部設計書作成時のポイントとしては、読み手であるプログラマの視点で作成するということです。設計者の意図がプログラマに伝わらなかったら内部設計書の意味がありません。誤解のない表現を心がけるようにしましょう。そのためには、書き方の統一が重要な内容の1つです。例えば、「通信データ」「通信伝文」など複数の表現をするのではなく、統一する必要があります。書いている側は「わかるだろう」と思っていても、異なる意味で取られてしまう可能性もあるためです。
また、曖昧な表現を避けることも大切です。例えば、「一定時間経過後に」ではなく、「10秒後に」など、できるだけ具体的な数値を用いて表現するようにしましょう。
まとめ
今回の記事では外部設計と内部設計についてご紹介しました。DX案件を探している方、事例を知りたい方は、ぜひfoRProまでご相談ください。