システム開発の工程とは？ウォーターフォールモデルやアジャイルモデルなどシステム開発の種類も徹底解説！｜注意点や略語も！

発注者の要望に沿ったシステム開発を行う際、ベンダーは様々な工程に分割し作業します。システム開発には様々な手法があり、開発するシステムの特性や発注者の要望によって、最良の手法を選択していく必要があります。

本記事では、システム開発の代表的な手法であるウォーターフォールモデル及びアジャイルモデルについてや、注意点及び略語等を解説致します。

システム開発の工程とは？

システム開発の工程とは、開発を進めていく上の手順のことです。開発を行う上では、工程を分け、分業することで、進捗状況の把握や品質の管理が行いやすくなるというメリットがあります。

システム開発の工程

基本的なシステム開発の工程は、次の通りです。

1. 要件定義（要求定義）
2. 外部設計（外部設計）
3. 内部設計（詳細設計）
4. プログラミング
5. 製造・単体テスト
6. 結合テスト
7. システム（総合）テスト
8. 運用テスト
9. システム移行（リリース）
10. 運用・保守

本項目では、上記の工程を順に解説致します。

1.要件定義（要求定義）

要件定義とは、開発において一番最初に行うことで、ベンダーが発注者と打ち合わせを行い、開発するシステムに搭載する機能及び仕様、運用フロー等について決定していくことです。

この際、発注者はどのようなシステムが必要なのか、できる限り具体的にベンダーに伝えておかなければ、イメージと違う成果物が完成してしまうことに繋がり兼ねませんので注意しましょう。

また、要件定義は、さらに細かく2つの要件に分類し決定していくことがことが大切です。

• 機能要件
• 非機能要件

機能要件

機能要件とは、特に画面及び帳票、バッチ等といった実装するべき機能のことです。

非機能要件

非機能要件とは、開発するシステムの性能といった機能面以外のことです。

2.外部設計（外部設計）

外部設計とは、前述した要件定義の内容を基に、ユーザーインターフェースを設計することです。

ユーザーインターフェースとは、システムの画面等の見た目のことで、発注者にとって使用しやすいシステムを開発するための大切な工程となります。

発注者は、ベンダーとの打ち合わせの際、どのような見た目が良いのか、例えば具体的に流通している既存のシステム画面等を見本としてベンダーと共有することで、イメージの食い違いが起きにくくなるので、覚えておきましょう。

3.内部設計（詳細設計）

内部設計とは、前述した外部設計を基に、実際にプログラミングを行うことができよう、内部に特化した詳細の設計を行うことです。

内部設計における成果物は、「機能仕様書」「データフロー図」「データベース物理設計書」等が挙げられます。これらの成果物の内容は、ベンダー側のプロジェクトメンバー内のみで共有され、発注者と調整を図ることはほぼありません。

内部設計はさらに細かく次の3つに分類できます。

• 機能分割
• 物理データ設計
• 入出力の詳細設計

機能分割

機能分割とは、プログラミング及びシステムメンテナンスを実行しやすくするため、搭載する機能をモジュールごとに分割することで、各モジュールの機能を明確にすることを指します。

さらに、データフロー（機能間でデータが処理される際の流れ）を設計し、データフローを明確にすることで、バグを洗い出すことにも繋がります。

物理データ設計

物理データ設計とは、ユーザーにはわからない、不可視の部分である内部のファイル及びデータのやりとりに関連する部分の設計を行うことです。

入出力の詳細設計

入出力の詳細設計とは、前述の外部設計で決定したインターフェースに関して、プログラミングで実装する際、どのように表現を行うかについて詳細を設計することです。主に「エラー処理」「初期値及びデフォルト値の定義」「入力データのチェック方法」「メッセージ表示」等が検討されます。

4.プログラミング

プログラミングとは、前述した内部設計において作成された「詳細設計書」に基づき、実際にプログラム開発を行うことです。設計書の通り、プログラムを書くことでソフトウェアが正しく動作するようにしていくことになります。

内部設計同様、基本的にベンダー側のみでの作業、情報共有のみが行われます。

5.製造・単体テスト

