YAZエンジニアが運営するメディア

システム開発をする場合、最初からプログラミングに着手することはありません。まず、どんなシステムが必要なのか発注側・開発側ですり合わせを行い、求められる機能・仕様を詳細に決めていきます。このように、システム開発でプログラミングの前に必ず行われるのがシステム設計です。

こちらでは、システム設計の概要や一般的な流れ、システム設計を依頼する際に発注側が意識しなければならないことについてお話しします。

システム設計の基礎知識

システム設計は、システム開発において不可欠な工程です。以下では、システム設計の意味や重要性についてお伝えします。

システム設計とは？

システム設計とは、システムを実際に開発する作業に移る前に、機能や仕様を決定することです。発注側の情報システム担当者と、開発側で打ち合わせを行い、現状把握・業務フローでどんな課題があるのかをヒアリングし、システムによって解決可能な課題を要件としてまとめます。

システム設計は、システム開発の上流工程として行われます。実際には「要件定義」「外部設計（基本設計）」「内部設計（詳細設計）」という3つのプロセスに分けられ、それ以降は実際にシステムをプログラミングで実装していく「下流工程」に移っていきます。

システム設計の重要性

開発するシステムの内容は設計段階で決まります。開発段階に入ってからの修正指示は受け入れられないことも少なくありません。修正できたとしても、時間やコストが大幅にかかってしまうケースがあります。結果として、スケジュールの遅延や予算オーバーを招きます。綿密なシステム設計を行っておくことは、こうした問題を防ぐために重要であり、必要不可欠です。

システム設計の主な流れ

システム設計は「要件定義」「外部設計（基本設計）」「内部設計（詳細設計）」という流れで進められます。以下では、各工程の内容についてお話しします。

STEP1：要件定義

要件定義は、システムに必要な条件を整理してまとめる工程です。実装する機能、システム開発の目的、開発期間、導入・運用方法などを決定します。開発側が発注側の要望をヒアリングし、その内容を踏まえて「要件定義書」としてまとめます。要件定義書には、開発するシステムに実装される機能一覧が具体的に記載されています。

STEP2：外部設計（基本設計）

要件定義の次は、外部設計（基本設計）を行います。外部設計は要件定義での決定内容を基に、要件を実現するためのシステムの基本設計を行う工程です。ユーザーインターフェース（UI）をはじめとした、主にユーザーから見える部分、データベースなど別システムとの連携の設計を行います。

操作画面、操作方法、データ出力の方法などが、設計で決める代表的な項目です。また、プログラムを記述する言語も、この段階で決定されます。要件定義の精度が高くなるほど、外部設計の作業にかかる時間は短くなるため、外部設計に進む前に、綿密な要件定義をしておくことが大切です。

外部設計は「方式設計」「機能設計」「その他の設計」へさらに細分化できます。方式設計は、開発言語やハードウェア・ソフトウェアの機能構造、ハードウェアの構成などを決定する工程であり、「アーキテクチャ設計」とも呼ばれます。機能設計は、システムを細かく分けたモジュール単位でデータベース方式設計を行う項目です。その他の設計では、納期や開発費用など、その後の開発での業務方針を決定します。

STEP3：内部設計（詳細設計）

内部設計（詳細設計）では、外部からは見えにくいシステム内部の設計を主に行います。機能分割、物理データ設計、入出力の詳細設計が作業内容です。上流工程はこの内部設計までであり、以降、これまでのシステム設計を基にプログラミングなどの開発作業を含む下流工程に移っていきます。

内部設計は「機能分割」「物理データ設計」「入出力の詳細設計」に分けて行うのが一般的です。機能分割では、各モジュールの機能を明確に決定します。物理データ設計は、データ・ファイルのやり取りについて決定する設計工程です。入出力の詳細設計では、外部設計で決定したUIの表現方法についてさらに詳細に決定します。

システム設計段階で発注側が確認すべきこと

システム会社は開発側の作業ですが、発注側が意識しなければならないこともあります。実際に使えるシステムを開発するために、知っておいていただきたいことをご紹介します。

認識のずれが起きていないか

発注者と開発者の間では、それぞれの視点が違うことからたびたび認識のずれが起こります。上述したとおり、要件定義の際は開発側によって要件定義書が作成されます。その後の設計工程は要件定義書の内容を基に進められるため、発注側がシステムに求めているものが反映されているか確認が必要です。

求めているものや要件と要件定義書の内容にずれがある場合は、適宜修正を求めます。発注側と開発側の認識のずれを出来る限りなくし、発注側で合意すると次の工程へ移ります。

外部設計の際にも、「外部設計書」「画面仕様書」「帳票仕様書」「インターフェース仕様書」といった書類が開発側によって作成されます。原則として、これらの書類は開発側から提出され確認が求められるため、合意できる内容になっているか詳細にチェックしてください。

開発側の担当者のコミュニケーション量は適切か

要件定義書は、開発側とのコミュニケーション内容を基に作成されます。コミュニケーション量が不足していると認識のずれが生じやすいため注意が必要です。

発注側の要望を不足なく伝えるため、定期的に打ち合わせの機会を設けましょう。打ち合わせの要望に対応してくれるかどうか、また、要望をスムーズにくみ取ってくれるかどうかは、ベンダーを選ぶ基準ともいえます。

設計書が標準化されているか

外部設計時には、開発側によって設計書が作成されます。この設計書は、その後のプログラミングの指針となる書類です。設計書は発注側にも提出されますが、内容が標準化されているか確認する必要があります。テンプレート化され誰もが理解しやすい設計書になっている場合は安心です。

プログラマー・システムエンジニアのスキルや知識に依存しない安定した作業が期待できるほか、プログラミング作業が効率化されているため滞りなくスムーズに納品されると考えられます。

丁寧なシステム設計を行う開発会社を選ぶことが重要

システム設計の内容や重要性、一般的な流れについて解説しました。システム設計は、その後の開発すべてに影響します。設計によっては、発注側の要望がほとんど反映されていないシステムができあがってしまうかもしれません。納品されたシステムに希望の機能が実装されていなければ、コストをかけて発注した意味がなくなってしまいます。

この点に留意し、システム設計を丁寧に行う開発会社を選ぶことが大切です。新たにシステム開発を依頼する際は、システム設計の段階から丁寧な連携を行い、開発コストがお得なYAZをご検討ください。