- 設計書というのは、システムをどう作るかを文章や図でまとめた、開発の設計図にあたる文書のことだよ。
- いきなりコードを書き始めるのではなく、何をどんな仕組みで実現するかを先に決めておくための土台になる。
- 設計書の役割が分かると、開発の手戻りやチーム内の認識ズレがなぜ起きるのか、その構造が見えてきます。
【深掘り】これだけ知ってればOK！
家を建てるとき、設計図なしにいきなり木材を組み始める大工はいません。システム開発も同じで、何を・どんな構造で・どう動かすのかを事前に文書化したものが設計書です。建物の設計図がそうであるように、設計書は関係者の共通言語として機能します。発注者が求めるものと、開発者が作るものを一致させ、複数のエンジニアが分担しても全体の整合性を保つ。この認識を揃える働きこそ、設計書の核心です。口頭の合意だけで進めると、完成してから思っていたものと違うという悲劇が起こります。
設計書は通常、抽象度の違う段階に分かれます。利用者や発注者の視点で何を実現するかを描くのが基本設計、それをどう実装するかという開発者視点に落とし込むのが詳細設計です。基本設計では画面構成や機能の一覧、詳細設計ではデータベースの構造や処理の流れなど、技術的な中身を定めます。大きな絵から細部へと段階的に具体化していく流れだと捉えると分かりやすいでしょう。
現実の開発では、設計書のメンテナンスが追いつかず、実装と乖離していくケースが頻発します。古い設計書を信じて作業した結果、バグや手戻りが生まれるのは典型的な失敗です。一方で、近年のアジャイル開発では、分厚い設計書を作り込むより、動くソフトウェアと対話を重視する流れもあります。とはいえ、まったく設計しないわけではなく、必要な分だけ軽量に残すのが主流です。プロジェクトの規模や性質に応じて、どこまで設計書を作り込むかを見極める判断力が、現場では問われます。
よくある誤解
設計書は一度作れば変えないものだという誤解
完成させて固定する文書、というイメージは実態と合いません。開発中に仕様変更や新たな気づきは必ず生じます。そのたびに設計書を更新しないと、文書と実際のシステムがズレていき、かえって混乱のもとになります。生きた文書として保守し続ける姿勢が必要です。
設計書が詳しいほど良いプロジェクトという思い込み
文書が分厚く精緻であればあるほど良い、とは限りません。作り込みすぎた設計書は、書くのにも保守するのにも膨大な時間を奪います。変化の速いプロジェクトでは、過剰な設計がかえって足かせになることもあるのではないでしょうか。必要十分な粒度を見極めることが大切です。
会話での使われ方
実装に入る前に、基本設計書のこの画面遷移、認識合ってますか？ここがズレると後の詳細設計が全部やり直しになります。
プロジェクトマネージャーが設計レビューで、開発チームに確認を取っている場面です。
前任者の設計書が古くて、実際のコードと全然違うんですよ…どっちを信じればいいんですか。
保守を引き継いだ若手エンジニアが、先輩にSlackで愚痴まじりに相談しているトーンです。
今回はアジャイルで進めたいので、設計書は最小限にしたいです。どこを文書化してどこを省くか、線引きを相談させてください。
クライアントの開発責任者が、商談でベンダーのコンサルタントに方針を伝えている場面です。
【まとめ】3つのポイント
- 開発の共通言語：設計書とは、システムをどう作るかを文書化した設計図で、関係者の認識を揃える共通言語として機能します。
- 基本から詳細へ：何を実現するかを描く基本設計と、どう実装するかを定める詳細設計に分かれ、段階的に具体化していきます。
- 生きた文書として保守：仕様変更のたびに更新しないと実装と乖離するため、プロジェクトに応じた粒度で最新に保つことが重要です。
よくある質問
-
Q基本設計と詳細設計はどう違いますか？
-
A
視点と抽象度が違います。基本設計は利用者や発注者の立場で何を実現するかを定め、画面や機能の全体像を描きます。詳細設計はそれを開発者の立場でどう作るかに落とし込み、データベース構造や処理の流れなど技術的な中身を決めます。
-
Q設計書は誰が読むものですか？
-
A
複数の関係者が読みます。発注者は要件が満たされるかを確認し、開発者は実装の指針として使い、テスト担当者は検証の基準にします。さらに運用・保守の担当者が後から仕様を理解する際にも参照します。立場の違う人々をつなぐ文書なのです。
-
Q設計書を作らずに開発することはできますか？
-
A
小規模なものなら可能ですが、リスクが伴います。設計書がないと認識のズレや手戻りが起きやすく、人が増えたり期間が空いたりすると破綻しがちです。アジャイル開発でも設計をしないわけではなく、必要な分だけ軽量に残すのが一般的です。
-
Q設計書と仕様書との違いは何ですか？
-
A
重なる部分も多いですが、力点が異なります。仕様書は主に何を作るか、どう動くべきかという要求や振る舞いを定義した文書です。設計書は、その仕様をどう実現するかという構造や方式まで踏み込んで記述します。仕様書が要求、設計書が実現方法、という関係で捉えると整理しやすいでしょう。
【出典】参考URL
IPA 独立行政法人情報処理推進機構: 設計工程・開発プロセスの解説 https://www.ipa.go.jp/
経済産業省 情報システム・モデル取引契約書: 設計成果物の位置づけ https://www.meti.go.jp/
IPA 基本情報技術者試験シラバス: 開発工程の基礎 https://www.ipa.go.jp/
コメント