ITの上流工程とは？システム開発の要である上流工程を徹底解説！

悩める人

・システム開発の上流工程って具体的にどういうことをやるの？
・ITの仕事では、上流工程と下流工程のどちらがキャリアアップに役立つ？

この記事はこういった人のために書きました。

ヤマダといいます。

IT業界での長年のキャリアと、過去の転職経験、現役の採用面接官として信頼性の高い情報を発信しています。

この記事でお伝えしたいこと

この記事では、システム開発における上流工程の内容と、それに携わる職種と仕事の進め方についてお話します。

結論から言うと、上流工程は顧客のビジネス上の課題を解決するシステムの在り方と仕様を決める仕事であり、上流工程の経験はエンジニアのキャリア形成に非常に重要です。
上流工程を円滑に進めるためには「システムの実装イメージ」を語れることが大事で、実は下流工程をリードできる人材はとても重宝されます。

ヤマダ

現在、上流工程に興味がある方、エンジニアとしてキャリアアップを考えている方はぜひ最後まで読んでみてください。

システム開発の上流工程とは？ざっくり言うと

システム開発における上流工程とは、ざっくりいうと、システム開発の初期段階において、顧客のビジネス上の課題を解決するシステムの在り方と仕様を定義・設計する工程です。

いわゆる「ウォーターフォール型開発」では、開発工程は「上流工程」と「下流工程」に分けられ、一般的には概ね下記のように分類されます。

※上記は一般論で、必ずしも表の通りになるとは限りません。

上記は「要件定義→設計→製造→テスト」の順に開発が流れる「ウォーターフォール型開発」を例に挙げましたが、アジャイル開発でもプロトタイプ開発でも、顧客の要求を設計に落とし込む上流工程のフェーズは存在します。

開発するシステムの目的、解決すべき課題と、そのために必要となる要件を顧客へヒアリングして取りまとめ、実装する機能や非機能を定義し設計していく重要な作業になります。

理由は後述しますが、IT業界、特にSI（システム・インテグレーション）業界においては、エンジニアのキャリアアップのためには「上流工程」の経験が必要です。

上流工程の重要性

なぜ上流工程が重要で、その経験がキャリアアップのために必要なのでしょうか。

もう少し「ウォーターフォール型開発」におけるシステム開発の流れ踏まえて詳しくお話します。

システム開発の流れ

現在SI業界で主に採用されているウォーターフォール型開発では、おおよそ下記のように開発工程が進んでいきます。

※上記は一般論で、必ずしも表の通りになるとは限りません。

ウォーターフォール型開発は、それぞれの工程をきちんと終わらせ、工程単位で品質を確認しながら進めていきます。

もちろん、課題や問題が発生して次の工程に申し送りになることもありますが、それは長期的な課題としてきちんと管理して開発に影響が出ないように進めていきます。

従って、ひとつの工程でミスがすり抜けて次の工程に進むと、設計や製造の「手戻り」が発生し、品質やスケジュールに大きな影響を与えることになります。

システム開発工程としての重要性

上流工程は、システムの機能や構成をデザインし、システムの性能や可用性といったシステム全体における重要な取決めを行っていく工程です。

従って、上流工程で抜け漏れやミスが発生すると、以降の工程全てに影響が出てしまいます。

下流工程に進んでからも設計の追加、修正、プログラミングのやり直しなどの手戻りが発生しやすくなります。

このように、上流工程はシステム開発プロジェクトの要であり、システムの品質を左右する重要な役割があります。

上流工程でのミスが、下流工程で大きなトラブルを引き起こす原因になる可能性もある、非常に重要な工程であるということです。

キャリアとしての重要性

上流工程は、プログラミングスキルや、インフラの知識など純粋なITスキルも大事ですが、基本的には顧客との会話やヒアリングなど、コミュニケーションやプレゼンテーションを中心に作業が進んでいきます。

また、成果物をアウトプットするためには、設計やプログラミングの経験だけでなく、現状分析や課題解決能力が求められます。

従って、上流工程を担当するエンジニアに必要なスキルは、下記のようなソフトスキルが必要となり、これらの多くは上流工程の経験を通じてスキルアップしていきます。

そして、SI業界におけるキャリアアップとは、一般的には下記のように、上流工程やマネジメント職への転向を指します。

