ソフトウェア開発の5工程とは？プロセスモデルや工数比率も解説

こんにちは。Wakka Inc.メディア編集部です。

ソフトウェア開発の際は、工程を把握して効率的に計画を立てることが大切です。
開発に必要な工数を押さえることで、スムーズに開発を進めてミスや漏れを防止できます。

ソフトウェア開発をスムーズに進めるために、よく使用される略語やプロセスモデルを確認しておきましょう。
本記事では、ソフトウェア開発の工数をリソース比率やプロセスモデルを交えて解説します。

工程ごとに管理する目的や、開発で活用できる工程管理表も解説するので、ぜひ参考にしてください。

【おすすめ資料】システム開発会社が利用する、プロジェクト計画書のテンプレートです！

PMBOKを意識した内容になっており、プロジェクトの概要からスコープ、マネジメント、リスク管理といった項目が盛り込まれる計画書テンプレートです。

ソフトウェア開発の5工程

ソフトウェア開発とは、顧客や市場のニーズを満たすソフトウェアを開発することを指します。
ソフトウェア開発を実施する際には、開発の流れを把握するために、工程を理解しておくことが重要です。

主なソフトウェア開発の工程は、次の通りです。

• 【工程1】要件定義
• 【工程2】設計（外部設計・内部設計）
• 【工程3】プログラミング
• 【工程4】テスト
• 【工程5】リリース・運用保守

それぞれの工程を確認して、ソフトウェア開発をスムーズに進めましょう。

【工程1】要件定義

ソフトウェア開発を実施する際には、まず要件定義が必要です。
要件定義とは、ソフトウェアに搭載する機能や仕様・運用方法など開発の「要件」を定めることです。

開発者と依頼者が連携し、どのようなソフトウェアを開発すべきか打ち合わせます。

なお、要件定義は開発工数の方向性を決める重要な工程であり、依頼者ができるだけ精密な完成イメージを共有しておくことが大切です。

現状の業務の流れや課題、市場のニーズを依頼者にヒアリングし、「どのようなソフトウェアを求めているのか」認識を共有しましょう。
具体的なイメージを共有し、認識の相違を防ぐことで、思い描いた通りのソフトウェアを開発できます。

また、具体的な要件定義は開発プロセスを確定するうえでも不可欠なものです。
要件定義が曖昧など工数の見積もりが正確にできず、無駄な作業を発生させるリスクが高まります。

【工程2】設計（外部設計・内部設計）

要件定義の後は、ソフトウェアの機能や仕様を決める設計が必要です。

設計の工程では、ユーザーから見える部分を設定する外部設計（基本設計）、エンジニア向けにソフトウェア内部を設計する内部設計（詳細設計）の2種類に分類されます。

依頼者の要望を満たすために、画面設計・データベース設計・インタフェース設計をまとめた基本設計書を作成し、認識の相違がないか確認しましょう。

基本設計書を作成する際は、専門用語や複雑なデータを使用せず、ソフトウェア開発に詳しくない依頼者が見ても内容を理解できるよう工夫する必要があります。

内部設計では、ソフトウェアの動作や仕様を決めるため、機能仕様書・データフロー図・データベース物理設計書などの詳細設計書を作成しましょう。

詳細設計書に誤りがあると、開発工程でバグが発生しプロジェクトが遅延する可能性があります。
そのため、設計工程で不備や誤りがないか徹底的に確認し、後の工程につなげることが大切です。

【工程3】プログラミング

設計が完了したら、プログラミングを行いソフトウェア開発に進みます。
設計工程で作成した設計書をもとに、エンジニアがプログラミングを行って、ソフトウェアの形を作っていきます。

製品の種類やデバイスによって、活用する開発言語が異なるため、適切な開発言語を扱える専門のエンジニアがプログラミングを担当しましょう。

なお、システムごとに使用する開発言語の種類は、次の通りです。
※表は横にスクロールできます

開発言語はそれぞれ難易度が異なります。
言語によっては、ノウハウがないとうまく利用できないリスクがあるので注意が必要です。
自社のノウハウや開発メンバーのスキルに合わせて開発言語を選びましょう。

【工程4】テスト

プログラミング工程で開発したソフトウェアが、適切に動作するかテストする必要があります。
テスト工程は、バグや欠陥などがないかソフトウェアを検証する工程です。

実際にソフトウェアを展開してユーザーが使用した際に、バグや欠陥が残らないようテスト工程で徹底的にエラーをなくす必要があります。

そのため、テストは複数人・複数環境で実行し、さまざまな状況を仮定してチェックを繰り返しましょう。
なお、ソフトウェアをテストする方法として、次のような種類があります。
※表は横にスクロールできます

