「システム開発を外部に依頼したいが、何がどう進むのか分からない」「途中で認識がずれて手戻りが発生した」——こうした悩みは、開発の全体像を把握しているかどうかで大きく変わります。この記事では、システム開発の標準的な流れと各工程の進め方を、発注側・開発側の双方の視点から整理します。専門用語はかみ砕いて説明するので、開発の経験が浅い担当者でも全体像をつかめます。
システム開発の全体像
システム開発は、大きく次の6つの工程に分けられます。前の工程の成果が次の工程の入力になるため、各工程の品質が後工程に積み上がっていくのが特徴です。
| 工程 | 主な内容 | 代表的な成果物 |
|---|---|---|
| 要件定義 | 何を作るかを決める | 要件定義書 |
| 設計 | どう作るかを決める | 基本設計書・詳細設計書 |
| 実装 | プログラムを書く | ソースコード |
| テスト | 正しく動くか検証する | テスト仕様書・結果報告書 |
| リリース | 本番環境へ展開する | リリース手順書 |
| 運用・保守 | 安定稼働を維持する | 運用マニュアル・障害対応記録 |
それぞれを順に見ていきます。
要件定義 — 何を作るかを固める
要件定義は、プロジェクトの成否を最も左右する工程です。ここでの認識ずれは、後工程で何倍ものコストになって跳ね返ります。
要件には大きく2種類あります。
- 機能要件: システムが何をするか（例: 会員登録ができる、注文を検索できる）
- 非機能要件: どのくらいの品質で動くか（例: 同時1000人が利用できる、画面は2秒以内に表示される、99.9%稼働する）
非機能要件は見落とされがちですが、後から「遅い」「落ちる」といった問題の温床になります。性能・セキュリティ・可用性・運用性を、この段階で言語化しておくことが重要です。
発注側のポイント: 「業務でどう使うか」を具体的に伝えること。理想は完璧な仕様書ではなく、現場の実態が共有されることです。
設計 — どう作るかを決める
設計は「要件をどう実現するか」を技術的に落とし込む工程です。一般に2段階に分かれます。
基本設計（外部設計）
利用者から見える部分を設計します。画面のレイアウト、操作の流れ、入出力するデータの項目、他システムとの連携方式などです。発注側がレビューに参加しやすい工程でもあります。
詳細設計（内部設計）
開発者向けに、内部の処理ロジック、データベースの構造、モジュールの分割などを定義します。ここはエンジニアの領域ですが、設計の妥当性が実装の品質を決めるため、技術力の差が出やすい部分です。
実装 — プログラムを書く
設計に基づいてプログラムを書く工程です。単にコードを書くだけでなく、次のような開発の作法が品質を左右します。
- コードレビュー: 他の開発者が変更内容を確認し、バグや設計の問題を早期に発見する
- バージョン管理: Gitなどでソースコードの変更履歴を管理し、複数人での並行開発を可能にする
- CI/CD: 自動でビルド・テスト・デプロイを行い、品質と速度を両立する
近年は生成AIによるコード補完やレビュー支援も実装の生産性を押し上げています。ただし、AIが出力したコードもレビューと検証は不可欠です。
テスト — 正しく動くかを検証する
テストは品質を担保する要です。段階的に範囲を広げていきます。
| テストの種類 | 検証する範囲 |
|---|---|
| 単体テスト | 個々の関数・部品が正しく動くか |
| 結合テスト | 部品同士をつないで正しく連携するか |
| システムテスト | システム全体が要件どおり動くか |
| 受入テスト（UAT） | 発注側が業務で使えるかを確認する |
特に受入テスト（UAT）は発注側が主役です。実際の業務シナリオで動かし、「現場で本当に使えるか」を確認します。ここを開発側任せにすると、リリース後に「思っていたものと違う」が発生しやすくなります。
リリース — 本番環境へ展開する
完成したシステムを本番環境へ展開します。リリースには手順とリスク管理が欠かせません。
- リリース計画: いつ、誰が、どの順で展開するかを決める
- 切り戻し（ロールバック）手順: 問題が起きたときに元に戻す手順を用意する
- 段階的リリース: 一部のユーザーから順に公開し、影響範囲を抑える
データ移行を伴う場合は、移行リハーサルを事前に行い、本番での失敗を防ぎます。
運用・保守 — 安定稼働を支える
システムは作って終わりではありません。むしろ稼働してからが本番です。運用・保守には次のような活動が含まれます。
- 監視: サーバーやアプリの状態を常時監視し、異常を早期検知する
- 障害対応: トラブル発生時に原因を切り分け、復旧する
- 改善・機能追加: 利用状況に応じて改善を重ねる
- セキュリティ対応: 脆弱性への対応やライブラリの更新を継続する
運用コストは見落とされがちですが、システムのライフサイクル全体では開発費を上回ることも珍しくありません。発注時点で運用体制まで見据えることが、長期的なコスト最適化につながります。
ウォーターフォールとアジャイル
開発の進め方には、大きく2つのアプローチがあります。
ウォーターフォール
要件定義から運用まで、工程を順番に進める方式です。各工程の成果物が明確で、計画が立てやすいのが利点です。一方、後工程で要件変更が起きると手戻りが大きくなります。仕様が固まっており、変更が少ないプロジェクトに向きます。
アジャイル
短い期間（スプリント）で「設計→実装→テスト」を繰り返し、動くものを少しずつ作り上げる方式です。要件の変化に強く、早期に成果物を確認できます。一方、全体像やコストが事前に見えにくく、発注側にも継続的な関与が求められます。要件が変わりうる、新規性の高いプロジェクトに向きます。
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 進め方 | 工程を順に進める | 短い反復を繰り返す |
| 変更への強さ | 弱い | 強い |
| 計画の立てやすさ | しやすい | しにくい |
| 発注側の関与 | 工程の節目 | 継続的 |
どちらが優れているという話ではなく、プロジェクトの性質に合わせて選ぶ、あるいは両者を組み合わせるのが実務的です。
発注側が押さえるべきポイント
最後に、発注側が良いシステムを得るために意識したい点をまとめます。
- 要件定義に時間を惜しまない: ここの精度がすべての土台になる
- 非機能要件を明示する: 性能・セキュリティ・運用も最初に決める
- レビューに主体的に参加する: 任せきりにせず、節目で必ず確認する
- 受入テストを自社で行う: 業務目線での検証は発注側にしかできない
- 運用まで見据えて契約する: リリース後の体制を最初に決めておく
まとめ
システム開発は、要件定義から運用保守まで一連の流れで成り立っており、各工程の品質が積み上がって最終的な成果を決めます。全体像を理解しておくことで、発注側も適切なタイミングで関与でき、手戻りや認識ずれを防げます。進め方はウォーターフォールとアジャイルを性質に応じて選び、要件定義と運用を軽視しないことが成功の鍵です。
合同会社Vermudaは、要件定義から設計・実装・テスト・運用保守までを一貫して支援する受託開発を行っています。当社の開発プロセスやサービス紹介もあわせてご覧ください。進め方や見積もりのご相談はお問い合わせよりお気軽にどうぞ。