システム開発といえば、Javaなどの言語を駆使してプログラミングすることや、オシャレで洗練されたWebデザインを用いてWebサイトを構築することに注目が集まりがちですが、そこまでに至るまでのシステム設計の工程がとても重要なことをご存知でしょうか？

家を建てる際はきちんと作成した設計書・設計図がなければ進められないように、システム開発においても、流れにそったカタチで設計をこなしていくことが求められます。

今回はこのシステム設計について、基本からおもな流れや失敗を防ぐコツ、準備についてエンジニア目線で解説します。

システム設計とは？

システム設計とは、システムを実際に開発（プログラミング）する工程に入る前に、システムに必要な機能や仕様を決め、仕様書や設計書に落とし込む作業のことを指します。

作業としては、現状の業務フローを把握し、経営陣から現場の担当者までどのような課題に直面しているのかなどをヒアリング。それがシステムによって解決可能な課題の場合には、要件としてまとめることからスタートします。

設計が重要な理由は、システムの内容は設計段階で決まると言っても過言ではないからです。実際に開発するフェーズに入ってからの修正指示は受け入れられない現場も少なくありません。

仮に修正できたとしても、時間や予算が大幅に超過してしまうケースも発生し、スケジュールの遅延やカットオーバーの延期などにつながります。

細部にまでこだわったシステム設計をしておくことは、後々のトラブルを回避させるためにも不可欠だといえます。

システム設計のおもな流れ

システム設計は、システム開発の「上流工程」という部類に含まれます。上流工程のおもな流れは、「要件定義」「方式設計」「基本設計」「詳細設計」の4つのプロセスに分類することができます。

それぞれ順を追って確認していきましょう。

STEP1. 要件定義

まずはシステム開発における最上流工程に位置している「要件定義」からです。

要件定義とは、発注者の開発要望を踏まえて、システム開発の概要、目的、必要な機能、必要な予算、人員、スケジュールなどを定義づける工程のことを指します。開発プロジェクトはこの要件定義のフェーズで決めた内容をもとに進んでいくため、とても重要な工程となります。

仮に要件定義があいまいなままプロジェクトを進めてしまうと、以下のような問題に直面することでしょう。

・想定していたシステムと違うシステムが出来上がる
・ユーザーが業務で使うことのない機能が搭載される
・開発スケジュールや本番稼働が大幅に遅れる
・予算が大幅に超過してしまう

こういったことを避けるためにも、システム開発を依頼する場合には、業界への理解がある開発会社に依頼することも選択肢のひとつです。

また、要件定義の大まかな流れは以下の通りです。

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

ユーザーがシステムに対して求める仕様を定義し、システム化の対象となる業務の流れ（業務要件）を明確にするところからがスタートです。業務要件を明確にできれば、そのなかからシステムで実現すべき要件（機能要件）を定義します。また、機能以外でもユーザーがシステムに求める要件（非機能要件）も定義する必要があります。

最後に、要件定義のフェーズで固まった要件をまとめて「要件定義書」を作成します。要件定義書はユーザーも確認する資料であることを踏まえて作成することが求められます。

Web制作の要件定義で発注者側が知っておきたい4つのポイント｜東京のWEB制作会社・ホームページ制作会社｜株式会社GIG

Web制作やシステム開発においては、制作会社にすべてを一任するのではなく、発注者側も認識のズレがないかどうか、最新の注意を払う必要があります。今回は、発注者側も知っておくべき要件定義での4つのポイントをご紹介いたします。

giginc.co.jp

STEP2. 方式設計

要件定義で決めたことを実現するために、関連するハードウェアやソフトウェア、ネットワーク、外部I/Fなどを定義することを「方式設計」と呼びます。

方式設計では、技術的なリスクも明確にする必要があります。この段階でそういったリスクを割り出すことができれば、実際の開発工程でのトラブル抑止にもつながってくるからです。

