システム設計の流れとは｜システム設計の流れについて解説

システム設計の流れとは、「ユーザー（非技術者）軸からシステム（技術者）軸に仕様を落とし込んでいく作業」と言い換えるとわかりやすいかもしれません。「要件定義」でユーザー要件をシステム化する範囲を決め、「基本設計」でユーザーがわかる粒度で各機能を設計し、「詳細設計」でプログラミングができるレベルまで詳細化します。そうすることで、ユーザー要件に対して過不足のないシステムを開発できるようになるのです。

システム設計の流れは方法論の違いでいくつかの分け方がありますが、今回は「要件定義」も含めて「要件定義」「方式設計」「基本設計」「詳細設計」の四つに分けて解説します。

要件定義によって、ユーザー要求のどの範囲を、どのようにシステムで実現していくかを定義します。システムが実装すべき機能や性能を明確にし、開発者の視点でわかりやすく文書化することで、具体的な進め方を決定します。
要件定義の流れを大まかに挙げると、以下のようになります。

1.「要求定義」で「業務要件」を明確にする
2.「機能要件」を定義する
3.「非機能要件」を定義する
4.「要件定義書」を作成する

まずは要件定義の最初のステップとして、「要求定義」を行います。ユーザーがシステムに対して求める仕様を定義し、システム化の対象となる業務の流れ（業務要件）を明確にします。
業務要件がまとまったら、その中からシステムで実現すべき要件（機能要件）を定義します。
次に、機能以外でユーザーがシステムに求める要件（非機能要件）を定義します。非機能要件には、セキュリティやパフォーマンスなどが含まれます。なお、非機能要件については、IPA（情報処理推進機構）が公開している「非機能要求グレード」の中で詳しく紹介されています。
最後に、要件定義工程で固まった要件をまとめて「要件定義書」を作成します。要件定義書はユーザーも確認するため、専門知識が無くても読めるように意識しましょう。

要件定義で定められた要件を実現するため、システムに関連するハードウェアやソフトウェア、ネットワーク、外部I/Fなどを定義することを「方式設計」と呼びます。一般的には要件定義から基本設計工程にかけて実施されます。
方式設計では主に以下の設計を行います。

1.ハードウェア構成
2.ソフトウェア構成
3.ネットワーク構成
4.アプリケーションアーキテクチャ
5.外部I/F

方式設計工程の中で技術的リスクを明確にすることで、後工程でのトラブルを抑止できます。また、パフォーマンスやセキュリティなどの非機能要件を考慮することも重要です。

基本設計は、要件定義で決定した要件をもとに、システムの機能を具体化するための工程です。「外部設計」と呼ばれることもあります。
方式設計に対して、アプリケーションとして実装する機能やデータベース、画面や帳票などを設計することを「機能設計」と呼び、一般的には基本設計の一部として方式設計の後に実施します。機能設計では機能ごとにシステムを分割し、要件定義で定められた要件を満たすよう、それぞれの機能を設計していきます。
基本設計工程の中で、要件定義ではまだ概要レベルだった箇所を具体化していきますが、主にシステム概要図や画面・帳票といったユーザーインターフェース部分など、ユーザーの目に触れる範囲が対象となります。そのため、適宜ユーザーへのレビューを行い合意を取る必要があります。
基本設計の成果物には、様々な種類があります。例えば、「機能一覧」「画面設計」「帳票設計」「バッチ設計」「メッセージ定義」「画面遷移図」「テーブル項目」「ＥＲ図」「ＣＲＵＤ図」「ファイル定義」「インターフェース定義」などが挙げられます。これらのうち実際にどれが必要になるのかは、開発プロジェクトのルールによって異なってきますが、基本設計工程のアウトプットが詳細設計工程のインプットとなるため、過不足のない設計書を用意する必要があります。

詳細設計では基本設計で定義した内容をさらに詳細化し、プログラムを製造できる状態まで落とし込みます。「内部設計」と呼ばれることもあります。
詳細設計の成果物もまた、様々な種類があります。例えば、「画面設計」「帳票設計」などは基本設計工程の成果物をベースに詳細化し、プログラマーが製造工程で活用できるレベルまで落とし込みます。また、「クラス図」や「シーケンス図」など、新たな詳細資料を起こす場合もあります。基本設計とは異なり、ユーザーの目に触れない範囲が対象となるため、基本的にユーザーに合意を取る必要はありません。プログラミングに必要な内容を適切に表現することが大切です。

システム開発を成功させるためには設計工程がとても重要ですが、すべてを完璧にこなそうとすると負荷が高すぎるため、早々に挫折してしまうことになりかねません。なるべく無理のない現実的な計画を立てる必要があります。