テスト工程で、バグや欠陥を発見した場合は修正し、再テストを実施します。
バグや欠陥などの問題がなくなるまでテストと改善を繰り返し、次の工程に進みましょう。

【工程5】リリース・運用保守

テスト工程を通して、動作や操作性に問題がないことを確認したら、ユーザーへリリースします。
依頼者にソフトウェアを納品後、適切にシステムが動作するよう運用保守を行う必要があります。

継続的にシステムが稼働するよう管理し、不具合が発生した際には復旧対応できる体制を整えましょう。
納品時には問題がなくとも、ソフトウェアを使用していく過程でバグや不具合が生じる可能性があります。

不具合が発生した際に早急な対応ができると、顧客満足度の向上につながるため、運用保守の体制を整えることが大切です。
また、定期的にソフトウェアをアップデートし、システム変更が必要な際に対応する必要があります。

ソフトウェア開発は依頼者に製品を納品して終わりではなく、システムが継続的に稼働するよう運用保守を徹底することが重要です。

ソフトウェア開発を工程ごとに管理する目的

ソフトウェア開発は工程ごとの管理が不可欠です。
しかし、実施する目的を理解していなければ、適切な管理はできません。

ソフトウェア開発を工程ごとに管理する目的は、次の通りです。

• タスク管理を円滑化する
• トラブルを未然に防ぐ
• 人員配置を最適化する
• 従業員の負荷を軽減する
• 生産性を向上させる
• QCDを向上させる

具体的な目的を確認して、ソフトウェア開発の工程管理を重視すべきか検討しましょう。

タスク管理を円滑化する

ソフトウェア開発の工程ごとに管理する目的の1つ目は、タスク管理を円滑化するためです。
開発工程を細分化し、工程ごとにゴールを設定すれば開発メンバーが完成形をイメージしやすいというメリットがあります。

工程ごとに管理者を配置することで、タスク管理を円滑化し開発をスムーズに進められます。

トラブルを未然に防ぐ

ソフトウェア開発の工程ごとに管理すれば、トラブルの防止が可能です。

工程ごとにテストを実施し、不具合を発見することで、ソフトウェア開発後の予期せぬバグや不備を防ぎやすくなります。

早い段階で不備や漏れを発見するために、工程ごとの管理を徹底することが大切です。

人員配置を最適化する

工程ごとの管理体制を強化することで、人員配置を最適化できます。

各工程に必要な人員を見極め、状況に応じて人員を追加・変更すれば、ソフトウェア開発に必要なリソースを最適化できます。

人員配置を最適化すれば、開発をスムーズに進められ、開発コストの削減が可能です。
さらに適切な人員配置により、ソフトウェア開発を効率化できるため、成果物のクオリティを向上できます。

従業員の負荷を軽減する

従業員の負荷を軽減することも、ソフトウェア開発を工程ごとに管理する目的の1つです。
特定の従業員に負荷がかかると、スケジュール通りに開発が進まず、納品が遅延するリスクが高まります。

工程ごとのリソースを把握し、従業員の負荷を適切に設定することで、特定の従業員に依存せずにスムーズな開発を実現できます。

成果物の品質低下やスケジュールの遅延、従業員のモチベーション低下を防ぐために、工程ごとに負荷を最適化した開発計画を立てましょう。

生産性を向上させる

ソフトウェア開発の生産性を向上させるために、工程ごとの管理体制を強化することが重要です。
工程ごとの作業内容や人員配置を最適化し、業務効率を向上させれば、生産性向上につながります。

また、開発メンバーが取りかかるべきタスクを明確化できるため、不要な残業を削減して効率的に作業を進められます。

従業員の労働時間を削減できれば、モチベーションを維持しやすい環境の構築が可能です。

QCDを向上させる

工程管理を徹底すれば、QCDを向上させられます。
QCDとは、次の要素の頭文字を取った略語です。

• Quality（品質）
• Cost（コスト）
• Delivery（納期）

工程ごとの管理体制を強化すれば、スケジュールの遅延を防止し納期までに成果物を仕上げられます。

また、納期を早めることで人件費などの開発コストを抑え、成果物を見直す時間が増えるため高品質なソフトウェアを開発できます。

ソフトウェア開発を工程ごとに管理する目的は、QCDを向上させて顧客満足度を高めるためです。

ソフトウェア開発工程で使用される略語

ソフトウェア開発では、さまざまな略語が使用されます。
開発チームでスムーズにコミュニケーションを取ったり、工程を管理したりするためにも、よく使用される略語を知っておく必要があります。