また、パフォーマンスやセキュリティといった非機能要件についても十分に考慮することが求められます。非機能要件に関しては、機能要件よりも検討事項が多くなるケースも想定されますので、まずはIPA（独立行政法人情報処理推進機構）が定義する「非機能要求グレード」を参考にするのがおすすめです。

以下は、方式設計に含まれる代表的な作業です。

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

STEP3. 基本設計

基本設計とは、要件定義で決めた事項を実現させるために、システムに実装する機能を明確化していく工程のことを指します。ユーザー向けに行われる設計でもあるので、ユーザーから見たときにどのような動作になるのかを決める「外部設計」という呼び方がされることもあります。

先ほど見た方式設計に対して、実装する機能やデータベース、画面、帳票などを設計することを「機能設計」と呼び、基本設計の一部として方式設計後に行います。機能設計では機能ごとにシステムを分割し、それぞれの機能が要件を満たすように設計していきます。

機能設計がある程度固まったら、基本設計書に落とし込みます。基本設計書にはユーザーに具体的なシステムの仕様に問題がないかを確認してもらう役割もあります。

基本設計書に盛り込まれる項目は、以下のようなものになるのが一般的です。

・機能一覧
・業務フロー図
・システム構成図
・画面設計図
・帳票設計図
・バッチ設計図
・データベース設計図
・外部UI設計図

STEP4. 詳細設計

詳細設計とは、基本設計書をもとに、プログラミングを行うエンジニア向けに「機能をどのように実装するのか」という設計を行う工程のことを指します。

詳細設計書を見ただけでエンジニアがプログラムを組めるよう、細かい部分までテキストに落とし込むことが求められます。基本設計と違い、ユーザーからは見えない部分の設計を行うため「内部設計」と呼ばれることもあります。

詳細設計で作成するドキュメントにもさまざまな種類がありますが、「画面設計」や「帳票設計」などは、基本設計で作成した成果物をベースにより詳しく設計し、エンジニアが開発で活用できるレベルまで落とし込みます。

また、「クラス図」や「シーケンス図」といった詳細設計ならではのドキュメントを作成する場合もあります。基本設計とは異なり、ユーザーの目に触れない範囲が対象となるため、プログラミングに必要な内容をエンジニアがわかるように表現することが求められます。

詳細設計書に盛り込まれる項目は開発内容によって異なりますが、以下のようなドキュメントを作成することが多くなるでしょう。

・画面設計や帳票設計などをより詳しく説明したテキスト、図表
・クラス図
・アクティビティ図
・シーケンス図
・モジュール構成図

システム設計で失敗を防ぐコツ

システム開発の経験がない方は、どうしてもプログラミングすることに意識が集中しがちですが、システム開発を成功させるためには、プログラミングの前段階である設計工程がとても重要です。

設計がきちんと行われていれば、その設計をもとにあとはプログラミングするだけとなるので、失敗のリスクを大幅に減らせます。

ここからはシステム設計で失敗しないコツについて、エンジニア目線で解説します。

コツ1. 設計書は標準化させる

メンバーの違いによって発生する差を最小限に抑えるためには、設計標準や開発標準などの標準書類をまずは作り、それらを遵守させるルール作りが不可欠です。

そのため、多くのメンバーが参画する開発現場では、ドキュメント類はなるべく統一・標準化させておく必要があります。

ですが、現実は実行するのが難しい作業でもあります。どの開発現場も限られた工数・人員でタイトなスケジュールを意識しつつ作業を進めざるを得ないため、下準備にそこまでの時間はかけられないのが本音です。

他のシステム開発で使用した標準書類がある場合はそれらを流用したり、設計書にある程度の制限をかけたりすることで、それ自体をシステム設計標準として機能させるなど、標準化させるための工夫も必要になってくるでしょう。

コツ2. あいまいな部分を少なくする

要件定義→基本設計→詳細設計とフェーズが進むにつれ、機能や仕様についてより深掘りし、要件を詰めていく必要があります。しかし、詳細設計の段階に入ってもあいまいな部分が多く残っているようでは「今まで何やってたの？」と開発メンバーから不満があがってくることでしょう。

