ITにおけるシステム設計とは？重要性と開発成功のポイントを解説
こんにちは。Wakka Inc.のWebディレクターの安藤です。
ITプロジェクトにおいて、システム設計はプロジェクト成功のカギを握る重要な工程です。それほど重要なシステム設計ですが、
「システム設計で実施すべき内容の理解が漠然としている」
「開発ベンダーにシステム開発を発注するときに、何を注意すべきかわからない」
と感じることも多いのではないでしょうか。本記事では、システム設計を円滑に進めるために必要な、
- システム設計で実施すべきこと
- システム設計を上手く進めるポイント
などについて解説します。システム開発を成功させるために、ぜひ本記事をご参考になさってください。
システム設計の相談ならWakka Inc.。
経験豊富なディレクターとエンジニアが貴社システムの設計をサポート可能です。システム設計のちょっとした疑問から お見積もり依頼まで、お気軽にお問合わせください
ITプロジェクトにおけるシステム設計とは
ITプロジェクトにおけるシステム設計とは、具体的にどういったことを指すのでしょうか。
システム設計で実施すること
システム開発工程において、システム設計は上流工程にあたります。
上流工程は要件定義と設計に大きく分けられますが、設計の中でも特に方式設計と外部設計（基本設計）を上流工程に分類することが多いです。要件定義と設計の目的を、おおざっぱに分類すると次のようになります。
要件定義
- システムを利用して達成すべき目的を明確にする
- 開発するシステムで実現したい内容について、いつ（When）、どこで（Where）、誰が（Who）、何を（What）、何のために（Why）の5Wを決める
設計
- 目的の達成にシステムが貢献するための手段を明確にする
- 要件定義で決めた5Wをシステムでどのようにして（How）実現するか、1Hを決める
システム設計の重要性
開発するシステムの具体的な機能や振る舞いは、システム設計の段階で決定します。プログラミング、テストといった開発工程の作業はすべて、システム設計の結果に従って進められます。
つまり、開発工程に入ってから仕様を変更するには、再度システム設計に戻ってやり直さなければなりません。やり直しが発生すると、スケジュールの遅延や開発予算の超過に繋がり、プロジェクトに打撃を与えます。
したがって、あとの工程で手戻りが発生しないよう、正確で質の高いシステム設計を実施することが重要です。
システム設計の流れ
システム設計における工程の分け方、呼び方はいくつかありますが、進め方や流れはほぼ同じです。本記事では要件定義を
- 業務要件定義
- システム要件定義
システム設計を
- 方式設計
- 外部設計（基本設計）
- 内部設計（詳細設計）
と分けて解説します。
業務要件定義
はじめに、ユーザーが実施する業務の流れを明確にし、業務の中でユーザーがシステムに求める機能を洗い出します。ユーザー業務の流れは業務フロー図で表されます。
業務フロー図の中では、システム機能の利用に関しても記載するのが一般的でしょう。
洗い出したシステム機能については別途、機能一覧の概要説明に、システム機能に対して期待する動作の概要を記載します。
性能、セキュリティ、運用に関して要望がある場合は、非機能要件として合わせて記載しても良いでしょう。業務要件定義で決まった内容は、業務要件定義書や要求定義書と呼ばれるドキュメントにまとめます。
開発ベンダーに発注する場合は、業務要件定義書や要求定義書にまとめた内容を、RFP*で開発ベンダーに提示しましょう。
※RFP……Request For Proposal：提案依頼書
システム要件定義
業務要件定義でまとめた内容をもとに、次はシステム要件定義を進めます。
システム要件定義では、業務要件定義で洗い出された機能について、業務要件を満たすために必要なシステム要件を定義します。
要件定義から開発ベンダーに発注する場合、システム要件定義は発注者と開発者が合同で進めることが多いでしょう。役割分担としては、発注者であるユーザー企業が主導的に進めるのがシステム要件定義です。
業務要件定義で作成された業務フローをもとに、さらにシステムの振る舞いに特化したシステムフロー図を作成し、より具体的な機能要件まで落とし込んでいきます。
性能、セキュリティ、運用に関する非機能要件についても合わせて定義します。
システム要件定義で決めた内容は要件定義書にまとめ、業務部門のレビューで承認されたら確定です。要件定義については下記の記事でも詳しく解説しています。
また、開発ベンダーにシステム構築を依頼することをお考えの方は、下記の記事も合わせてお読みください。開発費用の相場や、費用を抑える方法についても詳しく解説しています。
方式設計
要件定義で定められた要件を実現するため、システムに関連するハードウェアやソフトウェア、ネットワーク、外部システムとの連携方式などを決定する過程を方式設計と呼びます。
設計工程で実施する場合は外部設計（基本設計）の前の段階ですが、システム要件定義の中で合わせて実施されることも多いでしょう。
方式設計は開発ベンダーが主導で進めますが、発注者の自社内にシステムインフラ技術者がいる場合は、発注者の主導もしくは合同で進めることになるでしょう。方式設計では、主に以下の項目について決定します。
- ハードウェア構成
- ソフトウェア構成
- ネットワーク構成
- アプリケーションの基盤構造
- 外部システムとの連携方式
方式設計工程の中で技術的なリスクを明確にしておけば、あとの工程でトラブルにつながりそうな要因を未然に防げる可能性が高くなるでしょう。
また、性能やセキュリティなど、非機能要件を満たす対応を考慮するのも重要です。
外部設計（基本設計）
外部設計では、システム要件定義と方式設計で決まった内容をもとに、より具体的なシステムの振る舞いを決めていきます。
ユーザーが機能の振る舞いを具体的にイメージできる部分を中心に設計します。外部設計で取り扱う項目は以下の通りです。
- 画面設計
- 帳票設計
- 機能設計
- データベース設計
それぞれどのような設計をするか見ていきましょう。
画面設計
画面設計（UIデザイン）では、画面のデザインや振る舞いを具体的に決定します。
各画面のレイアウトや項目配置、ボタンやリンクをクリックしたときの動作はもちろんですが、画面間の遷移やメニュー構成も設計します。
帳票設計
帳票設計では、出力する帳票の形式（CSV、PDFなど）やデザインを決定します。
各帳票のレイアウトや、帳票に配置する項目と出力仕様などを具体的に設計します。
機能設計
機能設計では、画面から登録ボタンや検索ボタンなどをクリックしたときに、システムの裏側で実行される処理の振る舞いを設計します。
また、夜間などに一括でデータの更新処理を行うバッチ処理が必要な場合は、バッチ処理が実行する処理についても設計します。具体的に設計する内容は、機能が実行すべきIPO*の定義です。
※IPO……Input-Process-Output：インプットをもとにプロセスを整理して、アプトプットを行う考え方。設計書の作成や成果物の管理に利用する。
データベース設計
画面設計、帳票設計、機能設計の内容を受けて、システムがどのようなデータの持ち方をすべきか決めるのがデータベース設計です。
画面や帳票に必要な項目をそのままの形で保持するのではなく、正規化という作業でデータの構造を分析し、無駄なく効率的にデータを保持できるように設計します。正規化によってデータ構造の論理設計ができたら、次はテーブル設計です。
テーブル設計では実際にデータを格納する器であるテーブル名、テーブルに必要な項目と、項目の型や桁数を決めていきます。以上、外部設計で実施する内容を具体的に解説してきました。
開発ベンダーに発注する場合、外部設計は開発ベンダーが主導的に進める工程ですが、最終結果は発注者が承認するため、設計で実施される内容は十分理解しておいた方が良いでしょう。
最後に、解説した内容の要約と、設計で作成する主なドキュメントを一覧にまとめておきます。
| 設計対象 | 設計する内容 | 作成する主なドキュメント |
|---|---|---|
| 画面設計 | ・各画面のデザイン、レイアウト ・各画面に配置する項目と入出力の仕様 ・ボタンやリンクを押されたときの動き ・メニュー構成や画面遷移 ・ログイン、ログアウト、ヘルプなど共通画面の設計 | ・画面一覧 ・画面遷移図 ・画面レイアウト ・画面定義書 |
| 帳票設計 | ・帳票の形式（CSV、PDFなど） ・帳票のデザイン、レイアウト ・帳票に配置する項目と出力の仕様 | ・帳票一覧 ・帳票レイアウト ・帳票定義書 |
| 機能設計 | ・画面から登録ボタン、検索ボタンなどを押されたときの具体的な処理内容 ・データを一括で更新するバッチ処理の具体的な処理内容 | ・機能一覧 ・機能設計書 |
| データベース設計 | ・データ構造の分析と正規化 ・テーブル設計 | ・ER図 ・テーブル一覧 ・テーブル定義書 ・区分コード定義書 |
内部設計（詳細設計）
内部設計では、外部設計で確定した内容を、実際にシステムで実現するために必要な内部構造を設計します。内部設計は開発者に向けたものなので、基本的に発注者が深く関わることはありません。
ただし、内部構造を詳細に定義していく中で、外部設計や要件定義の内容にも影響する変更が必要なケースも出てくるため、開発者に対するフォローは引き続き必要です。
- 機能分割と共通機能設計
- データベース物理設計
- 入出力とプロセスの詳細構造設計
内部設計では、主に上記のような内容が設計されます。（一般的に、内部設計の結果を発注者がレビューする機会はあまりありません。）
システム設計で発注者が実施すること
システム設計からは開発ベンダーが主導的に進めることが多いのですが、発注者であるユーザー企業が積極的に支援すべきこともあります。
このパートでは、システム設計において発注者が実施すべき内容について解説します。
設計方針の提示
開発ベンダーにシステム設計を進めてもらう上で、自社の方針として設計に反映してほしいことがあれば、設計の最初の段階で提示しておくのが良いでしょう。一例ですが、よくあるのは次のような内容です。
- 画面の共通デザインとして、自社のコーポレートカラーや会社のロゴを指定する
- 表記のゆれ（マスタとマスターなど）が発生しやすい文言は、用語辞書に定義されている表記に統一してもらう
- 自社が共通で使用している設計書のフォーマットを指定する
- 自社で統一されている設計方式や共通部品がある場合は共通で使用してもらう
設計が進んでしまうとあとから変更するのが大変になるため、なるべく早い段階で提示しておきましょう。
開発担当者とのコミュニケーション
外部設計は開発ベンダーが主導的に進める工程ですが、設計の品質がシステムの使い勝手や品質に直接影響するところでもあります。
設計を進めていく中で、開発担当者だけでは判断が難しいことや、要件定義では出てこなかったユーザーの情報が必要になることも多いものです。
発注者は、開発担当者の判断をサポートし、設計上の疑問を解消するために、Q&Aのやりとりなどを通じて密なコミュニケーションをとるべきでしょう。
設計上の課題検討
設計を進めていく中で開発担当者が不明点や課題を発見した場合、発注者が課題を持ち帰って自社で検討し、解決しなければならないケースもあるでしょう。
- システム稼働後の運用に影響する課題
- 既存の他システムに影響する課題
例えば、開発担当者から上記のような相談を受けた場合、自社内で運用担当者や他システムの担当者も巻き込んで協議し、課題に対して適切な対応策を決める必要があります。
設計レビュー
外部設計の結果はシステムの使い勝手や品質に直接影響するため、開発ベンダーが実施した設計内容について、発注者は責任を持ってレビューをしなければなりません。設計レビューにおいては、
- 要件定義で決めた内容が反映されているか
- 設計方針として提示した内容が反映されているか
- ユーザーの使い勝手に問題がなさそうか
などの視点で設計ドキュメントを確認します。設計内容に考慮もれや気になる部分がある場合は遠慮なく指摘し、適切な修正を求めましょう。
設計の品質を担保するために、外部設計のレビューは極めて重要です。
システム設計を上手く進めるポイント
システム設定を上手く進めるためには、どのような点に注意すれば良いでしょうか。
外部設計を開発担当者に任せすぎない
外部設計は開発ベンダー主導で進めることが多いので、基本的には開発担当者が中心となって設計を進めます。
しかし、だからといって発注者が外部設計にほとんど関わらず、開発担当者に任せきりにするのはおすすめできません。発注者の意図した通りに、開発担当者が設計しているとは限らないからです。
例えば設計の期間中、画面のレイアウトや入出力項目などを決めるために、ヒアリングやレビューを実施する機会があるでしょう。
ヒアリングやレビューの場では、開発担当者の提示した設計内容を受け入れるだけでなく、積極的に要望を出して議論するのがおすすめです。
設計内容の考慮が不足していることもあるため、要望や意見を出すことで開発担当者の意識が高まり、設計品質の向上に繋がることも期待できるからです。
また、設計内容によってシステム稼働後の運用に影響しそうな場合は、持ち帰って自社内で方針を検討すべきでしょう。
計画的にコミュニケーションをとる
システム設計を円滑に進めるためには、開発担当者が抱えている課題を上手く引き出し、解決していくためのコミュニケーションが必要です。
特に外部設計の段階では、定期的な進捗報告会議を開催するだけではコミュニケーションが足りないことも多いものです。そこで、システム設計を円滑に進めるためのコミュニケーションとして、
- 課題検討会を定期開催する
- 重要なテーマを集中的に議論する場を設ける
のようなことを計画的に実施してみてはいかがでしょうか。議論を深めることで課題解決のポイントや、発注者の意図について開発担当者の理解が深まるでしょう。
また定期的にコミュニケーションをとれば、開発担当者と認識のずれが起きていないかを確認し、早い段階で軌道修正ができます。
ユーザーを巻き込んでレビューを実施する
外部設計の品質を向上させるためには、ユーザーを巻き込んでレビューするのも効果的です。早い段階でユーザーの意見を直接聞ければ、設計内容を軌道修正でき、品質向上に役立てられるからです。
また、開発担当者も設計で考慮すべきポイントを押さえられるため、その後の設計指針として活かせるでしょう。
すべてのレビューにユーザーを巻き込むのは難しいでしょうが、初回のレビューなど重要なタイミングで上手く巻き込めるよう計画してみてはいかがでしょうか。
システム設計のポイントを押さえてプロジェクトを成功へ！
今回は、システム設計の重要性、進め方、上手く進めるポイントについて解説してきました。その後の開発、テストなどすべての工程に影響するシステム設計が、いかに重要かおわかりいただけたでしょうか。
開発するシステムの品質は、システム設計で決まると言っても過言ではありません。
ポイントを押さえた取り組みでシステム設計の質を高め、プロジェクトを成功させましょう。
フルスクラッチのシステム開発のご相談はWakka.incまで
Wakka inc.では、専門性の高いチームがお客様のニーズに寄り添い、フルスクラッチでのオーダーメイド開発はもちろん、業務のIT化・開発リソースの確保など、ビジネスの成功に向けて着実にサポートします。
サポートの概要や費用感など、下記のお問い合わせフォームよりお気軽にご連絡ください。（構想段階で形になっていないアイデアでも問題ありません）
また、ラボ型開発やビジネスに関する豊富な資料も用意しています。お気軽にこちらからダウンロードください。
▼参考記事
学生時代にWebサイトを自作したことがきっかけでWebの世界に。制作会社でデザイン、WordPressテーマ開発の実務を経て、テクニカル・ディレクターとして大規模サイト構築のディレクションを経験。2021年からWakka Inc.の日本拠点でWebディレクターとして参画。最近はブロックエディタになったWordPressをもう一度、勉強しています。
