システム設計とは｜システム設計の流れを解説

システム設計とは、対象のシステムの仕様・機能・構造などを決定することを言います。設計工程のアウトプットが製造工程のインプットとなるため、システム開発を成功させるために最も重要な工程と言っても過言ではありません。

システム設計工程では、要件定義で合意した内容を元に、システムを実装できるレベルまで仕様を詳細化していきます。画面・帳票・バッチ処理やデータベースの設計だけでなく、ハードウェアやソフトウェア、ネットワーク構成など、対象システムに必要なすべての設計を行う必要があります。

製造工程においてプログラマーの判断に委ねられる箇所があればあるほど、そのシステムの品質は不安定になります。プログラマー任せにせず一定の品質を保つためには、設計工程でなるべく明確に定義することが重要です。
また、設計工程の不備が後工程で発覚すると、その修正には時として膨大な時間を要すると共に、ミスも誘発します。トラブルを抑止し、スケジュールの遅延や予算オーバーといった問題を防ぐには、システム設計工程での準備が特に重要なのです。

定義の上では「要件定義」の次の工程を「設計」と呼びますが、「要件定義」も「設計」の工程に含めて、大きく「要件定義」「基本設計」「詳細設計」の三つに分けて「システム設計の流れ」と表現する場合も多いため、今回は「要件定義」も含めることとします。
また、設計の方法論の違いで「要件定義」～「詳細設計」の一部を「方式設計」「機能設計」のように定義づける場合もあるため、こちらについても簡単にご紹介します。

要件定義によって、ユーザーの要求のどの範囲を、どのようにシステムで実現していくかを定義します。システムが実装すべき機能や性能を明確にし、開発者の視点でわかりやすく文書化することで、具体的な進め方を決定します。
似た言葉で「要求定義」というものがありますが、こちらはユーザー（非技術者）がシステムに対して求める仕様の定義であり、要件定義の最初のステップにあたります。
要求定義の中で明確化された、システム化の対象となる業務の流れを「業務要件」、要件定義の中でシステムに実装すべきと定められた要件を「機能要件」、その他セキュリティなど機能以外に満たすべき条件や制約が定められたものを「非機能要件」と呼びます。

要件定義で定められた要件を実現するため、システムに関連するハードウェアやソフトウェア、ネットワーク、外部I/Fなどを定義することを「方式設計」と呼びます。一般的には要件定義から基本設計工程にかけて実施されます。
方式設計に誤りがあると、パフォーマンスが出なかったり一部機能が正常に動作しないなど、後工程で大きなトラブルが発生するリスクがあるため、とても重要な工程です。

基本設計は、要件定義で決定した要件をもとに、システムの機能を具体化するための工程です。「外部設計」と呼ばれることもあります。
「方式設計」や「機能設計」を行うことで、要件定義ではまだ概要レベルだった箇所を具体化していきますが、主にシステム概要図や画面・帳票といったユーザーインターフェース部分など、ユーザーの目に触れる範囲が対象となります。そのため、適宜ユーザーへのレビューを行い合意を取る必要があります。

方式設計に対して、アプリケーションとして実装する機能やデータベース、画面や帳票などを設計することを「機能設計」と呼びます。一般的には基本設計の一部として方式設計の後に実施されます。
機能設計では機能ごとにシステムを分割し、要件定義で定められた要件を満たすよう、それぞれの機能を設計していきます。

詳細設計では基本設計で定義した内容をさらに詳細化し、プログラムを製造できる状態まで落とし込みます。「内部設計」と呼ばれることもあります。
基本設計とは異なり、ユーザーの目に触れない範囲が対象となるため、基本的にユーザーに合意を取る必要はありません。プログラミングに必要な内容を適切に表現することが大切です。

設計工程に不備があると、後工程で必ずトラブルや手戻りが発生します。それを防ぐために、システム設計段階で以下のことを常に心がけると良いでしょう。
・不明点、あいまいな点を明確にする
・手戻りを無くす
・確認・見直しを確実に行う

具体的な対策としては、以下のようなものが考えられます。

