外部設計書と内部設計書の違いは、一言でいうとシステムの見えるところを設計するのが外部設計、見えないところを設計することが内部設計です。
どちらもシステム開発においては欠かせない工程です。本記事では外部設計書を作成する際の注意点や管理の重要性、業務の効率化についてご紹介していきます。
システム設計の流れをおさらい
外部設計書と内部設計書について詳しく解説をする前に、そもそものシステム設計における流れについて確認をしておきましょう。まずはシステム設計の流れについて解説をしていきます。
要件定義
要件定義とは、クライアントが求めている機能をまとめて、システムの仕様やどこまで対応させるかという範囲を決定することです。ここでは、クライアントの要望について詳しく調査することが必要です。
一般的に要件定義の精度が高ければ高いほど、後々の仕様変更が少なくなります。これは最初にさまざまなケースに対して想定をしているため、予想外のトラブルが発生するという事態に陥りにくいからです。
外部設計
外部設計は基本設計や概要設計とも呼ばれます。
要件定義で決定した機能や性能、制約条件などを基にしてシステムの基本となる設計を行います。操作画面や操作方法、データ出力など、ユーザーから見えるインターフェース部分の仕様を決定したり、セキュリティや運用規定、システム開発のスケジュールや費用などを設計したりと、基本的にユーザーに向けた仕様を設計するのが外部設計です。
要件定義が不十分だと外部設計をスムーズに進めることができません。要件定義で決めた要求機能を具体化するのが外部設計なので、元となる要件定義が不十分だと当然具体化できません。外部設計に入る前に、十分に要件定義が出来ているのかは関係者全員で確認するようにしましょう。
内部設計
内部設計とは、外部設計をもとにして、システム内部の動作や機能といったユーザーから見えにくい部分の設計を行うことです。詳細設計とも言います。内部設計は、その後の実際のプログラミングの工程に入れるよう、プログラマが何をどのように作ればいいかを定めた指示書といったイメージです。内部設計がしっかり出来ていないと、プログラミングの生産性が落ちてしまうことにつながります。
これらがシステム設計の流れです。要件定義、外部設計、内部設計という流れで進んでいきます。
外部設計書とは？
システム設計の流れについて理解したところで、外部設計書についてご紹介いたします。
前述しましたが、外部設計は要件定義で定めた機能を具体化し、その後詳細設計に入れるようにシステムをアウトラインを明確にする工程です。この外部設計の工程で作成する各種ドキュメントが「外部設計書」です。
外部設計では、
- 業務フロー
- 機能一覧表
- ネットワーク構成図
- テーブル定義
- ER図
- 画面レイアウト
- 帳票レイアウト
などを外部設計書として作成します。
内部設計書とは？
内部設計では、外部設計の結果を実際にプログラミングできるように、システム内部の詳細な設計を行います。
内部設計では、
- 機能仕様書
- データフロー図
- データベース物理設計書
- クラス図
- モジュール構造図
- アクティビティ図
- シーケンス図
- IPO
などが作成されます。内容は開発を行うメンバーに共有されますが、内部設計でクライアントとの調整を行うことはほとんどありません。
必要なドキュメントについてはこちらの記事でも詳しく紹介しております。
基本設計・詳細設計とは？仕様書との違いは？企業の設計課題を解決する方法
https://products.sint.co.jp/ober/blog/basic-design-detailed-design
外部設計書と内部設計書の違い
外部設計と内部設計の違いについて確認していきましょう。
外部設計と内部設計の大きな違いは、ユーザー、クライアントから見える部分を設計するか、見えない部分を設計するかという点です。
外部設計とは、ユーザーが直接関わる部分の設計を指します。ユーザーが直接関わる部分というのは、画面の操作であったり、システムの直接的な機能だったりといった部分です。クライアントが要件定義としてシステムに求めてくる事項があります。それらのほとんどは外部設計に該当します。
そのため、外部設計はユーザービリティを優先する必要があります。外部設計の良し悪しでユーザーの評価が大きく変わってくるため、ユーザーのことをよく考えて設計しなくてはいけません。
対して内部設計は、システム内部の詳細な設計のことです。システム内部とは、データ処理や初期値の定義などです。どのような内部設計を行おうと、システムの内容は変わらないのでクライアントに対しての影響はほぼありません。
しかし、開発メンバーの負担を軽減するためには内部設計をする必要があります。プログラミングをするための内部構造などを決定するのも内部設計に該当するのですが、これがしやすいのかどうかは保守・メンテナンスにおいて大きな差があります。
内部設計を何も考えずに決定してしまうと、いざというときにメンテナンスが行いづらくなってしまいます。クライアントが利用しているシステムであっても、自分の会社が提供していることに変わりはないので、しっかりとメンテナンスは行わなくてはいけません。
メンテナンスの負担軽減のため、内部設計を工夫しているのです。
外部設計と内部設計の違いについて、作業内容や範囲も大きく異なるのですが、誰のために設計を行うのかという点が挙げられます。外部設計はユーザーのために行う設計であるのに対して、内部設計は開発メンバーのために行う設計です。
外部設計書の書き方ポイント
作成時の前提条件
要件定義を経て、外部設計（基本設計）フェーズに入っていきます。ここでは外部設計作成時のポイントを解説いたします。
まずは以下の前提条件を把握しましょう。
要件定義との整合性
基本設計で決めた事柄は、その後の全工程に絡んできます。
成果物が要件定義の内容とかけ離れていては本末転倒です。基本設計の段階で、「要件定義の項目を満たしているか」を注意深くチェックする必要があります。
実現可能なシステムとなっているか
要件定義でヒアリングした内容を設計書に落とし込んでいくのが基本設計フェーズです。
クライアントの「理想」を実際のシステム開発で「現実」にできなくては意味がありません。クライアントの希望はできる限り盛り込むべきですが、システムとして実現できるかどうかの線引きはしっかりと行うべきです。仕様書を作成する段階から、この点について意識しておくことが大切です。
クライアントにとって分かりやすくなっているか
基本設計はシステム開発の根幹を固めていく作業であるため、クライアント側も理解できる内容になっている必要があります。
開発工程がかなり進んだ後で「自分たちの希望とかけ離れている」と指摘した場合、修正にはかなりの手間が掛かってしまいます。開発側だけでなく、顧客側にも大きな損害が出てしまうことでしょう。基本設計フェーズの段階でも、クライアントと綿密な意思疎通を図っていくことが大切です。担当エンジニアは間に立って上手く立ち回る必要があります。
外部設計書の書き方
業務フローの明確化
クライアント（ユーザー）が実際に行う業務内容を想定し、その流れを図で表現していきます。業務フローはシンプル・明確であることが望ましいとされています。
複雑化しすぎるとクライアントが理解しにくいだけでなく、システムとしての実現も難易度は高くなってしまいます。
システム構成図を作る
システムにおける、ハードウェア・ソフトウェア・ネットワークなどの構成図をそれぞれ作成する必要があります。ソフトウェア構成では使用OSやミドルウェアの詳細等、ハードウェア構成ではルータやスイッチ等を明確に記述していきます。
機能一覧表の作成
ここでいう機能とは、「開発の対象となっている機能」のことです。満たすべき機能要件を一覧化することで、開発担当のエンジニアが作業内容を把握しやすくなります。
非機能要件もまとめる
クライアントの業務内容に直接は影響しない非機能要件についても、基本設計書でまとめていきます。そのシステムを継続的に使用することになる側にとっては、セキュリティ面・スピード面なども大切な要素です。
5.3 外部設計書作成時のポイント
ドキュメントは作りすぎない
基本設計によって「基本設計書」が作られますが、ドキュメントを生産し過ぎてしまうことにも注意が必要です。全ての書類がしっかりとメンテナンスされているなら問題ありませんが、誤った情報が含まれていると開発フローに支障を来します。
求められるのはドキュメントの質であり、量ではありません。
どの程度生産するかはクライアントとの折衝で判断していくべきでしょう。
図表や数式表現をうまく使う
基本設計書は、顧客・エンジニア問わず多くの関係者が目にすることになるドキュメントです。文章ばかりだと理解に苦労するほか、仕様に誤解が生じてしまうことも考えられます。
開発を担うエンジニアにとっては、テキストよりも数式表現を使ったほうが作業する上でも負担が減るでしょう。
設計する側にも技術力は求められる
基本設計書は、後工程のエンジニアが実装を行なう際に欠かせない書類です。
なので、技術者がそれを利用するという前提で作成していくことになります。
設計側にもある程度の技術力は必要です。
上流工程を担うのは主にSEですが、SEも社内研修でIT技術の習得を行なう場合が殆どです。要件定義をメインに行うエンジニアはある意味「コンサル 」といえるものの、エンジニア要素もやはり関係してくることになります。
まとめ
外部設計書と内部設計書の違いについてご紹介いたしました。どちらもシステム設計という点は同じですが、業務の範囲やターゲットが異なるという点に注意しましょう。
システム開発とは、要件定義でクライアントの求めている機能を引き出し、それを外部設計で形にして、内部設計でシステムの作り方を考えることを意味します。
設計段階で十分に時間をかけることは、その後のプログラミング作業を素早く正確に行うために重要です。どちらの範囲に含まれるかということよりも、一つ一つの項目の目的を理解し、質の良い製作物をつくるために良い設計をすることが大切です。
設計書の品質を向上するにはツール導入もおすすめです。SI Object Browser Designerのようなツールを導入して、設計書の品質向上を目指しましょう。
