システム設計とは？
システム設計とは、プログラミングなどの実装工程に進む前に必要な機能や仕様を明確化し、設計書としてまとめる工程です。
システム化しようとしている業務フローやニーズなどを分析し、どこに課題が隠れているのか特定するところから、設計書にまとめるところまでを担います。
システム設計が重要な理由
システム設計が重要な理由は、設計段階でシステムの内容がほとんど決まるためです。
設計の不備が開発の後期段階で発覚すると、修正に多大な時間とコストがかかります。
また、設計時の要件定義が明確でないと、複数の開発者がそれぞれ独自の解釈で開発を進めてしまい、品質のばらつきが生じたり、当初の要件を満たさないシステムになったりするリスクも高まります。
このような理由から、システム設計はプロジェクトを成功させるために欠かせない重要なプロセスと言えるでしょう。
システム設計の流れとは？
システム設計の流れは、以下の通りです。
①要件定義
②基本設計（外部設計）
③詳細設計（内部設計）
④単体テスト
⑤結合テスト
⑥受け入れテスト
ここからは、システム設計の工程について、それぞれ詳しく説明します。
参考：デジタル庁. “デジタル・ガバメント推進「標準ガイドライン」研修資料”. 2022
①要件定義
システム設計の最初のステップは「要件定義」です。
ここでは、発注者の要望を詳細に分析し、システムの目的・必要な機能・予算・人員・スケジュールなど、開発プロジェクトの全体像を明確に定義します。
一般的には「プログラミングがシステムの質を決める」と認識されていますが、実は、システムの質は要件定義の時点でほとんど決まってしまいます。
この要件定義で決定された内容がその後の開発プロジェクトの道筋となるため、非常に重要です。
②基本設計（外部設計）
基本設計は、要件定義で決定した要件を元に、システムに実装する機能を具体化する工程です。
機能の内容・画面のデザインをはじめとした、発注者側から見たシステムの動作を定義するため「外部設計」と呼ばれることもあります。
リリース後ユーザーが直接目にする部分なので、適宜レビューを実施して、認識のすり合わせを行うことが大切です。
③詳細設計（内部設計）
詳細設計は、基本設計で設計した内容をさらに具体化し、プログラマーがコーディング作業をおこなえるレベルまで落とし込む工程です。システムの内部構造を設計するため「内部設計」とも呼ばれます。
設計内容が曖昧だったり不十分だったりすると、後工程での手戻りやバグの発生につながるので、綿密に設計することが大切です。
しかしユーザーの目には触れない部分なので、基本的に、発注者へ詳細設計のレビューを求めることはありません。
④単体テスト
単体テスト（ユニットテスト）は、プログラムの個々のプログラムやモジュールが正しく動作するか確認する工程のことです。
システム開発の初期段階で「プログラムを構成する比較的小さな単位（ユニット）が正しく機能しているか」テストを行うことで、この後のテスト工程での手戻りのリスクを低くすることができます。
⑤結合テスト
結合テストとは、複数のプログラムやモジュールを組み合わせたときに正しく機能するかを検証する工程です。一般的には、プロジェクトの中盤から終盤にかけて行われます。
単体テストのように挙動を確認するだけでなく、要件定義で必要とされた機能を搭載するためにはどの機能を組み合わせるべきか・仕様書の通りに機能間の連携がされているか など、さまざまな視点から確認する必要があります。
⑥受け入れテスト
受け入れテストは、単体テスト・結合テストを終えて完成したソフトウェアが業務要件を満たしているか、実際の利用環境で動作するかを確認する工程です。そのため、基本的には発注者側が行う必要があります。
ただし、受け入れテストを行うリソースやスキルが不足している場合は、第三者のパートナー会社の支援を受けてテストを実施することもあります。
システム設計での失敗を防ぐコツ
システム設計での不備は、後工程でのトラブルや手戻りの原因になります。ここからは、システム設計の際に注意するべきことを詳しくお話しします。
【計画】詳細な要件定義
システム設計で失敗を防ぐためには、できる限り詳細な要件定義を制作することが重要です。
要件定義時のアウトプットは、その後の設計者や開発者にとってのインプットになります。
要件定義が正しく行われていないと、その後の工程で手戻りの原因になったり、ニーズに合わないシステムになったりするリスクが高まります。
以下のような点に留意して、発注者側と開発会社側が、共にシステムの要件定義を進めていくことが大切です。
・あいまいな表現を避ける
・定期的にレビューする
・発注者の要求を深く理解する
・非機能要件まで明確にする
【計画】実現性のあるプランを立てる
基本設計の工程に入ると、要件定義の段階で決められた要件を叶えるための具体的な工程と、それを叶えるためのプランを決めることになります。
この時、実現可能性の低いプランを立てると、開発に十分な時間を割けない・適切な人員が配置されないなどのリスクが生じます。
・要件の優先順位付け
・技術的な実現性の確認
・開発期間とコストの見積もり
・人員計画
・リスク管理
システム設計を成功させるには、以上の点に留意しながら、実現性のある綿密なプランを立てることが非常に重要です。
【実行】設計書フォーマットの統一
プロジェクトの規模が大きければ大きいほど、システム開発をスムーズに進めるためには、設計書フォーマットを統一する必要があります。
例えば「同じシステムなのに、機能ごとに仕様書の記述方法が違う」「フォーマットがなく、担当者が独自の形式で書類を作成している」状態だと、開発者が内容を理解するために余計な時間をかけることになったり、誤解を生んでしまったりする可能性があります。
システム開発にあたっての工数を削減するためにも、発注者が求めるシステムを正しく開発するためにも、設計書フォーマットや記述のルールなどを明確にすることが大切です。
【実行】仕様変更は確実に反映させる
システム開発を行う中で、設計時やプログラム開発時に仕様が変わることは少なくありません。
そういった仕様変更が生じた場合に留意するべきことは「仕様変更が発生したら確実に反映すること」です。仕様変更が設計書や関連ドキュメントに適切に反映されないと、開発の後期段階での手戻りや、リリース後の不具合につながる可能性があります。
仕様変更が遅れると、その分大規模な修正が必要になります。
金銭的にも時間的にも大きなコストがかかってしまうので、関係者が仕様変更を把握できるよう変更管理表を作成したり、履歴を随時残しておいたりすることが非常に大切です。
【実行】各工程の基準を満たしてから作業を進める
これはシステム設計に限った話ではありませんが、システム開発時には「各工程で明確な完了基準を設定し、その基準を満たしてから次の工程に進む」ことがとても大切です。
完了基準を満たさずに次の工程に進んでしまうと、後工程での手戻り・プロジェクトの遅延などを招く可能性があります。
「設定した完了基準が満たせていない場合は、妥協するのではなく、スケジュールの見直しを行う」など、開発者の中でルールを設置し発注者にも理解していただけるよう努力を行う必要があります。
【管理】こまめなミーティング
方式設計以降のフェーズは要件定義を元に進められるため、要件定義の内容が少しでもズレていると、その後の開発内容が全て発注者の意図とは違うものになってしまう可能性もあります。
このように、開発者と発注者の間で認識のズレが発生し、トラブルにつながるケースも多いです。
要件定義の際に概ね合意しているとしても、詳細までは詰められていないことも多いため「発注者が求めているシステムを開発できているか」を確認するために、発注者と開発者は、各工程でのこまめなミーティングを通して開発内容を固めていく必要があります。
【管理】適切なレビュー
システム設計を行う際は、次の工程に進む前に発注者からのレビューを行う必要があります。
認識のズレ・仕様の漏れ・設計の不備などがある状態で次の工程に進むことは、手戻りやトラブルのリスクを高めるからです。
発注者がレビューを通して作業状況を確認すること、開発者がレビューの指摘を確実に設計書に反映させることを徹底すれば、こういったリスクを回避し、スムーズにシステム開発を進めることができるでしょう。
システム開発の際は、BLUEWIND ASIAへ
システム開発を成功させる鍵は、システム設計などの設計段階にあります。
特に要件定義やレビューの際には綿密なコミュニケーションが求められることから、システム開発会社を選ぶ際は、値段や実績だけでなく「担当者とのコミュニケーションの気持ちよさ」なども重視する必要があります。
弊社BLUEWIND ASIAは、フィリピンのセブ島でオフショア開発の支援を行っており、日本の大手企業さまとのお取引実績も50件以上ある企業です。
オフショア開発では「海外人材が窓口になっているのでコミュニケーションを取りにくい」などの問題も散見されますが、弊社では必ず窓口に日本人の担当者を配置しておりますので、
「オフショア開発においてネックになる言語・文化の障壁なく、さらに国内で開発を行うよりも安価にプロジェクトを進行できる」と好評をいただいております。
自社の体制にオフショア開発は向いているか？予算や納期の目安は？など、小さなことからでも構いません。
日本人スタッフが丁寧にお話しを伺いますので、まずはお気軽にお問い合わせください。