エンジニアの上流工程とは？下流工程との違いや必要スキルを解説

上流工程とはどこまで？エンジニアの担当範囲を解説

システム開発における上流工程は、開発の目的や利用者の要求を整理し、実装可能な仕様へ落とし込む前半の工程です。

本記事では、日本のIT政策を実施する公的機関である「IPA（独立行政法人情報処理推進機構）」が示す開発プロセスを踏まえ、企画・要件定義・基本設計を中心に上流工程として扱っています。

なお、上流工程は、管理職を意味する言葉ではありません。プロジェクトの方向性を決め、関係者の認識をそろえながら、システムの全体像を形にする開発フェーズを指します。

システム開発における上流工程の位置づけ

上流工程は、システム開発の土台を整える段階です。

企画では、業務上の課題やシステム化の目的を明確にし、開発の方向性を定めます。

要件定義では、利用者や事業部門へのヒアリングを通じて、必要な機能や性能、運用条件などを整理します。

基本設計では、要件定義の内容をもとに、画面や帳票、データ、外部システムとの連携方法などを具体化していくのが仕事です。

なお、上流工程は、特定の職種名ではありません。SE（システムエンジニア）やプロジェクトマネージャ、ITコンサルタントなど、複数の職種が関わる開発フェーズの呼称です。

企業やプロジェクトの体制によっては、プログラマーやインフラエンジニアが上流工程から参加する場合もあります。

上流工程と下流工程それぞれの位置づけ

上流工程と下流工程では、開発における役割が異なります。

上流工程では、業務上の課題を踏まえて「何を、なぜ作るのか」を明確にし、システムに必要な仕様を決定します。一方、下流工程は、上流工程で決めた仕様を詳細化したうえで実装し、想定どおりに動くかを検証する段階です。

なお、上流工程と下流工程に、優劣はありません。

どちらも開発を進めるうえで欠かせない役割を担っており、上流工程だけで技術や予算、納期を無視した仕様決定はできません。後工程で実現できる内容を把握し、実装やテストまで見通した設計が求められます。

詳細設計における上流・下流の位置づけ

詳細設計は、基本設計とプログラミングの間に位置する工程です。

基本設計で決めたシステムの外部的な仕様をもとに、プログラムの内部処理やデータ形式、モジュール構成、処理手順などを具体化します。そのため、上流工程と下流工程をつなぐ隣接工程として捉えるとよいでしょう。

ただし、詳細設計を上流工程に含めるか下流工程に含めるかは、企業やプロジェクトによって異なります。求人票に「上流工程を担当」と書かれていても、企画や要件定義ではなく、基本設計や詳細設計から参加するケースも考えられます。

仕事内容を確認する際は「上流工程」という表現だけで判断せず、担当工程や成果物、顧客との折衝範囲まで確認するのが大切です。

上流工程では何を決める？開発フェーズごとの仕事内容を解説

上流工程では、経営や業務が抱える抽象的な課題から、システム化の目的と対象範囲を定めます。そのうえで関係者が合意できる要件を整理し、後工程で設計・開発できる仕様へ具体化していきます。

なお、企画・要件定義・基本設計は、独立した作業ではありません。「なぜ作るのか」から「何を実現するのか」「どのような仕組みにするのか」へ、段階的に落とし込む一連の工程を指します。

システム企画の仕事内容

システム企画では、経営戦略や事業方針、現行業務の課題を踏まえ、ITを活用する目的を整理します。主な検討事項は、以下のとおりです。

● 対象とする業務
● システム化する範囲
● 期待する効果
● 必要な予算やスケジュールなど

検討した内容は、システム化構想やシステム化計画としてまとめます。

システム企画は、要件定義よりも前に「何のためにシステムを作るのか」を明確にする工程です。

システム企画の段階では、画面や機能といった個別の仕様を細かく決めるわけではありません。事業や業務の全体像を捉え、システム導入によって解決すべき課題と、目指す状態を定める視点が重視されます。

要件定義の仕事内容

要件定義では、利用者や業務部門から出された要求を整理し、システムに必要な条件へ具体化します。

「検索しやすくしてほしい」「作業時間を短縮したい」といった要望は、そのままでは設計や開発に使用できません。対象業務や利用場面、必要な処理などを確認し、関係者が共通認識を持てる要件へ変換します。

