システム構築をする際に、結構やっかいなのは用語の煩雑さである。同じものを指すのに違う用語があったり、その逆に同じ単語でも会社や人によって違う意味で使っていたりする。

 特に煩雑な用語が「設計書」である。「基本設計書と外部設計書と概要設計書はどこが違うのか」「詳細設計書と内部設計書は同じなのか」「仕様書と設計書は同じなのか、それとも違うのか」という質問をされたら読者はどう回答するだろうか。おそらく人によって回答はバラバラではないかと思う。

 いろいろな解釈や定義が人によってあるのは承知の上で、筆者は以下のように割り切っている。基本設計と外部設計は同じ意味。詳細設計と内部設計も同じ。概要設計はおそらく基本設計と同じような意味だが、個人的になじみが薄いのでこの用語はなるべく使わない。設計書はシステムを作るために開発前に作るもので、仕様書は完成したシステムがどのようなものかを記載する。

 この定義を前提に特に基本設計書(以下、設計書とする)について考えてみたい。設計書は要件定義書に記載された業務視点の要件を、システムの視点で書き直し、それを読めばシステムを作ることができるようにするものである。要件定義書が発注者(実際にシステムを使って業務を行うエンドユーザー)視点だとすれば、設計書は開発者(システム構築するITエンジニア)の視点で作られる資料だ。

 設計書の作成は請負契約の範囲内に入っていることが多い。そのためか、要件定義書はきちんと発注者がレビューを行うが、設計書のレビューは形式的になってしまうことが少なくない。設計書レビューが形式的になる別の理由として、「設計書は難しくてよく分からない」という声がある。設計書の役割と重要度は開発するシステムの規模や対象業務、あるいは開発手法や開発期間の長短、本番稼働後の維持管理の体制などによって違ってくる。

 大規模システムであれば多くの種類の設計書を高品質に作り、その変更管理も徹底的に行うべきである。逆に比較的小規模で、エンドユーザーの参画もある場合は「設計内容がエンドユーザーにも分かり、レビューが可能であるもの」を作るべきである。「納品物のための設計書」になってしまわないよう、発注者はどのような設計書をベンダーに作ってもらうのか、あるいは一緒に作るのか、議論すべきであろう。設計書の役割は文字通りどのようなシステムを作るのかを設計することにあるが、もう1つ、テストフェーズで不具合が出た場合に設計段階で問題があったかどうかのチェックに役立つ。

 「納品物のための設計書」ではそもそも作成段階でチェックが甘いことが多いので、テストで不具合の出る確率も高くなる。発注者が理解できる「身の丈に合った設計書」によって作成段階できちんとレビューし、設計ミスを極力なくすことが大切だ。

 開発手法が多様化し、開発期間が短縮する傾向に加え、情シス以外のユーザーの開発プロジェクトへの参加が増えている。こうした現状を踏まえ、設計書とはどうあるべきか、発注者とベンダーできちんと認識を共有することを推奨したい。

永井 昭弘(ながい あきひろ)
イントリーグ代表取締役社長兼CEO
日本IBMの金融担当SEを経て、ベンチャー系ITコンサルのイントリーグに参画、96年社長に就任。多数のIT案件のコーディネーションおよびコンサルティング、RFP作成支援などを手掛ける。著書に「RFP&提案書完全マニュアル」「事例で学ぶRFP作成術 実践マニュアル」(共に日経BP社)がある。