システム開発の工程（流れ）とは？開発工程や略語を詳しく解説

システム開発の工程（流れ）を理解することは、内製や外注に関わらずシステム開発を成功させる上で重要です。今回は、ウォータフォールモデルなど主な開発手法の工程に加え、開発中に使われる「略語」やアジャイル開発の考え方、外注する際のポイントなどについて、わかりやすく解説します。

システム開発の工程とは。工程管理が重要な理由

システム開発は「工程」にしたがって開発を進めていくのが一般的です。工程表を作成することで、複雑化しやすいシステム開発のプロセスが「見える化」でき、管理しやすくなるといったメリットが得らるほか、品質の高いシステム開発にもつながります。

ところで、システム開発と一口に言っても、さまざまな開発手法があり、それぞれの工程には違いがあります。ここからは、システム開発のモデルごとに、具体的な工程を解説していきます。

システム開発工程｜ウォーターフォールモデル

ウォーターフォールモデルとは、工程を1つずつ順番に終わらせていく手法

ウォータフォールモデルは、最初にスケジュールや人員、要件定義をしっかり固めた上で、工程を1つずつ順番に終わらせていく開発手法です。システム開発モデルの中で、もっとも古くからある、ポピュラーな手法として知られています。

「ウォータフォール（waterfall）」は、和訳すると「滝」を意味する言葉です。工程の進め方が、上から下に流れていく「滝」のようであることから、ウォータフォールモデルと名付けられました。

ウォータフォールモデルの基本的な工程をご紹介します。

①要求分析・要件定義

システムを開発するにあたって、最初に行うのが「要求分析」と「要件定義」です。システムに何を求めるのか、明確にしていく工程を「要求分析」と言い、その要求に基づいて、必要な機能や要求をまとめていく作業のことを「要件定義」と言います。

クライアントの要求を実現することを目的に、実装する機能や性能などを検討し、具体的な進め方を決めていきます。ここでは、クライアントと開発者の間で、認識に相違がないことを確かめておくことが大切です。

②外部設計（基本設計）

外部設計は、サービス利用想定者の視点に立って、具体的に搭載すべき機能や特徴を検討する工程です。使い勝手に関わる重要な工程の1つで、「基本設計」や「概要設計」と呼ばれる場合もあります。

外部設計の工程では、要件定義をもとにユーザーインターフェース（UI）を設計し、基本設計書等を作成します。インターフェースとは、サービス利用者から見える部分のこと。つまり、画面などの外面的な見た目や、操作方法の構成を指します。

③内部設計（詳細設計）

内部設計は、サービス利用者側から見えない「内部機能」を設計していく工程です。外部設計で作成した基本設計書をもとに、それをシステムとしてどのように実現していくのか、具体的に決めていく工程となります。「詳細設計」や「プログラミング設計」などとも呼ばれます。

内部設計では、具体的な実装を想定した「機能仕様書」など、詳細設計書を作成します。それぞれ個々に作成した詳細設計書をもとに、次の段階のプログラミングへと進みます。

④プログラミング

プログラミングとは、詳細設計書をもとにプログラムを設計・構築する工程です。コンピュータが意図した動作を行うよう、「プログラミング言語」やそれに相当する「仕組み」など用いて、細かく順序だてた指示を記述していく作業にあたります。プログラミングは、システムエンジニア（SE）やプログラマーが行う工程です。

⑤テスト

プログラミングが完了したら、それぞれのシステムが正確に機能するかどうかを確認するために、次のような各種テストを実施します。

⑥システム移行（引き渡し）

すべてのテストが完了したら、旧システムから新システムへ移行していきます。システム移行の方法は、次のようないくつかの種類があります。

⑦運用・保守

運用・保守は、リリースしたシステムが正常に稼働し続けるために必要不可欠な工程です。

「運用」とは、改修やアップデートなどを行って、問題が起こらないようにシステムを日々支える業務のことです。

一方で、「保守」とは、システムに問題が発生した場合に対応する業務のことを言います。

システムに障害が発生し通常の運用ができなくなった場合、多大な損害が発生してしまうことも考えられます。システムトラブルを回避するためには、適切な「運用・保守」が重要です。

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

