システム開発の上流工程とは？工程内容・成果物・下流工程との関係をわかりやすく解説

システム開発の上流工程とは、システム開発プロジェクトの初期段階を指します。具体的には、要件定義及び基本設計（外部設計）する段階を指し、システムが提供する機能や目的を明確にする作業のことを指します。

最近では要件定義よりもさらに上流の工程、企画・構想や戦略コンサルティングを上流工程に含める場合もあります。本記事では、企画・構想を最上流工程として各上流工程とPMに求められるスキルを解説していきます。

システム開発の上流工程とは？

上流工程での意思決定はプロジェクト全体の方向性を決定するため非常に重要であり、言い換えれば上流工程の活動がプロジェクトの成否を決めると言っても過言ではありません。
上流工程には、要件定義、システム設計、プロジェクト計画が含まれます。これらの活動を通じて、開発するシステムの全体像を把握し、具体的な開発作業に移る準備を整えます。

上流工程の定義と種類

ここでは、上流工程の種類を具体的に解説していきます。

システム企画

企画・構想フェーズは、システム開発に着手する前段階で、「なぜシステムを作るのか」「何を解決したいのか」を明確にする工程です。

発注者側で整理すべきポイントは以下です。

• 背景・課題の整理：業務で発生している問題点や非効率な部分を洗い出しと「システム化による期待する改善点」を明確にする。
• 目的・ゴールの設定：システム導入によって達成したい目的（業務効率化、コスト削減など）を定義する。
• 対象業務・利用者の整理：誰がどの業務でそのシステムを利用するのかを整理する。
• 概算スケジュール・予算感の検討：実現したい時期や想定予算を大まかに決める。
• 体制・役割：企画・構想フェーズを進めていく体制と、各メンバーの役割を決める。

要件定義

要件定義とは、顧客の要望（要求）を基に、システムが満たすべき具体的な「機能」「性能」「制約条件」を整理・明文化するプロセスです。要件定義の構成はプロジェクトによって異なりますが、一般的には以下の観点で整理されます。

• 機能要件：システムが実現すべき機能
• 非機能要件：システムの応答時間やデータ処理能力などの性能
• 品質要件：セキュリティや可用性などシステムの品質を確保するための基準
• 実行計画：システム開発に必要な工数・コスト・スケジュールの考え方

なお、要件定義工程についてより詳しい情報を知りたい方は以下をご確認ください。

関連記事：システム開発の要件定義とは？欠かせない要素と進め方を解説

見積り

システム開発の見積りは、単なる「金額提示」ではありません。上流工程では、企画の段階で見積もりをするパターン（概算見積り）と、要件や前提条件をもとに見積もり（詳細見積り）をするパターンがあります。

• 概算見積り：企画段階・要件が固まっていない段階で算出（予算の目安を知るために使われる）
• 詳細見積り：要件定義後、仕様が明確になった段階で算出（契約を見越して使われる）

なお、見積もりを算出する方法はいくつかあります。以下の記事で解説していますので、気になる方はぜひご覧ください。

関連記事：システム開発の見積りとは？算出方法・内訳・チェックポイントを徹底解説

基本設計（外部設計）

基本設計とは、要件定義が完了した後、要件定義で決めた内容をもとに、ハードウェアの設計やシステムの操作画面のレイアウトなど、搭載すべきものやシステムの特徴をより具体的に決定していきます。

仕様にもよりますが、基本設計は以下の項目が該当します。

• 業務フロー図
• システム構成図
• 画面一覧
• インターフェース図
• コード一覧
• CRUD図
• バッチ一覧
• DB設計書
• 非機能要件一覧

詳細設計（内部設計）

詳細設計では、システムの中身である機能や動作の設計を行います。開発言語やAPIとの連携、サーバー・データベース、プログラミングのルールの策定など、主に技術的な要素を設計していきます。

内部設計というとおり、人の目に触れないものを動かすために必要な部分を設計します。

なお※詳細設計はプロジェクトや企業によって、上流工程に含める場合と下流工程に含める場合があります。本記事では、上流工程の一部として扱っています。

上流工程の主な活動

上流工程では、前述のように要件定義、システム設計、プロジェクト計画の作成などが主な活動となります。これらの活動を通じて、開発すべきシステムの全体像を把握し、具体的な開発作業に移るための準備をします。

具体的な開発作業とは、プログラミング（コーディング）やテストなどを指します。これらの活動は、上流工程で設計したシステムを具体的に実現するための作業（下流工程）です。