複数のメンバーが参画するシステム開発の現場において、成果物の統一をいかにして図るかというのはとても重要且つ厄介な課題です。メンバーの違いによって発生する差異を可能な限り少なくするには、設計標準や開発標準などの標準書類と、それらを徹底させるルールが必要です。
しかし、ただそれらを用意すればいいのかというとそうではありません。理想を言えば、十分な時間をかけて標準・ルールを徹底させることで成果物の品質向上を目指したいところですが、実際はそのような「急がば回れ」のようにはいかないことが多いでしょう。現場ではどうしても、限られた工数に収まることを求められるため、下準備に時間をかけられないことが多いのではないでしょうか。
現実的な解決策として、標準フォーマットや設計ツールを上手く活用して、設計書に入力できる情報を制限することが挙げられます。フォーマットにある程度の制限があることで、それ自体がシステム設計標準として機能するため、自然と読みやすくなるとともに不要な情報が入り込む余地もなくなります。ルールを覚えさせるのでなくレールを敷いてあげる方が、管理者・作業者ともに楽になるでしょう。

要件定義から基本設計へと仕様を落とし込んだ結果、出来上がった設計書がユーザー要件を満たしているのかという目線で改めて確認するといいでしょう。ユーザー軸からシステム軸へと思考がシフトしていく中で、システム化にとって都合のいいように考えすぎてしまい、肝心のユーザー要件から逸脱してしまう場合があるためです。設計通りのプログラムができたとしても、それが要件に合致していなければ意味がありません。
特に「ウォーターフォール開発」の場合、要件定義からリリースまでに数年を要するケースも少なくなく、要件定義で必要とされた機能がリリース時には不要なものになっていることさえあります。そのため、システム単位ではなく機能単位に要件定義～リリースのサイクルを繰り返す「アジャイル開発」の導入を求める声もよく耳にしますが、導入に踏み切れないケースが多いのが現状です。
そんな長いシステム開発期間において、要件と設計のズレが後工程で発覚した場合、リカバリに膨大な工数を必要とすることもあります。そうならないよう、何が正解なのかを改めて確認する機会が必要なのです。

設計期間中にどのような変化があったのか、設計書の履歴を確認できる仕組みがあるといいでしょう。

設計工程に限った話ではありませんが、システム開発においては次の工程に移る前に適宜レビューを行うことがとても重要です。誤りや漏れがある状態で次工程に移行してしまうと、それがトラブルや手戻りの原因になり、プロジェクトの失敗へと繋がってしまいます。
次工程に移る前に適切にレビューを実施できていれば、後々のトラブルを回避できます。ただしそれは、レビュー時の指摘を正しく設計書に反映できてこそです。設計工程が終盤になればなるほど、仕様変更の影響範囲は大きくなるため、手作業による影響調査・反映は困難になっていきます。工数増加だけでなく、ミスや漏れが発生するリスクもあるため、ツールを導入するなどなるべく手作業を減らすように努めましょう。

近年のシステム開発では、ローコード開発ツールやテスト自動化ツールなど、必要に応じてツールを導入するケースが増えてきています。しかし設計工程においては、未だExcelやWordといった汎用的なツールを使って設計を行っている企業が多いのではないでしょうか。
設計工程の品質が向上することで、システム開発全体の品質も向上することはわかっていながらも、「これまでの運用を変えることに抵抗がある」「費用対効果がわからない」などの理由で、導入を見送られがちなシステム設計ツール。しかし、よく知られていないだけで、実は様々なメリットがあるのです。

設計書を設計ツール上で一元管理することで、ファイルサーバーでの管理でありがちな「最新の設計書がどれかわからない」という問題が発生しなくなります。過去の設計書の履歴まで管理できるツールであれば、より効果を発揮することでしょう。

システム設計ツールは設計のために用意された専用ツールなので、入力補助が充実しています。例えば画面レイアウト作成時、Excelなどでは基本図形を駆使して表現しなければなりませんが、設計ツールにはボタンやテキストボックスといった、システム開発に必要なコントロールがあらかじめ用意されているため、簡単に表現力の高い設計書を作成できます。

テーブル定義や画面定義など、システム開発に必要な設計書のフォーマットが用意されているため、誰でも同じフォーマットの設計書を作成できます。

設計書間の関連付けを行えるツールであれば、仕様変更があった際に影響箇所を特定したり、変更を自動反映できたりします。これらを手作業で行うとなるとかなりの重労働であるため、ツールの効果が最も発揮されるところかもしれません。

ファイルサーバでの管理となると、あまり細かい権限設定を行うのは運用上とても煩わしいですが、設計ツールの場合は開発する「システム単位」や「設計書の種類単位」など、システム開発において都合のいい権限を簡単に設定できるものもあります。

システム設計の流れを理解し、正しい設計を行っていくことはとても大切ですが、人の手で行える範囲には限界があります。ツールなどを活用しつつ、無理のない範囲で進めていくことが成功への近道だと考えられます。
システム設計ツール「Verasym System Designer（VSSD）」は、システム設計に必要な20種類以上の設計書を統一されたフォーマットで作成でき、設計変更時の影響参照や変更反映を簡単に行えるなど、システム設計を便利にする機能が数多く搭載されています。
上流工程を改善すれば、必ず下流工程にも活きてきます。システム開発全体の生産性・品質向上のため、システム設計ツールの導入をご検討されてはいかがでしょうか。