ソフトウェア開発工程で使用される略語は、次の通りです。
※表は横にスクロールできます

上記の略語はソフトウェア開発で使用されやすいため、円滑に開発を進められるよう覚えておきましょう。

ソフトウェア開発のプロセスモデル

ソフトウェア開発には、いくつかのプロセスモデルがあり、それぞれ工程が異なります。
主なソフトウェア開発のプロセスモデルは、次の通りです。

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

それぞれのモデルを確認して、ソフトウェア開発の際に活用しましょう。

ウォーターフォール型

ウォーターフォール型は、「Water Fall（水が落ちる）」を意味するソフトウェア開発のプロセスモデルです。
川の上流から水が下流へと流れるように、開発工程を順番に進めてソフトウェアを完成させます。

ウォーターフォール型の具体的な工程手順は、次の通りです。

1. 要件定義
2. 設計
3. プログラミング
4. テスト
5. リリース
6. 保守運用

要件定義で必要な人員やスケジュールを決め、1つの工程が完了しなければ、ウォーターフォール型は次のステップに進めません。
そのため、スケジュール管理や予算計画策定が容易になり、大きな問題が起きにくいというメリットがあります。

対して、工程が完了しなければ次の工程に進めないため、リリースまで時間がかかる点がデメリットです。
仕様変更やトラブルが発生すると、工程を一からやり直さなければならないため、大幅なスケジュール遅延が発生します。

そのため、ウォーターフォール型は完成までの時間がかかっても問題がない大規模なプロジェクトや、完成形が決まっているプロジェクトにウォーターフォール型が向いています。

アジャイル型

アジャイル型は、ソフトウェアの機能ごとに開発工程を分けて、それぞれで設計・プログラミング・テストの工程を実施するプロセスモデルです。

小さな単位ごとに開発を進めるため、最終的に1つのシステムとしてリリースします。
機能ごとに開発を進めるため、短期間での納品が可能で、依頼者が成果物を確認しやすいメリットがあります。

また、修正箇所が発覚した際も機能ごとに開発工程を分けているため、柔軟な対応が可能です。

ソフトウェア全体を完成させなくても、機能の動作を確認できるため、認識の相違を解消しながら市場や依頼者のニーズに沿ったソフトウェア開発ができます。

プロトタイプ型

プロトタイプ型は、開発の途中で試作品を作成し、依頼者からフィードバックをもらうことで完成させるプロセスモデルです。
システムの動作やデザインなど依頼者と相談しながら開発を進められるため、要件の変更など柔軟に修正対応ができます。

プロトタイプ型の具体的な手順は、次の通りです。

1. 試作品作成
2. テスト
3. 修正
4. 本開発

試作品の段階で依頼者からのフィードバックを得られるため、大幅な仕様変更を避けられます。
要件変更や機能追加などを試作品の段階で対応してから本開発に進めるため、開発途中でスケジュール調整がしやすいメリットがあります。

対して、試作品を作成する回数が増えるほど、時間や労力・開発コストがかかるため、予算やスケジュールをオーバーしやすい点がデメリットです。

スパイラル型

スパイラル型は、ウォーターフォール型とアジャイル型の双方のメリットを兼ね備えたプロセスモデルです。
機能ごとなどシステムを細分化し、設計・開発・テストの工程を繰り返すことで、らせん状にシステム全体を開発します。

重要な機能・システムから開発を進めてから次の工程に移り、すべての機能が完成したらソフトウェアをリリースし、運用保守を行います。

1つのサイクルを完了するごとに依頼者からのフィードバックを受け、次のサイクルで巻き取れるため、スムーズな修正対応が可能です。

ただし、プロジェクトを細分化して開発を進めるため、全体像を把握しにくい点には注意しましょう。
また、スパイラル型は仕様変更や修正対応・進捗管理がしやすいメリットがある反面、プロジェクトの全体像を把握しにくい点がデメリットです。

V字モデル型

V字モデル型は、各工程で対応するテストを実施し、検証作業を効率化するプロセスモデルです。

例えば、要件定義で定めた内容に対応するシステムを検証したり、受入テストで内容を検証したりと、工程ごとに応じたテストを実施します。

工程ごとに検証を実施するため、進捗状況を確認しやすくスケジュール管理がしやすいメリットがあります。

対して、仕様変更や修正対応の際は、要件定義を変更するだけでなくテスト工程も対応する必要があるため、工程数やコストが増加する点がデメリットです。

【おすすめ資料】システム開発会社が利用する、プロジェクト計画書のテンプレートです！