ウォータフォールモデルは、プロジェクト全体のスケジュールを立てやすい点が大きなメリットです。工程ごとに仕様書やタスクが決まっているため、進捗率を管理・把握しやすく、無理がないようにタスクを割り振ることができます。

金額の見積もりや予算の手配がしやすいことから、システム開発を外注する場合（受託開発）、ほとんどのケースでウォータフォールモデルが採用されています。

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

ウォータフォールモデルでは、基本的に工程を後戻りすることができません。仮に、仕様が変更される事となった場合には、大幅なスケジュール変更が必要となるほか、当初の見積もりも変わってしまいます。

このため、「自社開発のwebサービス」など、リリースしながらブラッシュアップしていく方が向いている開発の場合は、ウォータフォールモデル以外の開発手法を用いるのがオススメです。

だたし、システムの変更が頻繁にあっては困る「金融系の基幹システム」など、きっちり作り切ってからリリースする方が向いているサービスは、ウォーターフォールモデルで進める方が安心でしょう。

システム開発工程｜スパイラルモデル

スパイラルモデルとは、細かく分割したサブシステムごとに開発する手法

スパイラルモデルとは、システムを複数のサブシステムに分け、サブシステムごとにウォータフォールモデルで述べたような「設計、開発、テストの工程」を進めていく開発手法です。開発の流れが、スパイラルつまり「螺旋（らせん）」を描いているように表せることから「スパイラルモデル」と名付けられました。

スパイラルモデルの主な工程は、次の通りです。

システム全体が完成するまで、上記のようにサブシステムの開発を繰り返すのがスパイラルモデルの特徴です。

スパイラルモデルのメリット

開発工程をサブシステムごとに細かく分割するスパイラルモデルでは、サブシステムが完成するごとにクライアント確認の時間をとります。そのため、不具合や問題点に気づきやすいというメリットがあります。

さらに、軌道修正も柔軟に行えます。仕様変更が必要であれば、その変更を反映して次のサブシステム開発に移ることができるのです。

スパイラルモデルのデメリット

スパイラルモデルは、初期段階で詳細を決めず、柔軟に対応する点が魅力である一方、開発プロジェクトの管理側からすると、進捗を把握しづらいことがデメリットと言えます。

「想定よりもサブシステムが多くなってしまった」というケースもあり、開発期間が長期化するリスクもあります。軌道修正が多くなると、その分費用が膨んでしまう点にも注意が必要です。

システム開発工程｜プロトタイプモデル

プロトタイプモデルとは、開発初期の試作品をもとに完成を目指す手法

プロトタイプモデルは、「試作品（プロトタイプ）をクライアントに見てもらって意見を聞き、より良いシステムを開発しよう」という考え方に基づく開発手法です。

開発の流れは、まず初めに開発の目的や必要な機能を具体化する作業を行います。だたし、試作品作成後に、検証しながら要件を詰めていくことが前提であるため、ウォータフォールモデルにおける要件定義ほど厳密な作業は行いません。

その後、試作品をつくり、クライアントに確認してもらいながら検証と再作成を繰り返し、システムに必要な機能や仕様を具体化させたところで、要件定義を固め、本開発に進むという流れです。

本開発においては、最終的な試作品をもとに、システムの細部についても実装を進めていきます。

プロトタイプモデルのメリット

プロトタイプモデルでは、クライアントの声を要件定義の段階で取り入れられるため、完成に近い形をイメージしやすい上、開発途中における大きな修正や仕様変更も回避しやすいでしょう。

このようにクライアントの声を頻繁に取り入れることは、結果的に、質の高いシステム開発にもつながります。

要件定義や仕様、やりたいことが明確になっていないシステムの場合は、プロトタイプ作りから始めると上手く行きやすいでしょう。

プロトタイプモデルのデメリット

プロトタイプモデルは、システムのイメージが明確になっていない段階から開発を進められると述べましたが、そのために当初の想定よりも費用がかかったり、開発が長引いてしまったりする可能性が考えられます。

また、大規模開発の場合は、試作品の制作や修正に対する負担が大きく、プロトタイプモデルはあまり採用されません。大規模で複雑なシステムを開発する場合には、人員工数管理やチームマネジメントが容易なウォーターフォールモデルが向いています。