元請けSIer・ITコンサル企業の社員は、基本的に上流工程を担当しますので、成果を出すためには上流工程の経験を積むことが必要です。

また、元請けSIerは比較的大企業が多く、そうした企業は扱う案件規模も大きくなり、複数の開発会社を束ねる役割を担います。

自ら手を動かすよりも、チームリーダーやプロジェクトマネージャーとしてリーダーシップを発揮し、マネジメントを行うことが求められます。

ITコンサル企業でも、上流工程で現状分析やコンサルテーションに携わるだけでなく、マネジメントを行うこともありますし、開発会社と顧客との橋渡し役を任せられることがあります。

このようなマネジメント業務を円滑に行うためには、コミュニケーションやマネジメントなどのソフトスキルが必要となります。

企業を問わず、出世してマネージャー職を目指すならなおさらです。

SIerやITコンサルではもちろん、SES企業でもマネージャーや経営層になるためには、顧客や取引先と対等に交渉ができるようになる必要があります。

つまり、上流工程の経験を積むことで、上流工程そのもののスキルだけでなく、キャリアアップに必要なスキルも鍛えられ、転職活動のアピールポイントになったり、社内での出世コースにつながっていくということです。

上流工程での仕事内容

上流工程における工程ごとの仕事内容について詳しくお話していきます。

システム化企画

はじめにお伝えしておくと、システム化企画とはシステムの開発工程ではありません。

システム化企画は、システムのユーザー企業（顧客）が主体的に行うフェーズで、主に下記を目的としています。

システム化構想の立案

システム化構想とは、経営のニーズ・課題を解決するための新たな業務の全体像と、実現に向けたシステム構想を立案することを指しており、ビジネスの「要件定義」とも呼ばれます。

経営層や業務部門が主体となり、会社のビジネスや業務そのものの在り方を見直し、そこから具体化されるニーズや課題を解決するための情報システムをどのようなものにするべきか、情報システム部門と構想を練ります。（情報システム部門が主体となる場合もあります）

具体的には、下記について定義していきます。

システム化計画の立案

立案したシステム化構想を実現するために、下記の通り、システム開発から運用までを見据えたスケジュール・開発体制などの具体的な計画をシステム化計画書という形でアウトプットし、業務部門や経営層などのステークホルダの合意を得る必要があります。

ITベンダの関わり方

システム化企画は、基本的には、ユーザー企業（顧客）の業務部門や情報システム部門が主体的に行いますが、SIerやITコンサル企業が下記のような形で関わることがあります。

ユーザー企業は、システム構想を練る際に、ITでどのような製品やソリューションがあるのか、費用感はどのくらいなのかを確認する際に、RFI（情報提供依頼書）を作成し、ITベンダからIT技術動向に関する情報を得ることがあります。

また、大規模開発となることが見込まれる場合、システム化企画そのものの作業を、SIerやITコンサル企業に委託する場合もあります。

受託側は、ユーザー企業（顧客）の業務部門や情報システム部門と協働し、自社ノウハウを活用してシステム化企画をリードし、システム化構想とシステム化計画を「システム化構想書」や「システム化計画書」といった形でアウトプットすることになります。

要件定義

次に要件定義についてお話します。

要件定義とは、顧客のビジネス上の課題を解決するITシステムに求められる「要件」を定めていく工程ですが、下記の分類と作業の順序性があります。

よく、要求定義と要件定義は混同されることがありますが、下記のような明確な違いがあります。

このように、要求定義とは、ビジネス目標を達成するために、業務がどうあるべきかを定め、要件定義は、業務を滞りなく遂行するためのシステムがどうあるべきかを定めることを指します。

ひとつずつ具体的にお話していきます。

要求定義（ビジネス要求定義）

要求定義は、IPAでは「ビジネス要求定義」とも呼ばれています。

システム化企画で定めたシステム化構想とシステム化計画をインプットに、具体的な業務への要求を洗い出し、在るべき業務の姿と、そのための課題や問題点を明確化するフェーズです。

具体的な作業内容は下記の通りです。

業務の現状分析（As-Is分析）

インプットとなる「システム化構想」「システム化計画」でシステム化の目的や背景を確認した上で、まずは業務の現状分析（As-Is分析）を行います。

