システム開発における工程比率とは？工程や決める際のポイントなども解説

システム開発における「工程比率」とは、開発全体の作業量（工数）のうち、各工程にどれくらいの割合を割り当てるかを示した考え方のことです。

システム開発は一般的に「要件定義」「設計」「実装」「テスト」などの複数の工程にわかれており、各工程で必要となる時間や人員は異なります。また同じ工程であっても、担当者のスキルや経験によって必要な工数は変わります。たとえば、スキルの高い担当者であれば効率よく進められる一方、経験が浅い場合はレビューや修正に時間がかかることもあります。

このように、工程比率を考える際は単に工数だけを見るのではなく、担当者のスキルやチーム全体の体制も踏まえて、どの工程にどれだけリソースを割くかを判断することが重要です。

また経営層の視点で見ると、工程比率は単なる現場のスケジュール管理の話ではなく、「投資配分の設計」といえます。

たとえば、要件定義工程と設計工程の比率が低すぎる場合、開発途中で仕様の食い違いが発覚し、手戻りが発生します。結果として追加コストが発生し、納期遅延や品質低下につながります。逆に要件定義や設計に一定の時間を確保できているプロジェクトは、後工程が安定しやすく、トータルコストの抑制につながるでしょう。

つまり工程比率とは、「どの工程でリスクを抑え、どこで価値をつくるかを決める経営判断の材料」なのです。

さらに、工程比率は固定的なものではありません。開発するシステムの種類、規模、技術難易度、既存システムの有無などによって適切な配分は変わります。そのため一般的な目安を参考にしつつ、それぞれのプロジェクトの状況に合わせて調整することが重要です。

要件定義についてはこちらもご覧ください。
＞＞要件定義とは？作成手順や前後の流れをわかりやすく解説！のページへ

工程比率をある程度決めずに開発を進めると、現場任せの進行になりやすく、次のような問題が起こります。

・本来時間をかけるべき工程で十分な作業時間が取れない
・後半で問題が集中し、納期に間に合わなくなる
・品質確認が不十分になり、不具合が残る
・現場の負担が増え、属人化や疲弊が進む

特に多いのが、「前工程の不足が後工程にしわ寄せされるパターン」です。要件定義や設計の比率が低いと、「聞いていた話と違う」「想定外のケースが出てきた」といった問題が開発終盤に発覚します。すると、実装のやり直しや追加テストなどの現場への負担が重くのしかかり、コストもスケジュールも膨らみます。

これは単なる技術的な問題ではなく、マネジメント設計の問題です。工程比率は、プロジェクト開始時点でのリスク管理であり、品質保証の土台でもあります。

経営層にとって重要なのは、「なぜその工程にその工数が必要なのか」を理解し、短期的なコスト削減だけで工程を削らない判断をすることです。工程比率の設計は、将来の手戻りコストを防ぐための「先行投資」ともいえるのです。

システム開発は、いくつかの工程にわかれて段階的に進みます。一般的には「要件定義→設計→実装→テスト」という流れで進行します。それぞれの工程には役割があり、どれか1つでも不足すると最終的な品質やコスト、納期に大きな影響が出ます。

工程比率については、組織や企業をまたがって収集した多数の開発データが整理分析されたIPAの『ソフトウェア開発分析データ集2022』が参考になるでしょう。

ここでは、上記のソフトウェア開発データ白書も踏まえ、システム開発における各工程についての説明と工程比率についてご説明します。

ただし、ここで紹介する工程比率はあくまで目安です。実際にはプロジェクトの規模、システムの複雑さ、既存資産の有無、開発体制などによって変動します。そのため、以下の数値は「標準的な傾向」として捉え、プロジェクトごとに都度調整することが重要です。

システム開発についてはこちらもご覧ください。
＞＞システム開発とは？工程や手法、依頼時のポイントまでわかりやすく解説のページへ

要件定義における工程比率の目安は約10％～20％です。

要件定義は、「何をつくるのか」を決める工程です。ここで経営課題や業務課題を整理し、システムに求める機能や性能、制約条件などを明確にしていきます。具体的には、次のような内容を整理します。

・現在の業務の課題
・システム導入の目的
・必要な機能の洗い出し
・利用部門・利用者の範囲
・連携する他システム
・セキュリティや性能面、運用面の条件

ここが曖昧なまま進むと、「思っていたものと違う」という事態が起こりやすくなります。経営層の意図が正しく反映されないリスクも高まるでしょう。その結果、後工程での手戻りや追加開発が発生し、コスト増加につながります。

