みなさんは，外部設計書を誰に読んでもらい，理解してもらおうとして思って作成していますか？レビューしてもらう開発プロジェクトのリーダー向けですか，後工程でプログラミングを担当してもらう技術者向けですか，それとも自分のためですか？
もちろん外部設計書は，リーダーも読みますし，プログラミングを担当する技術者も見ます。しかし最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。上の質問に対して，「お客様」と自信を持って回答できることが，今の技術者に求められているのです。
外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。
とはいえこれまでは，「発注者に理解してもらう」という観点での外部設計の体系的なノウハウはほとんどありませんでした。そこで本連載では，発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。読んだその日からすぐに使えるノウハウばかりなので，ぜひ日々の設計作業に役立ててください。
外部設計書を介してシステム像の共通認識を持つ
外部設計書は，発注者（お客様，ユーザー企業）が挙げた要件をどんな情報システムとして実現するのかを，開発者（ベンダー）が明らかにし，まとめたものです。ほとんどの場合，標準化された表記方法を使って作成されます。
外部設計書を作成する外部設計工程は，発注者と開発者が「この仕様でソフトウエアの開発を進めてよいですね？」ということを相互に確認し合意する最後の段階です。従って外部設計工程では，開発者が外部設計書の内容を発注者にきちんと伝え，発注者にその内容を理解し納得してもらうことが必要です。また外部設計書は，開発者と発注者が意思疎通を図り，目的とするシステム像に関して共通認識を持って合意された内容になっていなければなりません。その努力を怠ると，後になってトラブルを招く元となってしまいます（図1）。
 |
| 図1●外部設計書に求められること 外部設計書を介して，開発者と発注者がシステム像に関する共通認識を持つ必要がある。 |
ところが，外部設計工程はたいてい「開発者主体の作業」なので，外部設計書も後続の作業であるソフトウエア開発を意識した「開発者の視点」で作成されることがほとんどです。外部設計書を「開発者の視点」で作成してしまうと，発注者が読んでもその内容を正確に理解することは容易ではありません。発注者は業務のプロではあっても，ソフトウエア開発のプロではないからです。
その結果，外部設計書の内容が発注者にうまく伝わらないまま，システム開発が進むことになります（図2）。そうなると，後の開発工程で仕様の抜けや誤りが発覚して修正に多大な工数がかかる，といったトラブルが起こりやすくなります。発注者側が出来上がったシステムを見て「こんなはずではなかった！」と不満を持つかもしれません。これでは技術者の苦労も報われないというものです。
発注者に外部設計書の意図を伝えるために，説明が不十分な事項を適宜補足説明しているプロジェクトも多いことでしょう。 しかし，この場合も「開発者の視点」で作成してしまうと，補足説明の資料作成に多大な工数がかかる割には発注者側にうまく伝えられず，期待していたほどには理解してもらえません。
 |
| 図2●発注者と開発者の意思疎通が図れないことによる弊害 |
