システム開発は、新たな事業展開や社内の業務効率化を進めるために必須といっても過言ではありません。
しかしシステム開発の工程は多くの人員と要素が複雑に絡み合っているため、すべて管理するのは一苦労です。
そのため、時間もお金もかかるシステム開発の進め方に不安を抱く方もいらっしゃるでしょう。
この記事では、一般的なシステム開発の工程や便利な開発モデルについて解説します。 システム開発の不安をなくし、新たなシステムやサービスを生み出すきっかけになれば幸いです。

目次

• システム開発の工程における一連の流れ
• システム開発の各工程の内容
• 要件定義
• 基本設計（外部設計）
• 詳細設計（内部設計）
• プログラミング
• 単体テスト
• 結合テスト
• システムテスト（総合テスト）
• 運用テスト
• システム移行（リリース）
• 運用・保守
• システム開発モデルの種類によって工程が異なる
• ウォーターフォールモデル
• アジャイルモデル
• プロトタイプモデル
• スパイラルモデル
• まとめ

システム開発の工程における一連の流れ

システム開発とは、ユーザーのニーズや課題に応えられる製品を作り出すために、IT技術を駆使してシステムや仕組みを構築することです。
システム開発と一口に言ってもさまざまな工程が含まれており、一般的には以下の流れで進められます。
・要件定義（要求定義を含む）
・基本設計（外部設計）
・詳細設計（内部設計）
・プログラミング
・単体テスト
・結合テスト
・システムテスト（総合テスト）
・運用テスト
・システム移行（リリース）
・保守・運用
複数の工程のうち、要件定義に近い工程は「上流工程」と呼ばれ、保守・運用に近い工程は「下流工程」と呼ばれます。

※関連記事：システム開発とは | システム開発における工程と注意ポイント

システム開発の各工程の内容

ここからはシステムの各工程内容について解説します。

要件定義

要件定義では、まずシステム開発におけるご要望を正確に捉えることが大切です。
そのご要望を実現するために、開発目的やターゲットなどシステム開発の根幹となる部分を決めていきます。
そのため、外部委託の場合は最初に依頼者へ徹底したヒアリングをおこないます。
ヒアリングした内容をまとめる工程を「要求定義」と呼び、要求を開発項目に落とし込む「要件定義」と区別する場合もあります。

要件定義で決める内容は大別すると3つです。
・システム要件：ご要望を実現できるシステムの概要を決める
・機能要件：より詳細なシステムの内容を決める（盛り込む機能や階層構造、画面表示など）
・非機能要件：システムの安定性、拡張性やセキュリティなどを決める
非機能要件を決めたあと、使用する言語やデータベースを決める段階を「技術要件」と呼ぶこともあります。
上記の内容は要件定義書にまとめ、あとから内容を確認できる状態にしておきましょう。

基本設計（外部設計）

基本設計では、要件定義で決まった内容をもとに画面表示や画面遷移などのユーザーインターフェースを設計します。
システム開発の目的を今一度確認し、ターゲットユーザーにどのように使ってもらいたいかを決める工程です。
そのため、ユーザー側に立った目線が必要になります。
外部委託する場合には、システム会社のエンジニアが画面設計やデータベース設計などを記載した基本設計書を作成しますが、依頼側も目を通す資料のためあまり専門用語は含まれません。
しかし、仮にわからない部分があった場合は開発後半で齟齬が生まれないよう、こまめに質問するのがおすすめです。

詳細設計（内部設計）

詳細設計では、基本設計で決めた機能や大枠の内容をプログラム単位まで細分化します。
詳細設計書には各プログラムの機能設計、データフロー図、ファイル設計などが記載されます。
エンジニア向けのプログラミング指示書の意味合いが強く、書類自体を依頼側に確認いただくことはほとんどありません。
ただ、開発会社によっては依頼側に相談のないまま詳細まで詰めてしまい、後々トラブルになるケースもあるので、定期的なミーティングで情報共有と認識のすり合わせをおこないましょう。

プログラミング

諸々の設計が決まったら、プログラミングをおこなってシステムを形作っていきます。
外部委託する場合、プログラミングの知識がない依頼者にとっては進捗が見えづらい工程になるため、引き続き定期的なミーティングをおこなうとともに進捗を可視化できるツールを導入するのもおすすめです。

単体テスト

テスト工程は、作成したプログラムが要件定義どおりに動作するかを検証するフェーズです。
単体テストでは、小さなモジュール単位でテストをおこない、設計どおりの動作になっているかをチェックします。
もし不具合が見つかった場合は、修正して再度テストをおこなうサイクルを繰り返します。
システム会社によっては、テストを専門的におこなうテスターがいる場合もあります。

結合テスト

結合テストは、単体テストで確認が終わった複数のモジュールを結合し、動作に問題がないかテストする段階です。
具体的にはモジュールを組み合わせたときに不具合が起きないか、連携がうまくいっているか、モジュールごとでインターフェースがちぐはぐになっていないかを確認します。

システムテスト（総合テスト）