現状分析では、ユーザー企業の業務部門に、現在の業務の流れと、業務に関わる部門や担当者などをヒアリングし、業務フローを可視化します。

もし、現行業務を理解・把握できるドキュメントがない、もしくは最新化されていないような場合は、現行で実際に稼働しているシステムから手がかりを得ることもできます。

現行システムの保守部隊などへヒアリングし、データモデルや、アプリケーションの処理ロジック、運用スケジュールなどから逆追いで可視化するといった方法があります。

課題の抽出と優先順位付け

合わせて現行業務の課題・問題点や改善要求などのヒアリングを行い、課題抽出を行います。

課題は様々で、解決の難易度が低いものから高いもの、費用がかかるものとかからないものがありますが、そういった評価軸を作って優先順位付けを行い、合意を取っていきます。

あるべき業務の定義（To-Be定義）

そして、現行の業務フロー（As-Isモデル）と現行業務の課題や改善点から、それらを解決可能な在るべき業務フローの明確化（To-Beモデル、To-Be業務フロー）を行っていく、といった流れで作業が進んでいきます。

このように、要求定義では、業務の在るべき姿＝組織が達成するべきゴールを定義し、そのための優先課題を顧客と合意することが作業目標になるということです。

要件定義（システム化要求定義）

要件定義は、IPAでは「システム化要求定義」とも呼ばれており、要求定義で定義した要求を下記の3つの観点で、システムの「仕様」として定義することです。

※非機能要件から「運用要件」「移行要件」を切り出して別工程として作業を行う場合もあります。

機能要件定義

機能要件定義は、要求定義（ビジネス要求定義）で文書化した「業務の在るべき姿」をシステムの機能面で仕様化する作業です。

具体的には、システム化する業務の範囲（スコープ）を定め、システムの画面や機能、データ構造、他のシステムとのインターフェースなどを定めていきます。

下記は簡単なイメージです。

＜画像を拡大＞

機能要件定義は、導入するシステムが機能面・技術面で実現可能かどうか、利用面で問題なく利用可能かどうかを確認することが目的となります。

機能要件定義で作成するアウトプット（一例）は下記の通りです。

アーキテクチャ検討

システムのアーキテクチャは、基本設計工程で検討を行うと書かれている記事や書籍が多いですが、私は要件定義工程の中で実施することが良いと考えています。

理由は下記の通りです。

アーキテクチャ検討では、システムに求められる機能やピーク時の処理量などから、画面などのUIや、機能、データをシステム構成要素（サーバー、ディスク装置など）へ配置（配置設計）し、相互に連携して動作させる処理方式を立案し、要求通りに動作可能なシステム構成を作り上げていきます。

＜画像を拡大＞

この段階では、物理的・論理的なサーバやネットワーク機器の構成や台数などは意識せず、業務で必要な画面と機能、データのみに焦点を当て、業務処理が実現可能なアーキテクチャ、システム構成を検討します。

非機能要件定義で作成するアウトプット（一例）は下記の通りです。

非機能要件定義

非機能要件定義は、要求定義（ビジネス要求定義）で文書化した「業務の在るべき姿」をシステムの機能面以外で仕様化する作業です。

機能面以外の全てがスコープとなるため、範囲が非常に広く、それゆえに正しく定義されないままシステム開発に進んでしまうことが多いです。

そして、非機能要件が曖昧なことが原因で、後々大きなトラブルに発展するケースが多いです。

それでは、非機能とは何か？については、下記の通りです。

※本記事では、非機能要件についてはIPAが定義している「非機能要求グレード2018」を参考としています。

これらの項目に対する要求度合いを「非機能要求グレード表」という資料をベースにヒアリングを行い、合意を取ることが作業の目的となります。

非機能要件を定義すると、どの程度の処理性能が見込まれるのでサーバーが何台必要だとか、サーバーやネットワークなどの多重化（冗長化）のレベルはどのくらいか、セキュリティを確保する設備、運用保守に必要な設備は何かなど、システム構成に影響する部分が明確になるため、システムの構成全体を定めるために非常に重要な作業となります。

＜画像を拡大＞

上記の例では、アーキテクチャ検討時点では考慮されていなかったサーバの台数や、業務処理以外で必要となるセキュリティ関連（アンチウイルス）や、監視サーバなどを導入した例としています。

