外部設計とは何か？外部設計書の項目と注意すべきポイントをやさしく解説

2019年11月5日2024年3月26日

外部設計と外部設計書の概要

外部設計とは、ソフトウェア開発プロジェクトの中で、開発しようとしているソフトウェアが持つべき機能や性能、システム全体の中での構成やシステムを外部から見たときのシステムの振る舞いや構成を定義する工程のことです^[1]飯村結香子 (著)、大森 久美子 (著)、西原 琢夫 (著)、川添 雄彦 (監修)『ずっと受けたかったソフトウェアエンジニアリングの新人研修 第3版 … Continue reading。
共通フレームでは「ソフトウェア方式設計」と呼ばれますが、この他「外部仕様」や「機能設計」などと呼ばれることがあります。

アメリカの建築家・ルイス・ヘンリー・サリヴァン（Louis Henry Sullivan）の言葉に、「形式は常に機能に従う。（form ever follows function. ）」というものがありますが^[2]ルイス・サリヴァン – Wikipedia、外部設計は「どのような機能が必要か？」をプロジェクト・チームで検討し、「それらの機能にはどのような画面が必要であり、システム全体としてどのような構成にしなければならないのか」を考えていく作業です。

外部設計の成果

外部設計を行うことで、プロジェクトは以下の状態になります^[3]共通フレーム、156頁をもとに一部表現を変更して掲載。。

• 外部設計書が作成されている
• 開発するシステムのインターフェースが定義されている
• 要件と外部設計との間に一貫性と追跡可能性が確立されている

外部設計書とは要件定義書と共に、顧客と開発者の両者がこれから開発するソフトウェアの全容を理解できるようにする文書です。
顧客から見れば、開発の最終成果物であるアプリケーションがどのようなものかを確認できる仕様書となります。
一方、開発者から見れば、実現可能な仕様であることを確認できていることと、次のフェーズである内部設計のベースを固めるための設計書になります。

外部設計の流れ

外部設計は以下の内容を明らかにすることで設計を進めていきます ^[4]共通フレーム、157～158頁をもとにソフトウェア方式設計を外部設計に変更して掲載。 。

• システム構造とコンポーネントの方式設計
• 各インターフェースの設計
• データベースの設計
• 文書化
• 結合テストのためのテスト要件の定義
• 外部設計の評価
• 外部設計の共同レビューの実施

これらの作業の中で作成されるのが、次に紹介する各種の文書です。

外部設計で作成する主な文書

外部設計で作成する主な文書を下記に挙げます。

画面設計

多くのアプリケーションでは、外部設計での主な作業は画面設計です。
全体の画面遷移、及び各画面の設計を行います。

画面遷移設計

画面遷移設計では、開発しようとしているソフトウェアの全体の画面遷移図を記載します。あくまでそのソフトウェアを操作した時にどのような画面遷移を行うのかを確認することが目的であるため、各画面名称と遷移が分かる簡単なもので構いません。

画面設計

画面設計とは、ソフトウェアの各画面について、画面を構成するコンポーネントのレイアウト、そして各コンポーネントの表示仕様、入力仕様、操作仕様を記載したもので、ワイヤーフレームとも呼ばれることがあります。
画面のデザインを行う必要はありませんが、顧客がこの設計書を見たときに、実際の画面をイメージでき、操作方法が分かるように記載して下さい。

ユーザビリティを重視する

画面設計を行うときに最も重要なことは、操作性を最優先に考えることです。
ソフトウェアの品質を決めるポイントはいくつかありますが、操作性は最も重要な要素とも言えます。
操作性の意味として下記の２つの考え方があり、バランスを取りながら画面仕様を作成していきます。

直感で分かる画面仕様

ユーザーはこれまで幾度となくソフトウェア製品の画面を操作しています。そのため、一般的によく使われている操作方法を採用することで、直感的に操作できる画面を作成することができます。
また、画面表示の連続性が失われると、ユーザーは何が起こったか分からなくなり混乱することがあります。
簡単な例では、表示の拡大、縮小を行う場合には、細かい単位で変更可能とし滑らかに動きを見せることでユーザーの思考が途切れなくなります。

操作に慣れてから使いやすい画面仕様

頻繁に使われる画面については、操作回数を減らす、操作時間を短くするなどを考慮して画面を作成します。
ユーザーは画面操作に慣れていても操作ミスを起こさないとも限りません。
そのため、操作ミスが起こりにくいコンポーネントの配置を考えます。
また、操作ミスが起こっても致命的な事が起きないような配慮も必要です。

機能設計

機能設計とは、ソフトウェアにどのような機能が必要なのかをまとめていく工程であり、最終的には機能設計書としてまとめられます。

ソフトウェアが持つ機能は、それを起動させるトリガーが必要です。
例えば、「ボタンをクリックしたら」「○○からの通知を受け取ったら」というような条件がトリガーにあたりますが、機能設計を行う場合には、そのトリガー単位でまとめると分かりやすい設計書になります。
その主なものを下記に挙げます。

画面操作の機能

多くの機能は画面操作によって起動します。
その場合は、画面設計の中に各画面が持つ機能を記載することで、画面仕様と機能仕様が連携した設計書を作成することができます。

外部入力を受けたときの機能

通信などの入力を受けたときに起動する機能がある場合は、その入力毎に機能をまとめます。

タイマーで起動する機能

バッチ動作の機能では、スケジューラーに登録することでタイマー起動となります。

入出力のファイルフォーマット

ファイルの入出力を持つアプリケーションは少なくありません。
各ファイルについて、データフォーマットと文字コードを定義します。
独自にデータフォーマットの設計を行う場合には、拡張性を持たせること、また、データ破損が検知できることが望ましいです。

他のソフトウェアとの接続

他のアプリケーションと連携する場合は、その接続仕様をまとめます。
受け渡しするデータの性質によっては、セキュリティの観点から暗号化通信が必要になることもあります。

レビューの重要性

ソフトウェア開発の各フェーズでレビューを行いますが、外部設計書のレビューが最も重要と言えます。
顧客、開発プロジェクトのメンバーで下記の観点についてレビューを実施します。

顧客の理解と承認

開発するアプリケーションの仕様について顧客から承認をもらいます。
ここで大事なのは、外部設計書を開発者視点ではなく顧客視点で書くことです。
また、レビューのときの説明についても、ソフトウェア開発特有の用語は使わず、顧客に分かりやすい説明をします。

設計の網羅性

要件定義書に記載されている事項すべてが設計されていることを確認します。
重要な要件に対して設計漏れがあった場合、最終的にアプリケーションの致命的な欠陥になってしまいます。

仕様の不整合がないこと

大規模な開発の場合には、外部設計だけでも月単位の期間が必要になることもあります。
設計の時間差や設計の途中変更、担当者が違うことなどから、全体仕様の不整合が起こっている可能性もあります。
外部設計のレビューで仕様の不整合がないことも確認します。

実現の可能性

外部設計書で顧客の承認を得ても、実現できない仕様であれば、開発フェーズのどこかで問題が発生します。
通常、外部設計のときには開発で使うプラットフォームは決まっているはずですので、レビューのときに実現可能かという視点でも確認します。

未決定事項の管理

外部設計のフェーズで、すべての仕様が決定されるとは限りません。
何らかの理由で、外部設計フェーズ完了時に未決定の部分が残ることもあります。
その場合には、外部設計書に未決定事項を記載しておき、開発スケジュールの中に各未決定事項の対応をタスクとして入れておきます。