次の章では、上流工程と下流工程の違いについて解説します。

上流工程と下流工程の違い

ここでは、上流工程と下流工程の違いについて解説していきます。

下流工程の種類

下流工程では、上流工程で完成された要件・設計を実際に形していきます。具体的には以下があります。

• 開発・製造
• テスト
• システム移行・リリース

これらについて解説していきます。

開発・製造

一言でいうと、コーディング・プログラミングと呼ばれるものです。内部設計の際にもプログラミングはしますが、ここでは、実際にモノを作り上げるイメージです。システムごとに必要となるプログラミング言語か異なるため、さまざまな言語を使い分けていきます。

テスト

開発が一通り完了したら、実際動くかテストをします。テストにはいくつか種類があり、それぞれ目的が異なります。

テスト名	テストの目的	テスト方法
単体テスト	プログラムが正しく動作するかチェックする	詳細設計の際に作成しておいた単体テスト仕様書をもとに行なう
結合テスト	プログラム同士を連携させて、正常に反応するかどうかをチェックする	基本設計書で定めた機能をもとに行なう
受入テスト（総合テスト）	システムを利用する環境に近いものを用意し、システム全体の機能や性能に問題ないかチェックする	要件定義で作成した要件の内容に沿っているかを行なう

※結合テストを「結合テスト・システムテスト」に分ける場合もあります。

なおシステム開発におけるテストの種類と詳細は以下の記事で解説しています。

関連記事：システム開発におけるテストの種類は？工程別に特徴と進め方、成果物を解説

システム移行・リリース

先述の各テストで徹底的に検証し、現場での運用に問題がない状態だと判断できれば、システム移行やリリースをおこないます。

市場にリリース（公開）するときは、システムのすべての機能が一度に公開されるわけではなく、クライアント側のビジネス戦略に応じて順次リリースされていきます。

もしも既存のシステムを使っている場合は、旧システムから新システムへの移行作業をおこないます。この場合も、一気に切り替えていく方法と、少しずつ切り替えていく方法があります。

上流工程と下流工程の違い

上流工程と下流工程の違いを以下の表に示します。

テスト名	テストの目的	テスト方法
目的	システムの方向性や要件・仕様を決める	決められた仕様をもとにシステムを形にする
主な役割	「何を・なぜ作るか」を明確にする	「どう作るか」「正しく動くか」を実現・検証する
主な工程	システム企画 要件定義 見積り 基本設計/詳細設計	開発（製造） テスト システム移行・リリース
主な成果物	要件定義書 設計書 見積書 プロジェクト計画書	プログラム テスト結果報告書 リリース済みシステム
関与する人物	プロジェクトマネージャー 発注者 業務担当者	エンジニア テスター 運用担当者
意思決定の重さ	非常に重い（後工程への影響が大きいため）	比較的軽い（仕様に従って実装）
変更のしやすさ	後工程に進むほど変更コストが増大	手戻りが発生しやすくコストが高い
失敗時の影響範囲	プロジェクト全体に影響	該当機能や工程に主に影響

上流工程は「考える工程」、下流工程は「作る工程」と言われることが多く、上流工程での判断や設計の精度が、下流工程の品質や効率を大きく左右します。

特にプロジェクトマネージャーは、上流工程での意思決定内容が下流工程で正しく実行されているかを常に確認・調整する役割を担います。

上流工程で作成される主な成果物

ここでは上流工程で作成される主な成果物をご紹介します。

要件定義書

要件定義書は、クライアントから提出された要求仕様書やRFP（提案依頼書）、企画書・仕様書、ヒアリングの中で聞き出した内容を基にして作成します。

これらはシステムを実際に設計・開発する前に提出する書類ですので、実装予定の機能についてできる限り詳細に記入する必要があります。

設計書（基本設計・詳細設計）

上流工程で詳細設計書を含めないこともありますが、設計書で必要となるものは以下です。

基本設計書の主な成果物一覧

• 業務フロー図
• システム構成図
• 画面一覧
• インターフェース図
• コード一覧
• CRUD図
• バッチ一覧
• DB設計書
• 非機能要件一覧

詳細設計書の主な成果物一覧

• 状態遷移図
• シーケンス図
• 画面遷移図
• クラス図
• アクティブ図
• モジュール構造図
• 入出力設計書
• バッチ処理設計書
• テスト設計書
• データベース物理設計書
• 外部インターフェース設計図
• IPO（処理機能記述書）

なお、各成果物の詳細は以下の記事で解説しています。

