参考URL：https://pixabay.com/

技術職では実際に作り始める前に必ず設計を行います。これはIT業界でも例外ではなく、何かシステムを作る際には必ず最初に設計を行います。しかし、設計と一言に言ってもいくつか設計の種類があり、それぞれの役割は異なります。

そこで今回は、アプリケーション開発における設計の種類とその役割について解説します。

設計の種類

IT業界でシステム開発を行っている方は、「基本設計」「詳細設計」に関してはよく耳にするかと思います。そして、開発案件によっては「パラメータ設計」というものも含まれます。

具体的にそれぞれの設計書をどのように作るのかは開発現場によって様々です。たとえばExcelに日本語のみで記載していく場合もあれば、一部コードを記述しつつまとめることもあります。

またExcelだけでなく、いまだに一太郎で設計書を作成する開発現場も存在します。このように設計書の中身や使用するツールは様々なのですが、各設計書は大まかな役割が決まっています。

大まかな役割はどの開発現場でも同じなので、知っておくと汎用的に役立ちます。

基本設計とは

まず基本設計とは、その名の通り開発の土台となる設計書のことです。システム開発は以下の流れで進みます。

要件定義→基本設計→詳細設計→開発→テスト

顧客との打ち合わせである要件定義で決まった内容を基に各システムの機能をまとめたものが基本設計になります。システムの全体概要は要件定義時にドキュメントでまとめることが多いのですが、それをシステムの各機能ベースにまで落とし込んだものが基本設計ということです。

ただし、基本設計の段階では細かいロジックまでは指定しません。たとえば、関数、戻り値、変数、ループの回数、どのロジックを呼び出すか、といったことは基本設計の段階では決めないのが通常です。

システム全体を各パーツに分け、それぞれのパーツでどのような処理を行ってほしいのかをざっくり記述したのが基本設計で、その基本設計を基に次の詳細設計を作っていきます。

詳細設計とは

詳細設計は、上で紹介した基本設計を基により詳細に設計していくものです。具体的には、そこで使用する関数、変数、戻り値、呼び出すロジック、処理したデータをどこに渡すのか、などを詳細に記述します。

記述方法も日本語ベースではありますが、実際にプログラミングしたものをExcel等に記載するケースも多いです。もちろんすべてのプログラムを詳細設計書に書いていたらキリがないので、たとえばクラス名や関数名だけそのまま詳細設計書に記載して、その内容に対しては日本語で言及するようなイメージです。

ソースコードはコメントで補足説明するのが一般的ですが、詳細設計書はコメントとソースコードの割合を逆にしたようなイメージです。ソースコードの重要な部分を一部記述して、それに対してコメントを充実させるようにします。

基本設計ではざっくりとここではどのような処理をしてほしいのか、を記述するだけでしたが、詳細設計は実装を意識して作り込むことがポイントになります。なので、詳細設計書がしっかり作り込まれていればプログラミングの作業は難しくありません。

詳細設計書にはロジックも記述するので、あとはそれを実現するための関数等を調べて書くだけになります。ただし実際の開発現場ではそううまくはいかず、詳細設計の通り実装しようとしても実現不可能だったりバグが発生したりすることが大半です。

本来は詳細設計書を基にプログラミングするのですが、結果的にプログラミングした結果を基に詳細設計書を修正することがかなり多いです。プログラミングした結果基本設計レベルで問題がある際には、プログラミングした結果を基に詳細設計書と基本設計書の両方を修正するパターンも多く、うまく工程ごとに進むことはむしろ稀と言えるでしょう。

パラメータ設計とは

パラメータ設計とは、テストを見越してデータのバラツキを決めるために作る設計書のことです。IT業界では主に組み込み式の製品で用いられることが多く、実際に製品を使用した結果をテストするためのものです。

パラメータ設計はもともとは最終的に製品を物理的に動かしてチェックするための役割が大きかったのですが、そこから派生してソフトレベルのチェックでも用いられることがあります。

IT業界の大半はソフトウェア開発なので、物理的なテストを行うことは稀です。そのためソフトウェアのテストでパラメータチェックが行われるのですが、その際のパラメータは意味合いが少し異なります。

というのも、物理的なテストではデータにバラツキが発生しますが、ソフトウェアのテストではデータにバラツキはありません。プログラミングした通りにしか出力されないので、実行するたびに結果が異なることなどありえないからです。

つまり、ソフトウェアのテストでパラメータ設計を行う際には、データのバラツキではなく単純に出力結果を予測したものをまとめます。いわば、テスト設計書の一部がパラメータ設計書になっています。

ソフトウェアのテストでは実行した結果や個々の処理が正しく行われているかチェックしますが、その際には入力した値と出力結果を見るのが一般的です。その出力結果というのがパラメータです。

パラメータ設計では最終的な出力結果だけでなく、プログラム実行の途中経過を切り出してデータを確認することもあります。最終的な実行結果が予想と一致していても、実は途中の処理が間違っていることもあるので注意が必要です。

処理を実行した結果どのようなデータが出力されるのかを予測してパラメータを設定しますが、テストした結果が予測と異なればバグが発生しています。このバグを修正するためにパラメータ設計書が存在します。

まとめ

簡単にまとめると以下のようになります。

・基本設計

要件定義を基にシステムの各パーツでどのような処理が必要かを日本語でまとめたもの。

・詳細設計

基本設計を基に重要なロジックをプログラミングベースで記載し、それに対して日本語で詳しく説明したもの。

・パラメータ設計

テストでの入力値と出力値の予測を記載したもの。

各開発現場によって設計書の役割はかなり違うことが多いのですが、定義上は上記のようになります。

それぞれの違い、理解しておきましょう！