これまでの連載では主にIT業界の構造やエンジニアの仕事内容について触れてきました。IT業界といえども、様々な形態で仕事を行っているため、初めて就職するような場合は注意が必要になります。
システムエンジニアとして働いていく中で、常駐案件として送り込まれる先の企業で働くこともありますので、留意しておくようにしてください。そうした認識がない中で仕事を行っていく場合、どうしても「こんなはずじゃなかった」と後悔する可能性もあると思います。
今回の記事では「上流工程」について解説していきたいと思います。IT業界を志す人には「上流工程」と聞いたことある人が多いと思いますが、実はこの「上流工程」こそが案件を左右する超重要な内容になります。遅かれ早かれ、どんな形式であれ「上流工程」にかかわる機械はあると思いますので、その重要性を認識してもらえればと思います。
上流工程とは
上流工程とはシステム開発において重要なアクティビティを行うフェーズのことを指しています。
- 要件定義
- 機能定義
- 計画立案
- 予算作成
- 設計
プロジェクトが立ち上がった後、システムを開発する際の「何を作るべきか」「どう作るべきか」「どのような計画で進めるか」といった、プロジェクトの方向性を決める一番最初で重要な部分の工程を指しています。
顧客が「どのようなシステムが必要なのか」を見極める要件定義や、要件をカバーする機能の取捨選択、それを作成するために必要な予算と計画、さらに全体的な方針決めなど、上流工程はシステムを作るための羅針盤を作るようなアクティビティとなります。
必要なシステムを見誤ると、プロジェクト全体が意味のないものになりますし、計画が杜撰であれば収支があわず問題となり、場合によっては裁判沙汰を引き起こしかねないのが上流工程です。
上流工程の業務内容
では具体的に上流工程が何をしているのか、を解説していきたいと思います。上流工程では様々なアクティビティがあります。例えば以下のようなものがあり、それらすべてはアプリケーション開発において重要です。
- 要件定義
- 工数見積
- スケジュール
- 基本設計
- 要件定義
「要件定義」とはアプリケーション開発において「何を、どこまで、どのようにして作るのか」を定義してドキュメントに起こしていく仕事になります。出来上がったドキュメントを「要件定義書」と呼び、アプリケーション開発において達成するべきゴールでもあります。
要件定義を最初の段階で作成して、顧客側の「要求」をドキュメント化していきます。一般的に顧客は「何を作ってほしいのか」が分かっていない場合がほとんどです。ですので、お客さんの業種や仕事の流れ、業務上の問題点などを上手に聞き出し、アプリケーションとして「どのように解決するか」を定義していきます。
はじめに達成するべきゴールを策定することで、「〇〇に〇〇の機能を追加実装して欲しい」といった唐突な要望に対して「要件定義書には記述していないので、追加要望として別費用でなら対応します」といった自衛をすることが可能になります。要件定義書は開発する側のためのドキュメントでもありますが、同時に顧客の同意も得て決定されるドキュメントになるので、有効範囲がきっちりと明確になります。
要件定義書がしっかりとできていない場合、例えば顧客の要求が上手く汲み取れなかった、などでは最終的に「顧客が必要としないアプリケーション」が開発されてしまうので、かなり重要です。時々要件定義がうまくいってなかった影響で、完成した後に「こんなものは使えない」と顧客側から突き返されてしまう場合もあるので注意が必要です。
工数見積
要件定義（つまり顧客の要求）が固まった段階になると「アプリケーションの形」が少しづつ見えてきます。そこで作成する必要があるのが「工数見積」です。「工数」とは「規模感や必要な人員、期間」などを算出するアクティビティになります。
工数見積はお客さんの予算にも関わってきますし、どれくらいの人員を集める必要があるか、といった指標にもなります。例えば「10人で開発すると1年かかります」というようなアプリである場合、人件費や営業にかかる費用、機材代などを計算するとある程度の金額を見積もることが可能です。この金額が顧客側の予算と合致するかどうかをみるのです。
費用がかかりすぎる場合は、特定の機能の実装を取り止めて必要人数や期間を少なくしたりして金額の調整をすることになります。金額を調整して顧客との妥協点を見つけるために必要になるのが「工数見積」となります。もちろん工数見積もとても重要で、「10人で1年掛かる」というアプリ開発が、ふたを開けてみたら「15人で1年」という規模感・難易度でした、となったら大問題です。
期間も厳しくなりますし、何より請求金額と実費用に差分が生じてしまい、実質赤字になる可能性があります。そうした点をしっかりと見極めるためにも重要な作業の一つになります。通常はエンジニアが見積を作成することが多いのですが、営業マターで工数が削られたりすることもあります。
スケジュール
物事には期限があるようにアプリ開発にも期限があります。要件定義などで「〇〇年〇〇月までに完成する」というような取り決めを行っている場合、その期限に間に合うように作業を細分化してスケジュールを組み上げていきます。工数見積などから必要人数を算出し、それらを稼働させて「どの順序で、どのように取り組むか」を明確にする作業といえます。
一般的に最初の方に出すスケジュールはあいまいなことが多く、実際に案件を進めていく中で問題が生じたり、想定期間におさまらない難易度だったりすることがありますので、必要に応じてスケジュールを調整し、顧客側と交渉テーブルに着くような場合もあります。
スケジュールは立てるのも難しいですが、それを守り予定通りに進行させることもかなり難しいというのが実情です。柔軟にエンジニア達の作業内容や実情を把握しながら、顧客との間で「上手い落としどころ」を探るのも仕事になります。もちろんスケジュール通りに進まなければ、顧客側もお怒りになることがありますが、そうした自体の矢面に立たなければならないのも仕事の一貫になります。
基本設計
「基本設計」とはアプリケーションの基本的な部分を定義するドキュメントになります。要件定義で定まった顧客の要求に対して大まかなアプリケーションのイメージを伝えるために作成することがほとんどになります。中には上流工程で取り組まないこともありますが、企業によっては基本設計までを上流工程とする場合もあります。
基本設計はアプリケーション開発を行う中で、顧客がイメージを持ってもらえる資料である必要があります。顧客のほとんどがプログラミングが分からない人々ですので、専門的な内容を極力避けながらアプリケーションの動きを定義していきます。例えば「更新ボタンを押下すると、画面の入力値が保存されます」や「検索ボタンを押下すると、入力内容に応じた検索結果が一覧として表示されます」などを画面イメージと共に定義していく感じです。
私的に基本設計で押さえるべきは「画面イメージ」と「ボタン押下時の処理」、「初期表示時」だと考えています。要するに「顧客がアプリケーションをイメージできること」が重要で、専門的な内容を省いて「アプリケーションがどんな動きをするか」を示す必要があると思っています。
顧客によっては基本設計までを成果物として「納品」を求めることが多いです。中には全く不要という日々ともいますが、基本的には顧客との同意のうえで作成されるドキュメントですので、納品しておくことが望ましいと思います。
また、基本設計を行うことでアプリケーションの「動き」が定義できますので、これを基にしてより実装に近い設計書を起こすことになります。それらは「詳細設計」などと呼ばれ、内部ドキュメントとしてメンテナンスされていきます。そうした「作業に必要な書類」を作成する、おおもとになるのが「基本設計」ということになります。
上流工程の責任範囲
上流工程は顧客と直接的なやり取りの多くなる立場であり、案件を代表する「顔」となることが多いです。したがって何かトラブルが発生した場合、それらを迅速に報告し、顧客との対応を行う必要があります。ですので顧客に怒られたり、詰め寄られたりすることもあります。
上流工程で仕事をする場合はプログラミングをすることは少なく、割とマネージャーに徹することが多いため、責任を追う立場になると認識しておいた方がよいでしょう。また仕事を遂行するにあたって、コミュニケーション能力を求められることが多いです。
- 相手に内容を簡潔に伝える
- 相手に報告内容を正しく伝える
- 押し切られないように踏みとどまる
などが挙げられます。上流工程で顧客に押し切られると下につくエンジニアすべてが疲弊する可能性があるので責任重大です。技術的な内容を振られて答えられなかったりすると相手からは不審がられますし、適当なことを言ってしまうとエンジニア側からの信頼を失ってしまいます。エンジニアから信頼を失うと案件をスムーズに進行することは難しくなります。
上流工程で仕事をする理想的なエンジニアは「技術的なことが分かること」「コミュニケーション能力があること」「人の上に立つ資質（チームリーダー）があること」が挙げられます。これらがないと案件を上手に操ることが出来ず、自身が大変な想いをすることになるので注意が必要です。
上流工程は重要で難しい
以上、アプリケーション開発で重要となる「上流工程」について解説してきました。上流工程の重要さ、大変さなどを理解してもらればと思います。とはいえ、通常、入社してすぐに上流工程に参画することは稀ですので、あまり心配しなくても良いかと思います（上流工程メインの企業を除く）。
上流工程はアプリケーション開発において舵取り役である「船長」のような存在です。「案件」という大きな船を、正しく運航して港まで船を運べるのか、途中で氷山にぶつかって沈没するか、もしくは進路を間違えて別の港に到着するかは「船長」である「上流工程」に賭かっているといっても過言ではありません。
それほどまでに「上流工程」は重要なアクティビティなのです。「上流工程」の作業に当たるエンジニアは、責任をしっかりと持ち、上流工程の意味を理解したうえで職務に当たる必要があることを理解しておきましょう。