理想はエンジニアが詳細設計書を確認するだけで、それに沿ったカタチですぐにプログラミングに取り掛かれるような状態です。

「ここの仕様はこれで大丈夫なの？」と疑問を持たれるような設計書では良い設計書とは言えません。あいまいな部分は極力なくし、エンジニアなら誰もが理解できるようなドキュメント作りを心がけましょう。

また、説明文はなるべくシンプルにまとめてください。長い文章だと読み手は理解するのに時間がかかりますし、誤解して受け取る可能性も高くなります。説明事項が多くなる場合には、箇条書きにしたり、図や表を使用したりして工夫するのもおすすめです。

コツ3. 実現性を意識する

要件定義の段階では、要件の実現方法にまで踏み込んでいないので、多くの実現方法が存在する状態です。しかし、基本設計の段階からは後の工程も意識しながら適切な実現方法を選択する必要があります。

インフラの構成からシステムの機能、処理性能や運用面を考慮するのはもちろんのこと、それらを実現させるためのコストも検討事項に含まれるでしょう。

判断が難しいケースなどでは、特定の技術や業務に詳しい専門家に意見を求めるのも選択肢のひとつです。

コツ4. 認識のズレが起きていないか確認する

システムの発注者側と開発者側では、しばしば認識のズレが発生します。

要件定義書は開発者側によって作成されますが、システムの設計フェーズは要件定義書の内容をもとに進められるため、そもそも要件定義書の内容が間違っていては意味がありません。発注者側がシステムに求めているものがきちんと反映されているかどうかをしっかり確認しましょう。

発注後、もし求めている機能や要件が要件定義書の内容とズレていると感じた場合、速やかに修正を求めましょう。後で指摘しても「もう工程が進み過ぎて修正できない」「追加で費用がかかる」などのトラブルに発展する可能性が高くなります。

発注者側と開発者側の認識のズレはできる限りなくせるように、ミーティングの機会は設計工程では多く設けるようにしましょう。

コツ5. レビューを適切に行う

これは設計工程に限った話ではありませんが、システム開発においては次の工程に移る前に随時レビューを行うことがとても大切です。

認識のズレや仕様漏れがある状態で次の工程に移ってしまうと、それが原因でトラブルや手戻りが発生し、その結果プロジェクトが頓挫してしまうことにもつながりかねません。

次の工程に移る前には適切なレビューを実施し、後々のトラブルを回避するように努めましょう。

しかし、ただレビューするだけでは意味がありません。レビュー時の指摘を正しく設計書に反映してこそ実のあるものになります。設計工程が終盤にさしかかると、仕様変更の影響範囲は大きくなるため、影響調査も含めて工数は増加します。少しでも疑問や不安がある箇所はすべて指摘しましょう。それが双方のためにもなります。

システム設計を開発会社に依頼する前の準備

システム開発を進めるうえで、要件定義からシステム設計に至る工程はキモになります。この部分は、信頼できるシステム開発会社に依頼することをおすすめします。

最後に、システム設計を依頼する前の準備についても解説を行います。

1. システム開発の契約形態を知る

システム開発の契約形態には、おもに「請負契約」と「準委任契約」の2パターンが存在します。

■請負契約

請負契約とは、「仕事の完遂」をもって契約が完了する契約形態のことを指します。つまり、システムやソフトウェアなどの納品物を納品することで契約が完了することを意味します。

基本的にはチームはプロジェクト単位で組まれ、プロジェクトが終了したらチームは解散します。

請負契約では、プロジェクトマネジメントも含めて委託先に一任するため、手をかけずに開発を行える一方、発注後の仕様変更などは困難です。そのため要件定義のフェーズがとても重要になります。

■準委任契約

準委任契約とは、「契約期間に仕事を実施」すれば契約が完了となる契約形態のことを指します。つまり、開発業務を行う際、システムやソフトウェアなどの納品物がなくても契約違反とはなりません。

