内部設計（詳細設計）とは何か？設計のヒントとあわせて解説
内部設計の概要
内部設計とは、開発するシステムが要件を満たし、安定した品質で開発を行うために、詳細な設計を行うことです。
内部設計は詳細設計とも呼ばれることもあり、IPAが刊行している共通フレームでいうソフトウェア詳細設計に該当します。
内部設計ではフロー図のような視覚的な記述をするだけでなく、プログラミング言語のように記述し、限りなくプログラムに近い設計を行うこともあります。
システム開発のVモデルに従うと、内部設計は外部設計の次のプロセスに該当します。
要件定義、外部設計のフェーズを経て、どのようなアプリケーションを作るのか明確になりました。
ここからプログラミングのための内部設計を始めますが、設計されるソフトウェア構造は様々です。
それは、どのような単位で構成するモジュールを作るか、というだけでなく、どのような思想を持って設計を行うか、という点が大きな要因となります。
一例ですが、開発期間の短いプロジェクトでは、複雑な構造とした場合には多くのバグが発生しスケジュール遅延のリスクがあるため、処理速度を多少犠牲にしても、シンプルな構造となるよう設計する、というケースもあります。
ソフトウェアに限らず、設計思想を持てるようになって初めて一流の設計者となれるのかもしれません。
内部設計の目的
内部設計の目的としては様々なものが挙げられますが、主な目的は以下の通りです。
- 開発したシステムを後から検証できるようにする
- 品質の安定したコーディング（プログラミング）ができるようにする
以下、詳しく見ていきましょう。
システムの検証
内部設計では、開発したシステムを検証できるようにしていきます。これは開発した後に検証作業が容易になるだけでなく、実際にコーディング作業を行う前にシステムのミスを発見し、品質を担保することにもつながります。
品質の安定したコーディング
内部設計を行う理由としては、コーディングの品質を安定させるというものも挙げられます。
細かな指示を与えることで、経験の少ないプログラマーが粗野なコーディングをするのを防ぐことができます。また、コーディングするプログラムを部品化させて再利用を可能にしたり、プログラムの結合を容易にしたりすることができます[1]飯村結香子 (著)、大森 久美子 (著)、西原 琢夫 (著)、川添 雄彦 (監修)『ずっと受けたかったソフトウェアエンジニアリングの新人研修 第3版 … Continue reading。
内部設計の成果
内部設計を行うことで、プロジェクトは以下の状態になります[2]共通フレーム2013、158頁の表現を一部変更して掲載。。
- 開発するシステムを構成する各コンポーネントの詳細設計が行われている
- 外部インターフェースが定義されている
- 一貫性及び追跡可能性が要件・外部設計・内部設計の間で確立されている
内部設計をする際のヒント
モジュールで分割して考える
内部設計では、システムのモジュール単位で考えていくのが一般的です。
モジュールとはソフトウェアを構成する部品（小さな単位のソフトウェア）のことです。
一般的なモジュール分割としては、「入力機能」、「処理機能」、「出力機能」とデータの流れに着目した分割方法があります。
モジュール分割を行うメリットとして下記があります。
- モジュール単位、その後にアプリケーション全体と、テストを段階的に実施することでテスト効率が上がる
- モジュール単位で、詳細設計、実装、単体テストを並行開発できるため開発スケジュールを短縮できる
- 独立性、汎用性の高いモジュールを設計することで、ソフトウェアの再利用に有効となる
- 保守については、保守の対象範囲を限定しやすくなる
作らない開発
ソフトウェアは新しく作ることで必ずバグも一緒に作り込むことになります。
そのため、プログラム構造、プログラムコードの無駄を無くすことで作り込むバグを減らすことができます。
そして、新しく作るプログラムを減らすのに最も効果的な方法はソフトウェア資産の流用です。
内部設計フェーズにおいて、どのようなモジュールが必要か明確になった段階で、流用できるソフトウェア資産を探してみます。
ソフトウェア資産をきちんと管理できている組織は少ないため、必要なモジュールを持っていると思われる開発チームに確認してみます。
何も手を加えずに使えるモジュールの入手は難しいとしても、多少の変更を行うことで流用できるモジュールが見つかれば、大きな収穫になります。
ただし、モジュールの流用は、まだ発見されていないバグも一緒に取り込む可能性があります。その点は注意しなければなりません。
エラー処理を設計する
ユーザーからの画面操作、読み込むファイルなど、アプリケーションの外部からの入力が適切でない場合が多くあります。
また、アプリケーション内部でのモジュール間の出力、入力であっても、ソフトウェアのバグによって異常なデータが受け渡されることもあります。
そして、アプリケーションの出力処理においても、ファイルが書き出せないなど正常に処理ができないことが起こりえます。
ソフトウェアにはエラー処理は必ず必要ですが、それを実装フェーズで対応しようとすると、どうしても抜け、漏れが出てしまいます。
したがって、内部設計フェーズで、エラー処理もきちんと設計することが大事なポイントです。
エラー処理の目的としては下記の２点があります。
- ユーザーにエラーが発生したこと、及びこの後の操作方法を知らせる
- 開発者に対して、ソフトウェアのどの部分で、どのようなエラーが発生したかを分かるようにする
（エラー処理の設計としては、エラーコードの定義、エラーメッセージのリソース管理、エラー表示の仕組み、エラーログ対応などがある）
保守を考えた設計
ソフトウェア開発は、リリースですべてが終わるわけではありません。ソフトウェアはリリース後にも動き続けなくてはならないからです。
リリース後には、顧客からの要望による機能変更、動作環境の変化に対する追従、バグの修正など、保守作業は必ず発生します。
ソフトウェアのコストとは、リリースまでの開発コストと、リリース後の保守コストの合算になるため、保守のしやすさを考えた設計が大事になります。
具体的にはモジュール分割も含めた、ソフトウェア構造の最適さが、保守作業に最も大きく影響します。
また、ソフトウェアの構造はプログラムコードを見ただけで理解するのは難しく、開発プロジェクトのメンバーではない保守担当者にも分かりやすい内部設計書を作成することが大事です。
効果的な設計レビュー
設計の品質を上げるのは簡単ではありません。
ソフトウェア開発の経験豊富な有識者による設計レビューを行い、その指摘事項をフィードバックすることにより設計書の品質を上げる方法が一般的です。
効果的なレビューを行うための大事なポイントは下記になります。
- 設計書がレビューを受けられる完成度に達していること
- レビュアーがレビューできるだけのスキルを持っていること
- レビュアーはレビュー対象の設計書を事前に確認すること
- 重要な指摘事項について設計書にフィードバックすること
逆に、効果が出ないレビューとしては、設計書の説明だけで終わってしまう、次の実装フェーズへ進めるための儀式になってしまう、細かい指摘ばかり大量に挙がる、などがあります。
設計書のブラックボックステスト
設計書の最終確認を行う手法としてブラックボックステストがあります。
通常、ブラックボックステストとは、各モジュール、アプリケーション全体に対して実施するものです。
また、内部設計フェーズでは、テストケースの作成はまだできていませんので、要件定義書にあるユースケースを使い、内部設計書に記載されているプログラム構造で処理の流れを確認してみます。
アプリケーションの入力から出力まで、設計書の上でデータ処理を追いかけることで、モジュールの機能は足りているか、モジュール間のインターフェースは問題ないか、のチェックができます。
美しい設計は実装せずとも動きが見えるように思えます。
このブラックボックステストについては、下記の記事でも解説していますので、ご参照ください。