要件定義は一見すると地味ですが、投資対効果を左右する非常に重要な工程です。

設計における工程比率の目安は約20％～30％です。

設計は、要件定義で決めた内容をもとに、システムの中身を具体化する工程です。設計工程は、主に次の2つにわけられます。

・基本設計：画面の構成や操作方法、外部システムとの連携方法など、利用者から見える部分の設計
・詳細設計：プログラム内部の処理内容やデータ構造など、技術的な詳細の設計

この工程は、システムの「設計図」をつくる作業にあたります。建物でいえば、構造計算や詳細図面をつくる段階です。

設計の比率が低すぎると、実装段階で判断に迷いが生じ、担当者ごとの解釈の違いが出ます。その結果、品質のばらつきや手戻りが増える可能性が高まります。逆に設計がしっかりしているプロジェクトは、実装がスムーズに進み、トラブルが少ない傾向があります。

実装における工程比率の目安は約30％～40％です。

実装は、設計書に基づいて実際にシステムをつくる工程（プログラミング）です。エンジニアがコードを記述し、画面や機能を形にしていきます。

一般的に「開発」と聞いてイメージされやすい工程ですが、実装だけでシステムの成否が決まるわけではありません。前工程の質が低い場合、実装中に仕様変更や設計見直しが頻発し、効率が大きく下がります。

そのため、実装の比率は高いものの、単純に実装工程を増やせばよいという考えは危険です。前工程とのバランスが取れてこそ、実装の生産性が発揮されるのです。

テストにおける工程比率の目安は約20％～30％です。

テストは、完成したシステムが正しく動作するかを確認する工程です。単に「動くかどうか」だけでなく、次のような観点も確認します。

・機能が仕様通りか
・操作性に問題はないか
・異常時に正しく処理されるか
・データが正しく保存・連携されるか
・性能に問題はないか

テストは品質を管理・担保するための最後の砦です。この工程の比率が低いと、不具合を抱えたまま本番稼働するリスクが高まります。結果として、稼働後の障害対応や信用低下といった経営リスクにつながります。

特に近年は、システム停止が事業に直結するケースも多いため、テスト工程はコストではなくリスク対策投資と捉えることが重要です。

前章では一般的な工程と比率の目安を説明しましたが、実際のプロジェクトでは開発するシステムの種類によって最適な工数配分は変わります。同じ「システム開発」でも、新しくゼロからつくる場合と、既存システムを修正する場合では、重点を置く工程が異なるからです。

ここでは、新規開発、改良開発、再開発の3パターンの工数比率の考え方について解説します。ただし、ここで紹介する内容もあくまで目安です。システムの規模、業務の複雑さ、既存資産の品質などによって調整が必要になります。

新規開発とは、これまで存在しなかったシステムを新たに構築することです。業務フローの整理からはじまり、仕組み自体をゼロから設計するケースが多くなります。

この場合、特に重要になるのは要件定義と設計の比率です。業務の整理や課題の明確化が不十分だと、「想定していなかった業務がある」「現場の運用にあわない」といった問題が後から発覚しやすくなります。新規開発では前例がないため、判断材料が少なく、不確実性が高いのが特徴です。

そのため、一般的な目安よりも要件定義や設計の比率が高めになる傾向があります。前工程に時間をかけることで、後半の手戻りを減らし、全体のリスクを抑えられるでしょう。

改良開発とは、既存のシステムを活用しながら機能追加や修正を行う開発形態です。現在稼働しているシステムをベースにするため、新規開発よりも要件のイメージがもちやすいという特徴があります。

ただし注意点もあります。既存システムの構造が複雑だったり、過去の仕様が整理されていなかったりすると、影響範囲の把握に時間がかかります。小さな変更のつもりが、思わぬ部分に影響を及ぼすこともあります。

そのため、改良開発では設計とテストの比率が重要になります。既存機能に影響が出ないかを慎重に確認する必要があり、テスト工程の負担が増える傾向にあるためです。

再開発とは、老朽化・陳腐化したシステムをつくり直す開発のことです。技術の更新や保守性の向上、運用コスト削減などを目的に実施されます。

再開発のむずかしさは、「現在動いている仕組みを止めずに置き換える」点にあります。既存システムの仕様が文書化されていないことも多く、実際の挙動を確認しながら進める必要があります。

