ＰＧ・ＳＥ初級・中級者の方向け
システム開発の工程（プロセス）と工程比率、PMBOKとの違いについて

システム開発工程と工数比率

システム開発の工程

システム開発では、いきなりプログラムを作り始めるわけではありません。
「どのようなシステムを作るのか」を整理し、利用者の要求を確認し、設計を行い、プログラムを開発し、テストを実施して、最終的に利用者へ提供します。
このように、システム開発には一定の順序と工程があります。
また、実際のシステム開発プロジェクトでは、開発作業だけでなく、スケジュール管理、品質管理、課題管理、リスク管理、関係者とのコミュニケーションなど、多くの管理業務が必要になります。

システム開発工程とは、システムを企画してから、設計・開発・テスト・導入・運用まで進めていく一連の作業の流れです。
代表的な開発工程として、次のようなものがあります。

1. 企画・構想
   • システム開発の最初の段階が、企画・構想です。
   • 「なぜシステムを作るのか」「どのような問題を解決したいのか」を整理します。
   • この段階では、単に「新しいシステムを作る」という話だけではなく、「システムを導入した結果、どのような効果を得たいのか」まで考えることが重要です。
2. 要件定義:
   • クライアントの要望や解決したい課題をヒアリングし、システムに必要な機能や予算、納期を確定させる最も重要な工程です。
3. 基本設計（外部設計）:
   • 要件定義で整理した内容をもとに、システム全体の構造や機能を設計します。
   • 基本設計では、利用者から見たシステムの仕様を中心に検討します。
   • 具体的には、画面レイアウト、帳票、業務フロー、システムの処理概要など「ユーザーが見える・操作する部分」の仕様を、中心に決定します。
4. 詳細設計（内部設計）:
   • 基本設計をベースに、データベースの構造やアルゴリズムなど「システム内部の仕組み（開発者向け）」を具体化します。
5. プログラミング（実装）:
   • 設計書に従い、実際にプログラミング言語を用いてコードを記述し、システムを形にします。
   • 複数の開発者が参加する大規模プロジェクトでは、ソースコードの管理や開発ルールを統一することも重要です。
6. テスト:
   • 開発されたプログラムが仕様通りに動くか段階的に確認します。
   • 「単体テスト」：
     　開発したプログラムを、機能単位で確認する工程です。
     　単体テストでは、プログラムの内部処理が設計どおりに動作するかを確認します。
   • 「結合テスト」：
     　複数のプログラムや機能を組み合わせて、正しく連携できるか確認します。
     　それぞれの機能を組み合わせて、データが正しく引き渡されるかを確認します。
   • 「総合テスト（システムテスト）」：
     　システム全体が、要求された仕様どおりに動作するかを確認します。
     　「機能が動くか」だけではなく、「実際の業務で利用できるか」という観点が重要になります。
7. 受入テスト（運用テスト）
   • 受入テストは、顧客やシステム利用者が中心となって実施するテストです。
   • 受入テストで利用者から承認を得て、正式なリリースへ進みます。
8. リリース（システム移行）:
   • テストをクリアしたシステムを実際の運用環境に移行し、稼働を開始させます。
   • 特に大規模なシステムでは、リリース作業そのものが大きなプロジェクトになる場合があります。
9. 保守・運用:
   • リリース後もシステムが正常に稼働するよう監視し、不具合の修正や機能追加、環境のアップデートを継続して行います。
   • システムを安定して利用し続けるためには、開発工程だけではなく、運用・保守まで含めて考えることが重要です。

ウォーターフォール開発の開発工程の工数比率

ウォーターフォール開発のスクラッチ開発工程比率は、設計：開発：テストの場合、３：４：３となります。
・設計→要件定義、基本設計、詳細設計
・開発→プログラム設計、プログラミング（コーディング）、単体テスト
・テスト→結合テスト、総合テスト、受入（運用）テスト
・移行については、本稼働へ向けた作業となりますので、稼働時期等利用者側の要件等も加味して別途時期・期間を見積もります。
これは、目安であり各プロジェクトの特性により調整を行います。
例えば、要件があいまいでスコープを詰める必要があれば、要件定義の工数を上げることなど配慮します。

システム開発工程を理解するメリット

システム開発工程を理解すると、自分が担当している作業だけでなく、プロジェクト全体を見ることができるようになります。
例えば、プログラマーであれば、「自分は現在、開発工程を担当している」と理解できます。
さらに、「この前の工程では詳細設計が行われていた」、「この後には結合テストがある」、「自分が作るプログラムは、次のテスト工程で利用される」というように、前後の工程との関係も理解できます。
これは、IT業界で仕事をするうえで非常に重要な知識です。

（参考）パッケージ導入での工数比率

大規模主幹業務系パッケージの導入は、開発工程も違っており、上記の比率はあてはまりません。
設計（FIT＆GAP分析等）、開発（パラメータ設定（カスタマイズ）・アドオン開発）、テストとなっていきます。
アドオンが不要であれば、開発工程の比率が下がり、テストについてもパッケージ部分のテストは省けますので、
設計４：開発２：テスト３：移行：１が目安となります。
移行を工程比率に含めたのは、パッケージでの移行作業はパターン化されている場合が多く初期から工数の目安がついています。
また、パッケージの導入では、あまり開発工数が大きくないので、全体の工数から移行の比率が大きくなるためです。