製造・単体テストとは、前述のプログラミングが完了次第、開発したプログラムが要件定義で定めた通りの動作をするかどうかを確認するためのテストです。

まず最初に、モジュール単位でのテストを実施し、その際バグ等が発見された場合、修正を行なったり、テストの結果のフィードバック等を実施したりしながら、プログラムを完成させていきます。

6.結合テスト

結合テストとは、前述の製造・単体テストにおいて、単体のモジュールに不具合がないことが確認され次第、複数のモジュールを組み合わせ、サブシステムにおいてバグが発生しないか、インターフェーズにズレが生じていないか、各サブシステムの連携がスムーズに行われているか等のテストを実施することです。

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

システム（総合）テストとは、前述の結合テストにおいて、各サブシステムの不具合がないということが実証された後、全体にバグが発生しないか等を確認するためのテストのことです。

開発したプログラム全てが要件定義通りに動作を行うかどうかだけでなく、アクセス集中時の耐久性及び処理速度のスピード等、様々な視点からテストを実施します。

8.運用テスト

運用テストとは、開発したシステムの納品及びリリース前の最終テストのことです。

ベンダーは、発注者と決定した要件定義に基づいた機能が搭載されているのか、各機能が問題なく動作するかだけでなく、発注者にとって使いやすい仕様となっているか等、実際に運用が始まってから想定できるトラブル及び不具合等が起きないか、起きたとしても対応ができるのかどうかを確認します。

また、発注者側の担当者が、実際の業務と仮定し、運用テストを行うこともありますが、ベンダーのみでテストを行うよりも、実際の使用感等を確認できる良い機会となるため、発注者が了承する場合、実際に発注者側にテストに協力してもらうことが推奨されます。

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

システム移行（リリース）とは、現行のシステムから開発したシステムに移行させる作業のことです。

システム移行は、既存のシステムの仕様により様々なトラブルが発生することが多く、最も緊張感のある工程であると言えます。

さらに、システム移行の際は、既存のシステムを停止している間に完了しなければならず、時間制限があるため、とても難しい工程だと言えるでしょう。

10.運用・保守

運用とは、開発したシステムの改修及びバージョンアップ等で変更を行うことです。また、保守とは、開発したシステムが滞りなく動作するようにデータ入力を行なったり、トラブル発生時に対応手順書に基づいて処理を行なったりすることを指します。

運用及び保守は、開発したシステムが安定した動作を保つことができるか否かを司る工程となるため、それぞれの担当者同士が連携して実施することが大切です。

システム開発の種類

システム開発には、いくつかの種類が存在します。選択する種類によって、システム開発の工程が変わってくるため、その都度最適なものを選定することが大切です。

特に代表的なものとして、次の4つが挙げられます。

• ウォーターフォールモデル
• アジャイルモデル
• プロトタイプモデル
• スパイラルモデル

本項目では、上記4つのシステム開発について解説致します。

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

その名の通り、滝が流れるように、上流の工程をはじめとし、下流の工程まで順番通りにシステム開発を進めていく方法です。

途中で後戻りをしないという特徴があります。

ウォーターフォールモデルの流れ

流れとしては、下記の通りです。

• システム化企画
• 要件定義
• 設計
• 開発（実装）
• テスト
• リリース〜運用・保守

システム化企画

発注者側において、課題及び要求に基づいて、システム化の企画を立ち上げることです。システム化したい業務の内容を分析することで、必要となるシステムの機能や、どのように開発及び導入を進めていくかを決定します。

要件定義

要件定義は最も重要であると言っても過言ではありません。発注者及びベンダーの間で、綿密な打ち合わせを行い、開発するシステムについて、認識のズレが生じることのないようにする必要があります。

設計

発注者の要望を基にユーザーインターフェースを設計する基本設計と、ベンダー側からの視点でシステム設計する詳細設計を行い、システム開発全体の計画を立てます。

開発（実装）

プログラミングを行うフェーズです。

テスト

完成したシステムが不具合なく動作するかをテストします。

リリース〜運用・保守

完成したシステムを発注者に納品し、実際に運用、保守を行っていくフェーズです。

ウォーターフォールモデルのメリット

