システム開発の上流工程とは？発注者が知っておくべき工程の全体像と関わり方

「要件定義はベンダーに任せておけばいい」

「詳しいことはよくわからないから、あとはよろしく」

システム開発を外注するときに、上記のような姿勢で依頼してしまう発注者は少なくありません。このような上流工程の丸投げが原因で、納期の遅延・コストの膨張・現場で使われないシステムの完成、という三重苦に陥るプロジェクトはよく見られます。

IPA（独立行政法人情報処理推進機構）もシステム開発の失敗の大きな原因の一つとして「要件定義の失敗」を挙げています。システム開発の成否は「上流工程」でどれだけ発注者が主体的に動けたかによって、大きく左右されるのです。

本記事では、上流工程の全体像から各フェーズで発注者がすべきこと、発注前の準備、ベンダー選定のポイントまでを発注者の視点で解説します。

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

システム開発の上流工程とは、開発プロジェクトの初期段階作業のことです。具体的には以下の作業が含まれます。

• システム企画
• 要件定義
• 見積り
• 基本設計（外部設計）
• 詳細設計（内部設計）

一言でいえば、上流工程とは「何を・なぜ・何のために作るかを決める作業」といえます。実際のコーディングやテスト・リリースといった「作る作業（下流工程）」に入る前に、システムの目的・機能・仕様を固めるフェーズがすべて上流工程に当たります。

発注者にとっては、この上流工程こそが「発注者の関与がもっとも求められるフェーズ」といえます。なぜなら、業務の課題や目的を1番よく知っているのは発注者自身だからです。ベンダーだけで上流工程を進めるのは非常に難しいでしょう。

なぜ上流工程が重要か

上流工程の質は、プロジェクトの成否を決めると言っても過言ではありません。なぜなら、システム開発では変更が入った場合の修正コストが遅れれば遅れるほど膨らむからです。

たとえば、要件定義の段階で発生する修正コストを「1」とするなら、開発段階での修正コストは「10」、テスト段階では「100」以上に膨らむ可能性があります。

家を建てるときでも、設計段階で部屋を追加するのと、工事が始まってから部屋を追加するのでは修正コストがまったく違うことはわかると思います。システム開発でも同じです。上流工程での認識のズレや見落としは後工程で大きな手戻りになってしまうのです。

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

上流工程は「考える工程」、下流工程は「作る工程」と表現されます。発注者の視点で両者の違いを整理したのが以下です。

項目	上流工程	下流工程
目的	何を・なぜ作るかを決める	決めた仕様をシステムとして形にする
主な工程	システム企画、要件定義、見積り、設計	開発、テスト、移行・リリース
主な成果物	要件定義書、設計書、見積書	プログラム、テスト結果報告書
発注者の関与	非常に高い（主体的な参加が必要）	受入テストでの確認が中心
意思決定の重さ	非常に重い（後工程への影響が大きい）	比較的小さい（仕様に従って実装）
変更コスト	早いほど低い	手戻りが発生すると高コスト

発注者がとくに意識すべきは「発注者の関与」です。上流工程では発注者が主体的に動かなければならない場面が多くあります。

一方、下流工程に入ると発注者の主な役割は受入テストでの確認に絞られます（スケジュールの調整等はある程度発生する）。上流工程が発注者の最大の見せ場であることを頭に入れておくことが重要です。

上流工程の各フェーズと発注者がすべきこと

上流工程は複数のフェーズで構成されており、それぞれのフェーズで発注者が果たすべき役割が異なります。「ベンダーに任せておけばいい」という場面と「発注者が主体的に動かなければならない」場面を正しく理解しておくことが、プロジェクトを円滑に進めるうえで重要です。

以下では各フェーズの内容と、発注者として意識すべきポイントを順に解説します。

システム企画

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

この工程で整理すべき内容は以下の5項目です。

• 背景・課題の整理：現在の業務で発生している問題点や非効率を洗い出し「システム化によって何を改善したいか」を言語化する
• 目的・ゴールの設定：業務効率化、コスト削減、顧客体験向上など、システム導入によって達成したい目標を定義する
• 対象業務・利用者の整理：誰がどの業務でシステムを使うのかを明確にする
• 概算スケジュール・予算感の検討：実現したい時期と想定予算の大枠を決める
• 推進体制の設計：企画フェーズを進める担当者・役割分担を決定する

発注者が意識すべきポイント：

これら5項目は発注者にしか整理できない情報です。ベンダーへのヒアリングで引き出してもらうことも可能ですが、事前に発注者側で整理しておけば、その後の要件定義の精度と速度が上がります。

