ITの上流工程とは何か、そしてどのような仕事内容か気になりませんか?
私が下請けPGから上流工程を目指した頃、具体的な仕事内容をイメージするのに苦労しました。
上流工程SE、ITコンサルタント、社内SEと体験してきた内容をもとに、具体的にお伝えしていきます。
目次
上流工程とは
上流工程とは、システム導入の最初に行われる要件決めや、概要のシステム設計などを指します。
システム導入・開発では最初に「システムで何がしたいか」を決めます。これを要求や機能要件などと呼びます。
しかし要求を決めるのは簡単ではありません。たとえばスマホ、新しい端末が発売され使ってみたところ、「地図アプリが見にくい」「メールソフトの使い勝手が悪い」などの不満が出たとします。
この不満を受け改良を加えようとしても、「見にくい」「使い勝手が悪い」だけではどのように開発すべきか分かりません。
「地図のズームの拡大率が十分ではなく、路地裏の細かい道路が表示されない」「メール件名が途中で切れて表示されるため、一覧性がない」くらいまで細かく不満を伝えてくれれば分かりますが、すべての利用者がこのように表現してくれるわけではありません。
上流工程の仕事の一つは、「見にくい」から、「路地裏の細かい道路が表示されるようにしてほしい」という要求を引き出すことです。ユーザの思いを推測しながら、コミュニケーションを重ねて明確にする必要があります。
また、「路地裏の細かい道路」を表示するためには、どこまで拡大率を挙げられればいいか、などの設計も行います。
それらを経て、初めてプログラマーに仕事が渡り、プログラミング・テストなどが実施されます。
川が上流(山の水源から始まる川の流れの最初)から下流(海につながる川の流れ)にうつり、最後に海につながるように、上流工程で「システムで何をしたいのか」を決め、下流工程でプログラミング・テスト等を行って、海につながる(システムをリリースする)という考え方です。
もし上流で水が止まったら、あるいは流れが悪くなったらどうなるでしょうか。下流でどれだけ頑張ろうとしても、そもそも水がこなければ下流は何もできません。流れが悪ければ下流に来る水も減り、海に流せなくなります。
上流工程でシステム導入の成功・失敗は決まります。では上流工程にはどのようなフェーズ(段階)があるのでしょうか。
上流工程の仕事内容は
上流工程ではどのような仕事をしているでしょうか。
システム導入のフェーズ(段階)ごとに仕事内容を説明していきます。
IT戦略立案
まず最初は、企業全体の中長期のIT戦略立案から始まります。
数年後の会社の売上目標・組織目標などをもとに、目標達成を支援するためにどのようなシステム構成が必要か、新規システム導入をどのくらいのスケジュール・予算で行うか、など戦略を立案します。
このフェーズは通常の上流工程とは分けて、「超上流工程」などと呼ばれることもあります。
業務プロセス設計
IT戦略立案の後、システム導入に入る前に業務プロセス設計を行います。
業務プロセス(手順)設計とは、業務の流れ・手順を洗い出し、今後こうすべきという理想の業務を決める作業です。
理想の業務に向けて、どのようなシステムを導入すべきかを後のフェーズで確立していきます。
システム選定(ベンダ選定)
システム選定(ベンダ選定)では、システムを導入するための選定作業を行います。
この選定とは、システムの種類(パッケージソフトウェア・一から自社開発など)、導入担当会社(SIerなどのシステム会社に依頼・自社開発者で対応など)を比較検討し、決めていく作業を指します。
業務プロセス設計で決めた理想の業務に合う、優れたシステムを選ぶために、複数のITシステム会社(ベンダ)に声をかけて提案してもらうことが一般的です。
ここで誤った選定をすると、詐欺まがいのシステム会社にあった、理想の業務にまったく合わないシステムを作ってしまった、ということになりかねないため、非常に重要な工程です。
ちなみにIT戦略立案同様、さきほどの業務プロセス設計、そしてシステム選定(ベンダ選定)まで含めて「超上流工程」と呼ぶこともあります。
私の経験上ですが、ここまでのフェーズでシステム導入成否はほぼ決まります。業務プロセスを適切に設計でき、優れたシステム会社(ベンダ)を選ぶことができれば、あとは問題なく導入が進むことがほとんどです。
失敗するプロジェクトは、ほぼ例外なく、業務を適切に決められていない(要求が膨らんで必要機能が多すぎるなど)、経験の薄いSEや品質意識の低いPGが担当に付いた、などが原因です。
要件定義
システム選定まで決まると、具体的な導入が始まります。
まず最初は「システムで何がしたいか」(要件)を決める要件定義です。業務プロセス設計で決めた理想の業務が、選定したシステム(パッケージなど)で実現可能かを詰めていく「Fit&Gap」(実現可能なフィットと、やりたい業務を満たせないギャップ)という手法と、業務を満たす機能を一から確認していく手法があります。
ここで要件を具体的に決めておかないと、「地図アプリが見にくい」という曖昧な話のまま進んでしまい、後になって認識齟齬が出て仕様変更、ということになります。
基本設計
要件定義が決まると、要求を具体的にシステム機能に落とし込む基本設計が始まります。
プログラマーの方であれば、「設計書」を作るフェーズといえば分かりやすいかもしれません。ただしPGが担当する詳細設計と違い、基本設計ではユーザも理解可能な表現で設計書が作られます。
基本設計では、例えば「地図アプリの拡大率は最大○○%」、「画面のボタンとテキストボックスの配置は○○とする」、「ボタンを押したら交通費一覧を表示」など、目に見える、あるいはユーザ業務に影響するシステム動作などを決めていきます。
ちなみに詳細設計は、ユーザが理解できない(ユーザが意識しない)、主にプログラミング内容を文章等で記述します。
一般的に、この基本設計までを上流工程と呼びます。
下流工程(詳細設計以降)
基本設計の後は下流工程と呼ばれるフェーズになり、以下のような工程で構成されます。
詳細設計→コーディング→テスト→ユーザ教育・データ移行→(本番稼働後の)運用保守
詳細設計ではJava等のプログラム内容を、日本語の文章で記述します。その内容を受け、コーディング(プログラミング)を行います。
作ったプログラムに問題がないかテストを行い、問題なければシステムの操作教育に移ります。利用中のシステムからデータを移す作業を行い、本稼働を迎えます(工程の順序や時間は前後することがあります)。
本稼働後は、運用保守で問合せ対応や不具合修正、新しい機能の開発(二次開発)などを行います。
ITの上流工程の特徴
ITの上流工程の特徴は、システムに直接手を触れていないということです。
下流工程のプログラマーであれば、プログラミングをして機能を作り、システムの動作を形作っていきます。
しかし上流工程のシステムエンジニアは、ユーザとコミュニケーションをとりながら要件を決める(要件定義)、画面の動作をドキュメントにまとめる(基本設計)、などシステムには直接手を加えていません。
上流工程のSEには、プログラミング経験のない人が多くいます。システムに直接関わっていなくとも仕事ができるということです。技術の理解も重要ですが、要件定義等をこなすにはコミュニケーション力や業務知識、システム全体を俯瞰する視野のほうが求められるためです。
もちろんプログラミング経験もあり、上流工程SEの能力もあるのが望ましいです。技術も業務も理解し、ユーザとコミュニケーションも取れるSEは、プロジェクトに引っ張りだこです。
上流工程ならではの特徴を意識しながら転職活動すると、企業にも評価されやすくなりキャリアプラン実現に近づけます。