メリークリスマスでした。
が、こちらのアドベントカレンダーは続きます。
12/30頃にクローズ予定です。
年末で忙しいと思いますが、投稿の余裕がある方はぜひ！楽しみにしています。

はじめに

この記事を読んだらどうなる

設計書を管理する新人が、
設計の存在意義を理解するようになる

...ことを願いつつ書いてまいります

前提

システム開発における設計についてまとめています。
そこで想定しているのは、
開発手法:ウォーターフォール (アジャイル等ではなく)
開発対象：アプリケーション (インフラ等ではなく)

まず、システム開発とはどういうものか

設計書は何かを達成するためのツール、手段だと捉えます。その目的を達成できるなら、正直設計書ではない別の方法に乗り換えてもよいのです。では、設計書はどのような目的を達成することを期待されているのでしょうか。そして、それを設計書はどのように達成していくのでしょうか。

設計書はシステム開発のためのツールのようです。
(一生開発する気ゼロのプロジェクトに設計書はあるでしょうか。)

それではシステム開発を理解する必要がありそうです。
まず、システムとは。システムの構成要素を見てみると、以下のスタック通りです。
ちなみに開発後には、移行や運用も起きます。

システム開発は、それぞれの図の四角の部分を開発、調達します。

では、設計とは

設計は何のためか　その役割

設計は要件定義のアウトプットをもとに行い、成果物は実装のインプットとなります。
(開発方法がウォーターフォールであることを思い出してください)

イメージ図

たとえば、よくある要件定義のアウトプットには以下が挙げられます。

ユースケース分析
概念モデリング
非機能要件定義

この要件定義から開発の間にある設計をすっ飛ばしてはいけないのでしょうか？
設計の必要性を考えるために思考実験もどきを挟みたいと思います。

絶対に設計してはいけない24時でシステムの開発・運用をするとします。
設計すると即座に罰が与えられる世界。
その世界で、ユーザーが頭の中に思い描くアプリを受注者は作ることができるか?
プログラマは何に基づいてプログラミングをするのか。できるのか?
保守、運用担当者はどうやってプログラムを理解し、修正or機能追加するのか?

プログラマが敏腕だったり、ユーザーとコミュニケーションが上手くとれたら良いかもしれません。一方、これが現実として難しいこともあります。また、保守・運用担当者がアプリの仕様をちゃんと理解できたらいいですが、開発に参加していない場合もあります。そうなると、運用時に修正などをする際、他人のコードを読み、修正箇所などを考えることになります。コードより自然言語でまとまってたらいいなと思うかもしれません。

設計があった方が品質や効率の点でよい場合がありそうです。

つまり、設計により達成したい目的には
開発関係者がシステムがどういうものかについて把握する
開発終了後の保守開発や機能拡張の際に参照される
が挙げられます。

ちなみに、
要件定義で詰められていない外部仕様があれば設計でカバーすることがあります。

設計とは何か　その実体

設計のトレーサビリティ

設計には、要件からのトレーサビリティが必要です。
トレーサビリティとは、要件→要件を実現するための機能→その機能を実装する方法
とつながっているということです。

このトレーサビリティができているかチェックするために、目の前の設計は、どの要件を満たすためのものか？をチェックするとよいでしょう。

設計の種類

さらに設計にも種類があります。
ここでは外部設計、内部設計を扱います。

外部設計
何のためのものか？：外部仕様を設計する。外部仕様とは、ユーザーや外部システムにとって、システムがどんな機能をもたらしてくれるか？の仕様。あるいは、システムの視点でとらえると、システムの入力と出力を明確にすること。
この仕様は業務や業界のやり方に沿っていなければならず、そこで業界知識が求められます。例えば、商品配送システムの場合。一般の小売業界だと、発注→配送という順序が通常です。しかし、物流倉庫会社だと、発注なしで配送するケースがあります。相手が得意先の場合など。このように、要件定義と外部設計のためには業界知識が必要となることがあります。

具体的には？：

画面設計
(→画面モックアップ、画面遷移図、画面入力チェック仕様書etc.)
外部システムI/F設計
バッチ設計
帳票設計
データベース論理設計
※括弧内はドキュメント

内部設計
何のためののものか？：
入力と出力の間で行う内部処理を設計します。

具体的には？：

画面プログラム設計(→Controller設計書)
ビジネスロジックプログラム設計
データベースプログラム設計(→エンティティクラス図, CRUD設計書)
データベース物理設計(→物理ER図、テーブル定義書)

以上、外部設計･内部設計をシステムの構成要素で対応付けるとこのようになっています。
入力と出力ー外部設計　処理ー内部設計

さて、設計はドキュメントを通して表現し、管理していくことが多いようです。(ウォーターフォール型では)
既に先ほどちらっと出ましたが、設計書の概念を整理します。

設計書の種類

ただし、各設計書の作成されるフェーズはプロジェクトごとに異なることがある。
種類が多いので、個別の設計書は別の記事で扱いたいと思います。
~~サラミ出版じゃないです(震え声)~~

参考書籍

『はじめての設計をやり抜くための本第二版』
『エンジニアなら知っておきたいシステム設計とドキュメント』