ページイベントカウント(初期表示)

上流工程の仕事内容とやりがい

IT上流工程とは?仕事内容は?

更新日:

上流工程の仕事内容

ITの上流工程とは何か、そしてどのような仕事内容か気になりませんか?

私が下請けPGから上流工程を目指した頃、具体的な仕事内容をイメージするのに苦労しました。

上流工程SE、ITコンサルタント、社内SEと体験してきた内容をもとに、具体的にお伝えしていきます。

上流工程とは

上流工程とは、システム導入の最初に行われる要件決めや、概要のシステム設計などを指します。

システム導入・開発では最初に「システムで何がしたいか」を決めます。これを要求や機能要件などと呼びます。
 
しかし要求を決めるのは簡単ではありません。たとえばスマホ、新しい端末が発売され使ってみたところ、「地図アプリが見にくい」「メールソフトの使い勝手が悪い」などの不満が出たとします。

この不満を受け改良を加えようとしても、「見にくい」「使い勝手が悪い」だけではどのように開発すべきか分かりません。

「地図のズームの拡大率が十分ではなく、路地裏の細かい道路が表示されない」「メール件名が途中で切れて表示されるため、一覧性がない」くらいまで細かく不満を伝えてくれれば分かりますが、すべての利用者がこのように表現してくれるわけではありません。

上流工程の仕事の一つは、「見にくい」から、「路地裏の細かい道路が表示されるようにしてほしい」という要求を引き出すことです。ユーザの思いを推測しながら、コミュニケーションを重ねて明確にする必要があります。

また、「路地裏の細かい道路」を表示するためには、どこまで拡大率を挙げられればいいか、などの設計も行います。

それらを経て、初めてプログラマーに仕事が渡り、プログラミング・テストなどが実施されます。

川が上流(山の水源から始まる川の流れの最初)から下流(海につながる川の流れ)にうつり、最後に海につながるように、上流工程で「システムで何をしたいのか」を決め、下流工程でプログラミング・テスト等を行って、海につながる(システムをリリースする)という考え方です。

もし上流で水が止まったら、あるいは流れが悪くなったらどうなるでしょうか。下流でどれだけ頑張ろうとしても、そもそも水がこなければ下流は何もできません。流れが悪ければ下流に来る水も減り、海に流せなくなります。

上流工程でシステム導入の成功・失敗は決まります。では上流工程にはどのようなフェーズ(段階)があるのでしょうか。

上流工程の仕事内容は

上流工程ではどのような仕事をしているでしょうか。

システム導入のフェーズ(段階)ごとに仕事内容を説明していきます。

IT戦略立案

まず最初は、企業全体の中長期のIT戦略立案から始まります。

数年後の会社の売上目標・組織目標などをもとに、目標達成を支援するためにどのようなシステム構成が必要か、新規システム導入をどのくらいのスケジュール・予算で行うか、など戦略を立案します。

このフェーズは通常の上流工程とは分けて、「超上流工程」などと呼ばれることもあります。

業務プロセス設計

IT戦略立案の後、システム導入に入る前に業務プロセス設計を行います。

業務プロセス(手順)設計とは、業務の流れ・手順を洗い出し、今後こうすべきという理想の業務を決める作業です。

理想の業務に向けて、どのようなシステムを導入すべきかを後のフェーズで確立していきます。

システム選定(ベンダ選定)

システム選定(ベンダ選定)では、システムを導入するための選定作業を行います。

この選定とは、システムの種類(パッケージソフトウェア・一から自社開発など)、導入担当会社(SIerなどのシステム会社に依頼・自社開発者で対応など)を比較検討し、決めていく作業を指します。

業務プロセス設計で決めた理想の業務に合う、優れたシステムを選ぶために、複数のITシステム会社(ベンダ)に声をかけて提案してもらうことが一般的です。

ここで誤った選定をすると、詐欺まがいのシステム会社にあった、理想の業務にまったく合わないシステムを作ってしまった、ということになりかねないため、非常に重要な工程です。