システムテストでは、システム全体で不具合が出ないかをテストします。
要件定義どおりに動くかの確認はもちろん、非機能要件（安定性やセキュリティ）もクリアしているかチェックします。

運用テスト

運用テストはシステムをリリースする前の最終ステップです。
要求が満たされていることは言うまでもなく、ユーザーが実際に使う場面を想定して操作性や誤動作の有無を細かく確認します。
運用テストとほぼ同義で「受入テスト」という言葉が使われる場合もありますが、厳密には意味が異なっているため注意が必要です。
運用テストは開発側の担当者が要件定義を満たしているか確認するのに対し、受入テストは開発を委託した依頼側が依頼どおりの内容になっているか検証します。
運用テストと受入テストはどちらもユーザーが使う場面を想定してテストするという作業は同じですが、おこなう人が異なるため注意しましょう。

システム移行（リリース）

検証が終わったら、いよいよリリース準備です。
システム移行では、もとから使っていたシステムから新しく作成したシステムに移行します。
移行方法は複数あり、すべてを一気に切り替える一斉移行や、徐々に切り替える順次移行などがあります。
移行の際にはトラブルが発生しないよう、移行手順書を作成して方法や手順を確認しておきましょう。
旧システムの仕様によってはさまざまな不具合が出る可能性もあるので、開発を委託した側も認識のすり合わせをしておくことが大切です。

運用・保守

無事にリリースを終えたら、最後は運用と保守をおこなっていきます。
サーバーの起動・停止やアップデートの実行などを「運用」と呼び、システムが担う業務が滞りなく行われるよう日々の管理をおこない、時には変更を加えることを指します。
一方、システムの不具合修正やトラブル対応などシステムに異変があった際に手を加えることを「保守」と呼び、システムが常に問題なく動くよう整えることを指します。
トラブル対応には対応手順書を使用し、順に沿って処理をおこなうことが多いです。

システム開発モデルの種類によって工程が異なる

ここまでシステム開発の工程についてご説明しましたが、開発モデルによって進め方は若干異なります。
工程自体の内容に変化はないため、開発したい内容に合わせてモデルを選ぶのがおすすめです。

ウォーターフォールモデル

ウォーターフォール、つまり滝のように上流から下流へ常に一方向に開発を進める方法です。
1つのフェーズが終わってから次のフェーズに進むため進捗管理がしやすく、品質もある程度担保しやすいことがメリットです。
一方デメリットは、ミスが発覚すると前の工程に戻らざるを得ず、修正に大幅な時間やコストがかかる点が挙げられます。
特に、下流工程まで進んだ段階で上流工程のミスが発覚すると、時間もコストも大きくロスすることになります。
じっくり進めたいプロジェクトには向いていますが、スピーディーに開発を進めたい場合には不向きな手法です。

アジャイルモデル

アジャイルは「すばやい」という意味を持ちます。
その名前が表すとおり、スピーディーな開発に向いているモデルです。
開発を進める中で後戻りする前提で設計し、適宜修正しながら各工程を進めるため、開発スピードを上げられます。
新規事業など、とりあえず手を付けたいといった場合に有効です。
ただ、随時後戻りしながら進めるため進捗を把握しづらく、さらには対応できる開発会社が少ないのがデメリットです。

プロトタイプモデル

プロトタイプは「試作品」という意味を持ちます。
開発初期にプロトタイプを作成して関係者に確認してもらい、共通のイメージを持った状態で開発に取り掛かることができるため、開発側と依頼側の間で認識のずれが生じにくいことがメリットです。
しかし、プロトタイプを作成する時間やコストがある程度かかってしまう点はデメリットと言えるでしょう。
そのため、プロトタイプ作成にかかるコストや時間が少ない、小規模なシステム開発が向いています。

スパイラルモデル

スパイラルモデルではシステムをいくつかの小単位に分割し、その単位ごとのプロトタイプを確認しながら進めます。
1つの単位自体はウォーターフォールモデルで開発を進めますが、要件定義で完全に詳細を作りこまず、単位ごとに計画を立てて進めます。
そのため途中で仕様変更などがあっても柔軟に対応できるのがメリットです。
さらに、プロトタイプモデルと同じく開発側と依頼側でこまめにチェックをおこないながら進められるため、認識のズレが生まれにくいこともメリットの1つです。
ただデメリットとしては、プロトタイプの作成や修正を繰り返すことで進捗が把握しづらくなること、小さな単位が増えれば増えるほど開発コストも増すことが挙げられます。

※関連記事：システム開発 V字モデル｜V字モデルはシステム開発の基本

まとめ

システム開発の流れから各工程の内容、よく使われる開発モデルをご紹介しました。
想像していたより工程が長く、1から自分でおこなうには荷が重いと感じた方もいらっしゃるかと思います。
開発はチームでおこなうものですので、1人で抱え込まず、周囲と連携しながらすすめましょう。
また、システム開発の需要が高まっている昨今では、依頼側にもノウハウを蓄積できる会社や、アジャイル開発が得意な会社など特徴のある開発会社が増えています。
クオリティの高いシステムを低コストで作成するために、自社での開発以外に外部委託も選択肢に入れるとよいかもしれません。