設計の自動化と聞いて、皆様はどのようなことを想像されるでしょうか。開発者が頭の中で考えたことを機械が読み取って、設計書として出力してくれる夢のようなシステムは、当然のことながら存在していません。設計では、要件の内容をコーディングに向け詳細化していきますが、その情報の詳細化作業を自動化することは不可能です。

　情報の詳細化を自動化することは不可能ですが、開発の工程が進むにつれて発生する設計内容の段階的な詳細化や、他者と並行した設計作業において、自身が作成している設計書とは別の設計書との整合性を保つという作業では、自動化ができる余地があります。整合性を適切に維持できないと、開発したシステムが正しく動作しなくなってしまいます。この維持は開発人数、開発規模、開発期間が大きくなるほど難しくなります。

　整合性維持を自動化するためには現在、2つのアプローチがあります。自動化には開発プロジェクトに課される制約事項との間にトレードオフの関係があるため、一概にどちらのアプローチが正しいとはいえません。それぞれのアプローチを理解したうえで、どちらがその開発プロジェクトに適しているかを見極めてから導入することが重要になるでしょう。

ほどんどのシステムに欠かせない設計工程

　設計工程は、顧客と合意したシステムにかかわる要件について、コーディングをする前に情報を詳細化していくための工程といえます。まず初めに、なぜ設計は必要なのでしょうか。もし要件が非常に簡単であれば、設計をせずに要件から直接コーディングできるかもしれません。この状況は言い換えれば、要件の内容が十分に詳細化されていたことになります。しかしそれほど簡単なシステム開発が発注されることはほとんどなく、要件を詳細化していく工程つまり設計工程が、ほとんどのシステムに必要となります。

　当たり前のことですが、設計工程では成果物として設計書を作成します。アジャイル開発手法では「設計書は必要最小限作成すれば良い」といわれています。これを過大に解釈すると設計書は不要とも取れますが、完全に不要なのはごく少人数の開発の場合で、かつ要件が簡単であり、保守の際にも設計書が不要であるというレアケースに限られると考えられます。大半のプロジェクトでは少なくとも何かしらの設計書を作成しますので、その作成目的を整理します。