背景と前提
アジャイル開発だったチームからウォーターフォール（寄り）の開発のチームに移動になりました。設計フェーズから合流し仕様書を作っていますが、「このドキュメントがどこで活きるのか（なぜこんなにきちんと作らなければならないのか）」という点でまず最初に躓いたので、備忘として残しておきます。
私と同じような「設計書とは！？」という状態の方を読者として想定しています。
本記事で書くこと・書かないこと
- 「設計書」というドキュメントが、誰にとっていつどのように必要なのか、について自分の理解をまとめます。
- 各設計書のフォーマットや細かな書き方については触れません。（所属するチームの文化にもよると思いますし、分かりやすくまとまっている文献、サイトがすでにたくさんあるため）
- 開発手法についても詳細は触れません。（開発手法についての詳細やTipsはすでにネットにもたくさん知見があるため）
1. ウォーターフォール開発とは
設計書を書くのはシステム開発のどのタイミングなのかを説明するために、今チームで行なっている「ウォーターフォール」型の開発手法についての私の理解を簡単におさらいします。
ウォーターフォール型開発とは、ものを作るまでの決め事をするフェーズ（要件定義〜内部設計）と、ものを作り初めてリリースするまでのフェーズ（開発〜統合テスト）がきっぱり分かれている開発の進め方です。
(参考：「アジャイル開発」って何がいいの？--アジャイル開発を実案件に生かすための基礎知識)
上図のように、開発に入る前に「何のためにどういうものを作れば良いか」がしっかり決まりきっている状態なので、いざ手を動かす時に迷わずにすみます。また設計時点でどこにどれくらい時間がかかりそう、というのが分かるので進捗も把握しやすいのがメリットです。特に大規模なシステムを開発するときはこの手法が取られることが多いようです。
設計書は、システムで実現したいことを決めた後（要件定義）、どうやって実現するか、という検討をするとき（外部設計〜）から必要となります。
2. 本記事が示す「設計書」の種類
前述の「『何のためにどういうものを作れば良いか』がしっかり決まりきっている状態」を作るために必要なのが設計書、なのですが、本記事では具体的には下記のドキュメントのことを想定しています。それぞれの役割は記載の通りです。
- 画面遷移図・・・画面間のつながりと、遷移のトリガーを俯瞰できるもの。
- ERD・・・そのシステムに登場するデータの関係を表すもの。
- DFD・・・データの流れと関連する登場人物を俯瞰できるもの。 データ観点のシステムの地図。
- 各画面設計書・・・そのシステムの画面に登場する機能と、果たすべき役割の全量を示すもの。
- 機能一覧・・・開発フェーズで作り上げる機能の全量を示すもの。
3. 設計書は誰が、いつ、どのように使うのか
設計書を見る人の立場別に整理しました。
- 上記全ての立場の人が見てわかるようにするために、何をどこまで表現するか吟味する必要があります。また、書く内容の正確さに加え、単語の分かりやすさや見やすさに配慮する必要があります。
- おそらくそのために、ERDやDFDに共通の書式ルールが存在したり、チーム内でドキュメントのフォーマットや命名規則などのルールが設けられたりしています。
- 設計書をそのルールに従って作成することは、読者が設計書を読解するための時間をかけない、誤った理解をしないように防ぐ、という効果があります。
終わりに
開発手法の違いについてこれまで気にしたことはなかったのですが、自分が異なる状況に置かれて初めて、その文化を理解することは自分が手を動かすために必要なことなのだと実感しました。