この場合は、要件定義とテストの比率が高まる傾向があります。現行業務を正確に把握しなければ、置き換え後に業務が回らなくなるリスクがあるためです。また、旧システムとのデータ移行や並行稼働確認など、テスト項目も増えます。

再開発は一見「つくり直すだけ」に見えますが、実際にはリスクの高いプロジェクトであり、前後の工程に十分な時間を確保することが成功の鍵になります。

工程比率は単なる目安ではなく、プロジェクト全体の安定性を左右する重要な設計要素です。ここでは、現実的で実行可能な工程比率を決めるためのポイントを説明します。

工程比率を適切に決めるには、まず「何をどこまでやるのか」を具体的に分解することが重要です。「設計」「テスト」といった大きな言葉のままでは、実際の作業量が見えません。

たとえばテスト工程でも、

・単体テスト
・結合テスト
・総合テスト
・受入テスト

など、複数の種類があります。それぞれの工程でのテストの目的を明確にし、作業を細分化して洗い出すことで、作業量の全体像が明確になります。

作業内容が具体的になると、「誰が」「いつまでに」「どこまで」担当するかを決めやすくなり、工程ごとの比率も現実に即したものになります。

工程比率は、計画時だけでなく進行中の管理にも関係します。進捗管理ツールを活用すれば、各工程の進み具合を視覚的に把握できます。

・作業が予定より遅れていないか
・特定の工程に負荷が集中していないか
・問題が発生している箇所はどこか

このような情報が早期にわかると、工程比率の見直しやリソース再配分が可能になります。感覚や報告ベースの管理ではなく、データに基づいて判断することが、安定した開発につながるでしょう。

工程比率をPM（プロジェクトマネージャー）だけで決めると、理想論に偏ることがあります。実際の作業負荷や現場の制約を反映しきれないためです。

そのため、

・各工程の担当責任者
・現場の実務担当者
・運用担当者

など、さまざまな立場の人と話し合いながら決めることが重要です。現場の実情を踏まえた比率にすることで、計画倒れになるリスクを下げられるでしょう。

▽あわせて読みたい▽
＞＞PM（プロジェクトマネージャー）の育成はどのように行う？求められるスキルやポイントのページへ

開発作業のなかでは、想定外の事象が一定確率で発生します。仕様変更、技術的な問題、外部要因など、完全に予測することはできません。

そのため工程比率や工数をぎりぎりに設定すると、1つの遅れが連鎖し、全体スケジュールに大きな影響を与えます。

適度な余裕をもたせた工数設定は、無駄ではなくリスク管理の一環です。結果として、品質確保や納期遵守につながるでしょう。

システム開発における工程比率は、単なる作業時間の配分ではなく、プロジェクトの成功確率を高めるための経営管理指標です。どの工程にどれだけの時間と人員を投じるかは、品質、コスト、納期のすべてに直結します。

この記事で解説したとおり、一般的にシステム開発は「要件定義」「設計」「実装」「テスト」という複数の工程で構成され、それぞれに役割があります。特に前工程の不足は、後半での手戻りやトラブルの増加につながり、結果的にコスト増や納期遅延を招きます。短期的な工数削減が長期的な損失を生むケースは少なくありません。

また工程比率は固定的なものではなく、新規開発・改良開発・再開発といった開発形態によっても変わります。自社のプロジェクト特性に応じて比率を調整する視点が不可欠です。

工程比率を適切に設定するためには、作業内容の細分化、進捗の可視化、多角的な視点での合意形成、余裕をもたせた工数計画、などの取り組みが重要になります。

経営層に求められるのは、「なぜこの工程にこの工数が必要なのか」を理解し、現場任せにしないことです。工程比率は技術的な話ではなく、リスク管理と投資判断の話です。適切な工程配分は、結果として手戻りを減らし、安定した品質と事業価値の最大化につながるでしょう。

「工程比率に沿った開発がむずかしい」、「アジャイル開発に移行したいが社内にノウハウがない」とお悩みの場合は、SHIFTのアジャイル開発支援をご利用ください。

SHIFTのアジャイル開発支援では、お客様のアジャイル内製開発体制の構築とプロジェクト推進を強力にサポートいたします。また、アジャイル内製開発のための短期的な人材確保と長期的な人材育成など、お客様のニーズに合わせて柔軟に対応いたします。アジャイル開発でお困りの際には、SHIFTにご相談ください。

ご相談はこちらから
＞＞お問い合わせページへ
＞＞料金についてページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座

・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数

――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――