ウォーターフォールモデルには、様々なメリットが存在します。特に代表的なメリットとしては、次の3点が挙げられます。

• プロジェクト全体の計画を立てることが容易である
• 予算及び人員の手配が容易である
• 開発工程の進捗管理が容易である

プロジェクト全体の計画を立てることが容易である

ウォーターフォールモデルは、上流工程から順に開発を進めていく手法です。そのため、要件定義が策定できた段階で、システム開発のスケジュール全体の把握を行うことが可能となります。

予算及び人員の手配が容易である

要件定義の策定の後、詳細な計画を策定することができるため、プロジェクトメンバーの確保がしやすく、予算も明確に立てることができます。

開発工程の進捗管理が容易である

初期の段階で全てのフェーズで行うべき工程を明らかにし、開発を進めていくため、進捗状況を把握しやすく、万が一のトラブル発生時にも対応しやすいというメリットがあります。

ウォーターフォールモデルのデメリット

ウォーターフォールモデルには、デメリットも存在します。デメリットも把握した上で、開発を進めていく必要があります。

デメリットとしては、次の2点が代表的です。

• 遡って作業を行うことになると工数が増えてしまう
• 発注者の意見を途中で取り入れるのが困難

遡って作業を行うことになると工数が増えてしまう

基本的に上流工程から順に作業をし、後戻りして作業をすることはありません。しかし、何らかの理由によって、やむを得ず前の工程に戻り、作業をせざるを得ない場合があります。

その際、システム開発のスケジュールが狂ってしまい、納期が遅れたり、予算おーばーしてしまったりという問題が起こる可能性があります。

発注者の意見を途中で取り入れるのが困難

開発が始まってしまうと、途中で仕様変更を行うこと及び発注者の新たな要望を取り入れるということが困難となります。

そのため、要件定義のフェーズで発注者の要望を網羅し、漏れのないようにすることが必要です。

ウォーターフォールモデルが向いているプロジェクト

ウォーターフォールモデルにおける下流工程では、機能テスト及び結合テスト等、動作確認のテストが複数回実施されます。そのため他の開発モデルと比較し時間がかかってしまうことがありますが、スピード感よりも、高品質が求められるプロジェクトに向いていると言えるでしょう。

アジャイルモデル

ウォーターフォールモデルとは違い、システム開発の工程の最中に、仕様及び設計の変更が当たり前に起こるという前提において、初期の段階から詳細な仕様は決定せず、大体の仕様を決定し、細かいイテレーション（反復）開発及び小さい単位でのシステム実装からのテスト実施を複数回行って、徐々に開発を進めていく手法のことです。

アジャイルモデルの流れ

開発の流れとしては大きく次の3つにフェーズに分けることが可能です。

• リリース計画の策定
• システム計画の分割
• イテレーション

リリース計画の策定

システム開発の途中で、使用及び設計変更が起こりうることを前提に、計画段階では詳細な仕様を決定することなく、大まかな仕様及び要求を決定します。

敢えて大まかに計画を立てておくことで、途中で発注者からの新しい要望が出てきたとしても随時対応することが可能です。

システム計画の分割

大まかに策定されたシステム計画に基づいて、システム全体を構成する各機能を小さく分割し、重要度を把握しつつ開発に着手していく順番を決めていく工程です。

イテレーション

前述したシステム計画の分割で、分割された各機能毎に、要件定義をはじめ、設計及び開発、テスト及びリリースを反復していく工程です。

各機能毎にイテレーションを実施及び反復していくことにより、少しずつシステム全体が開発されます。各イテレーションが完了する度に、検証及び修正が行われ、発注者とベンダーが連携し、他に追加する機能はあるのかどうかをその都度判断していくことになります。

アジャイルモデルのメリット

アジャイルモデルのメリットとしては、開発工程の中で不具合等が発生したとしても、戻る工程が少ないということが挙げられます。

小さな機能毎に開発を進めているため、修正が生じたとしても微々たる影響しかありません。同時に開発途中で発注者に細かく確認を行うことが可能なため、発注者の要望に最大限応えることが可能です。

アジャイルモデルのデメリット

