"設計"とは

「モノ（プログラム）作りが好きだ」と言う人の大半が、おそらくは設計(あるいはドキュメンテーション)が嫌いか、もしくは興味がないのかもしれません。

私の身の回りにいたエンジニアの大半も、やはり設計やテストより「プログラミングが好き」という人が多かったように思います。

しかし、ソフトウェア開発に限って言えば、本来モノ作りの"モノ"とは設計工程で既に完成しているものであり、プログラムはそれをプログラム言語に翻訳し、組み上げているだけでしかありません。これは設計書を描く／描かないとは関係しません。

仮に直接プログラミングを始める人であっても、何も考えずに行き当たりばったりでプログラミングはしません。必ず頭の中で「どう作るか？」を考えながら、整理したものをプログラム化しているはずです。これは単純に設計書を描いていないと言うだけで、設計していることとほぼ同義なのです。

つまり、モノ（プログラム）作りが好きな人にとって、嫌いなのは

　「設計書を作る」

ことであって、設計すること自身が嫌いなわけではないのです。もし設計そのものが嫌いで、設計すらできない程度のスキルしかなければ、おそらくはプログラミングすることすらおぼつかないことでしょう。

さて。
そんな設計工程ですが、国や企業、団体等によって多少呼び方は異なるものの、大別すると

　基本設計と詳細設計

に分類されます。まぁ別に外部設計と内部設計でもかまいません。昔から踏襲された呼び方なので、実のところ現代のあり方とは合致しません…が、致し方ありません。

要件定義工程が、システム開発における、お客さまの「こんなものが欲しいんだよね～」という"ニーズ"をまとめる工程とすると、設計工程はどちらもそのお客さまの"ニーズ"を具体的にどう実現するかを整理する工程となります。

似ているところ
　どちらも設計作業（作るモノのレシピを考える作業）です。

違うところ
　"何"を設計するかが違います。

これはＶ字開発モデルを利用すれば、視覚的にわかりやすいかと思います。

関連する前後の工程がよく分かります。

それぞれ前工程の成果物を基に、後工程の入力となるものを作ればよいということになります。裏を返すと、基本設計書に単体試験の入力となるような内容は書かないということが言えます。

図ではＶ字モデルをベースにしてはいるものの、厳密にはウォーターフォール型かどうか、アジャイル型かどうかなどの開発手法とは関係ありません。どんな開発手法でも呼び方や進め方にほんの少し差があるだけで、この本質

　「テストの工程数は設計の工程数と同数」
　「テスト（答え合わせ）を行う源流は設計でなければならない」

は同じです。

もう少し具体的にするために、各工程に関わるステークホルダー（利害関係者）を追加してみましょう。

各責任領域は体制や契約によって変わると思いますが、通常の場合、各工程／各作業には主担当がいます。そして、前工程の担当者は後工程で作られたものが正しいことをレビューする責任があります。上記の場合、要件定義工程を責任領域としていたユーザーは、基本設計工程にて

　「本当に要望した機能が実装されているか」
　「要求が実現できるイメージが固まったか」

といった観点で基本設計書をレビューすることになります。そういった事情から、基本設計書はユーザーが理解できる内容でなければならないことが分かります。

これを証明するように、もう少し掘り下げてみましょう。

では、どのような内容であればユーザーが理解できるのでしょう？
必ずしも、ユーザーの現行知識だけで理解できなければならないわけではありません。ソフトウェア開発では様々な図（ダイアグラム）を用いたりすることがありますが、中には簡単な説明だけでユーザーでも読めるものは数多くあります。

考えてもみてください。

たとえば、建築の製図なんかも購買者の現行知識だけで全て読めるようになっているでしょうか。

たとえばこれは二級建築士の製図試験などで使われるレベルの図です。半分くらいはわかった気になりますが、細かい記号や数字が何を言っているのかまではその場で説明を受けないとわかりませんよね。このレベルでいいのです。

そもそも、ユーザーが利用者となる一般的なシステムであれば、ユーザーとシステムの関わりを示すのに"ロバストネス図"で分析することが可能です。

たとえば、ある注文を受けて、その注文内容を登録するという業務システムの場合は以下のようになります。

このことから、ユーザーは「バウンダリ(boundary)」を通じてシステムと関わることが分かります。「バウンダリ」とは「境界」のことなので、ユーザーはシステム境界の外側にいる、ということを理解することになります。というか、ユーザーにとっては内側のプログラムの細かい動きなんてわかりません。

つまり、基本設計かそれに類する設計（外部設計等）は、『バウンダリとして、システム境界の外側に見える部分』について書くということが分かります。

一方で、詳細設計書はシステム境界の内側について書くということになりそうです。外側に対してバウンダリがどのような見せ方をするかが決まれば、そのようにプログラムが動くためには、どう処理するべきかのロジックが見えてくるんですね。ここまでくると、ユーザーにはちんぷんかんぷんだと思います。あくまでエンジニアとプログラマーの間でコミュニケーションが成立すればよい設計ということになります（ゆえに、内部設計ともよばれるわけですが）。そうして、ロバストネス図に登場したコントロールやエンティティを、シーケンス図や ER 図などに噛み砕いていけばいい、ということが見えてきます。