関連記事：基本設計における成果物とは？ 開発工程の流れや注意点を含めて解説

関連記事：詳細設計の成果物は何が重視される？ 進め方や注意点を紹介

見積書・プロジェクト計画書

見積書とともに、プロジェクト計画書も納品することがあります。プロジェクト計画書は、プロジェクトを成功に導くための羅針盤となるもので、具体的には、以下が含まれます。

• プロジェクト概要
• 作業の範囲と成果物
• コスト（人件費・外注費・ライセンス費用など）と予算
• スケジュールとタイムライン
• 体制とリソース
• リスク管理

上流工程で決めた内容は下流工程でどう活かされるのか

上流工程で決定した内容は、下流工程における開発・テスト・リリースといった各工程の“判断基準”として機能します。上流工程が曖昧なまま進むと、下流工程では「どう作るべきか」「どこまで作ればよいか」が分からず、手戻りや品質低下を招きやすくなります。

ここでは、上流工程での決定事項が下流工程でどのように活用されるのかを、具体的に解説します。

実装・コーディングの指針（何をどう作るか）

上流工程で整理された要件定義書や設計書は、下流工程における実装・コーディングの指針となります。
「どの機能を実装するのか」「どのような画面・操作性を実現するのか」「どのシステムと連携するのか」といった点は、すべて上流工程で決められた内容をもとに判断されます。

上流工程で要件や設計が具体化されていれば、開発担当者は迷うことなく実装作業に集中できます。一方で、要件が曖昧なままだと、実装方針が担当者ごとに異なり、品質のばらつきや認識ズレが発生しやすくなります。

テストの基準（何を確認するか）

テスト工程では、「何をもって正常とするか」という基準が重要になります。
この基準は、上流工程で作成された要件定義書や設計書をもとに設定されます。

たとえば、受入テストでは「要件定義で定めた機能や性能を満たしているか」が確認されます。
上流工程で要件が明確に整理されていれば、テスト項目も明確になり、漏れのない検証が可能です。

逆に、上流工程で要件が十分に整理されていない場合、「何を確認すべきか」が曖昧になり、不具合の見逃しや品質低下につながるリスクがあります。

手戻り（再作業）の防止と効率化

上流工程の品質は、下流工程における手戻りの発生率に大きく影響します。
要件や設計が不十分なまま開発を進めると、実装後やテスト段階で仕様の認識違いが発覚し、大幅な修正や再作業が必要になることがあります。

一方、上流工程で関係者間の合意形成を十分に行い、要件や設計を明確にしておくことで、下流工程では想定外の修正が減り、開発全体の効率化につながります。
結果として、コスト超過やスケジュール遅延のリスクも抑えられます。

コミュニケーションの共通認識

上流工程で作成される成果物は、プロジェクト関係者全体の「共通言語」となります。
発注者、プロジェクトマネージャー、開発担当者など、立場の異なる関係者が同じ認識を持つための基準として機能します。

特にプロジェクトマネージャーにとっては、上流工程で定めた内容が正しく下流工程に伝わっているかを確認・調整することが重要な役割です。
共通認識が形成されていれば、認識ズレによるトラブルを未然に防ぐことができます。

発注者・クライアント側が理解しておくべき上流工程のポイント

上流工程は、システム開発を成功させるうえで最も重要なフェーズの一つです。
そのため、開発を依頼する発注者・クライアント側にも、上流工程の役割や重要性を理解しておくことが求められます。

丸投げが失敗につながる理由

システム開発において、上流工程をすべてベンダーに丸投げしてしまうと、期待した成果が得られないケースが少なくありません。
これは、業務の背景や課題、システム導入の目的を最も理解しているのが、発注者側であるためです。

発注者側が上流工程に十分関与しない場合、要件が表面的なものにとどまり、実際の業務に合わないシステムが出来上がるリスクがあります。
また、認識のズレが後工程で発覚すると、大きな手戻りや追加コストが発生する原因にもなります。

そのため、上流工程では発注者・クライアント側も主体的に関与し、要件や方針についてベンダーと認識をすり合わせながら進めることが重要です。
これにより、プロジェクト全体の成功確率を高めることができます。

上流工程で重要な要件定義のポイント

要件定義の中で最も意識すべきことは、「開発するシステムが企業のどのような課題を達成するのか。」を明確にすることであり、その方向性がシステム全体の品質にも影響します。ここでの品質とは、システムが要件を満たす程度や、エンドシステムがユーザーの期待に応える度合いを指します。