この時点で、導入するべきハードウエア（もしくはクラウドサービス）、ソフトウェア、サーバー・ネットワーク機器の台数などが仮FIXとなります。

完全なFIXに向けては基本設計工程で詰めることになりますが、この時点で物品の見積りや概算費用の算出が可能な状態となります。

なお、非機能要件定義を曖昧にしてしまうと、いざサービスを開始したときに下記のような取り返しのつかない問題・トラブルが発生するリスクがあります。

金融や行政など重要な社会インフラとなっているシステムでこういうトラブルが起きると、新聞やニュースを騒がせてしまうことになり、企業や行政の信頼を揺るがす大問題に発展する恐れがあります。

非機能要件定義で作成するアウトプット（一例）は下記の通りです。

基本設計（外部設計）

上流工程としては最後の工程「基本設計（外部設計）」についてお話します。

基本設計とは、要件定義書に従って、システムのアウトラインを設計する工程です。

設計するアプリケーションやインフラストラクチャーなどが外部から見たときにどのように動作するのかを設計書にまとめる作業を行います。

また、設計するにあたって顧客にヒアリングする事項や、課題などを一覧化して顧客とコミュニケーションを取りながら進めていく必要があります。

設計内容は企業やプロジェクトによって差が出てくるとは思いますが、基本設計工程では概ね下記の設計を行います。

ひとつずつ具体的にお話していきます。

アプリケーション設計

機能要件定義で定義した業務を実現するために必要なアプリケーションの機能・処理、画面、帳票、データ構造などについて、正常時、異常時、例外時を含めた実現方法を設計します。

また、アプリケーションが動作する土台となるアプリケーション基盤（フレームワーク）の、入出力、処理内容、設定内容、利用規約などの設計も行います。

情報システムを構築する目的は「業務」の実現ですので、システムの要となる業務アプリケーションの設計は、システム開発の主役であり、最も重要な工程となります。

アプリケーション設計で作成するアウトプット（一例）は下記の通りです。

※アウトプットはあくまで一例です。

システムアーキテクチャ・インフラ設計

要件定義工程で定めた機能要件、非機能要件、アーキテクチャ検討書をもとに、アプリケーションとシステム基盤（インフラ）の全体構成と、実現可能なシステムアーキテクチャを設計します。

システムアーキテクチャとは、機能要件、非機能要件それぞれについて、実現するための処理の仕組みと製品の構成のことで、下記のようなものがあります。

このように、システムアーキテクチャとは、業務処理を実現するアプリケーションのアーキテクチャだけでなく、可用性やセキュリティ、運用保守要件などの非機能要件を実現するためのアーキテクチャも含まれており、システム構成を最終的にFIXするために重要な役割を持ちます。

システムアーキテクチャ設計で作成するアウトプット（一例）は下記の通りです。

※アウトプットはあくまで一例です。

システム運用設計

システム運用設計とは、システム開発が終わり、サービスがリリースされた後に、問題なくシステムの運用保守を行っていくためのアウトラインを設計することです。

運用設計は、大きく下記2点に分類され、それぞれ設計を行います。

業務運用設計とは、システムで実現する業務において必要な運用作業を設計することで、例えばマスタデータ（部署情報など）のメンテナンスなどが該当します。

システム運用設計とは、名前の通りシステムを稼働し続けるために必要な運用作業を設計することを指し、例えばアラート監視後の挙動や、バックアップとリカバリ作業、定期的なユーザー管理作業などが該当します。

基本設計工程では、運用保守に必要な作業と、作業を行うためのソフトウェアやツール類、作業者などを洗い出し、一覧化していく作業を行います。

システム運用設計で作成するアウトプット（一例）は下記の通りです。

※アウトプットはあくまで一例です。

上流工程に必要なスキル

ここまでは上流工程の作業内容についてお話してきました。

上流工程の作業を行っていくにあたり、どのようなスキルが必要なのかについてお話します。

業務知識

上流工程を円滑に進めるために必要なのが、業務知識です。

システムを利用するユーザー企業（顧客）は、それぞれ事業を行う事業会社だったり、行政機能を持つ公共団体がほとんどだと思います。