要件定義は、利用者の要望を聞き取るだけの工程ではありません。業務上の目的を示すビジネス要求と、システムで実現するためのシステム化要求の整理を行います。

さらに、利用部門やシステム部門などと認識をそろえ、合意を得るところまでが主な仕事内容です。

ビジネス要求を整理する

ビジネス要求の整理は、経営上のニーズや現行業務の課題から、システム導入によって達成したい目的とゴールを明確にします。

たとえば、受注処理に時間がかかっている場合、単に新しい入力画面を作るのではなく、処理時間の短縮や入力ミスの削減といった業務上の目標を定めます。

複数の課題や要望があるときは、事業への影響や緊急性、費用対効果などを踏まえて優先順位を付けることも必要です。システムの機能を先に検討すると、本来の目的から外れた仕様になりかねません。

まず、「業務をどのように変えたいのか」を明らかにし、システム化の判断基準を整えるのが大切です。

システム化要求を整理する

システム化要求の整理は、ビジネス要求を実現するために、システムへ求める条件を機能面と非機能面に分けて具体化します。

両方を整理すると、実現する処理だけでなく利用時の性能や安全性、安定した運用に必要な条件まで明確にできます。

なお、システム化要求の整理では、ユーザーの要望をそのまま仕様にするとは限りません。費用や納期、技術上の制約も確認し、システムで実現可能な要求へ整理します。

代替手段がある場合は、業務上の目的に照らして適切な方法を検討することも必要です。

ステークホルダーと要件を合意する

整理したビジネス要求とシステム化要求は、要件定義書などに文書化します。そのうえで利用部門やシステム部門、プロジェクト責任者などのステークホルダーと内容を確認し、認識の違いを解消します。

対象業務や優先順位、実現範囲を明記し、誰が読んでも同じ内容を理解できる状態に整える力が求められる工程です。

曖昧な要求を残したまま後工程へ進むと、設計変更や追加開発が発生しやすくなります。費用やスケジュールへの影響を抑えるためにも、疑問点や未決事項を洗い出し、関係者が要件として合意できる粒度まで具体化しましょう。

基本設計の仕事内容

基本設計では、要件定義で合意した内容をもとに、利用者や外部システムから見た仕様を具体化します。

代表的な設計対象は、画面構成や操作の流れ、帳票の形式、データベースの構成、外部システムとの連携方法などです。利用者がどのように操作し、システムがどの情報を扱うのかを明確にします。

基本設計は、業務上の要件をシステムの構造へ変換する工程です。要件を満たしているかを確認しながら、後続の詳細設計で内部処理やプログラム構成を検討できる粒度まで仕様を整理します。

設計内容に抜けや矛盾があると後工程へ影響するため、要件定義書との整合性を確認する作業も欠かせません。
 

上流工程で成果を出すエンジニアに求められる実務力

上流工程は、技術知識があるだけでは担当できません。顧客の業務課題を把握し、システムで実現すべき要件や仕様へ変換する力が必要です。

また、予算や納期、技術的な制約を考慮しながら、関係者の合意を得る役割も担います。

実現可能な開発計画へつなげるには、課題把握力・設計判断力・合意形成力・プロジェクト管理力を組み合わせて発揮する必要があります。

課題把握力

課題把握力とは、顧客の要望を聞くだけでなく、背景にある業務上の問題を明らかにする力です。

たとえば、「入力画面を使いやすくしたい」という要望があるとします。入力画面の使いづらさの原因が、画面構成にあるとは限りません。業務手順の重複や承認フロー、データの管理方法に問題が隠れている可能性も考えられます。

解決へ導くには、ヒアリングや業務観察を通じて現状のプロセスを整理し、顧客自身が認識していない課題まで把握する力が必要です。

また、適切な課題を見つけるためには、IT知識に加えて担当する業界や業務への理解も欠かせません。

業務の流れや専門用語、関連する制度などを学ぶことで、要望の背景を正確に捉えられます。その結果、表面的な改善にとどまらず、業務上の目的に合った要件を定義しやすくなります。

設計判断力

設計判断力とは、顧客や利用者の要求を踏まえ、適切な実現方法を選ぶ力です。