要件定義

要件定義は、システムが満たすべき「機能」「性能」「制約条件」を整理・明文化するプロセスです。上流工程の中でもプロジェクトの成否に直結する工程であり、発注者とベンダーが密接に連携して進める必要があります。

発注者がベンダーに伝えるべき情報は、大きく以下の4つに分類されます。

分類	発注者が伝えるべき内容
機能要件	業務上必要な機能（例：受発注管理、在庫連携、帳票出力など）
非機能要件	応答速度、想定ユーザー数、データ処理量などの性能に関する要望
品質要件	セキュリティ基準、稼働率、障害時の復旧に関する要望
制約条件	予算・納期・利用環境・既存システムとの連携条件など

発注者が意識すべきポイント：

要件定義はベンダーが「聞き出す」工程ではなく、発注者が「教える」工程だと意識しましょう。業務の現場を知っているのは発注者側であり「なんとなくこういうものが欲しい」という温度感では、ベンダーは正確な要件を定義できません。とくに、現場の例外ルールや特殊なビジネスロジックは、発注者から積極的に伝えるようにしましょう。

見積り

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

種類	タイミング	用途
概算見積り	企画段階・要件未確定の段階	予算規模の目安を把握するために使用
詳細見積り	要件定義完了後、仕様が明確になった段階	契約の根拠として使用

発注者が意識すべきポイント：

概算見積りの段階では±30〜50%程度の幅があることが一般的です。見積りを確認する際は、金額だけでなく「根拠と前提条件」を確認しましょう。

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

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

基本設計（外部設計）

基本設計は、要件定義で決めた内容をもとに「システムが外部からどう見えるか」を具体化する工程です。ユーザーが直接触れる画面や操作の流れ、他システムとの連携方式などを設計します。

発注者がレビューすべき主な成果物は以下の4点です。

• 業務フロー図：現場の業務の流れがシステムに正しく反映されているかを確認する
• 画面一覧・画面レイアウト：実際の操作感をイメージしながら、使いやすさと業務適合性を確認する
• インターフェース設計図：既存システムや外部サービスとの連携方式に抜け漏れがないかを確認する
• 非機能要件一覧：要件定義で合意したセキュリティ・性能・可用性の要件が反映されているかを確認する

発注者が意識すべきポイント：

基本設計のレビューは「ベンダーの作業確認」ではなく「仕様と現場業務との照合」を意識しましょう。画面や業務フローが実際の現場の動きと合っているかどうかは、発注者にしか判断できません。ここで見落とした不一致が開発フェーズ以降に発覚すると、大規模な修正が必要になります。

詳細設計（内部設計）

詳細設計は、プログラムの動作ロジックやデータベースの物理設計など、システムの「内部」の技術的な実装詳細を定義する工程です。このフェーズになると主にエンジニアが中心となって進めるため、発注者が直接内容を判断する必要はありません。

発注者が意識すべきポイント：

詳細設計の遅延は開発フェーズ全体に波及するため、予定通り進んでいるかを定期的に確認することが重要です。開発定例会議を開催して定期的に進捗を確認するようにしましょう。

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

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

要件定義書

要件定義書は、発注者からの要求仕様・ヒアリング内容をもとに作成される書類です。実装予定の機能について、設計・開発前に関係者全員が合意した内容を記録した文書であり、プロジェクト全体の判断基準となります。

関連記事：要件定義の成果物とはなにか？具体的な作業内容や進め方についてシステムエンジニアが解説

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

設計書は、要件定義の内容をシステムで実現するための具体的な設計を記載した書類です。基本設計書はシステムの「外部」（画面・業務フロー・外部システム連携）を、詳細設計書はシステムの「内部」（ロジック・データ構造）を定義します。

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

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

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

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

プロジェクトのコスト・スケジュール・体制・リスク管理の方針を記載した文書です。主に以下の要素で構成されます。

• プロジェクト概要・目的
• 作業スコープと成果物の定義
• コスト内訳（人件費・外注費・ライセンス費用など）
• スケジュール・マイルストーン
• プロジェクト体制図
• リスク一覧と対応方針

発注前に準備しておくべき5つのこと

システム開発を外注する際、「まずベンダーに相談してから考えよう」という姿勢で臨む発注者は少なくありません。しかし、発注者側の準備が不十分なまま上流工程に入ると、ヒアリングが表面的なものにとどまり、要件定義の精度が下がります。

ここでは、発注前に準備しておく5つのポイントを解説します。

課題を定量的に言語化する