一定の期間・一定数の人材を確保したうえで開発業務を進めることができるので、契約期間中であれば、プロジェクトの進捗状況に応じて開発内容の変更も可能です。

専属チームとして人材を確保できるぶん、より社員に近いカタチで開発を進めることができますが、直接の指揮・命令関係が生じないことを覚えておく必要があります。

近年では、社外に専属の開発チーム（ラボ）をつくり、開発を進めるラボ型開発も注目されています。ラボ型開発も準委任契約に含まれるため、興味のある方はぜひ下記の記事も参照ください。

ラボ型開発とは？ 請負型との違いやメリット・デメリットを解説｜東京のWEB制作会社・ホームページ制作会社｜株式会社GIG

giginc.co.jp

2. 提案依頼書（RFP）を作成する

RFPとは、「Request for Proposal」の略称で、直訳すると「提案依頼書」になります。システムを発注する側の企業が、開発会社に対して提案してほしい内容をまとめた文書のことを指します。

RFPに要望や依頼事項をまとめて記載することで、提案依頼を受けた複数の開発会社は、共通の条件のもとで提案書の作成や見積額の算定が行えます。

仮にRFPを作成しないで各社から提案依頼を受けた場合、提案範囲や見積額にバラつきが発生します。

これでは、各社からの提案依頼を横ならびで比較検討することが難しくなってしまうでしょう。RFPを作成するには時間や手間もかかりますが、最終的に期待しているシステムを手に入れるためには、しっかり準備を行ったうえでRFPを作成することをおすすめします。

RFPの書き方とは？ サンプル・テンプレ付きで準備やポイントも解説！｜東京のWEB制作会社・ホームページ制作会社｜株式会社GIG

giginc.co.jp

3. 複数社から見積もりを取得する

作りたいシステムの方向性が決まったら、発注先候補となる制作会社に見積もりを依頼しましょう。

馴染みの企業があると、どうしてもその企業に依頼しがちですが、制作会社にも得意・不得意の分野があるため、その企業が期待しているシステムを納品してくれるかどうかはわかりません。依頼先が1社だけだと適正価格も見えてこないので、必ず複数社に見積もりを依頼するようにしましょう。

見積り依頼を行う際には、RFPや提案依頼事項に対する回答も同時に取り寄せます。依頼事項に対してしっかりと回答がもらえているか、スケジュールや費用の概要を比較検討したうえで、発注先を決めていきましょう。

システム設計はGIGにお任せください

今回はシステム設計について解説を進めてきました。システム設計のフェーズは要件定義とセットで考えるべき工程であり、かつ開発会社に一任していいものでもありません。システム開発のプロジェクトを成功へ導くためにも、システム設計の重要性を再認識していただき、積極的に関与していくことが大切です。

またスムーズにシステム開発を進めるためには、システム開発の会社選びも重要なポイントです。可能であれば、要件定義からシステム設計、開発、リリース、保守・運用まで一気通貫しての作業を行える開発会社に依頼するのがベスト。

GIGには、培ってきたシステム開発のノウハウと知見を活かした開発体制が整っており、システム設計からサイトリリース後の保守・運用まで一気通貫でのご支援が可能です。それぞれの企業様ときちんと向き合い、豊富なシステム開発の実績から最適なサポートをご提供いたします。

システムの設計・開発を検討している方、すでに稼働している自社システムの保守・運用の内容を見直してみたい方は、まずはお気軽にお問合せください。

■株式会社GIG
お仕事のお問い合わせはこちら
採用応募はこちら（GIG採用サイト）
採用応募はこちら（Wantedly）

■システム開発事例
サッポロ うちれぴアプリ - UIUXデザイン / アプリ開発
WAmazing - 多言語メディアサイト制作 / システム開発
Azoom - コーポレートサイト制作 / システム開発

GIG BLOG編集部

株式会社GIGのメンバーによって構成される編集部。GIG社員のインタビューや、GIGで行われたイベントのレポート、その他GIGにかかわるさまざまな情報をお届けします。