すべての要求をそのまま採用すると、システムが複雑になり開発費や保守負担が増える可能性があります。技術的な実現性やシステム全体の構造、性能、セキュリティ、運用方法を考慮し、目的に合った方式を判断しなければなりません。

複数の選択肢がある場合は、それぞれの利点と制約を比較して決定します。

上流工程の設計は、後工程で実装・テストできる内容である点が重要です。担当者によって解釈が分かれない粒度まで仕様を具体化し、既存機能や外部システムへの影響も確認します。

開発から運用までを見通して設計できると、手戻りや仕様変更の抑制につながります。

合意形成力

合意形成力とは、各部門の要求や制約を整理し、認識の違いを解消しながら意思決定へ導く力です。

上流工程では、立場や専門知識が異なる関係者が多数参加します。顧客や業務部門は使いやすさや業務改善を重視する一方、開発チームは実現性や工数を考慮するケースが一般的です。経営層からは、予算や納期に関する条件が示される場合もあるでしょう。

合意形成のためには、専門用語を並べるのではなく、相手の知識に合わせて説明する姿勢が求められます。

また、口頭で認識をそろえるだけでは、不十分です。決定した要件や検討中の課題、担当者、期限などを文書化し、関係者が確認できる状態にしなければなりません。

合意内容と判断の根拠を残し、後の認識違いや仕様変更を防ぎまましょう。

プロジェクト管理力

上流工程では、システムの仕様とともに開発を進めるための条件も整理します。

対象範囲や内容、目的を明確にし、工程や予算、品質基準、必要な人員を踏まえて実現可能な計画へ落とし込む管理力が必要です。想定されるリスクを洗い出し、発生する可能性や影響の大きさに応じて対応方法を決める力も重要です。

特にリーダーやプロジェクトマネージャを目指す場合は、仕様変更が費用や納期へ与える影響を把握し、顧客や開発チームと調整する力まで求められます。

問題が表面化してから対応するのではなく、遅延や認識差の兆候を早めに捉え、必要な対策を講じましょう。

下流経験を上流工程につなげるキャリアの進め方

上流工程を担当できるかどうかは、経験年数だけでは決まりません。プログラミングやテストで得た知識を生かし、実装できる仕様か、どのようなリスクがあるかを判断する力も求められるからです。

まずは、下流工程で基本から設計意図までをきちんと理解し、上流工程の補助業務に参加しながら担当範囲を広げましょう。

現在の職場で上流工程の補助業務に参加できない場合は、転職によって経験できる工程を変える選択肢もあります。

下流工程で設計意図まで理解する

プログラミングやテストでは、設計書に記載された内容を正確に実行するだけでなく、仕様が決まった理由まで確認する姿勢が大切です。

「なぜこの処理が必要なのか」「仕様を変更すると、実装やテストにどのような影響が出るのか」を考えると、システム全体への理解が深まります。不明点があれば設計担当者へ質問し、判断の根拠を把握しておきましょう。

実装の難易度やテスト範囲を理解しているエンジニアは、要件や設計の実現可能性を具体的に判断できます。現場で得た技術知識は、手戻りの少ない仕様を考え、後工程まで見通して設計するための土台になります。

上流工程の補助業務から経験する

上司の指導を受けながら、設計書の一部作成、レビューへの参加、議事録の作成など、上流工程の補助業務から取り組むのも、効率的な学び方です。特に顧客との打ち合わせへの同席は、要望をどのように聞き出し、要件へ整理するのかを実務を通して学べます。

担当領域は、現在の業務に近い範囲から広げると取り組みやすいです。たとえば実装経験のある機能の基本設計を担当し、次に関連する業務の要件整理へ進む方法があります。

上流工程に必要な知識を体系的に補いたい場合は、資格学習もおすすめです。
 
関連記事：システムエンジニアに資格はいらない？未経験こそ取るべき理由とおすすめ10選

上流工程を担当できる環境へ移る

現在の職場で上流工程に参加する機会が少ない場合は、担当業務を変えられる部署への異動や転職も選択肢の一つです。

ただし、求人票に「上流工程あり」と記載されているだけでは、実際の仕事内容を判断できません。企画や要件定義から参加するのか、基本設計以降を担当するのかを確認しましょう。