PMBOKを意識した内容になっており、プロジェクトの概要からスコープ、マネジメント、リスク管理といった項目が盛り込まれる計画書テンプレートです。

ソフトウェア開発の工程別リソースの割合

ソフトウェア開発における人員配分を決める際には、工程ごとのリソースの割合を把握しておくことが大切です。

独立行政法人の情報処理推進機構が公表した「ソフトウェア開発データ白書2018-2019」を参考に、工程ごとのリソース割合を解説します。

ソフトウェア開発のリソース割合を把握するため、次の数値を確認しておきましょう。

• 新規開発のリソース比率
• 改良開発のリソース比率
• 再開発のリソース比率

新規開発のリソース比率

新規開発のリソース割合は、次の通りです。

上記のデータをまとめると、工程ごとのリソース割合は次の通りです。
※表は横にスクロールできます

なお、上記の数値は100％に合わせるため調整しています。

改良開発のリソース比率

改良開発のリソース比率は、次の通りです。

上記の数値をまとめると、改良開発のリソース比率は次の通りです。
※表は横にスクロールできます

再開発のリソース比率

再開発のリソース比率は、次の通りです。

上記の数値をまとめると、改良開発のリソース比率は次の通りです。
※表は横にスクロールできます

ソフトウェア開発で活用できる工程管理表3選

ソフトウェア開発の工程管理を効率化するために、工程管理表を活用しましょう。

工程管理表は、工程ごとのタスクを可視化しプロジェクトの進行を円滑化するためのツールです。

要件定義からリリース・運用保守までの全行程を一括管理できるため、チーム内での進捗把握やスケジュール管理を効率化するだけでなく、顧客への工程説明を円滑化できます。

ソフトウェア開発で活用できる工程管理表は、次の通りです。

• ガントチャート工程表
• バーチャート工程表
• WBS

それぞれの工程管理表の特徴を確認して、ソフトウェア開発に活用しましょう。

ガントチャート工程表

ガントチャート工程表は、プロジェクトの進捗状況とタスクを管理するための工程管理表です。
縦軸にタスクや担当者名・開始日・締切日を記し、横軸にタスクの進捗率を記載します。

ガントチャート工程表は、Excelで縦軸にタスクなどの要件を記載し、横軸のセルを塗りつぶしてバーにしたり図形機能で矢印を描画したりして簡単に作成できます。

それぞれのタスクの進捗状況を色分けすると、視覚的に工程の進捗率を把握できるため、工程管理が容易です。
各工程の進捗率や全体の進捗状況を可視化できるため、スケジュールの遅延を防止できます。

バーチャート工程表

バーチャート工程表は、プロジェクトのタスクを時系列順に並べて進捗管理を行う工程管理表です。
縦軸にプロジェクトのタスクをそれぞれリストアップし、横軸にタスクの実行日を記載することで、工程ごとの進捗状況を可視化します。

バーチャート工程表は、横長のバーを設置し長さによってタスクの所要時間を表します。
バーチャート工程表は、工程ごとの作業と必要な日数を確認するための工程管理表です。

プロジェクト全体の進捗状況を把握するより、工程ごとのスケジュールや作業進捗を確認する際に向いています。

WBS

WBSは、プロジェクトの成果物を定義し管理・計画する工程管理表です。
WBSは「Work Breakdown Structure」の略称で、「作業分解構成図」の意味を持ちます。

細かい作業を分解して構造化し、開発管理やスケジュール作成を円滑化することで、プロジェクトの進行管理を効率化できます。

ガントチャート工程表を作成する際は、プロジェクトを構成する要素を洗い出すWBSが必要です。
WBSによって、プロジェクトに関わる作業内容を洗い出し、内容をガントチャートに移すことで効率的な工程管理を実現できます。

工程管理を効率化するシステムの選び方

工程管理を効率化するためには、ツールやシステムの導入が効果的です。
工程管理ツールやシステムを導入すれば、管理業務を効率化できます。

ソフトウェア開発を工程ごとに管理し、生産性・業務効率を向上させるために、自社に適した管理システムを導入しましょう。

工程管理を効率化するシステムの選び方は、次の通りです。

• 開発プロセスへの適応性
• 工程表の作成機能
• UI/UX
• 料金設定
• 既存システムとの連携性

システム選びのコツを押さえて、工程管理を効率化しましょう。

開発プロセスへの適応性

工程管理システムを選ぶ際には、開発プロセスに適したものを選ぶ必要があります。
ウォーターフォール型かアジャイル型のどちらを採用するかで、選ぶべきシステムが変わります。