システムで実現する業務は、それぞれの事業・行政機能に基づいた業務となりますので、顧客の業務に精通することで、業務の要件を詰める際にも細かなニュアンスも含め認識ずれなどをなくし、スムーズに要件定義を進めることができるようになります。

分析スキル

上流工程、特にシステム化企画やビジネス要求定義といった「超上流」と言われる工程において、分析スキルは必須となります。

経営のニーズを分析し、業務の改善に落とし込んだり、現状の業務をヒアリングや資料を通じて分析（As-Is分析）と在るべき姿（To-Be定義）の導出を行うなど、コミュニケーションやデータ・資料を読み込み、解釈し、業務改善を実現可能なシステムを導き出す力が求められます。

コミュニケーションスキル

ここまで読み進めて頂いた方はもうお分かりだと思いますが、上流工程とは、ITベンダ独自で進められるものではありません。

上流工程とは、システムのユーザー企業（顧客）との共同作業です。

顧客の情報システム部門、業務部門、場合によっては経営層へのヒアリング、コミュニケーションを密に行い、問題や課題も共有しながら一体となって解決策を導き出していくという作業を行います。

コミュニケーションは下記のような作業・ツールを駆使して行う必要があり、それぞれのスキルを伸ばしていくことが重要です。

アーキテクチャ設計スキル

アーキテクチャ設計スキルとは、その範囲が非常に幅広いですが、ざっくりまとめると下記の通りとなります。

※IPA「システムアーキテクト試験」の内容より抜粋・要約

このように、誰でもいきなりアーキテクチャ設計ができるようになるわけではなく、アプリケーションやインフラの経験や知識を根底に持ち、多くのシステム設計に触れ、業務をITに置き換える際のベストプラクティスのノウハウを多く蓄積する必要があるということです。

マネジメントスキル

上流工程は、一人でこなせるものではありません。

チームを作り、場合によっては外部のハードウェア、ソフトウェアベンダなどの力を借りながら進めるものです。

そのために、進捗管理、課題管理、要員計画などのマネジメントスキルや、チームをまとめあげるリーダーシップといったものが必要になります。

上流工程に携わる職種と年収

上流工程に携わるエンジニアの職種と、その平均的な年収についてお話します。

プリセールス、ITコンサル、ITアーキテクトなどは高度なコミュニケーションスキルや技術と経験を求められる職種で、年収は高めになります。

それぞれのエンジニアの仕事についてまとめた記事です。こちらもよかったらぜひ読んでみてください。

ITコンサルタント

ITコンサルタントは、上流工程の中でも、システム化企画や要件定義といった「超上流」で活躍する職種です。

顧客の業務内容をよく理解し、その上で業務上非効率となっているプロセスや手順がないか、その原因は何かを分析し、ITを導入して解決するための提案を行います。

アクセンチュアやデロイトトーマツコンサルティング、アビームコンサルティングなど、外資系コンサルティングファームが有名です。

• 年収の目安

プリセールス

プリセールスは、上流工程の中でもシステム化企画や、ビジネス要求定義などのフェーズで、これからITベンダを選定するようなタイミングで活躍します。

ソフトウェア製品やハードウェア製品を販売・導入する際に、営業に同行し、その製品の専門的・技術的な知識をもって営業をサポートしする職種です。

一般的に、営業が顧客の窓口となり、プリセールスは製品築の技術面に関わる専門的な説明や、顧客とのQ&Aを行います。

技術面の専門的な説明を行いますが、ITの知識が少ない顧客のために簡素でわかりやすい説明やプレゼンを行う必要があり、技術力とプレゼンテーション能力、コミュニケーション能力を兼ね備えたハイブリッドなスキルを持った職種です。

• 年収の目安

アプリケーションンジニア・インフラエンジニア

アプリケーションエンジニア、インフラエンジニアは、顧客とコミュニケーションを取りながら、どういったシステムを開発するのかをヒアリングし、システムの仕様を取り決める、要件定義から基本設計まで幅広く活躍する職種です。

それぞれ、アプリケーション分野と、インフラ分野（サーバー、ネットワーク、データベースなど）を担当し、それぞれの専門性を活かして仕様を取り決めていきます。

• 年収の目安

