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