システム開発工程の一つに基本設計があります。開発の流れは理解しているものの、成果物が明確になっていないケースや詳細設計との違いが曖昧な方も多数いらっしゃるのではないでしょうか。ここでは各工程の概略を説明した上で、基本設計と詳細設計の違い、基本設計における成果物を解説します。
システム開発の工程
まずはシステム開発工程の概略を紹介します。工程の分け方は人によって様々ですが、ここでは10の工程に分けて工程を紹介します。
要件定義
要件定義フェーズは１番始めの工程でありながら、今後のシステム開発の段取りを決める最も重要な工程です。この工程ではクライアントの課題を明確にし、何を実現したいのか丁寧に洗い出すフェーズになります。
要件定義の作業は一見簡単そうに見えますが、実は非常に難度を伴う作業です。本工程ではクライアントの要望を抜け漏れなく描写し、双方が共通認識を持てるように擦り合わせを行う必要があるからです。もし機能要件や非機能要件に抜け漏れがあると、要件追加の作業が発生し、後工程の開発担当者、試験担当者が混乱する事態に陥り、プロジェクト全体の遅延や停止を招く可能性があるからです。現状の業務プロセスやフロー表を作成し、１つ１つの作業をしっかりと確認する必要があるのです。
—————————————————————————————————————
要件定義について詳しく学びたい方はこちらの記事をご参照ください。
関連記事：要件定義の成果物とはなにか？具体的な作業内容や進め方についてシステムエンジニアが解説
—————————————————————————————————————
基本設計（外部設計）
基本設計とは要件定義で決めた大まかな機能を１つ１つ検討し、それぞれの機能が「何を実現できるか」を決める工程です。主にユーザから見てシステムがどのように動くかを検討して、どのような動作になるのかを決めるため、別名としては「外部設計」とも呼ばれています。
例えば、要件定義で顧客の情報を登録できること、と定めるならば、基本設計では顧客情報の登録には登録ID、会社名、郵便番号、住所、電話番号などが必要であること、郵便番号から住所の一部を自動で取得すること、顧客情報を登録・変更するときには承認プロセスを経ることなどというような感じで要件定義の内容を詳細化していきます。
開発プロジェクトにおいては、要件定義から、基本設計を含めて「上流工程」と呼ぶのが一般的です。※諸説ございますが、開発会社の「上流工程」の定義の仕方によっては、この後の工程である詳細設計までを開発の上流工程と捉えるケースもございます。
—————————————————————————————————————
基本設計について詳しく学びたい方はこちらの記事をご参照ください。
関連記事：基本設計における成果物とは？開発工程の流れや注意点を含めて解説
—————————————————————————————————————
詳細設計（内部設計）
詳細設計は基本設計の内容をどのように実現するかを定義する作業です。別称として、内部設計とも呼ばれています。次工程の開発・製造工程で定義した機能を要件通りに実装するために開発者が実装ロジックを整理し、設計書等のドキュメントに落とし込んでいきます。この詳細設計作業を疎かにしてしまうと、実装したかった機能が実装できなかったり、誤った実装をしてしまう可能性があります。
—————————————————————————————————————
詳細設計について詳しく学びたい方はこちらの記事をご参照ください。
関連記事：詳細設計の成果物は何が重視される？進め方や注意点を紹介
—————————————————————————————————————
開発・製造（プログラミング）
開発・製造工程は実際にコーディングやインフラ面の境設定を行い、実際にクライアントが求めているものを作り上げていくフェーズを指します。本工程では要件定義から詳細設計で作り上げてきた設計書等のドキュメントを基に作業を進めていきます。
このフェーズでは１つ１つソースコードをプログラミングし、作っていく作業ですので、フルスクラッチ（オーダーメイド）による開発においては、最も時間が掛かる工程です。
また、スマホアプリ開発だけでなくインフラ部分の構築も同時並行的に進めていきますので、開発の段取りやマイルストーン管理も非常に重要になってきます。このあたりはPMと呼ばれるプロジェクトマネージャーの素量が試されます。
単体試験（単体テスト）
単体試験とはプログラムを開発した後最初に行われるテストのことです。単体試験の他、単体テストと呼ばれたりもします。プログラムを構成しているユニット（１単位）毎に正常に動作するかを試験していきます。単体試験では、コード作成時などの早い段階でエンジニアやテスター（試験担当者）によってレビューされることが多いです。
単体テストをスムーズに進めることで、早期にバグを抽出することができ、後続の作業を効率的に進めることができます。
—————————————————————————————————————
各種試験（テスト）について詳しく学びたい方はこちらの記事をご参照ください。
関連記事：テスト計画書とは何か。システム開発におけるテストの重要性を現役エンジニアが解説
———————————————————
結合試験（結合テスト）
結合試験とは単体テストの後に行われるテストのことで、機能毎に意図した通りの挙動になるかを確認するテストのことです。別称として、結合テストとも言われています。単体試験を通過した各ユニットを結合し、１機能として試験することで単体テストで発見できなかったユニットの連結部分のバグや問題点などを発見できます。また、操作と機能動作に関しても着目し、仕様書通りの挙動をするかどうかを検証する工程でもあります。
システム試験（総合テスト）
システム試験は別名、総合試験もしくは総合テストとも呼ばれ、システム全体の挙動が正常に動作するかを確認する工程になります。結合した機能を組み合わせて、開発したシステムが想定通りに動作するか、構築したシステムが仕様書通りの機能や性能要件を満たしているかについて検証していきます。ハードウェア関連のテストも行うため、ハードウェアを含めたシステム全体としてのバグを検出することができます。
運用試験（運用テスト）
運用試験は実際に運用オペレーション部門が業務の流れに沿って検証し、開発したシステムが使えるかどうかを確認するテストです。別称としては運用テストとも呼ばれています。実際の稼働状況に沿った運用試験を実施することで、業務に耐えうる設定になっているかを検証します。本工程ではシステム部門が主導するのではなく、運用オペレーション部門が主体となって検証作業を行い、開発会社やシステム部門はサポートに回ります。
場合によってはこの運用試験を行いつつ、利用するユーザー全体の教育を兼ねて実施することもあります。
システム移行（システム・マイグレーション）
システム移行とは、開発から運用テストまで、完成したシステムを開発環境から本番環境に移行し、一般ユーザーに使える状態にする工程です。開発会社の界隈ではマイグレーションとも呼ばれています。本工程ではプログラムだけでなく、データベースの移行や既存データの登録も行います。システム移行は前述した試験工程と同時並行的に進めるケースも多く、何度も移行リハーサルしながら検証作業を行います。場合によっては移行期間中に古いシステムを止めなければならないこともあり、移行時間に制限が設けられることもあります。そのため、入念な準備が必要となる工程であり、このあたりもプロジェクト万ージャーの力量が試されます。
システム運用・保守
システム運用・保守とは主にシステムの監視や障害対応、不具合対応などを行い、システムを円滑に動かすサポートをする工程を指しています。普段はシステムの監視や定常作業といった運用作業を行いながら、障害発生時には緊急対応を行い、可能な限り通常業務に支障が出ないように迅速かつ円滑な対応が求められます。近年のシステムは２４時間３６５日動いていることもあるので、監視ツールを上手く駆使しながらシステムの運用・保守を進めることが多いです。
基本設計とは？
ここでは基本設計の内容をより理解してもらうために、基本設計と要件定義の違い、基本設計と詳細設計の違いを紹介します。
要件定義との相違点
要件定義はクライアントが何をしたいのかを明確にするフェーズです。クライアントのやりたいことを機能単位で確認しながら必要な機能数と機能概要を決定させることが重要になります。また、技術者視点で各項目を確認し、システムとしてできること、できないことを峻別する工程でもあります。
一方、基本設計は要件定義で決めた機能をユーザー視点で具体化していくことが求められます。ユーザ目線でどのような項目が必要なのか、大まかな機能として具体的な挙動はどのようなものを想定しているか詰めていきます。
詳細設計との相違点
基本設計はユーザー視点から見た挙動を決定する工程なのに対して、詳細設計は開発者視点で要件を詳細化し、プログラミングできるレベルまで落とし込んでいくフェーズになります。
例えば、基本設計を「郵便番号から住所の一部を自動導出するボタンを設置する」と定義するのであれば、詳細設計では「郵便番号と住所のDB設計を行い項目を決める」といった感じになります。
基本設計工程の具体的な成果物
ここでは基本設計に必要な成果物の一例を紹介します。
業務フロー図
業務フロー図とはシステムをどのような業務で利用するのか、業務の流れとシステムの関係性を記した資料になります。標準化された記号や図形を使い、工程別に記すことが求められます。
業務フローはユーザーがそれぞれの役割を明確化し、業務の順序や関係性を整理するために有用です。また、業務フローを作ることで、この機能はどの業務で使う想定なのか、機能と業務の整合性を取ることもできます。
RFPの中でお客様から提供されるケースも多いですが、システム開発会社側の技術的観点から業務フローを確認、整理していきます。
システム構成図
システムフロー図とはシステム全体の構成を図で表したものです。
ネットワーク構成やハードウェアの構成、他のシステムとの関連性が重要視されます。例えば、他のシステムとの関連性では「顧客情報を○○システムに連携する」などといった情報を図で表すことになります。
画面一覧
画面一覧表はシステムの必要画面を一覧としてまとめた資料になります。通常、画面一覧に合わせて画面設計図や画面遷移図も作成します。画面設計図ではどのような画面にするのか、ユーザーと協議しながら必要な画面の項目、配置等を決定していきます。画面遷移図ではボタンを押したらどの画面に遷移するのかなど、画面の移り変わりを図としてまとめます。いずれの場合においても正常プロセスとエラープロセス両方の画面を定義することが重要です。
インターフェース図
インターフェース（略語：IF）図は要件定義やシステム構成図でまとめた資料をもとにどの情報をどのシステムに連携するかを決定します。また、連携する項目だけでなく、連携するタイミングや連携する方法、エラープロセスなども決定します。
１つ１つのインターフェースに対してこの検討を行いますが、全体感がわかるようにインターフェース一覧を作成することも重要になります。
帳票一覧
帳票機能では帳票を出力するにあたって必要な項目、レイアウトを決定します。よく帳票を出力するケースとしては生産管理システムで仕様書を出力する、販売管理システムで請求書を出力するなどです。要件定義で作成した帳票一覧をもとに1つ1つのレイアウトを決定します。特に注意しなければならないのが対外向けの帳票です。対向先の企業によってレイアウトを変更している企業もあるので、１つの機能に対して何パターンも作成しなければならないケースもあります。
コード一覧
DB設計を進めるにあたり、必要となるのがコード一覧です。コードに関する区分や内容を整理することで、将来的なシステム保守に活用されます。将来的なシステム刷新、改修、更改、移行等を踏まえて作成する必要があり、エンジニアの力量が問われます。
CRUD図
コード一覧と同様に、DB設計に必要不可欠なのがこちらのCRUD図になります。DBのテーブル別にどのような機能を搭載させるかを記述します。CRUDという言葉はあまり聞き馴染みがないかもしれませんが、DB設計の中で使用する操作、Create：生成、Read：読み取り、Update：更新、Delete：削除の頭文字を取り、CRUD（クラッド）と呼びます。DBの安全性や操作性を適切に保つために、テーブル別にCRUDを纏めておくことが肝要です。
バッチ一覧
バッチとは、通常の業務の裏で定期的に動いているプログラムのことです。例えば、対向先システムから送られてきたデータを自システムのDBに登録するといったプログラムのことを指します。要件定義で定義されたバッチ一覧をもとにバッチの処理フローやバッチの処理内容を決めていきます。また、バッチのトリガーやエラー時のハンドリングもこの段階で定義します。
DB設計書
DB設計ではデータをどのように保存するか決めていきます。業務プロセスなどをもとに保存するデータを一覧化したテーブル定義書やDBの関係性をまとめたER図などを作成します。
非機能要件一覧
非機能要件とは具体的な業務プロセスとは直接的に関係ない機能を指します。前工程の要件定義工程の中で作成することもありますが、設計作業とも密な関連性があり、設計工程の中で作成・更新することもございます。非機能要件では大きく４つの項目に注力して定義していきます。
- 可用性：システムを継続的に利用するための要件です。システムの冗長化や運用スケジュールなどを定義します。
- 性能・拡張性：システムの処理速度や今後のシステム改修における拡張性を定義します。処理速度においてはどれくらいのトランザクションを処理できるか、画面遷移に何秒かかるかなどを定義します。
- 運用・保守性：システムの監視方法やバックアップ方法、保守体制を定義します。
- セキュリティ：システムのセキュリティ対策について定義します。アクセス制限や不正検知・監視の方法について定義します。
基本設計で失敗しないポイント３選
ここでは基本設計で失敗しないポイントを３つ紹介します。
実現方法が適切かどうか見極める
要件定義書ではあくまでユーザー目線として何をするかの概略を定義するものになります。したがって、どのような方法で実現するかまでは定義していません。基本設計ではこの方法を定義することが重要になります。この工程で実現方法を明確にしていない場合、詳細設計で大きな問題が発生する可能性があります。特にインターフェースなど他システムと連携するような処理の場合は要注意です。運用・保守している会社は別の会社であるため調整に時間がかかります。対向システムでも処理ができるのか、改修において追加費用がどれくらいかかるのか明確にしておきましょう。
要件定義との整合性をしっかり確認する
基本設計は要件定義の後工程に位置する工程です。基本設計の後、内部設計と呼ばれる詳細設計に入り、基本的には設計書を基に開発・製造、各種試験に進んでいきます。また基本設計で定めた業務プロセスに従ってテスト仕様書を作成していきます。基本設計は要件定義に比べるとより細かい部分を見ていくことになりますので、いつの間にか要件定義から反れてしまうといったケースが往々にして発生します。そのような事態に陥りますと、要件定義で決めた業務内容とは異なるシステムが出来上がってしまいますので要注意です。設計を担当するエンジニアは定期的に要件定義で作成した各種資料をしっかりと見返し、当初決めた方向性と反れていないかを確認するようにしましょう。
プロジェクト管理方針を明確にする
基本設計は細かいプロセスを確認していくため、作業量が膨らみやすいプロセスの一つと言えます。場合によっては現場のユーザーに確認しなければ決められないことも多く発生します。そのため、予め管理手法を明確にしておかないと何を決めればよいのか分からなくなるケースも出てきます。管理手法を明確にし、プロセスごとに開始と完了時期がわかるようにしましょう。
また、基本設計では課題やリスクも出てきます。これらを管理して、メンバー全員に共有できる管理方法も決めておく必要がありますので、こちらも入口段階から気を付けるとプロジェクトの品質がグッと高まるでしょう。
まとめ
本記事では、システム開発における各工程の概略をご紹介した上で、基本設計と要件定義の違い、詳細設計との違い、基本設計で必要な成果物、基本設計を成功させるポイントをご紹介しました。
基本設計は要件定義で決めたことを具体的にし、詳細設計や開発工程を効率良く実施するために重要な工程です。基本設計では要件定義との整合性に気をつけて、実現方法を明確にするようにしましょう。
—————————————————————————————————————
システム開発、スマホアプリ開発、MVP開発、新規事業立ち上げ、DX化の推進でお困りではありませんか？
日本全国には開発会社が無数にありますが、Webサービスやアプリサービスのスケール（規模拡大）を実現するビジネス推進力やシステムの堅牢性、可用性を意識した設計力・技術力を合わせ持つ会社は、全国で見ても多くはなく、弊社は数少ないその一つ。お客様のご要望通りに開発することを良しとせず、お客様のビジネス全体にとって最適な解を模索し、ご提案ができるビジネス×テック（技術力）×デザインの三位一体型のシステム開発/アプリ開発会社です。ITやDX全般に関して、何かお困りのことがございましたら下記の「GeNEEへのお問合せ」フォームからお気軽にご連絡いただけたらと思います。
—————————————————————————————————————
