ソフトウェア開発の工程とは?リソース比率やモデル・管理する目的を解説
ソフトウェア開発の際は、工程を把握して効率的に計画を立てることが大切です。
開発に必要な工数を押さえることで、スムーズに開発を進めてミスや漏れを防止できます。
ソフトウェア開発をスムーズに進めるために、よく使用される略語やプロセスモデルを確認しておきましょう。
本記事では、ソフトウェア開発の工数をリソース比率やプロセスモデルを交えて解説します。
工程ごとに管理する目的や、開発で活用できる工程管理表も解説するので、ぜひ参考にしてください。
システム開発を検討されている方に向けてすぐに使える『RFP(提案依頼書)テンプレート』をご用意!
編集しやすいパワーポイント形式のテンプレートなので、項目を埋めるだけで簡単にRFPが作成できます。
ソフトウェア開発の5工程
ソフトウェア開発とは、顧客や市場のニーズを満たすソフトウェアを開発することを指します。
ソフトウェア開発を実施する際には、開発の流れを把握するために、工数を理解しておくことが重要です。
主なソフトウェア開発の工数は、次の通りです。
- 要件定義
- 設計(外部設計・内部設計)
- プログラミング
- テスト
- リリース・運用保守
それぞれの工数を確認して、ソフトウェア開発をスムーズに進めましょう。
要件定義
ソフトウェア開発を実施する際には、まず要件定義が必要です。
要件定義とは、ソフトウェアに搭載する機能や仕様・運用方法など開発の「要件」を定めることです。
開発者と依頼者が連携し、どのようなソフトウェアを開発すべきか打ち合わせます。
なお、要件定義は開発工数の方向性を決める重要な工程であり、依頼者ができるだけ精密な完成イメージを共有しておくことが大切です。
現状の業務の流れや課題、市場のニーズを依頼者にヒアリングし、「どのようなソフトウェアを求めているのか」認識を共有しましょう。
具体的なイメージを共有し、認識の相違を防ぐことで、思い描いた通りのソフトウェアを開発できます。
設計(外部設計・内部設計)
要件定義の後は、ソフトウェアの機能や仕様を決める設計が必要です。
設計の工程では、ユーザーから見える部分を設定する外部設計(基本設計)、エンジニア向けにソフトウェア内部を設計する内部設計(詳細設計)の2種類に分類されます。
依頼者の要望を満たすために、画面設計・データベース設計・インタフェース設計をまとめた基本設計書を作成し、認識の相違がないか確認しましょう。
基本設計書を作成する際は、専門用語や複雑なデータを使用せず、ソフトウェア開発に詳しくない依頼者が見ても内容を理解できるよう工夫する必要があります。
内部設計では、ソフトウェアの動作や仕様を決めるため、機能仕様書・データフロー図・データベース物理設計書などの詳細設計書を作成しましょう。
詳細設計書に誤りがあると、開発工程でバグが発生しプロジェクトが遅延する可能性があります。
そのため、設計工程で不備や誤りがないか徹底的に確認し、後の工程につなげることが大切です。
プログラミング
設計が完了したら、プログラミングを行いソフトウェア開発に進みます。
設計工程で作成した設計書をもとに、エンジニアがプログラミングを行って、ソフトウェアの形を作っていきます。
製品の種類やデバイスによって、活用する開発言語が異なるため、適切な開発言語を扱える専門のエンジニアがプログラミングを担当しましょう。
なお、システムごとに使用する開発言語の種類は、次の通りです。
システムの種類 | 使用する主な言語 |
基幹システム | Java、C++ |
Windows | C# |
ゲーム | C# |
ECサイト | ASP、HTML/CSS、JavaScript、PHP、Ruby |
会計ソフト | ASP |
SNS | HTML/CSS、JavaScript、PHP、Ruby |
動画サイト | JavaScript |
チャットツール | JavaScript |
ブログ | HTML/CSS、PHP、Ruby |
掲示板 | PHP |
大規模サイト | Java |
テスト
プログラミング工程で開発したソフトウェアが、適切に動作するかテストする必要があります。
テスト工程は、バグや欠陥などがないかソフトウェアを検証する工程です。
実際にソフトウェアを展開してユーザーが使用した際に、バグや欠陥が残らないようテスト工程で徹底的にエラーをなくす必要があります。
そのため、テストは複数人・複数環境で実行し、さまざまな状況を仮定してチェックを繰り返しましょう。
なお、ソフトウェアをテストする方法として、次のような種類があります。
テストの種類 | 概要 |
単体テスト | 画面や機能などプログラムの対象単位ごとにテストする |
結合テスト | 複数の機能を組み合わせたサブシステムが、想定通り動作するかテストする |
総合テスト | 本運用を想定し、システム全体の動作や仕様をテストする |
受け入れテスト | 要求通りの機能や操作性を備えているかテストする |
テスト工程で、バグや欠陥を発見した場合は修正し、再テストを実施します。
バグや欠陥などの問題がなくなるまでテストと改善を繰り返し、次の工程に進みましょう。
リリース・運用保守
テスト工程を通して、動作や操作性に問題がないことを確認したら、ユーザーへリリースします。
依頼者にソフトウェアを納品後、適切にシステムが動作するよう運用保守を行う必要があります。
継続的にシステムが稼働するよう管理し、不具合が発生した際には復旧対応できる体制を整えましょう。
納品時には問題がなくとも、ソフトウェアを使用していく過程でバグや不具合が生じる可能性があります。
不具合が発生した際に早急な対応ができると、顧客満足度の向上につながるため、運用保守の体制を整えることが大切です。
また、定期的にソフトウェアをアップデートし、システム変更が必要な際に対応する必要があります。
ソフトウェア開発は依頼者に製品を納品して終わりではなく、システムが継続的に稼働するよう運用保守を徹底することが重要です。
ソフトウェア開発の工程を把握しておくべき理由
ソフトウェア開発の工程を把握しておくべき理由は、次の通りです。
- 効率的に計画を立てられるから
- ミスや漏れを防止できるから
- スムーズに開発を進められるから
それぞれの理由を確認して、ソフトウェア開発の工程を把握しておきましょう。
効率的に計画を立てられるから
ソフトウェア開発の工程を把握しておくと、効率的に開発計画を立てられます。
大まかな工程が決まっているため、フレームワークに沿って開発計画を立てるだけで、ソフトウェア開発を実行できます。
作業内容やスケジュール、必要な人員などを工程ごとに調整できるため、計画立案を効率化できるのです。
ミスや漏れを防止できるから
ソフトウェア開発の工程を把握しておけば、作業の抜けや漏れに気づけるため、人的ミスの防止につながります。
開発工程で足りない作業が発覚すると、工程を後戻りして対応する必要があり、スケジュールが遅延します。
作業の抜けや漏れを事前に防止することで、円滑なソフトウェア開発が実現し、作業効率の向上が可能です。
スムーズに開発を進められるから
開発チームのメンバーがソフトウェア開発の工程を把握しておけば、共通の認識を持って作業を進められます。
開発メンバーが、工程ごとの作業内容や進捗を把握できるため、分担して作業を進められるのです。
また、外部企業からソフトウェア開発を依頼された際も、双方が開発に必要な工程を理解しておけば、コミュニケーションを円滑に取れます。
そのため、依頼者と開発チームが協力して開発を進められるため、認識の相違やスケジュールの遅延を防いで開発を進められます。
ソフトウェア開発のプロセスモデル
ソフトウェア開発には、いくつかのプロセスモデルがあり、それぞれ工程が異なります。
主なソフトウェア開発のプロセスモデルは、次の通りです。
- ウォーターフォール型
- アジャイル型
- プロトタイプ型
- スパイラル型
- V字モデル型
それぞれのモデルを確認して、ソフトウェア開発の際に活用しましょう。
ウォーターフォール型
ウォーターフォール型は、「Water Fall(水が落ちる)」という意味を持つソフトウェア開発のプロセスモデルです。
川の上流から水が下流へと流れるように、開発工程を順番に進めてソフトウェアを完成させます。
ウォーターフォール型の具体的な工程手順は、次の通りです。
- 要件定義
- 設計
- プログラミング
- テスト
- リリース
- 保守運用
要件定義で、必要な人員やスケジュールを決め、1つの工程が完了しなければ次のステップに進めません。
そのため、スケジュール管理がしやすく予算を立てやすいため、大きな問題が起きにくいメリットがあります。
対して、工程が完了しなければ次の工程に進めないため、リリースまで時間がかかる点がデメリットです。
仕様変更やトラブルが発生すると、工程を一からやり直さなければならないため、大幅なスケジュール遅延が発生します。
そのため、完成までの時間がかかっても問題がない大規模なプロジェクトや、完成形が決まっているプロジェクトにウォーターフォール型が向いています。
アジャイル型
アジャイル型は、ソフトウェアの機能ごとに開発工程を分けて、それぞれで設計・プログラミング・テストの工程を実施するプロセスモデルです。
小さな単位ごとに開発を進めるため、最終的に1つのシステムとしてリリースします。
機能ごとに開発を進めるため、短期間での納品が可能で、依頼者が成果物を確認しやすいメリットがあります。
また、修正箇所が発覚した際も機能ごとに開発工程を分けているため、柔軟な対応が可能です。
ソフトウェア全体を完成させなくても、機能の動作を確認できるため、認識の相違を解消しながら市場や依頼者のニーズに沿ったソフトウェア開発ができます。
プロトタイプ型
プロトタイプ型は、開発の途中で試作品を作成し、依頼者からフィードバックをもらうプロセスモデルです。
システムの動作やデザインなど依頼者と相談しながら開発を進められるため、要件の変更など柔軟に修正対応ができます。
プロトタイプ型の具体的な手順は、次の通りです。
- 試作品作成
- テスト
- 修正
- 本開発
試作品の段階で依頼者からのフィードバックを得られるため、大幅な仕様変更を避けられます。
要件変更や機能追加などを試作品の段階で対応してから本開発に進めるため、開発途中でスケジュール調整がしやすいメリットがあります。
対して、試作品を作成する回数が増えるほど、時間や労力・開発コストがかかるため、予算やスケジュールをオーバーしやすい点がデメリットです。
スパイラル型
スパイラル型は、ウォーターフォール型とアジャイル型の双方のメリットを兼ね備えたプロセスモデルです。
機能ごとなどシステムを細分化し、設計・開発・テストの工程を繰り返すことで、らせん状にシステム全体を開発します。
重要な機能・システムから開発を進めてから次の工程に移り、すべての機能が完成したらソフトウェアをリリースし、運用保守を行います。
1つのサイクルを完了するごとに依頼者からのフィードバックを受け、次のサイクルで巻き取れるため、修正対応がしやすいです。
ただし、プロジェクトを細分化して開発を進めるため、全体像を把握しにくいデメリットがあります。
仕様変更や修正対応・進捗管理がしやすいメリットがある反面、プロジェクトの全体像を把握しにくい点がデメリットです。
V字モデル型
V字モデル型は、各工程で対応するテストを実施し、検証作業を効率化するプロセスモデルです。
例えば、要件定義で定めた内容に対応するシステムを検証したり、受入テストで内容を検証したりと、工程ごとに応じたテストを実施します。
工程ごとに検証を実施するため、進捗状況を確認しやすくスケジュール管理がしやすいメリットがあります。
対して、仕様変更や修正対応の際は、要件定義を変更するだけでなくテスト工程も対応する必要があるため、工程数やコストが増加する点がデメリットです。
ソフトウェア開発工程で使用される略語
ソフトウェア開発では、さまざまな略語が使用されます。
開発チームでスムーズにコミュニケーションを取るために、よく使用する略語を知っておく必要があります。
ソフトウェア開発工程で使用される略語は、次の通りです。
開発工程 | 略語 | 正式名称 | 意味 |
要件定義 | RD | Requirement Definition | 要件定義 |
RA | Requirement Analysis | 要求分析 | |
設計 | SA | System Architectural design | システム方式設計 |
SP | System Planning | システム企画 | |
BD | Basic Design | 基本設計 | |
DD | Detail Design | 詳細設計 | |
ED | External Design | 外部設計 | |
FD | Function Design | 機能設計 | |
ID | Internal Design | 内部設計 | |
SS | System Structure Design | 構造設計 | |
UI | User Interface | UI基本設計 | |
PD | Program Design | プログラム設計 | |
PS | Program Structure Design | プログラム(構造)設計 | |
プログラミング | PG | Program / Programing | プログラミング |
CD | Coding | コーディング | |
テスト | ST | System Test | システムテスト |
UT | Unit Test | 単体テスト | |
IT | Integration Test | 総合テスト | |
OT | Operations Test | 運用テスト | |
PT | Product Test | 総合テスト |
上記の略語はソフトウェア開発で使用されやすいため、円滑に開発を進められるよう覚えておきましょう。
システム開発を検討されている方に向けてすぐに使える『RFP(提案依頼書)テンプレート』をご用意!
編集しやすいパワーポイント形式のテンプレートなので、項目を埋めるだけで簡単にRFPが作成できます。
ソフトウェア開発の工程別リソースの割合
ソフトウェア開発における人員配分を決める際には、工程ごとのリソースの割合を把握しておくことが大切です。
独立行政法人の情報処理推進機構が公表した「ソフトウェア開発データ白書2018-2019」を参考に、工程ごとのリソース割合を解説します。
ソフトウェア開発のリソース割合を把握するため、次の数値を確認しておきましょう。
- 新規開発のリソース比率
- 改良開発のリソース比率
- 再開発のリソース比率
新規開発のリソース比率
新規開発のリソース割合は、次の通りです。
上記のデータをまとめると、工程ごとのリソース割合は次の通りです。
工程 | リソース割合 |
基本設計 | 17% |
詳細設計 | 17% |
製作 | 33% |
結合テスト | 20% |
総合テスト | 13% |
なお、上記の数値は100%に合わせるため調整しています。
改良開発のリソース比率
改良開発のリソース比率は、次の通りです。
上記の数値をまとめると、改良開発のリソース比率は次の通りです。
工程 | リソース割合 |
基本設計 | 16% |
詳細設計 | 16% |
製作 | 33% |
結合テスト | 21% |
総合テスト | 14% |
再開発のリソース比率
再開発のリソース比率は、次の通りです。
上記の数値をまとめると、改良開発のリソース比率は次の通りです。
工程 | リソース割合 |
基本設計 | 16% |
詳細設計 | 16% |
製作 | 32% |
結合テスト | 21% |
総合テスト | 15% |
ソフトウェア開発を工程ごとに管理する目的
ソフトウェア開発は工程ごとに管理することが重要ですが、「なぜ工程ごとに細分化して管理すべきか」など目的を理解しておかなければなりません。
ソフトウェア開発を工程ごとに管理する目的は、次の通りです。
- タスク管理を円滑化する
- トラブルを未然に防ぐ
- 人員配置を最適化する
- 従業員の負荷を軽減する
- 生産性を向上させる
- QCDを向上させる
具体的な目的を確認して、ソフトウェア開発の工程管理を重視すべきか検討しましょう。
タスク管理を円滑化する
ソフトウェア開発の工程ごとに管理する目的は、タスク管理を円滑化するためです。
開発工程を細分化し、工程ごとにゴールを設定すれば開発メンバーが完成形をイメージしやすいメリットがあります。
工程ごとに管理者を配置することで、タスク管理を円滑化し開発をスムーズに進められます。
トラブルを未然に防ぐ
ソフトウェア開発の工程ごとに管理すれば、トラブルを未然に防ぐことが可能です。
工程ごとにテストを実施し、不具合を発見することで、ソフトウェア開発後にバグや不備が発覚する事態を防止できます。
早い段階で不備や漏れを発見するために、工程ごとの管理を徹底することが大切です。
人員配置を最適化する
工程ごとの管理体制を強化することで、人員配置を最適化できます。
各工程に必要な人員を見極め、状況に応じて人員を追加・変更すれば、ソフトウェア開発に必要なリソースを最適化できます。
人員配置を最適化すれば、開発をスムーズに進められ、開発コストを削減することが可能です。
さらに適切な人員配置により、ソフトウェア開発を効率化できるため、成果物のクオリティを向上させられます。
従業員の負荷を軽減する
ソフトウェア開発を工程ごとに管理する目的は、従業員の負荷を軽減するためです。
特定の従業員に負荷がかかると、スケジュール通りに開発が進まず、納品が遅延するリスクがあります。
工程ごとのリソースを把握し、従業員の負荷を適切に設定することで、特定の従業員に依存せずにスムーズな開発を実現できます。
成果物の品質低下やスケジュールの遅延、従業員のモチベーション低下を防ぐために、工程ごとに負荷を最適化した開発計画を立てましょう。
生産性を向上させる
ソフトウェア開発の生産性を向上させるために、工程ごとの管理体制を強化することが重要です。
工程ごとの作業内容や人員配置を最適化し、業務効率を向上させれば、生産性向上につながります。
また、開発メンバーが取り掛かるべきタスクを明確化できるため、不要な残業を削減して効率的に作業を進められます。
そのため、従業員の労働時間を削減できるため、モチベーションを維持することが可能です。
QCDを向上させる
工程管理を徹底すれば、QCDを向上させられます。
QCDとは、次の要素の頭文字を取った略語です。
- Quality(品質)
- Cost(コスト)
- Delivery(納期)
工程ごとの管理体制を強化すれば、スケジュールの遅延を防止し納期までに成果物を仕上げられます。
また、納期を早めることで人件費などの開発コストを抑え、成果物を見直す時間が増えるため高品質なソフトウェアを開発できます。
ソフトウェア開発を工程ごとに管理する目的は、QCDを向上させて顧客満足度を高めるためです。
ソフトウェア開発で活用できる工程管理表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を重視して使い勝手の良い仕様や機能・デザインを備えたものを導入してください。
料金設定
工程管理システムは、無料で利用できるものもありますが、月額料金や導入費用などコストがかかるものも多いです。
工程管理システムの料金設定を確認して、予算内で利用できるものから、自社に適したツールを比較検討しましょう。
初期費用だけでなく、中長期的な利用を想定してメンテナンス費用や月額料金を確認することが大切です。
予算内で無理なく利用できる工程管理システムを選ぶことで、業務効率を向上させて費用対効果が高い管理体制の改善を実現できます。
既存システムとの連携性
工程管理システムを導入する際は、システムの機能や仕様だけでなく、既存システムとの連携性を確認しておきましょう。
既存システムと連携してデータを管理・共有したい場合は、他システムと連携できる工程管理システムを選ぶべきです。
既存システムとの連携性が低いシステムを導入した場合、データ拡張や機能追加などの改良開発で、追加費用が発生する可能性があります。
費用を抑えて工程管理を効率化するために、既存システムと連携性が高い工程管理システムを選ぶことが大切です。
工程管理システムの連携性を確認した上で、既存システムと連携し業務効率を向上させられるシステムを選びましょう。
ソフトウェア開発の工程管理を効率化するため適切な工程モデルを選択しよう
ソフトウェア開発の工程管理を効率化するために、自社に適した開発プロセスを選択することが大切です。
ウォーターフォール型やアジャイル型など、工程管理を効率化するプロセスモデルは複数存在しており、自社に適したものを選ぶ必要があります。
それぞれの特徴を確認した上で、自社に適したプロセスモデルを選択することで、工程管理業務を効率化できます。
さらに、工程ごとの管理体制を強化するため、工程管理表を作成して各工程の進捗率や全体のスケジュールを把握することが大切です。
工程管理システムを導入すれば、工程管理表の作成業務や管理業務を円滑化し、業務効率が向上します。
ソフトウェア開発におけるQCDを向上させるために、自社に適したプロセスモデルと工程管理表を選択し、工程管理システムで進捗状況を可視化しましょう。
システム開発を検討されている方に向けてすぐに使える『RFP(提案依頼書)テンプレート』をご用意!
編集しやすいパワーポイント形式のテンプレートなので、項目を埋めるだけで簡単にRFPが作成できます。