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