システム開発の工程とは？各段階の目的・成果物・確認担当

システム開発の工程は、企画から要件定義、設計、実装、テスト、移行、運用へと仕事を整理するための区切りです。工程名を覚えるだけでなく、何を材料にして、何を決め、誰が次の段階へ渡すかを確認すると、自分が参加すべき場面を見つけやすくなります。

この記事では、開発に初めて関わる企業担当者とエンジニア向けに、各工程の役割を一つの地図にまとめます。工程名、成果物の名称、確認者はプロジェクトに合わせて調整してください。

開発工程の全体像を成果物でつかむ

IPAの共通フレームは、構想から開発、運用、保守、廃棄までの作業と役割を整理する枠組みです。IPAは、掲載する工程と作業の対応例を唯一の推奨体系とはしていません。IPA「共通フレーム2013」

以下はその規格表ではなく、業務システムを段階ごとに説明するための整理例です。「確認担当」は承認権限の指定ではなく、内容を確かめる役割の候補を示します。

工程	入力する材料	決めること・成果物の例	確認に参加する人
企画	業務上の課題、制約	目的、対象範囲、実施する理由	業務責任者、企画担当
要件定義	現行業務、利用者の要望	必要な機能、品質、対象外の条件	業務担当、開発担当、運用担当
基本設計・方式設計	合意した要件	画面、データ、連携、構成の仕様	開発担当、該当する業務・運用担当
詳細設計・実装	仕様と設計上の制約	処理の設計、プログラム、設定	実装担当、レビュー担当
テスト・受入	要件、設計、確認条件	テスト結果、修正記録、受入判断	開発・テスト担当、利用部門
移行・利用開始	確認済みシステム、移行計画	データ移行結果、切替結果、運用開始の判断	移行担当、業務責任者、運用担当
運用・保守	稼働中の構成、手順、問い合わせ	日常の確認、障害対応、変更記録	運用担当、開発担当、業務担当

資料を作る人と、業務として使えるかを判断する人は同じとは限りません。例えば開発担当が画面案を作っても、必要な情報が表示されるかは利用部門の確認が必要です。

要件定義では「どんな業務を成立させたいか」を整理し、設計では「それをどう実現するか」を具体化します。IPAも、利用者の要求を分析して関係者と合意する段階と、機能・構成・外部との接続を具体化する段階を分けて説明しています。IPA「要件定義とは」

説明用に、社内の備品貸出を扱うシステムを考えます。「二重予約を防ぎたい」は要望です。そこから、同じ備品の利用期間が重なるときの扱いや、予約を変更できる人を決めます。その条件を満たす画面、データの持ち方、処理を考えるのが設計の仕事です。

画面の見た目だけを先に確定すると、取消しや例外の扱いが残ることがあります。打ち合わせでは、今決めているのが業務上の条件か、実現方法かを確認し、未決事項を分けておきましょう。

テストを実行できる時点と、何を確かめるかを考える時点は別です。要件を決める際に「どの状態なら満たしたと判断できるか」を書いておくと、設計や実装の後に確認の基準を作り直さずに済みます。

備品貸出の例なら、通常の予約だけでなく、同じ時間帯の重複や取消しを確認対象の候補にします。細かなテスト項目は担当者が設計しますが、業務部門は実際に困る場面を伝えます。

利用部門が行う確認の具体化は、受入テストの準備で扱っています。工程表に「受入」と書くだけでなく、確認する人が使える時間と材料を確保してください。

次の工程へ進む際は、完成した資料に加え、未決事項と変更の連絡先を添えることを勧めます。以下は引き渡しメモの例です。

「設計完了」と報告されても、一部の外部連携だけ相手側の回答待ちなら、その部分まで確定したとは扱いません。一方、影響しない範囲まで必ず止める必要があるとも限りません。進められる部分と保留する部分を分けて判断します。

小さな機能を作って確かめる進め方では、表の工程が短い単位で繰り返されることがあります。この表は、一度終えた工程に戻れないという意味ではありません。

要求が変わったら、変更した文言だけでなく、設計、テスト、運用への影響も確認します。また、プログラムが完成した時点と、利用開始できる時点は区別しましょう。運用担当への資料・権限の受け渡しは、開発から運用への引き継ぎも参考になります。

まず、自分たちの工程表に「成果物」と「確認担当」の二列を加えてみてください。空欄があれば、作業が始まる前に関係者と補えます。開発体制についての相談先を探している方は、テクノヴァースのSES事業をご覧ください。