「業務が非効率」「システムが古い」といった漠然とした課題感では、ベンダーは適切な提案ができません。「月に何時間の作業が発生しているか」「どの工程でミスが頻発しているか」といった形で、課題を定量的に言語化しておくことが重要です。

数字で表せない課題は「具体的なシーン」で伝えることも有効です。「月末の締め処理になると担当者の残業が増える」「顧客からの問い合わせ対応中に別のシステムを何度も行き来しなければならない」など、現場の実態をエピソードとして整理しておきましょう。

機能の優先順位をつける

要望をすべて「必須」として伝えてしまうと、開発コストが際限なく膨らみます。事前に機能を以下の3段階に分けて整理しておくことで、予算内での最大効果を実現できます。

• Must：これがなければシステムとして成立しない機能
• Want：あると業務効率が上がる機能
• Could：将来的に追加できれば十分な機能

優先順位をつけることは、ベンダーへの「費用対効果の高い提案」を引き出すことにもつながります。

概算予算・スケジュール感を持つ

ベンダーへの初回相談時に「予算はいくらですか？」と聞かれて答えられない発注者は少なくありません。予算感を提示しないと、ベンダーは提案の規模感を判断できず、実態からかけ離れた提案が返ってくることがあります。

予算は「○○万円以内に収めたい」という目安で構いません。またスケジュールについても「このシステムを○月までに稼働させたい」という目標時期を持っておくことで、ベンダーとの初回相談がより具体的かつ生産的なものになります。

意思決定者・承認フローを決める

上流工程では、要件への合意・仕様変更の承認・予算追加の判断など、発注者側の意思決定が求められる場面が頻繁に発生します。その際「上長に確認してから返答します」という場面が続くと、プロジェクトの進みが悪くなりスケジュールに影響します。

事前に以下を決めておくことで、意思決定のスピードを確保できます。

• プロジェクトの担当窓口（ベンダーとの日常的なやり取りを行う担当者）
• 仕様・要件への最終承認者
• 予算変更が発生した際の承認フロー

開発後の運用イメージを持っておく

システムは完成・リリースして終わりではありません。導入後の運用・保守・改善まで見据えたうえで、上流工程を進めることが重要です。具体的には以下の点を事前に整理しておくと、要件定義や設計に反映しやすくなります。

• 導入後に社内のどの部門・担当者がシステムを管理するか
• 不具合や改善要望が発生した際の対応フロー
• 将来的な機能追加・拡張の可能性
• 保守・運用をベンダーに継続依頼するか、内製化するか

あわせて見落とされがちなのが、導入部門がシステムを使う動機付けです。どれだけ高品質なシステムが完成しても、現場の担当者に「使いたい」と思ってもらえなければ、リリース後に形骸化するリスクがあります。

上流工程の段階から現場担当者を巻き込み、「自分たちの課題を解決するシステムだ」という当事者意識を持たせることがシステム定着率を高めます。

上流工程丸投げで失敗する3つのパターン

システム開発の失敗パターンの王道として「上流工程のベンダー丸投げ」が挙げられます。失敗パターンを知っておくことで上流工程の大切さを確認しておきましょう。

パターン１：スコープが際限なく膨らみ納期が遅延する

要件があいまいなままで開発が進むと、進行中に「やはりこの機能もほしい」「仕様を変えてほしい」という追加・変更の要望が出てきます。これを「スコープクリープ」と呼びます。プロジェクトの範囲が当初の予定よりも拡大・肥大化していく現象です。

スコープクリープが起こると開発工数が増え、当初のスケジュールどおりに進まなくなります。結果、リリースが遅れてビジネスチャンスに乗り遅れる、現場に負担をかけ続けるという事態になる恐れがあります。

パターン２：手戻りが発生してコストが増大する

上流工程での認識ズレが後になって発覚した場合、遅ければ遅いほど修正コストは膨らみます。前述のとおり、要件定義段階での修正コストと比べてテスト段階での変更は修正コストが何十倍、何百倍にもなるのです。

丸投げによって要件が曖昧なまま開発が進むと、完成間近で「この画面に機能が足らない」「この機能では業務が進まない」といった問題が発生し、その手戻りでコストと開発期間が増大し、お金も導入時期も計画どおりに進まなくなります。

パターン３：現場で使えないシステムができあがる

発注者が上流工程にしっかり関わっていない場合、要件が表面的なものだけで終始してしまい業務実態に合わないシステムができてしまう可能性があります。

たとえば、現場担当者が日常的にこなす例外処理や特殊業務は、発注者からベンダーに積極的に伝えないと要件に反映されることはありません。「確かにモノ（システム）はできたが、うちの業務では使えない」というパターンはまさにこれです。