システムによって、ウォーターフォール型が得意なものもあれば、アジャイル型やスパイラル型に特化したものもあるため、自社が採用する開発プロセスに適したツールを選ばなければなりません。

工程管理システムを選ぶ際は、まず開発プロセスを選定してから適応性が高いツールを導入しましょう。

工程表の作成機能

工程管理システムを選ぶ際は、工程表の作成機能を確認しておくことが大切です。
システムによって作成できる工程表の種類やレイアウトが異なるため、工程表の作成機能を比較検討しておきましょう。

視覚的に分かりやすく工程管理を効率化できる工程表を作成できれば、管理業務に費やすリソースを削減し、業務効率が向上します。

工程管理表の種類によってメリット・デメリットが異なるため、「どのような工程表を作成したいのか」を事前に決めてから、工程管理システムの性能を確認することが大切です。

UI/UX

工程管理システムを導入する際は、UI/UXを重視して顧客満足度を向上させられるツールを選びましょう。
UIとは、「User Interface（ユーザーインターフェース）」の略称で、ユーザーの目に触れる部分を指します。

UXとは、「User Experience（ユーザー・エクスペリエンス）」の略称で、ユーザーが商品・サービスを通じて得られる体験のことです。

見栄えの良さや使いやすさは生産性に直結しにくいですが、ユーザーのUI/UXを高める重要な要素です。
使いやすく見栄えの良い工程管理システムは、ユーザーにとって便利なシステムとして認知されるため、顧客満足度を向上できます。

そのため、工程管理システムを選ぶ際は、UI/UXを重視して使い勝手の良い仕様や機能・デザインを備えたものを導入してください。

料金設定

工程管理システムは、無料で利用できるものもありますが、月額料金や導入費用などコストがかかるものも多いです。
工程管理システムの料金設定を確認して、予算内で利用できるものから、自社に適したツールを比較検討しましょう。

初期費用だけでなく、中長期的な利用を想定してメンテナンス費用や月額料金を確認することが大切です。

予算内で無理なく利用できる工程管理システムを選ぶことで、業務効率を向上させて費用対効果が高い管理体制の改善を実現できます。

既存システムとの連携性

工程管理システムを導入する際は、システムの機能や仕様だけでなく、既存システムとの連携性を確認しておきましょう。

既存システムと連携してデータを管理・共有したい場合は、他システムと連携できる工程管理システムを選ぶべきです。

既存システムとの連携性が低いシステムを導入した場合、データ拡張や機能追加などの改良開発で、追加費用が発生する可能性があります。

費用を抑えて工程管理を効率化するために、既存システムと連携性が高い工程管理システムを選ぶことが大切です。
工程管理システムの連携性を確認したうえで、既存システムと連携し業務効率を向上させられるシステムを選びましょう。

ソフトウェア開発に関するよくある質問

本章ではソフトウェア開発に関して、以下のようなよくある質問について解説します。

• Q1.ソフトウェア開発は何工程が一般的ですか？
• Q2．各工程の工数（人月）やリソース配分の目安は？
• Q3．ウォーターフォール型とアジャイル型、どちらを選べば良い？
• Q4．RFP（提案依頼書）を作る際のコツは？

ソフトウェア開発に関する疑問を解消する際にお役立てください。

【おすすめ資料】システム開発会社が利用する、プロジェクト計画書のテンプレートです！

PMBOKを意識した内容になっており、プロジェクトの概要からスコープ、マネジメント、リスク管理といった項目が盛り込まれる計画書テンプレートです。

ソフトウェア開発の工程管理を効率化するため適切な工程モデルを選択しよう

ソフトウェア開発の工程管理を効率化するために、自社に適した開発プロセスを選択することが大切です。

ウォーターフォール型やアジャイル型など、工程管理を効率化するプロセスモデルは複数存在しており、自社に適したものを選ぶ必要があります。

それぞれの特徴を確認したうえで、自社に適したプロセスモデルを選択することで、工程管理業務を効率化できます。

さらに、工程ごとの管理体制を強化するため、工程管理表を作成して各工程の進捗率や全体のスケジュールを把握することが大切です。

工程管理システムを導入すれば、工程管理表の作成業務や管理業務を円滑化し、業務効率が向上します。

ソフトウェア開発におけるQCDを向上させるために、自社に適したプロセスモデルと工程管理表を選択し、工程管理システムで進捗状況を可視化しましょう。

【おすすめ資料】システム開発会社が利用する、プロジェクト計画書のテンプレートです！

PMBOKを意識した内容になっており、プロジェクトの概要からスコープ、マネジメント、リスク管理といった項目が盛り込まれる計画書テンプレートです。