概要

この記事では、私が要求分析や要件定義に関する本読み、自分なりに納得した要求分析と要件定義の考えた方についてまとめます。
読書感想文的なものです。

なぜ要求分析と要件定義の本を読んだりしたのか

業務で上流工程のナレッジを共有する機会があり、せっかくなので上流工程を体系的に学習してみようと考えました。
上流工程の実務経験はありますが、自分の知識は企業文化に依存しており、正直、社内で共有するには心もとないと感じていました。
例：仕様書の名前が違う。作らない仕様書がある。スコープが違う。

同僚やCTOのおすすめから以下の本を読みました。

※本記事では「要求分析」と「要件定義」は同一のものとして記載します。

学習によって得た気づきには以下のものがあります。
なお、本の内容については本を読んだほうが速くてわかりやすいので記載しません。

今まで色々なプロジェクトに参加してきましたが、
仕事の流れとしては「仕事を受ける」→「要件定義」→「設計」のように仕事を受けた後に要求分析を行っており、
よく「実現無理では…」「スケジュールきつくね?」といった問題が発生していました。

そもそも「システムの要件」が決まっていない状態で開発を開始するべきではありません。
要件があるから見積もりができて、スケジュールを引けるのです。
見通しの立たない開発は炎上や低品質なシステムにつながります。

また、システムの品質は要件とシステムの動作がどれだけ一致するかで決まります。
極端な話「要件」がなければ明らかな異常動作でも低品質とは言えないのです。

理想は「要件定義の仕事を受ける」→「要件定義」→「開発可否判断」→「開発の仕事を受ける」となるべきです。
「開発可否判断」を行わないプロジェクトに参加した場合はぜひ「開発可否判断をやろう！」と行動してみてください。

元々は「システム開発」を行うため次の工程である「基本設計」を行うための基礎となる情報だから、漏れなくやる必要があると考えていました。
しかし「要件定義」の問題を整理すると実はちょっと目的が違ったのではないかと感じ、
今は「開発可否判断」を行うことが目的だと考えています。

顧客は「自分の欲しいシステム」がわかっていないことが多いのです。
ざっくりとしたイメージで話していることが多く、実際にシステムにしてからイメージと違うと問題になることも多々あります。

上記問題を解決するために「要件定義」にて、
顧客が欲しいシステムの要件を明らかにして、
わかりやすい資料に落とし込み、
顧客と認識のすり合わせや考えを共有し、
「このシステム要件が欲しいシステムである。これを開発してほしい」と開発可否判断をさせる/するべきだと思います。

「要件定義の目的」は顧客に「開発可否判断」をしてもらうことだとこれまで記載してきました。
そのために資料を作成します。決して「納品のため」ではないのです。

よく「納品さえすればいい」「うちでは作らない」といったお話を聞きますが、
「開発可否判断」ができるのであれば私はどちらでもよいと思います。
ただ、やっていないと言いながらもやっていないのはきっちりとした「要件定義仕様書」の作成であり、それに類する資料や行動をしていることが多いです。

システムにする業務の流れを共有するために業務フローを作成したり、
外部システムとの連携やインプットを明らかにするためにシステム構成図を作成し、
要件に漏れや勘違いがないか。
また、このシステムが実現できるのか開発側での判断を行います。

これまで記載した内容を社内で共有したり、開発側と顧客側で「開発可否判断」による合意を意識していきたいと思います。