システム設計とは？ 設計工程の流れや失敗を防ぐポイントを紹介！

更新：2024.4.26
著者：Ｓｋｙ株式会社

システム設計とは、目指すゴールを定めること

システム設計とは、開発工程に入る前にシステムに必要な機能や仕様を決め、仕様書や設計書にまとめていく工程です。システム設計は、システム化する業務の具体的なフローを理解し、どこに課題があるのかを把握することから始まります。そのため、ヒアリングは実際にシステムを利用する担当者だけではなく、マネージャー層や経営層にも行うことが理想的です。それは、現場、マネジメント、経営がそれぞれに感じている課題が必ずしも一致するとは限らないからです。

システム開発の多くは、業務上の課題を解決するために行われます。例えば「繰り返し作業が多い」や「入力手順が煩雑でヒューマンエラーが起きやすい」といった担当者が感じている課題だけではなく、「データ入力にかかる作業を自動化し、空いたリソースを別業務に充てたい」という課題も考えられます。課題の本質が明確になれば、解決に必要な「機能」や「仕様」が見えてきます。それらを実際の業務フローに沿って組み立てながら、システムが目指すべきゴールを明確にしていきます。システムが課題解決に貢献できるかどうかはシステム設計の段階で大半が決まると言っても過言ではありません。

システム設計は、なぜ重要なのか

システム設計では、発注者（ユーザー）の求めるものを細かく分析（要求分析）し、その結果に基づいてシステムに求められる要件を定めます（要件定義）。さらに基本設計、詳細設計という順に、段階的にシステムの設計を進めていきます。

なぜ、システム設計にこれだけの工数をかけるのでしょうか。それは、開発工程（実装作業）を担当するプログラマーの判断に委ねられる箇所が多いほど、システムの品質に良くない影響が出るからです。通常、業務用のシステムを1人で実装することはほぼありません。共通認識の上で実装作業を行うためにも、システム設計の段階でなるべく詳細に定義されていることが大切です。しかし、現実的にはシステム設計ですべての仕様を決めきることは難しいため、何をどこまで決めておくのか、何がまだ決まっていないのかということを整理しながら、設計を進めていくことになります。

システム設計の主な流れ

システム開発のプロセスでは、最上流の工程に「要求分析」や「要件定義」があり、その次に「基本設計」、次に「詳細設計」と進めていくのが一般的です。そのため、ユーザーの要求や要望を具体化し、システムの要件に落とし込む「要件定義」も設計工程の一つとして扱うこと多いです。さらに設計工程の一部を「方式設計」「機能設計」などと呼ぶ場合もあります。ここでは、これらの違いについてご説明します。

① 要件定義

要件定義とは、システム構築によって、ユーザーの要求をどのように実現するのかを整理し、システムに求められる要件を定義することです。新たに開発するシステムに実装すべき機能にはどのようなものがあるのか。それらには、どのような性能が求められるのか、といったことを定義して「要求仕様書」にまとめます。

ちなみに要件定義のうち、システム化の対象となる業務のフローなどを「業務要件」と呼び、システムに必要な機能に関する内容を「機能要件」、そのほかの性能や可用性、セキュリティといった、機能以外の内容を「非機能要件」といいます。

② 方式設計

方式設計とは、要件定義によって定められた要件を実現するために必要なものを定義することです。例えば、システムを構築するために必要なハードウェア、ソフトウェア、ネットワーク構成、外部インタフェースなどを定義します。この方式設計は要件定義から基本設計にかけて行われるのが一般的で、この段階で技術的なリスクを特定することが重要です。また、パフォーマンスやセキュリティなどの非機能要件についても十分に考慮することが必要です。

方式設計の段階で誤りやミスがあると、要件定義で定めたパフォーマンスを出せなかったり、一部の機能が設計どおりに動作しなかったりするなど、開発工程におけるトラブルの原因ともなるため、重要性が高い工程とされています。

③ 基本設計（外部設計）