基本設計工程のアウトプットは詳細設計工程のインプットになり、詳細設計工程のアウトプットはプログラミング工程のインプットになります。次工程を意識せず成果物（アウトプット）を定義してしまうと、次工程の作業に支障をきたすだけでなく、不要な成果物を作ることになるため、人的資源のロスにも繋がります。そのため次工程の正しいインプットになるよう、各工程の成果物を適切に定義する必要があります。
プロジェクト開始時に工程ごとの成果物を列挙し、成果物のフォーマットを正しく定義できていれば、作業者は各工程の作業に注力することができます。しかし、工程ごとの成果物の定義を企業単位で徹底できているケースは多くありません。プロジェクトリーダーの裁量で、類似システムの設計書を流用して開始しているプロジェクトは多いのではないでしょうか。
一言に「テーブル定義書」「画面定義書」と言っても、システムごとに要求は異なるためフォーマットは変わってきます。ただ盲目的に流用するのではなく、システムによる違いを見極めつつ、なるべく統一のとれた過不足のないフォーマットを準備することで、後々のトラブルは減少するはずです。

プロジェクトに参画するメンバーが多ければ多いほど、システムの設計・開発において成果物の統一を図るのは難しくなってきます。メンバーの違いによって発生する差異を少なくするには、設計標準や開発標準などの標準書類と、それらを徹底させるルールが必要です。
しかし、設計書のフォーマットと同様に、標準書類もまた類似システムのものを流用されているケースが多く見受けられます。また、時間をかけて対象システムに合った標準を定めたとしても、限られた工数の中でメンバー全員に徹底させるのはなかなか難しいでしょう。一通り目を通すだけでも大変なのではないでしょうか。
システム設計の標準化の解決策の一つとして挙げられるのは、標準フォーマットの自由度を高くしすぎないことです。自由度が高ければ書きたいことを書きたいように書けるため、書く側からすれば簡単ですが、人によて粒度が異なってしまうため読み取る側の負担が高くなります。フォーマットにある程度の制限があることで、それ自体がシステム設計標準として機能するため、自然と読みやすくなるとともに不要な情報が入り込む余地もなくなります。

設計工程の間に仕様が変わることは多くあります。プログラムの製造中に変わることも少なくありません。そして仕様変更が発生した場合、関連する設計書から影響箇所を探してすべて修正する必要があります。変更箇所によってはシステム全体に影響するため、影響箇所の特定には膨大な工数がかかりますし、反映漏れが発生するリスクもあります。しかし、これを怠ってしまうと設計書が陳腐化し、以降の開発やリリース後のシステム運用業務に支障をきたしてしまいます。
プログラム関連図やCRUD図など、システム内の各プログラムやDBの関連がわかる資料を用意しておけば、影響範囲の特定を効率的に行うことができます。また、仕様変更が発生した際に変更管理資料を作成していれば、より効果的でしょう。設計書の履歴を適宜残しておくことも重要です。

設計工程に限らず、各工程で工程完了基準を作り、必ずそれを満たしてから次工程に進むようにすることが大切です。工程内で行うべきことが終わっていない状態で次工程へ進んでしまうと、後でトラブルや手戻りを引き起こし、プロジェクトの失敗に繋がってしまいます。
基準を定めていないと、スケジュールが遅延している場合などは特に、どうしても判断が甘くなりがちです。あらかじめ完了基準を作成しておき、基準を満たさない場合はリスケしてでも満たすようルールを徹底しましょう。

プロジェクトで利用できるリソースには限りがあるため、人力でできる作業には限界があります。無理して突き進めば取り返しのつかない事態を引き起こすため、そうならないよう対策を講じる必要があります。
昨今では、システム設計ツールやローコード開発ツール、バグ検出ツール、テスト自動化ツールなど、各工程に専用のツールやサービスが用意されていますので、それらを上手く活用して人力の作業をなるべく減らすことが、システム設計・開発の標準化・効率化に繋がるでしょう。

一言に「システム設計」と言っても、開発言語や環境、対象業務など様々な要因により、求められるものは変わってきます。しかし、軸となる考え方はどのシステムでも共通であり、ツールによる標準化が可能です。
システム設計ツール「Verasym System Designer（VSSD）」は、システム設計に必要な20種類以上の設計書を統一されたフォーマットで作成でき、設計変更時の影響参照や変更反映を簡単に行えるなど、システム設計を便利にする機能が数多く搭載されています。
従来のシステム開発とやり方を変えるとなると、慣れない作業の中で工数が増加することが懸念されます。確かに、最初の案件では工数増加や混乱もあるかもしれません。しかし、運用が定着してしまえば、想定外のトラブルや手戻りが抑止されるため、スケジュール通りに安定した設計・開発が行えるようになるのです。少し長い目で見て、改革を進めてみてはいかがでしょうか。