設計書の書き方には絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなる。標準の設計フォームや設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。

松田 陽人（まつだ・はると）
システム・エンジニア

　一般によく言われることだが，設計書の書き方には「正解」や「こうしなければならない」という絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなり，完成した設計書の内容と質は設計者ごとに大きく異なる――といった結果に陥りやすい。

　もちろん，標準の設計フォーム（ひな型）や設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。一番怖いのは，「設計書は何のために存在しているのか」という点を設計者がうっかり忘れているか，そもそも意識していない場合である。

　筆者が考える設計書は，システム構築を目的としたコミュニケーションの「ツール」であり，そのコミュニケーションの「結果」を記述したものだ。設計書を作成する上で，標準化や定型化にとらわれ過ぎてしまうと，設計書を「何のために作るのか」という根本的かつ重要な情報が抜け落ちやすくなる。「とりあえず標準に沿って作成すればよい」という設計者の態度は，後の工程でトラブルを生む原因になりかねない。

　そこで本連載では，「意図が伝わる設計書」の書き方について，筆者が日ごろ感じているポイントを紹介していきたい。これは「読みやすい文章を書く」ということより，むしろ設計者の基本的な心得に依存するものと言えるだろう。分かっているようでも，トラブルを経験しないと本当に理解できないような注意点を，筆者の身近に起こった実例を通して紹介する。

　前述した通り，設計書の書き方には唯一の正解はないため，すべての内容に同意を得られるとは考えていない。しかし，設計書の書き方を見つめ直すきっかけとなり，標準フォームやガイドラインの改良，設計者の気づきを通じて，より良い設計書が生まれれば幸いである。

ユーザー，プログラマとのコミュニケーション

　改解説を始める前に，連載で論議する設計書を明確にしておきたい。「設計書」という言葉が，様々な意味合いで使われているからだ。混乱を避けるため，二つの設計書に的を絞ろうと思う（図1）。

　一つ目の設計書として，「ユーザーとの仕様策定時に作成する設計書」を連載前半の題材とする。提案や要件定義の結果，構築するシステムの全容が見えてきても，この時点のシステム仕様は骨組み程度である。このまま開発作業に入れることは少なく，プロジェクトは設計工程を通じて再度全体を見渡しながら，ユーザーと詳細な仕様の打ち合わせをすることになる。

　このとき作成される設計書の呼び名は開発現場によって異なるだろうが，ここでは「基本設計書」と呼ぶことにする。その内容については，ユーザーの要望をより深く理解して仕様にまとめたものであると同時に，「要望をシステムがどのように実現するのか」をユーザーに理解してもらうための資料であるとする。

　二つ目の設計書として，「開発工程でプログラマが参照する設計書」を連載後半で取り上げる。ここでは「仕様書」と呼ぶことにする。設計者からプログラマに向けて純粋にプログラミングに必要な技術仕様を提供するものである。

図1●二つの設計書の位置づけ
図1●二つの設計書の位置づけ
本連載で取り上げるのは「基本設計書」と「仕様書」の二つ。これら設計書の呼び方や内容は開発現場によって様々だが，ここでは上記のような目的を持った設計書とする

なぜ設計書の意図が伝わらないのか？

　さて，ここからが本題である。設計書を作成する際に起こりがちな問題を通して，設計者としての心得を考えていきたい。第１回のテーマは，基本設計書の「行き過ぎた技術志向」を取り上げる。

　システムを設計するに当たり，ユーザーからの要望の出かたは様々である。ユーザーがシステムの作り方を十分理解している場合（SIベンダーがユーザー企業のシステム部門を相手にする場合を含む）もあれば，システムに疎い場合もあり，状況はプロジェクトごとに大きく異なる。設計者は，こうした状況の違いに合わせて，基本設計書の表現手法や説明の深さなどを工夫する必要がある。

　特に注意すべき点の一つは，「技術的な説明をどこまで詳しくするか」というさじ加減だ。例えばシステムに疎いユーザーに，技術色の強すぎる基本設計書を作成してしまったとしよう。ユーザーによっては「よく分からないが，なんとなく理解したつもり」といったトラブルの種を植え付けることになる。開発がかなり進んだ時点で，「実はそういう意味ではなかった」となれば，プロジェクトの先行きが一気に暗くなってしまう。

　以下に紹介する二つの実例は，いずれもITに対するユーザーの理解がそれほど深くない状況で，技術的な設計を優先させたために起こったトラブルだ。これらの例を通して，「なぜ基本設計書の意図が伝わらなかったのか」を考えてみたい。