詳細設計書は実装と結合テストのインプットとなる

プログラマ向けドキュメントを作成する工程は、詳細設計という名前で定義されます。この工程で作成される開発ドキュメントは、一般的に「詳細設計書」と呼ばれます。詳細設計書は、プログラムをどのように作ればよいかを記述するとともに、結合テストのインプットとなるように作成する必要があります。

規模の大きな開発の場合、詳細設計から多くのプログラマが追加され、いくつかのチームに分かれて作業します。基本設計で分割された単位が各チームに割り当てられ、次工程の実装も同じチームでそのまま作業することになります。各チームは、リーダ的存在となるプログラマ（以下、チーフプログラマ）のもと、担当部分をプログラムとして完成させることを目指して作業します。主に詳細設計書を作成するのはチーフプログラマの役割です。ここでは、チーフプログラマが詳細設計書を作成する上で重要となるポイントを3つに絞って説明します。

詳細設計書の3つのポイント

1つ目は「実装のルールを決め、それを説明する」ことです。チーフアーキテクトの役割を担う人がいれば、基本設計の段階で検討しておくことが望ましいのですが、そのような人がいない場合でも、チーフプログラマ同士が連携して作成しなければなりません。チームが分割されていても、チーフプログラマ同士の連携はとても大切です。特にウォーターフォールモデルの場合はリファクタリングをする機会が少ないため、後で「こうしたい」と思っても、改善は容易ではありません。後で自分たちが苦労しないためにも重要な作業ですので、しっかりと行い、詳細設計書に記述する必要があります（図2）。

2つ目は「実装視点で分割を行い、そのインターフェースを定義する」ことです。基本設計での分割は、外部に対する振る舞いの視点からのものですが、プログラマに作業を割り当てるためには、さらに実装の視点から分割する必要があります。基本設計のときと同様に「結合度を低く、凝集度は高く」なるように分割することができれば、プログラマ間の連携は最低限で済み、効率よくプログラミングが進みます。

また、結合したときに問題が起こらないようにそれぞれのインターフェースをしっかり決める必要があります。中身のコードが少々きたなくても、インターフェースの仕様を満たしていれば結合はできます。中身はもちろん大切なのですが、優先度はインターフェースの方が上です。オブジェクト指向言語では、言語仕様としてインターフェースが用意されています。先にインターフェースだけを実装してしまうことも効果的で、詳細設計書の一部としてもよいでしょう。

3つ目は「データベースに格納するデータの仕様を決める」ことです。データベースの論理設計に基づき、データをデータベースにどのように格納すればよいかを考えます。論理設計がよくできていると、それをそのままテーブルにすればよいと思ってしまいがちですが、問題が起こることがあります。

データベースを使うソフトウェアのパフォーマンスが悪い場合、そのほとんどはデータベースの設計に原因があります。例えばインデックスの設定を間違っただけで、パフォーマンスは数十倍も異なります。この段階から性能のことを考え、テーブルを設計しておく必要があるでしょう。

また、データベースの性能は本体だけの問題ではありません。プログラムから発行するSQLが不適切な場合もパフォーマンスが大きく低下します。この点に関しても、早い段階からルールを決めておく必要があります。詳細設計書はプログラムのことばかり書かれる傾向がありますが、データベースに関しても記述しなければなりません。 次のページ