理想の設計書フォーマットを考える

 2023.02.10  株式会社システムインテグレータ

理想の設計書フォーマットとは?

さて、今回はスバリ「理想の設計書フォーマット」について考えてみたいと思います。おそらくこの業界で永遠に議論されるテーマではないかと思います。IT業界の設計書はWordやExcelというワープロソフト主流で作られてきた半面、会社や部署、案件ごとに設計書のフォーマットがバラバラであることが現実です。「設計品質が悪いほどトータルコストも肥大化する」とよく言われますが、所属する案件が変わるだけでも、新しい設計書フォーマットの読み方や作り方を覚えなければならないわけですから、明らかに品質にも悪影響を与えます。この課題を解決するために、時には会社単位で設計標準化プロジェクトを立ち上げて設計書テンプレートを作るようなこともされる企業も多くありますが、いざ現場で使おうとすると情報が足りない(あるいは過剰)とか、わかりにくいという理由で書き換えられてしまい、バラバラに戻ってしまうのが実情でしょう。

このような事実も踏まえれば、「理想の設計書フォーマットはない」というのが結論です。これも業界では定説とも言われますが、これで終わってしまうと身も蓋もないので、もう少し踏み込んで、「なぜ設計書フォーマットはバラバラになってしまうのか?」について考えてみたいと思います。その理由には大きく以下の3点があると考えています。

1.目的

一番の大きな要素はやはり「なんのためにその設計書を作るのか?」という点ではないでしょうか。設計書と一言に行っても、

・対象システムは汎用パッケージなのか、特定ユーザー向けの業務アプリケーションなのか?
・新規開発なのか、バージョンアップなのか?
・製造前に作るのか(ウォーターフォール型)、繰り返し(スパイラル型)で作るのか?
・設計書を渡す手はプログラマなのか、顧客なのか?
など、背景やシーンはバラバラです。これらのシーンにより当然求められる内容も大きく変わります。プログラマに向けであればプログラムにかかわる内部処理を詳しく書かなければならないですし、エンドユーザー向けであれば、外部仕様に重点を置くべきでしょう。

2.読み手の属性(人数・場所・知識等)

また、目的が「プログラマ向け」と一言で言っても、読み手となるプログラマが対象のシステムを長年携わっているベテランであれば、「○○画面にある○○機能を○○画面にも実装する」程度の記述で済むかもしれません。しかし、未経験のプログラマであれば、当然これだけの情報では理解できず、詳しい説明が必要になります。また、同じオフィス内に設計チームとプログラムチームがいて、人数も少なければ口頭のコミュニケーションで補足することができますが、人数が多くて口頭だけでは共有が難しくなります。また、拠点が離れていれば、コミュニケーション効率が落ちてしまいますので、できるだけ細かな事項も設計書内に記述しておく方がベターです。このように読み手の力量や人数、場所などにより設計書の粒度(レベル)も大きく変わります。 

3.他ドキュメントの存在

もう1つ忘れてはならないのは設計書以外のドキュメントのカバー度合でしょう。例えば、要件定義フェーズで業務フローが定義済なのか?基幹システムと連携するとすれば、基幹システムのドキュメントで取込インタフェースの仕様が記述されているのか?などです。もしこれらのドキュメントがなければ記載する必要がありますし、ドキュメントがあるのに設計書にも書くのは非効率です。

これらの要素によって必要なドキュメント体系や粒度が変わってくるものだと考えます。ドキュメント体系とは「画面レイアウト定義書」、「ロジック設計書」「クラス定義書」などの設計書の種類、粒度とは、「画面レイアウトイメージだけでなく、個々のテキストボックスなどの項目仕様も書くのか」や「画面単位で書くのか、さらにクラス単位に分けて書くのか」などです。

図1.求められる設計書の考え方

図1.求められる設計書の考え方

これらの関係を表したのが図1になります。少し大ざっぱですが、「目的」が「ドキュメント体系」、「読み手の属性」が「粒度」に大きく影響すると考え(相互にも影響を与えます)、この2つを掛け合わせた範囲に「その他ドキュメントのカバー範囲」を除いた部分が、求められる設計書像となります。

lights.png「基本(外部)設計書」と「詳細(内部)設計書」の住み分けについて
「基本設計書(外部設計書)」「詳細設計書(内部設計書)」をそれぞれどこまで書くべきか?という議論もありますが、これも絶対の正解はなく、今回挙げたような目的などの要素で正解が異なってくると思います。

また、図2のようにこれらの要素は案件によってバラバラのため、自社内であっても設計書の統一は難しいものと思います。しかし、要素の組み合わせごとにパターンを分類することで、複数パターンでの標準化パターン化なら可能そうに思えます。このように自社の案件パターンを整理し、パターンごとに標準化することが、理想の設計ではないでしょうか。

図2.求められる設計書は案件ごとにバラバラだが…

図2.求められる設計書は案件ごとにバラバラだが…


RELATED POST関連記事


RECENT POST「コラム」の最新記事


コラム

システム開発の手法とは?ウォーターフォールとアジャイル開発との違い

コラム

これからのソフトウェア設計書に求められる書き方とは?

コラム

システム開発手順について押さえるべきポイント

コラム

設計工程って本当に必要なの?

理想の設計書フォーマットを考える
新規CTA