ちなみにIT戦略立案同様、さきほどの業務プロセス設計、そしてシステム選定(ベンダ選定)まで含めて「超上流工程」と呼ぶこともあります。

私の経験上ですが、ここまでのフェーズでシステム導入成否はほぼ決まります。業務プロセスを適切に設計でき、優れたシステム会社(ベンダ)を選ぶことができれば、あとは問題なく導入が進むことがほとんどです。

失敗するプロジェクトは、ほぼ例外なく、業務を適切に決められていない(要求が膨らんで必要機能が多すぎるなど)、経験の薄いSEや品質意識の低いPGが担当に付いた、などが原因です。

要件定義

システム選定まで決まると、具体的な導入が始まります。

まず最初は「システムで何がしたいか」(要件)を決める要件定義です。業務プロセス設計で決めた理想の業務が、選定したシステム(パッケージなど)で実現可能かを詰めていく「Fit&Gap」(実現可能なフィットと、やりたい業務を満たせないギャップ)という手法と、業務を満たす機能を一から確認していく手法があります。

ここで要件を具体的に決めておかないと、「地図アプリが見にくい」という曖昧な話のまま進んでしまい、後になって認識齟齬が出て仕様変更、ということになります。

基本設計

要件定義が決まると、要求を具体的にシステム機能に落とし込む基本設計が始まります。

プログラマーの方であれば、「設計書」を作るフェーズといえば分かりやすいかもしれません。ただしPGが担当する詳細設計と違い、基本設計ではユーザも理解可能な表現で設計書が作られます。

基本設計では、例えば「地図アプリの拡大率は最大○○%」、「画面のボタンとテキストボックスの配置は○○とする」、「ボタンを押したら交通費一覧を表示」など、目に見える、あるいはユーザ業務に影響するシステム動作などを決めていきます。

ちなみに詳細設計は、ユーザが理解できない(ユーザが意識しない)、主にプログラミング内容を文章等で記述します。

一般的に、この基本設計までを上流工程と呼びます。

下流工程(詳細設計以降)

基本設計の後は下流工程と呼ばれるフェーズになり、以下のような工程で構成されます。

詳細設計→コーディング→テスト→ユーザ教育・データ移行→(本番稼働後の)運用保守

詳細設計ではJava等のプログラム内容を、日本語の文章で記述します。その内容を受け、コーディング(プログラミング)を行います。

作ったプログラムに問題がないかテストを行い、問題なければシステムの操作教育に移ります。利用中のシステムからデータを移す作業を行い、本稼働を迎えます(工程の順序や時間は前後することがあります)。

本稼働後は、運用保守で問合せ対応や不具合修正、新しい機能の開発(二次開発)などを行います。

ITの上流工程の特徴

ITの上流工程の特徴は、システムに直接手を触れていないということです。

下流工程のプログラマーであれば、プログラミングをして機能を作り、システムの動作を形作っていきます。

しかし上流工程のシステムエンジニアは、ユーザとコミュニケーションをとりながら要件を決める(要件定義)、画面の動作をドキュメントにまとめる(基本設計)、などシステムには直接手を加えていません。

上流工程のSEには、プログラミング経験のない人が多くいます。システムに直接関わっていなくとも仕事ができるということです。技術の理解も重要ですが、要件定義等をこなすにはコミュニケーション力や業務知識、システム全体を俯瞰する視野のほうが求められるためです。

もちろんプログラミング経験もあり、上流工程SEの能力もあるのが望ましいです。技術も業務も理解し、ユーザとコミュニケーションも取れるSEは、プロジェクトに引っ張りだこです。

上流工程ならではの特徴を意識しながら転職活動すると、企業にも評価されやすくなりキャリアプラン実現に近づけます。

ページイベントカウント(本文読了)

おすすめ記事紹介(転職体験談)

ページイベントカウント(全読了)

-上流工程の仕事内容とやりがい

Copyright© 上流工程専門 , 2020 All Rights Reserved.