基本設計は、要件定義に基づいて、システムに実装する機能を具体化する工程です。ユーザーとの認識合わせや合意形成のためにも用いられるため「外部工程」ともいいます。この基本設計では、開発対象とするシステムや機能の内容や画面構成（ユーザーインタフェース）などの基本的な仕様を整理し、ユーザーにもわかりやすい形にまとめて「基本設計書」を作成します。

先述した「方式設計」やこの後に説明する「機能設計」を行うことで、要件定義では概要だった仕様をより具体化していきます。ただ、この段階では主にシステム概略図や画面、出力する帳票の様式といったユーザーが直接目にする部分が対象となります。ユーザーと共に適宜レビューを実施するなどし、認識に相違がないかを確認することが大切になります。

④ 機能設計

ハードウェアやネットワーク構成、外部インタフェースなどを含む方式設計に対して、アプリケーションとして実装する各種機能やデータベース、出力する画面や帳票などを設計することを機能設計と呼びます。基本設計の一部として、方式設計を行った上で進めるのが一般的です。

システム全体を機能ごとに分割して設計を行い、要件定義を満たせるように各機能を設計します。基本設計の一部として行われるため、決定した内容は「基本設計書」に盛り込む場合もありますが、別途「機能設計書」を作成する場合もあります。なお、基本設計の工程では、このほかに「画面設計」「帳票設計」や「データ設計」などをそれぞれ別個に行う場合もあります。

⑤ 詳細設計（内部設計）

詳細設計の工程では、基本設計で決定した内容をさらに詳細に詰めていき、実装作業に取りかかれるところまで定義します。主に内部（開発側）のための作業なので「内部設計」ともいいます。基本設計とは異なり、基本的にユーザーの目に直接触れない部分に関する内容となるため、詳細設計を基にユーザーの合意を得るということは必要ありません。

詳細設計書には、画面遷移図やクラス図、シーケンス図、データベース物理設計書などが含まれており、それらに基づいてプログラマーなどのエンジニアは自分が担当する作業の範囲や、それらの関係性などを理解し、分担して実装作業（コーディング）を進めてきます。

システム設計のポイント

システム設計を進める際に、作業の手戻りや不具合の発生を防止するためのポイントを紹介します。上流工程に当たるシステム設計で、これらのポイントを押さえておくことで、下流工程の作業がスムーズに進められます。

各工程における成果物を明確に定義する

前述のとおり、基本設計におけるアウトプットは詳細設計のインプットとなり、詳細設計のアウトプットが実装作業のインプットになります。次の工程を想定していないアウトプットでは、次工程に支障が出るだけではなく、成果物（ドキュメント）を作成するためにかけた人的リソースが無駄になりかねません。そのため、要件定義→基本設計→詳細設計→実装作業という開発の流れを意識し、次工程につながるように成果物を定義することが重要です。プロジェクト開始時点で、各工程で必要となる成果物を明確にして、成果物に含める内容や記述様式をしっかりと決めておけば、担当者は迷うことなく作業に集中できるようになります。

しかし、成果物の定義やドキュメントの様式を統一している会社は、意外と多くありません。画面設計や帳票設計、データベース設計といった作成する文書は同じであっても、その中身の画面一覧や画面遷移図、帳票の入出力項目、テーブル定義などの各項目については、システムによって記載すべき内容が異なるからです。しかし、それらの違いを考慮した上で可能な範囲で統一を図りつつ、記載内容に過不足が起きないようフォーマット化することで、プロジェクト開始段階の工数を削減でき、その後の手戻りやトラブルを防ぐことにもつながります。

類似システムごとに標準書類のひな型を用意する

プロジェクトの規模が大きくなり携わる人数が多くなるほど、システム全体の統一性を保つことが難しくなります。例えば、機能ごとに画面構成や遷移方法に違いがあれば操作性が低下します。また、担当者によってドキュメントの様式や記述内容が異なれば、それぞれの内容を把握するのに余計な時間がかかってしまいます。これらの差異を最小限にとどめるために標準化が重要な鍵を握ります。