トライ＆エラーで行う開発手法「アジャイル開発」とは

システム開発に対する考え方の1つに「アジャイル開発」があります。アジャイルとは「すばやい」「俊敏な」という意味です。

アジャイル開発は、「アジャイルソフトウェア開発宣言」（詳しくは後述）で示された価値に基づく、迅速かつ適応性の高いシステム開発を行うための考え方やあり方、方法論の総称と言えます。

アジャイル開発で知っておきたい4つの「価値」

アジャイル開発が生まれた背景には、現代社会におけるビジネスや技術の急速な変化があります。変化に対応した製品やサービスを早く市場に投入するという考え方から、アジャイル開発が誕生しました。

2001年には、アジャイル開発手法を支持する17人の開発者によって議論が行われ「アジャイルソフトウェア開発宣言」が公開されました。ここにおいて、アジャイル開発に共通する「価値」や「原則」つまり、アジャイル開発に対する考え方やチームのあり方が明示されたのです。

アジャイルソフトウェア開発宣言で示されたものは、プロセスやドキュメント、契約交渉や計画は価値があると認めながらも、「対話を通じた相互理解」や「ソフトウェアを動かしてみること」「顧客との協働しあうこと」や「変化を味方につけること」により価値をおく、というものです。

アジャイル開発を取り入れるにあたっては、上記の考え方を基本として取り組むことが大切となるでしょう。

アジャイル開発の代表例「スクラム開発」の特徴

アジャイル開発の進め方の代表的な具体例の一つとして「スクラム開発」があります。

スクラム開発は、チームでコミュニケーションを取りながら、臨機応変に開発を行う方法です。リーダーやマネージャーがいない代わりに、ロール（役割）のあるチーム編成が組まれます。

リーダーやマネージャーがいないため、開発の優先順位が柔軟に変更できますが、それゆえスケジュールの全体像が把握しにくいほか、開発の方向性がぶれやすいといったデメリットがあります。

チーム内一人ひとりの、自立性やコミュニケーション能力が要求される方法であることも知っておきましょう。

システム開発の工程で使われる「略語」一覧

システム開発の現場では、業務を進めるなかでさまざまな「略語」が用いられます。略語を覚えておくことで、業務やコミュニケーションを円滑に行うことができるでしょう。ここでは、代表的な略語をご紹介します。

システム開発を外注するときのポイント

自社でシステム開発を行うことが難しい場合、システム開発を外注することも1つの方法です。外注する場合でも、ある程度の知識があってこそ、ニーズに合ったシステムを構築できるのではないでしょうか。

ここでは、システム開発を外注するときに重視したいポイントをご紹介します。

ポイント①全工程に対する各工程の「比率」を知っておく

システム開発というと、プログラミングが頭に浮かぶ方も多いのではないでしょうか。しかし、これまでご紹介したように、システム開発には多くの工程が存在します。要件定義や設計、テストといった工程もそれなりに比重が大きく、重要な工程なのです。

工程の比率は、開発手法や開発規模によって違いますが、それぞれの工程にどの程度の時間が必要なのか事前に確認しておきましょう。工程の理解や開発者とのコミュニケーションに役立ちます。

ポイント②各工程の「成果物」を明確にする

工程に分けて進めていくシステム開発において、各工程での成果物を明確にしておくことも、外注する上で大切にしたいポイントです。

最終的な完成品だけを成果物とした場合、それぞれの工程でどのような作業が行われているのか状況が把握しにくくなります。そうなると、完成後にイメージと異なるものが納品されてしまうリスクがあるのです。

依頼者と開発者で成果物を確認しながら開発を進めていく方が、理想的なシステムを実現できるのではないでしょうか。

工程の理解がシステム開発成功のカギ！

システム開発手法ごとに、開発工程やメリット・デメリットをご紹介しました。システム開発は、効率的に高品質のシステムを構築するため、細かい工程に分割して開発を進めていくのが一般的です。

システム開発の外注を検討する場合も、工程について理解しておくと、開発者とのコミュニケーションに役立ちます。自社のシステム開発を成功させるためにも、開発工程をしっかり確認しておきましょう。