このように考えると、「基本」「詳細」ではなく「外部」「内部」と呼ぶ方が適切に思えますが、これらは相反する概念ではなく、本来は直交する考え方です。

システムの規模が非常に大きい場合、外部設計、内部設計という括りだけでは対象が大き過ぎて全体を把握できないため、それぞれ基本設計、詳細設計に分ける、が正しいようです。つまりは

というイメージでしょうか。システムの規模がそこまで大きくない場合は、外部設計、内部設計だけでよいということにもなります。

また、よく分からないものについて考えるときに、取っ掛かりとして 5W1H で考えてみるのは定石です。言うまでもありませんが 5W1H とは

• WHEN (いつ)
• WHERE (どこで)
• WHO (だれが)
• WHAT (なにを)
• WHY (なぜ)
• HOW (どのように)

です。このうち、WHEN と WHO はステークホルダーを追加したV字モデルで明らかにできていると思います。WHERE はソフトウェアだけに絞ればあまり関係なさそうなので、残りの WHAT、WHY、HOW について考えてみましょう。

設計における WHAT

「なにを」設計するのかはもちろんですが、設計対象が「なにか」を記述することであると考えると、設計という作業そのもの と言えます。

設計対象が「なにか」を明らかにするためには、設計対象の名前、振る舞いなどを記述すればよさそうです。

名前は、各ドキュメントで一意になる ID と論理名をペアで付与してやればよいでしょう。論理名だけでは、表記が揺れて各ドキュメントを関連付けられなくなる恐れがあります。

設計における WHY

「なぜ」そのように設計しているのか、背景や制約、方針を記述することであり、設計根拠の妥当性を判断する重要な情報 になります。

その設計対象が必要である理由を簡潔に記述し、なんらかの制約や設計判断があった場合は参考情報として書き留めておくと、なにかトラブルがあった際に役に立つはずです。

また、この情報によって、設計担当者の口頭による補足が必要なくなり、設計書レビューの速度と精度、および後工程の品質が向上します。そもそも口頭による補足などはトレーサビリティが担保できないため、原則禁止事項です。

設計における HOW

WHAT で定めた設計対象の振る舞いを「どのように」実現するのか記述すると考えると、ロバストネスと図やシーケンス図、クラス図などを活用して、設計対象と関連する要素を記述すればよさそうなことがわかります。

ここで注意しなければならないのは 後工程の HOW に踏み込まない ということです。基本設計書や詳細設計書に具体的な処理手順や SQL を書く例をよく目にしますが、以下のような問題の原因となります。

　・責任領域があいまいになる
　・設計と実装が重複し、いずれ乖離する → 修正時のコストが肥大化する

「具体的な処理手順や SQL を書かないと細かい仕様が伝わらないのではないか」という主張をよく耳にしますが、WHAT で入出力の組み合わせを網羅的に定めていれば、テスト時に漏れなく確認はできますし、その心配はないはずです。

こういう主張は、そもそも"何を作るか"よりも、"どう作るか"ばかり考えてしまいがちなプログラマー脳の人によく見られる傾向です。本当にお客さまの視点に立って提案できるエンジニア(？)であれば、そういう考え方はしません。

そもそも、基本設計や詳細設計と言うコトバ自体があいまいなものですので、これを一般用語として踏襲していること自体に問題があります。このことはＩＰＡが定める共通フレーム2007でも定義されています（最新版は2013）。

また、「設計書」という言葉には、どこか「組み立て説明書」のような印象があり、具体的な処理手順を書くものと誤解しやすくなっていると思います。

工程や成果物の名称はただの飾りであり、その内容こそが重要であることは言うまでもありません。今までなんとなくで進めてきた開発手法は

　本当に正しい選択だったのですか？
　一度も問題は起きなかったのですか？
　トラブルに発展したチームはいませんでしたか？
　どんなプロジェクトでもそのまま適用できるものですか？

仕組みとしてテンプレート化、フレームワーク化するのは、効率という面から見ても、品質という面から見ても良いことだとは思います。ですが、テンプレートもフレームワークも、多くのベストプラクティスから汎化されたものである以上、すべてのプロジェクトにそのまま当てはまるかどうかは別です。参考になりこそすれ、そのまま丸写しすればいい回答というわけではないのです。

本質的な部分から目を背けず、

　・設計工程とはどうあるべきなのか
　・基本設計や詳細設計ではどのような検討が必要なのか

を、もう一度しっかりとソフトウェア開発活動の中で定めるべきではないでしょうか。

設計工程が

　・何のために存在しているのか
　・存在させなかった場合の不具合に対してすべて責任を持てるのか
　・何を記載するのがよいことなのか
　・何に対してよいことであればいいのか

など、考えるべきことはたくさんありますよね。