要件定義の重要性

要件定義は、開発すべきシステムの目的や機能を明確にするための重要なプロセスです。この作業が不十分だと、システムがユーザーの期待を満たさない、または開発コストが想定以上にかかるなどの問題が発生します。エンドユーザーの期待を満たさないシステムは、受け入れられず、システム開発の目的を達成することができません。また、開発コストが予想以上にかかると、プロジェクトの予算を超過し、プロジェクトの継続が困難になる可能性があります。

要件定義の誤りがもたらす具体的な影響

前節でも触れましたが、要件定義が不十分の場合、後工程で悪い影響をもたらします。具体的には、システムがエンドユーザーの期待を満たさないと、システムの利用者が減少し、システム開発の目的が達成されない可能性があります。また、要件未達成により、本来システム化できたものを業務オペレーションでカバーするといった動きが起き、非効率な業務、否定形的な業務を生むことになります。

また要件定義をし直すことになると、開発コストが予想以上にかかる、プロジェクトの予算を超過し、プロジェクトの継続が困難になる可能性も秘めています。さらに、開発スケジュールが遅延すると、システムのリリースが遅れ、ビジネスチャンスや業務効率化の機会を逃すことになります。

要件定義を成功させるための方法

要件定義を成功させるためには、エンドユーザーニーズに対する深い理解が重要です。ニーズを正確に理解するためには、ユーザーとのコミュニケーションに重点を置き、ユーザーの要求や期待への詳細なくみ取りが必要です。また、ユーザーのニーズやビジネス環境が変化する場合に備え、要件定義は一度で完了させずに、開発プロセス全体を通じて繰り返し行う必要があります。

ステークホルダーとのコミュニケーションの重要性

ステークホルダーとの適切なコミュニケーションは、要件定義の成功に大きく貢献します。ステークホルダーとは、主に『プロジェクトに関わる利害関係者のこと』を指しており、エンドユーザーの他、お客様先のプロジェクトマネージャー、プロジェクトに参画するメンバー、経営幹部層なども含みます。ステークホルダーの期待や要求を正確に理解し、それらをシステムの要件に反映させることが求められます。

上流工程の成功がプロジェクト全体に与える影響

上流工程の成功は、プロジェクト全体の成功に直結します。そのため、上流工程を適切に管理することは、コスト、時間、品質といったプロジェクトの三大要素を適切にバランスさせるために不可欠です。
これらの要素は、プロジェクトの成功を評価するための基準となります。

上流工程の成功がもたらすプロジェクトの効果

上流工程が成功すれば、開発作業がスムーズに進行し、予定通りのコストと時間でシステムを開発することが可能になります。また、要件が明確になることで、ユーザー満足度が向上する可能性があります。

これは、ユーザーのニーズに適合したシステムを提供することで、システムの利用者が増え、システムの価値が高まるためです。

上流工程の失敗がプロジェクトに及ぼす影響

一方、上流工程が失敗すると、開発作業が停滞したり、開発コストが予想以上にかかったりする可能性があります。

開発作業が停滞すると、システムのリリースが遅れ、ビジネスの機会を逃す可能性があります。開発コストが予想以上にかかると、プロジェクトの予算を超過し、プロジェクトの継続が困難になる可能性があります。

また、要件が不明確なまま開発が進むと、システムがユーザーの期待を満たさない可能性もあります。これは、システムがユーザーのニーズに適合しないため、システムの利用者が減少し、システムの価値が低下する可能性があるためです。

プロジェクトマネージャーに求められるスキルとは？

プロジェクトマネージャー（以下、PMとします。）は、システム開発プロジェクトの成功を導くための重要な役割を果たします。そのためには、技術的なスキルだけでなく、プロジェクトを管理し、チームをリードするためのさまざまなスキルが求められます。

PMの役割

PMの主な役割は、プロジェクトの計画、実行、監視、そしてプロジェクトの終了までを管理することです。これには、スケジュール管理、コスト管理、品質管理、リスク管理などが含まれます。

・スケジュール管理
プロジェクトの作業を計画し、その進行を監視し、必要に応じて調整することを指します。
・コスト管理
プロジェクトのコストを計画し、その実績を監視し、必要に応じて調整することです。
・品質管理
システムの品質を計画し、その実績を監視し、必要に応じて調整することです。
・リスク管理
プロジェクトのリスクを予測し、その影響を軽減または排除するための対策を計画し、その実施を監視することです。

必要なハードスキルとソフトスキル

