SAが起こす小さな現場革命 〜Part８：要件定義(前編)

私、えいる は2022年3月に転職して、あるベンチャー企業でソリューションアーキテクト(以後、SA)という仕事をしています。

SAはまだ知名度が低く、どんな仕事？と聞かれるマイナー職です。

しかし今後のコンサルやIT業界で必ず必要とされ、数年後は注目職の１つになると私は確信しており、SAの業務内容、必要性、活躍の事例を連載形式で紹介していくことにしました。

• クライアント要望を理解しきれず、適切な見積もりや提案ができない

• 受注後に想定外の作業・課題が多発して案件が炎上

• PMとエンジニアの会話が噛み合わない(現場が険悪)

こんな悩みを抱えている皆さん、その解決策の１つがここにあります！！

---

要件定義で案件の成功・失敗が決まる！？

今回から私がSAとして要件定義のプロセスにおいてどのような役割を担い、結果として何を残しているかを数回にわかって書いていきます。

第１回となる今回は、要件定義の必要性とSAの役割について紹介していき、最初にどのようなアクションとアウトプットを残しているかについてです。

---

要件定義は計画の見直しが許される最初で最後の機会である

要件定義はシステム開発おける最上流工程に位置し、今回のプロジェクトでいつまでに何を作り、何を実現するかといった開発に必要な「決めごと」を発注者とベンダーで最初に決定・合意するプロセスになります。

私自身、案件の成功・失敗の５０％以上が要件定義で決まると思っており、具体的には要件定義を怠った先には以下の未来が待っています。

• リリース後にほとんど使われない不要な機能に時間と予算を奪われた

• 機能数が多すぎて予算と納期が合っていない（最初から炎上前提）

• 開発の途中で発注者とベンダーの認識齟齬が多発し開発が進まない

このような失敗を招かないためにプロジェクトの最上流工程で今回の開発で作るもの・作らないものを決定させ、作るものの内容が予算と納期の観点で妥当であるかを見極めます。

プロジェクトが数週間、数ヶ月と進行していくにつれて予算と納期の変更は難しくなります（既に使ってしまった時間とお金は戻ってきませんよね）。

しかし、まだ開発がほとんど始まっていない要件定義の段階なら発注者側も妥当性が理解できれば、まだ予算と納期の調整がしやすい状況と言えます。

このように要件定義は、発注者/ベンダー双方にとって今回のプロジェクトで損失を生まないための最初で最後の見直しタイミングとなるのです。

---

SAは要件定義を通してプロジェクトを正解に導くキーパーソン

プロジェクトにおいて各ステークホルダーは以下を重視しています。

• クライアント：自分たちが抱える課題を解決するための要望

• PM：プロジェクトを予定通りに完遂させる安定性

• エンジニア：ITサービスとして確実に形にさせる実現性

これらは似て非なるものであり全てを叶えることは不可能です。この状況でSAは、プロジェクト全体を俯瞰的に捉え、過去の経験と知見をフル活用させ最適解が何かを導き出していきます。

このSAが導き出す答えはQCDの観点から誰もが納得でき、かつ実現性のある折衷案というのがイメージに近く最大限全員が得をするよう考えています。

このように個々の要望を吸い上げ、それらを繋ぎ、最適な実現手段の提供をミッションに掲げるSAの存在は、０→１を形にする要件定義において最適な人物像でありキーパーソンとしての活躍が期待できます。

次章からは、SAが具体的にどのような方法で要件定義を進めプロジェクトを成功に導いていくかを紹介していきます。

---

STEP1：業務フロー図を作成して、クライアントの現状・課題・解決イメージを体系化する