発注者が上流工程で確認すべきチェックリスト

3つの失敗パターンに共通するのは「気づいたときには手遅れ」という点です。要件定義は工事前の強固な基礎を築くための重要なフェーズですので、チェックリストを使いながら進めていくとよいでしょう。

企画フェーズ

□	システム化の目的・解決したい課題が文書化されているか
□	対象業務と利用者が明確に定義されているか
□	概算予算・スケジュールの目安が合意されているか
□	プロジェクトの担当窓口・承認者が決まっているか
□	現場担当者（エンドユーザー）が巻き込まれているか

要件定義フェーズ 

□	機能要件・非機能要件が具体的に文書化されているか
□	「必須機能」と「あったらいい機能」が区別されているか
□	現場の例外ルール・特殊なビジネスロジックが反映されているか
□	要件定義書の内容に関係者全員の合意が取れているか
□	スコープ（開発対象の範囲）が明確に定義されているか

 設計フェーズ 

□	業務フロー図が実際の現場の動きと一致しているか
□	画面レイアウトが現場担当者にとって使いやすい設計になっているか
□	既存システムとの連携方式に抜け漏れがないか
□	非機能要件（性能・セキュリティ・可用性）が設計に反映されているか
□	各フェーズの完了時に発注者として承認を行っているか

上流工程から伴走してくれるベンダーチェックリスト

上流工程での失敗を防ぐための準備と確認ができたとしても、伴走してくれるベンダー選びを誤れば、プロジェクトは失敗します。以下のチェックリストをベンダー選定の判断基準としてご活用ください。

	項目	概要
□	業務知識が豊富か	自社の業種・業態への理解をもとに、現場に即した設計を提案してくれるか
□	既存システムとのデータ連携実績があるか	販売管理・購買管理・会計システムなど、既存システムとの連携を前提とした設計をしてくれるか
□	要件定義・業務整理から支援できるか	仕様書を渡すだけでなく、上流工程の段階から伴走してくれるか。またその経験があるか。
□	運用・改善まで見据えた支援体制があるか	リリース後の保守・運用・機能改善まで長期的に対応してくれるか

基本的に過去の実績を元にチェックするとよいでしょう。開発メンバーの経験が浅いと、課題や問題への対処が後手後手になってしまい、開発が遅延、失敗する原因になる可能性があります。

まとめ：上流工程の質がシステム開発の成否を分ける

システム開発を成功させる要因は、上流工程の質が半分以上を占めるといっても過言ではありません。そのため、発注者が主体的に動き、ベンダーと連携を図るようにしましょう。

上流工程での失敗を防ぐために、本記事のチェックリストをプロジェクト開始前にご活用ください。

上流工程からのご支援をご検討の方は、ぜひGeNEEにご相談ください。企画・要件定義から開発・運用まで、一気通貫でサポートいたします。

FAQ（よくある質問）

Q. 上流工程と下流工程の違いは何ですか？

上流工程は「何を・なぜ作るかを決める工程」、下流工程は「決めた仕様をシステムとして形にする工程」です。

Q. 上流工程はどのくらいの期間がかかりますか？

小規模なシステムで1〜2ヶ月、中規模では3〜6ヶ月が目安です。上流工程を急いで短縮すると、後工程での手戻りリスクが高まります。

Q. 発注者は上流工程にどこまで関与すべきですか？

企画・要件定義フェーズでは深く関与することが重要です。業務の課題・目的・現場のルールは発注者にしか把握できない情報であり、ベンダーに丸投げすると業務に合わないシステムができあがるリスクがあります。

Q. 社内にIT担当者がいなくても上流工程は進められますか？

進められます。上流工程で最も重要なのは技術的な知識よりも、自社の業務・課題・目的を正確に伝えられるかどうかです。

Q. 上流工程を省略するとどうなりますか？

要件が曖昧なまま開発が進み、手戻り・コスト超過・納期遅延のリスクが高まります。

Q. 上流工程から対応してくれる開発会社はどう見つければいいですか？

「仕様書を渡してください」ではなく「まず業務を教えてください」というスタンスのベンダーが、上流工程への対応力を持っている目安になります。

• 

  GeNEEの開発実績

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

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

• 

  GeNEEの事業内容

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

  6事業の詳細はこちら

• 

  弊社主催セミナー

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

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

• 

  オウンドメディア

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

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

• 

  GeNEEの会社概要

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

  創業から15年の実績

• 

  GeNEEの5つの特徴

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

  GeNEEの5つの特徴

• 

  GeNEEへのお問い合わせ

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

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

• 

  GeNEEの資料をダウンロード

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

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