標準化の対象はいくつかあります。例えば、仕様書や設計書などの各ドキュメントの様式や記述内容、具体的な書き方などを定めてプロジェクトの成果物を統一する「ドキュメント標準」。また、画面の見た目や操作性、共通部品などを定めてシステム内の統一を図る「開発標準」や「設計標準」。これら「標準書類」と呼ばれる文書を作成し、文書に従ってシステム設計・開発を進めます。しかし、標準化に十分な工数を割けないケースも少なくありません。先述のとおり、システムごとに内容が異なるため、全社的にすべてを統一することは難しいのですが、あらかじめ類似システムごとに各種標準書類のひな型を用意しておくといった工夫をすれば、工数の削減につながります。このとき、担当者によって記述内容の粒度に差が出ないよう、ひな型にはある程度の制約を設けて、記述ルールを明文化しておくことも大切です。

仕様変更の際は、各ドキュメントに確実に反映する

システム設計を進めている間に仕様が変更になるのはよくあることです。中には実装作業中に変更になることもあります。このように仕様が変更された場合には、関連する設計書から影響範囲を特定して修正する必要があります。変更の内容によってはシステム全体に影響が出ることもあるため、要修正箇所を洗い出す作業だけでも大きな工数を費やしてしまいます。しかし、洗い出しが不十分だと修正漏れが発生してしまい、以降の工程でのトラブルやシステムリリース後の不具合などにつながりかねません。

プログラム関連図やCRUD図など、モジュールやデータベースなどの関係が確認できる資料を用意しておくことで、要修正箇所の洗い出しがスムーズに行えます。また、仕様変更の履歴を残すため変更管理資料などを作成しておくこともお勧めです。

レビューを丁寧に行う

設計工程だけの話ではありませんが、システム開発を進める際は、次の工程に移る前に十分なレビューを行うことが大切です。特に要件定義や基本設計（外部設計）では、発注元の要求に合致しているかを丁寧にレビューし、認識のズレや仕様の漏れがないかを確認することが大事です。そうしたリスクが残ったまま後の工程を進め、後になって仕様変更が必要になれば大きな手戻りが発生します。

また、発注元と行うレビューだけではなく、基本設計から詳細設計、詳細設計から実装作業など次の工程に移る前には、プロジェクト内でレビューを重ねます。前述のとおり、工程が進むほど仕様変更による影響の範囲が大きくなり、その分大きな工数をロスすることになります。そのため、レビューではわずかな疑問や不安も残さないように、時間をかけて認識をすり合わせながら行うことが大事です。

豊富な経験と確かなノウハウを有するＳｋｙ株式会社

Ｓｋｙ株式会社は、家電製品の組込み開発を手掛けたのをきっかけに、デジタル複合機やカーエレクトロニクス、医療機器など、幅広い分野でシステム開発を展開。また、AI・画像認識を活用したシステム開発にも携わっています。お客様先へのエンジニア派遣や受託開発などをはじめ、要件定義から設計、開発、検証、運用・保守まであらゆるフェーズで技術を提供しています。

業務系システムにおいても、金融・保険業界のコールセンターシステムや、医療業界の内視鏡ITシステム、建設業界の生産管理システムなど、多様な業界・業種で開発実績を積み重ねてきました。主要メーカー製品や各種スマートデバイスなどと連携するシステムをはじめ、クラウドサービスの活用を進めることで、ビジネス環境の急速な変化にも迅速かつ柔軟に対応できるシステムを開発しています。

まとめ

ここまでシステム設計の概要や、各工程をスムーズに進めるためにシステム設計で注意すべきポイントなどをご紹介してきました。特に成果物となる各種ドキュメントのフォーマットや標準書類のひな型の整備など、プロジェクトの標準化が工数の削減、品質の向上につながることをお伝えしました。これらは長年にわたり積み上げた開発実績のなかで培われるものです。

Ｓｋｙ株式会社は、自動車関連システム、業務系システムをはじめとした幅広い分野で、システム開発の実績があり、システム設計をはじめとする上流工程から品質管理に携わるノウハウも有しています。システム開発でお困りごとがあれば、ぜひＳｋｙ株式会社までお問い合わせください。