PMには、プロジェクト管理のためのハードスキル（例：プロジェクト管理ツールの使用、リスク分析など）と、チームをリードするためのソフトスキル（例：コミュニケーション、リーダーシップ、問題解決能力など）が求められます。ハードスキルとは、具体的な技術や知識を指します。ソフトスキルとは、人間関係をスムーズに進めるためのスキルや、問題を解決するための思考力を指します。

PMが上流工程を成功に導くための戦略

上流工程の成功は、プロジェクト全体の成功に直結します。そのため、PMは上流工程を成功に導くための適切な戦略を立てることが求められます。

プロジェクト計画の策定

プロジェクトの計画は、プロジェクトの目標を達成するためのロードマップです。PMは、上流工程の活動を適切に計画し、それを実行するためのリソースを確保する必要があります。（リソースとは、人材、時間、財政、設備など、プロジェクトを進めるために必要な要素を指します。）これらのリソースを適切に管理し、最大限に活用することが、プロジェクトの成功につながります。

リスク管理の重要性

リスク管理は、プロジェクトの成功を阻む可能性のあるリスクを予測し、それを軽減または排除するための活動です。PMは、上流工程におけるリスク（例：要件の不明確さ、ステークホルダーとのコミュニケーション不足など）を早期に特定し、適切な対策を講じる必要があります。

まとめ：システム開発における上流工程の意味

以上のように、システム開発の上流工程とは、システム開発プロジェクトの初期段階で行われる要件定義や設計などの活動を指します。これらの活動はプロジェクト全体の方向性を決定するため、非常に高い重要性を持ちます。

特に、要件定義はシステム全体の品質に直結するため、精度が求められます。また、上流工程を適切に管理するプロジェクトマネージャーには、技術的なスキルだけでなく、プロジェクトを管理し、チームをリードするためのさまざまなスキルが求められています。

上流工程の成功は、プロジェクト全体の成功に直結します。そのため、上流工程を適切に管理することは、コスト、時間、品質といったプロジェクトの三大要素を適切にバランスさせるために不可欠です。

上流工程が成功すれば、開発作業がスムーズに進行し、予定通りのコストと時間でシステムを開発することが可能になります。また、要件が明確になることで、システムがユーザーの期待を満たす可能性も高まります。

一方、上流工程が失敗すると、開発作業が停滞したり、開発コストが予想以上にかかったりする可能性があります。また、要件が不明確なまま開発が進むと、システムがユーザーの期待を満たさない可能性もあります。これらの問題を避けるためには、上流工程の活動を適切に計画し、リスクを早期に特定し、適切な対策を講じることが重要です。

これらのことを踏まえ、システム開発の上流工程の重要性と、その成功に向けた戦略について理解を深めることで、システム開発プロジェクトの成功につながるでしょう。

• 

  GeNEEの開発実績

  製造業、小売業、流通業、印刷・出版業など、業界別のベストプラクティスを保持しています。
  弊社の開発実績にご関心のある方はこちら

  一部公開可能な事例を掲載中

• 

  GeNEEの事業内容

  現在、6事業を展開しております。お客様の状況や目標に合わせて、FITするソリューションを提供いたします

  6事業の詳細はこちら

• 

  弊社主催セミナー

  最大月に1回のセミナーを開催しております。毎回30名以上の方にご出席いただいております。
  テック系のセミナーにご興味ある方はこちら

  月に1回テック系セミナー開催中

• 

  オウンドメディア

  GeNEE は技術に関する情報発信を積極的に行っています。 弊社のお客様だけでなく、業界全体に貢献のできる品質の高い情報提供を心掛けています。

  最先端テクノロジーの情報配信中

• 

  GeNEEの会社概要

  ビジネスxテクノロジーxデザインの三位一体で、お客様の課題を解決する独自のアプローチをご紹介

  創業から15年の実績

• 

  GeNEEの5つの特徴

  なぜGeNEEはコンサルティングやシステム開発のプロジェクト成功率が高いのか。
  競合他社との違いや優位性についてまとめております。

  GeNEEの5つの特徴

• 

  GeNEEへのお問い合わせ

  DX/ITコンサルティングのご依頼やシステム開発・スマホアプリ開発のご相談はこちらのフォームからお願いいたします

  お問い合わせフォームはこちら

• 

  GeNEEの資料をダウンロード

  ご希望の会社様にGeNEEのパンフレットをお送りしております。
  ITベンダーとの繋がりをお探しの方は是非お気軽にリクエストください。

  資料ダウンロードはこちら