システム開発の上流工程とは？各役割や下流との違いについて解説
「システム開発を依頼したいが、見積書や工程表にある『上流工程』という言葉が具体的によくわからない」 「なぜ開発（プログラミング）を始める前の準備に、これほどの費用と期間がかかるのか？」
システム開発の外部委託を検討する際、このような疑問をお持ちではないでしょうか。 システム開発における「上流工程」とは、建物を建てる前の「設計図」を作成する段階に等しく、プロジェクトの成否を分ける最も重要なフェーズです。ここをおろそかにすると、後から「思っていた機能がない」「使いにくい」といった大きなトラブルにつながりかねません。
本記事では、上流工程の具体的な内容や下流工程との違い、発注者が注意すべきポイントを解説します。ぜひ発注前の基礎知識としてお役立てください。
▼システム開発については、以下の記事でも解説しています。
「システム開発とは？開発手法・工程・費用・外注メリットまで徹底解説」
目次
【サンプル】システム開発 提案依頼書（RFP）
この資料でわかること
こんな方におすすめです
- 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
- 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
- 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方
システム開発における「上流工程」とは？
上流工程とは、開発の初期段階である「企画・要件定義・設計」を指します。一言で言えば、「どのようなシステムを作るか」「どんな機能を持たせるか」を決めるフェーズです。
上流工程での曖昧さや漏れは、その後の開発工程で手戻りを大量発生させ、コスト超過や品質低下の主要因になります。逆に、上流工程でビジネス・業務・技術の観点から仕様をきちんと固めると、下流工程がスムーズになり、納期・コスト・品質をコントロールしやすくなります。
下流工程との違い
一方、下流工程とは、決定した設計図に基づいて実際にプログラミングを行い、正しく動くかテストをする「製造・試験」の段階、つまり「実際に作る」フェーズを指します。
上流工程 | 下流工程 | |
|---|---|---|
主な役割 | 企画、要件の決定、設計図の作成 | プログラミング（実装）、テスト |
イメージ | Thinking（考える・決める） | Making（作る・検証する） |
担当者 | 発注者とSE（システムエンジニア）が協力 | 主にプログラマーが担当 |
重要性 | 何を作るか、方向性を決定づける | 設計通りに正確に作り上げる |
上流工程の具体的な4つのフェーズ
一口に「上流工程」といっても、その作業は段階的に進められます。ここでは、まだ何も決まっていない状態から、プログラマーが作業できる状態になるまでの4つのステップを順に解説します。
システム企画
開発のスタート地点であり、「超上流工程」とも呼ばれる段階です。ここでは、細かい機能の話をする前に、経営的な視点でプロジェクトの方針を固めます。
具体的には、「なぜシステムを作るのか（目的）」と「それによってどれくらいの利益や効果が見込めるか（投資対効果／ROI）」を明確にします。 例えば、「営業担当の残業時間を月20時間削減するために、日報システムを導入する」「予算は500万円、納期は半年後」といったゴールを設定します。ここがブレていると、開発途中で「あれもこれも」と機能を追加したくなり、予算オーバーの原因になります。
要件定義
発注者（お客様）の「やりたいこと」をヒアリングし、システムに必要な機能として明確に文章化するフェーズです。発注者と開発会社の間で「これから作るものはこれですね」と合意形成を行う、最も重要なステップと言えます。
ここでは主に以下の2つを定義します。
機能要件（何ができるか）
「会員登録ができる」「商品を検索できる」「請求書をPDFで発行できる」など、システムが具体的に行う処理のことです。
非機能要件（性能やセキュリティ）
「ボタンを押して2秒以内に画面が切り替わること（性能）」「顧客データは暗号化すること（セキュリティ）」など、機能以外の品質に関する条件です。
これらを曖昧にせず言語化・文書化することで、「言った・言わない」のトラブルを防ぎます。
基本設計（外部設計）
要件定義で決まった内容をもとに、ユーザー（利用者）から見える部分の仕様を決定する工程です。「外部設計」とも呼ばれます。
具体的には、パソコンやスマートフォンの画面レイアウト（ボタンの配置や色）、操作の手順、出力される帳票（レシートや請求書）のデザインなどを決めます。「このボタンを押したら、次はどの画面に移動するか」といった使い勝手（UI/UX）を確定させるため、発注者側も積極的に確認し、イメージと合っているかチェックする必要があります。
詳細設計（内部設計）
基本設計の内容を、実際にプログラマーがプログラムコードを書くための技術的な設計図に落とし込む工程です。「内部設計」とも呼ばれます。
ここでは、ユーザーの目には見えない「システム内部の仕組み」を構築します。例えば、データを保存する「データベース」の構造をどうするか、どのような計算式（ロジック）で金額を算出するか、といった技術的な詳細を決定します。
このフェーズは専門性が高いため、基本的には開発会社のエンジニア主体で進められます。
上流工程で作成する主な成果物の例
上流工程では、最終的にどのような書類（ドキュメント）が出来上がるのでしょうか。これらは単なる記録ではなく、発注者との合意証明であり、下流工程への指示書となります。代表的な成果物を紹介します。
要件定義フェーズの成果物例
要件定義書
決定した機能要件（何ができるか）、非機能要件（性能やセキュリティ）、業務要件（誰がいつ使うか）、制約条件（予算や法律など）を網羅的にまとめた、プロジェクトのルールのような書類です。
業務機能構成表・機能一覧
「在庫管理業務」には「入庫登録機能」と「出庫登録機能」が必要、といったように、業務に対して必要な機能をリスト化したものです。漏れがないか確認するために使います。
基本設計（外部設計）フェーズの成果物例
画面一覧・画面遷移図・ワイヤーフレーム
どのような画面が全部で何枚あり、ボタンを押すとどう移動するのか（画面遷移図）、各画面にはどのような入力項目があるのか（ワイヤーフレーム＝画面の設計図）を示した資料です。完成イメージを共有するために非常に重要です。
外部インターフェース設計書
今回のシステムが、他のシステムとどうデータをやり取りするかを定義したものです。例えば、「会計ソフトと連携して売上データを送る」際のデータの形式や通信ルールなどが記載されます。
詳細設計（内部設計）の成果物例
詳細設計書
プログラム一つひとつについて、「どのような入力データを受け取り、どんな計算をして、何を出力するか」という処理の流れ（アルゴリズム）や、エラーが起きたときの対処法などを記述した、プログラマー向けの指示書です。
入出力設計書
システムが出力する帳票のレイアウトや、システムが読み込むCSVファイルなどのデータ形式を細かく定義した設計書です。
なぜシステム開発において上流工程が重要なのか？失敗が招く3つのリスク
「とりあえず作り始めて、あとから直せばいいのでは？」と考えるのは危険です。上流工程での詰めが甘いと、プロジェクト全体に深刻な悪影響を及ぼします。ここでは代表的な3つのリスクを解説します。
手戻りによるコスト増大と納期遅延
システム開発には「修正コストは工程が進むほど跳ね上がる」という特徴があります。
例えば、紙の設計図の段階（上流工程）で「部屋の壁をなくしたい」と変更するのは簡単ですが、家を建ててしまった後（下流工程・完成後）に壁を撤去するには、解体や補強工事が必要となり、多大な費用と時間がかかります。
システムも同様で、プログラミング後に仕様の矛盾や誤りが発覚すると、プログラムの書き直しだけでなく、テストのやり直しも発生します。これを「手戻り」と呼び、当初の予算や納期を圧迫する最大の原因となります。
「望まないシステム」の完成
発注者と開発側のコミュニケーションが不足し、要件定義が曖昧なままだと、悲劇が起こります。 技術的にはバグ（不具合）がなく正しく動いているのに、「現場の業務フローと合わず使いにくい」「本当に欲しかった機能が付いていない」という、「コレジャナイ」システムが出来上がってしまうリスクです。
これでは、せっかくの投資が無駄になってしまいます。これを防ぐためには、上流工程で徹底的に「完成イメージ」をすり合わせる必要があります。
運用・保守フェーズでのトラブル
上流工程では、リリース後のことも考える必要があります。 将来ユーザーが増えたときにサーバーを増強できるか（拡張性）、システムにトラブルが起きたときに誰がどう対応するか（運用ルール）などを設計段階で考慮していないと、リリース後にシステムが頻繁に停止したり、少しの改修でも莫大な費用がかかったりと、長期的なビジネス損失につながる恐れがあります。
▼関連記事
「システム保守の引き継ぎで失敗しないための完全ガイド｜スムーズな移行と注意点を解説」
発注者が知っておくべき上流工程の契約と準備
最後に、実際に発注する際の実務的なポイントについて触れます。上流工程は「形のないもの」を作る作業であるため、契約形態や事前準備には特有の注意点があります。
契約形態の違い（準委任契約 or 請負契約）
システム開発の契約には、大きく分けて「準委任契約」と「請負契約」の2種類があり、工程によって使い分けるのが一般的です。
準委任契約（上流工程で一般的）
「システムを完成させること」ではなく、「業務を行う（考える）こと」に対して対価を支払う契約です。上流工程では、話し合いの中で仕様が変わったり、試行錯誤が必要だったりするため、完成責任を問うのが難しい場合があります。そのため、柔軟に対応できる準委任契約が選ばれることが多いです。
請負契約（下流工程で一般的）
「システムを完成させること」を約束し、その成果物に対して対価を支払う契約です。仕様がカッチリと決まった後の下流工程（製造）では、この契約が適しています。
上流工程からいきなり「完成責任」を求める請負契約にしてしまうと、ベンダー（開発会社）側はリスクを見込んで見積もりを高くせざるを得なくなったり、柔軟な仕様変更ができなくなったりする弊害があるため注意が必要です。
RFP（提案依頼書）の作成
開発会社に相談する際、ただ「良いシステムを作って」と伝えるだけでは、相手も正確な提案や見積もりができません。 そこで役立つのがRFP（提案依頼書）です。
発注者が作成する資料で、以下のような内容をまとめます。
- 開発の目的・解決したい課題（例：手作業の集計を自動化したい）
- 予算感（例：500万円～800万円程度）
- 希望納期
- 必要な機能の概要
事前に提示することで、開発会社からの提案の精度が高まり、「A社とB社で提案内容が全然違って比較できない」といった事態を防ぐことができます。
サブスクリプション型の開発チーム提供サービス「TechBand」のご紹介
秋霜堂株式会社が提供する「TechBand」は、月額10万円から利用できるサブスクリプション型の開発チーム提供サービスです。単にシステムを納品して終わりではなく、貴社の「システム開発部門」としてエンジニアチームが参画し、ビジネスの加速を強力にサポートします。
エンジニアが直接ヒアリングを行うため上流工程での認識ズレを防ぎやすく、1週間サイクルのアジャイル開発を採用しているため、開発途中の仕様変更や機能追加にも柔軟に対応できる点が大きな特徴です。最低契約期間の縛りもないため、リスクを抑えながら高品質な開発体制をすぐに構築できます。
【サンプル】システム開発 提案依頼書（RFP）
この資料でわかること
こんな方におすすめです
- 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
- 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
- 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