顧客との折衝の有無や、設計業務を担当する範囲も、重要な確認項目です。

しかし、転職自体を目的にすると、希望する経験を得られない可能性があります。要件定義、設計、マネジメントなど、自分が今後伸ばしたい領域を先に明確にするの大切です。

そのうえで配属予定の案件や教育体制、若手が上流工程へ参加した実績まで確認し、目指すキャリアにつながる職場を選びましょう。
 
関連記事：システムエンジニアとインフラエンジニアの違いを徹底解説！それぞれの適性も紹介

上流工程に関するよくある質問

上流工程の担当範囲や必要な経験は、企業やプロジェクトによって異なります。

そのため、「新人や未経験者でも参加できるのか」「詳細設計まで上流工程に含まれるのか」といった疑問を持つ人もいるでしょう。

ここでは、上流工程に関してよくある3つの疑問に回答します。

未経験でも上流工程を担当できますか？

実務未経験者でも、上流工程に関わる機会はあります。

具体的には、上司の指導を受けながら、顧客との打ち合わせへの同席、議事録の作成、要件の整理、設計書の修正などを担当するケースです。

補助業務や一部の機能から経験を積めば、企画・要件定義・基本設計の進め方を実務のなかで学べます。

ただし、要件定義や設計を最初から単独で担当するには、システム開発の知識だけでなく対象の業界や業務への理解も必要です。顧客の要望を整理し、実現性や費用、納期を踏まえて判断する力も求められます。

まずは、上司の指導を受けられる環境で経験を重ね、段階的に担当範囲を広げる進め方が現実的です。

上流工程はどこまでの対応内容が含まれますか？

システムの上流工程には、システム企画、要件定義、基本設計（合意形成も含む）が含まれます。「何を作るか」を決める工程であり、この後の詳細設計・製造・テストといった「どう作るか」を実装する下流工程に繋がります。

ただし、上流工程と下流工程を分ける基準は、企業やプロジェクトによって異なります。「上流工程を担当」という表現だけで判断せず、要件定義・基本設計・詳細設計のうち、実際にどこからどこまで担当するのかを確認すると安心です。

上流工程と下流工程を経験するとキャリアアップ繋がりますか？

上流工程と下流工程、両方の経験は必須ではありません。ただし、両方の視点を持つと、開発工程全体を理解しやすくなり、結果として、キャリアップに繋がることがあります。

下流工程の経験があれば、上流工程で決めた仕様を実装できるか、変更によってテスト範囲や工数がどの程度増えるかを判断しやすくなるでしょう。

一方、上流工程を経験すると、個別の機能だけでなく、業務課題や要件、システム全体の構造を俯瞰する力が身につきます。

上流と下流の経験は対立するものではなく、互いの判断を支える関係にあります。プログラミングやテストで培った知識を設計判断へ結び付けられることが、両工程を経験する大きなメリットです。

下流工程の実装経験があるからこそ実現性の高い設計ができ、その積み重ねが上流工程を担うキャリア形成にもつながります。
 
関連記事：プログラマー（PG）の仕事内容とは？システムエンジニア(SE)との違いも紹介！

まずは現在の業務から担当範囲を広げていこう

上流工程とは、経営・業務上の課題を整理し、システム化の目的や要件、基本的な仕様を決める開発の前半工程です。企画・要件定義・基本設計を通じて「何を、なぜ作るのか」を明確にし、後工程で実装できる形へ具体化します。

上流工程で成果を出すには、技術知識に加えて、課題把握力や設計判断力、合意形成力、プロジェクト管理力が必要です。プログラミングやテストで培った知識も、実現可能な仕様を判断する土台になります。

まずは、現在の業務で設計意図まで理解し、補助業務から担当範囲を広げていきましょう。

ワールドインテックのITS事業部は、チーム配属を軸にアプリケーション開発からインフラ・セキュリティまで幅広い技術支援を行う企業です。

関係会社と連携し、企画・要件定義から開発・テストまで一括して支援した実績もあります。研修や実務経験を通じてITエンジニアとして成長したい人は、事業内容や採用情報を確認してみてください。
 
ワールドインテックのITS事業部（ITソリューションズ＆サービス事業）