開発手法　ウォーターフォール開発とアジャイル開発について

システム開発の工程を進める手法には、全体のプロセスを順番に完了させる「ウォーターフォール開発」と、
設計・実装・テストを小さな単位で繰り返す「アジャイル開発」があります。

ウォーターフォール開発

工程をある程度明確に分け、計画に沿って順番に進める方法です。
「要件定義」→「 設計」→「 開発」→「 テスト」→ 「リリース」という流れが代表的です。
要件が比較的明確で、変更が少ないシステムなどで採用されることがあります。

アジャイル開発

小さな単位で開発・テスト・改善を繰り返しながら、システムを成長させていく方法です。
利用者からのフィードバックを取り入れながら開発できることが特徴です。
新しいサービスや、要件が変化しやすいシステムなどで利用されることがあります。
実際のプロジェクトでは、ウォーターフォールとアジャイルの考え方を組み合わせた「ハイブリッド型」が採用されることもあります。

開発工程とPMBOKとの関係について

システム開発を管理するうえで、知っておきたい代表的な知識体系がPMBOK®です。
PMBOKは、Project Management Body of Knowledgeの略で、プロジェクトマネジメントに関する知識を体系的に整理したものです。
PMBOK®ガイドは、Project Management Institute（PMI）が発行しているプロジェクトマネジメントの代表的な標準です。現在は第8版が公開されており、2025年11月に発行されています。

PMBOKで重要なマネジメント視点

• スコープ管理:
  • 開発工程が進むにつれて発生する「仕様変更（追加要望）」を、計画変更の手続き（チェンジコントロール）を通して厳格に管理します。
• 品質管理:
  • 各工程の「終結」フェーズで、あらかじめ決めた「ゲート（品質基準）」をクリアしているかチェックし、基準に達していなければ次の工程に進ませません。

PMBOKとシステム開発工程の違い

システム開発工程とPMBOKは、同じものではありません。

• システム開発工程：
  • 「システムをどのように作っていくのか」という開発作業の流れです。
  • 開発工程＝何を作るか・どのように作るか
• PMBOK：
  • 「プロジェクトをどのようにマネジメントするのか」という考え方・知識・実践方法を整理したものです。
  • プロジェクトマネジメント＝プロジェクトをどのように成功させるか

PMBOKのプロセス群（全体管理の段階）

1. 立ち上げ：プロジェクトの承認を得て目的を明確にする段階。
2. 計画：スケジュールやコスト、品質の目標と手順を細かく決める段階。
3. 実行：計画に沿って作業を進め、チームをまとめる段階。
4. 監視・コントロール：進捗のズレや問題を見つけて修正する段階。
5. 終結：すべての作業を完了し、顧客に引き渡す段階。

開発工程とPMBOKの組み合わせ構造

システム開発の各工程（要件定義、設計、製造、テスト）の内部では、以下のようにPMBOKのプロセスが実行されます。

• 要件定義工程（仕様を決める）
  • 立ち上げ: 要件定義の開始宣言、ステークホルダー（利害関係者）の特定。
  • 計画: 要件定義をいつまでに、誰が、どう進めるかの計画策定。
  • 実行: ユーザーへのヒアリング実施、要件定義書の作成。
  • 監視・コントロール: スケジュール遅延のチェック、要望の膨らみ（スコープクリープ）の抑制。
  • 終結: ユーザーからの要件定義書の承認（サインオフ）、次工程への引き継ぎ。

• 設計工程（基本設計・詳細設計）
  • 立ち上げ: 設計作業の開始、設計メンバーの決定。
  • 計画: 設計書のレビュー方法、成果物の基準、スケジュールの決定。
  • 実行: 基本設計書・詳細設計書の作成、レビューの実施。
  • 監視・コントロール: 設計の進捗管理、要件定義との整合性チェック。
  • 終結: 設計書の完成、開発チームへの引き継ぎ。

• 製造（プログラミング）工程
  • 立ち上げ: 開発環境の構築、コーディングルールの共有。
  • 計画: 実装順序の決定、ソースコードの構成管理計画。
  • 実行: プログラミング、単体テストの実施。
  • 監視・コントロール: ソースコードの品質（バグ数）測定、開発遅延の対策。
  • 終結: ソースコードの凍結、結合テスト環境への移行。

• テスト工程（結合・システム・受入）
  • 立ち上げ: テスト環境の準備、テストチームの結成。
  • 計画: テスト仕様書の作成、合格基準（残バグ数の許容値など）の定義。
  • 実行: テストの実行、バグ（不具合）の起票と修正確認。
  • 監視・コントロール: バグ収束曲線の分析、未解決バグの進捗管理。
  • 終結: テスト報告書の作成、本番環境へのリリース判定。

PMBOK®ガイドは、Project Management Institute（PMI）が発行するプロジェクトマネジメントの標準です。
現在の最新版は第8版で、PMI公式サイトでは第8版について、従来の原則・パフォーマンス領域を基礎としながら、実務に適用しやすいプロセスガイダンスを再整理したものと説明されています。
PMBOK®はProject Management Institute, Inc.の登録商標です。