平均年収を見ると平均的な年収となっていますが、上流工程を任されるエンジニアは、経験を積みそれなりに評価の高いエンジニアであることが想定されますので、上記の年収より高い年収を受け取っていると見てよいでしょう。

ITアーキテクト

ITアーキテクトは、上流工程において、要件定義や基本設計工程で、システムアーキテクチャの検討・設計を行います。

システムアーキテクチャ設計とは、業務アプリケーションがその機能や性能を満たすために、複数ある処理方式から最も適切な処理方式を選択し、そのシステムに合った形にデザインすることです。

システムが大規模になればなるほど、システム全体を俯瞰してバランスをとるためにITアーキテクトの存在が重要になります。

• 年収の目安

上流工程に携わるために必要なこと

これまで、上流工程の仕事内容や、必要なスキル、職種についてお話してきました。

最後に、上流工程に携わるためにどのような経験を積み、どう行動することが近道なのかについてお話します。

こちらもひとつずつお話します。

下流工程の経験

下流工程とは、詳細設計やプログラミング、テストといった工程を指します。

ぶっちゃけると、上流工程に携わるには必ずしも下流工程の経験は必要ではありません。

SIerやITコンサル企業には、下流工程の経験がないエンジニアが上流工程をいくつもこなしている例があったりします。

しかし、下流工程の経験があると、よりシステムの実装イメージが明確になり、顧客に対してリアルなイメージをもって、地に足の着いた提案ができるようになります。

上流工程における顧客への提案や説明の場では、顧客側の担当者が実装イメージを掴めずに困惑する場面がよくあります。

そういった場面では、こういったシステムの実装イメージを話せるエンジニアは大変重宝されます。

顧客とのコミュニケーション経験

エンジニアにとって、顧客とのコミュニケーションとは、つまりプレゼンテーションとQ&Aです。

技術を語るには専門用語を使うことが最も近道ではありますが、顧客へ説明する場面においては、ITの専門用語は「原則使用禁止」であると心得ましょう。

顧客の担当者の中には、システムやコンピューターの技術を「ツール」としか見ておらず、技術に対して興味がない方も多いです。

そういった方とコミュニケーションを成立させるには、易しい言葉に置き換えて話をする癖をつける必要があります。

また、上流工程は技術の話よりも、業務の現状がどうなっているか、将来はどうなるべきかといった「業務」に主眼が置かれます。

業務の知識を持ち、技術を易しい言葉で語れるエンジニアは、上流工程においても顧客に信頼され、活躍できるようになるでしょう。

資格取得

これまで下流工程をメインに担当していたエンジニアが上流工程に携わるためには、資格取得は有効な手段のひとつです。

「資格なんて意味ない。実践が大事だ」というエンジニアも多いですが、情報処理試験などは非常にエンジニアが上流工程を進めるために必要な知識・エッセンスが凝縮されています。

上流工程で本来行うべき作業や必要な考え方を体系的に学ぶことができ、それを対外的にアピールするには非常に効率の良い方法であると言えます。

下記のような高度な資格を持っていると、上流工程に携わるチャンス、可能性がぐっと増えます。

どの試験も合格率が10%前後の難関ですが、ぜひチャレンジしてみることをおすすめします。

転職活動

下流工程をバリバリ経験してきたエンジニアの方であれば、ITコンサル企業やSIerなど、上流工程をメインに行う企業へ転職するのも有効な手段です。

ITコンサルもSIerも、下流工程をリードでき、コミュニケーションスキルもあるエンジニアは非常に貴重な存在で、喉から手が出るほど欲しい人材なのです。

上述した通り、顧客とのコミュニケーションの場面においては「実装イメージ」を易しい言葉で語ることが非常に大事です。

あなたにそういった経験があるのであれば、転職活動はキャリアアップのために非常に有効と言えますので、転職エージェントなどに一度相談してみると今後のキャリア形成を考える良いきっかけになるかもしれません。

もし転職エージェントをじっくり選びたい場合は、こういった記事も書いていますのでぜひ読んでみてください。

まとめ

システム開発における上流工程の内容と、それに携わる職種と仕事の進め方についてお話しましたが、いかがでしたでしょうか。

最後にまとめです。

この記事を読んで、上流工程に興味がある方や、今後のキャリア形成に悩んでいる方の助けになったらうれしいです。