アジャイルモデルにおけるデメリットとしては、開発スケジュールのコントロールを行うことが困難であることが挙げられます。

各機能毎にスケジュールを策定するアジャイルモデルでは、それぞれの進捗状況を把握することが困難でありかつコントロールも困難であると言われています。

アジャイルモデルが向いているプロジェクト

ウォーターフォールモデルと違い、開発途中で仕様の変更及び追加が予想される場合に向いています。モバイル分野等の日々新技術が登場している分野で用いられることが多いです。

プロトタイプモデル

システム開発の初期フェーズにおいて、機能を簡易化した試作機（プロトタイプ）を作成し、発注者に評価してもらう工程を経て、全体の開発工数を減らし効率よく開発を行う手法のことです。

スパイラルモデル

開発するシステムを複数のサブシステム及びフェーズに分割し、それぞれのサブシステム及びフェーズ毎に順を追って開発を行っていく手法です。

なぜ分業するのか

システム開発には、様々なモデル及び手法があることを解説いたしましたが、どのモデルにおいても分業し開発を行っています。

なぜ、システム開発は分業するのかというと、効率よく、より高品質のシステムを開発するためと言えるでしょう。

開発するシステムの規模によっては、開発期間が半年〜数年に渡るものもあります。そのため、開発工程を細かくフェーズ毎に分割することで、プロジェクトメンバー全員の中で、完成システムの認識を一致させやすいというメリットがあるのです。

システム開発工程の注意点

システム開発工程における注意点は、いくつかありますが、代表的なものとしては、次の2点が挙げられます。

• 不明瞭なコミュニケーション
• 度重なる仕様変更

本項目では、上記2点の注意点について解説致します。

不明瞭なコミュニケーション

システム開発において、ベンダーと発注者においては、コミュニケーションを密に取る必要があります。

特に初期フェーズの要件定義においては、発注者の要望をしっかり汲み取ることが最重要です。要件定義の時点で、発注者の要望を汲み取れていないと、後々仕様変更等で納期の遅延が発生することに繋がりかねません。

度重なる仕様変更

発注者は要求定義の段階で全ての要望を明確にベンダーに伝えておく必要があります。初期フェーズで仕様変更の要望を出した場合、多少納期が遅れたとしても対応可能なことが多いですが、開発後期であれば、仕様変更＝当初の開発予定のシステム自体が変更となることを意味することも少なくありません。

仕様変更の可能性が開発当初から予想される場合には、前述したアジャイルモデル開発を行うことで、仕様変更による影響は少なくなるでしょう。

システム開発に携わる関係者

システム開発に携わる関係者としては様々な役割を持った人がいますが、本項目では下記の代表的な関係者についてご紹介致します。

• システムエンジニア
• プログラマー
• プロジェクトマネージャー
• プロジェクトマネジメントオフィス

システムエンジニア

システムエンジニア（SE）は、システム開発における要件定義や設計、プログラミング等を担当します。

特に要件定義を確定させることが主な業務となります。

プログラマー

プログラマー（PG）は、システム開発において、プログラミングや各種テストを担当します。

プロジェクトマネージャー

プロジェクトマネージャー（PM）は、システム開発において、プロジェクト全体のマネジメント及び進行を管理します。

システム開発の関係者の中において、数多くの決定権を持つポジションです。

プロジェクトマネジメントオフィス

プロジェクトマネジメントオフィス（PMO）は、システム開発において、人材開発及びコスト調整、ディレクション等を担当します。

プロジェクトマネージャーよりも細かい管理を行うことから、プロジェクトマネージャーの補佐的立場と言えます。

システム開発において覚えておきたい 略語

本項目では、システム開発において覚えておくと便利な略語についてご紹介します。

まとめ

本記事では、システム開発の代表的な手法であるウォーターフォールモデル及びアジャイルモデルについてや、システム開発における注意点や略語等を解説致しました。

システム開発は、各工程を分割することで効率よく品質の良いものを開発することができるということがわかりました。

ベンダーは、発注者の要望に最大限応えることができるよう、その都度最良の開発手法でシステム開発を行うことで、クオリティの高いシステム開発を行うことができ、発注者にも満足してもらえるように努めることが大切です。