おはこんばんちは！ゆるふわSEの「ゆるちょここ」です(*´ω｀*)
どーも最近要件定義的なお仕事をする機会が増えてきたので、今回は要件定義の難しさについてちょっと考えてみるよー！
私達SEのお仕事と言えば上流から下流まで一般的には、『要件定義、設計、実装、テスト、リリース』のフェーズをたどることが多いです。
このフェーズの中で一番難しいかつ繊細さが求められるフェーズが『要件定義』だと思います。この要件定義がうまく出来ているか（顧客との認識差異がなく、業務要件を機能要件へ落とせているか。また適正なボリュームかどうか）が9割型の今後のプロジェクトを左右するといっても過言ではありません！！！
ではまず要件定義とはなんでしょー？
『要件定義とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などを明確にしていく作業のこと。いわゆる上流工程の一部で、実際の開発・実装作業を始める前に行う作業の一つである。』だそーです。
※IT用語辞典より
下記に私が感じた要件定義の難しさと重要かなぁって思うとこを整理がてらあげてくので要件定義でつまづいちゃう人の少しでも参考になればと思います！
要件定義の難しさ（ポイント）体験談♬
・顧客の中で意思決定権を持つ人間が誰かという見極めが重要。
・顧客の知識レベルに合わせシステム的な用語を極力分かりやすく説明できる力が重要。
・当然ですが、顧客の要望を聞いた時にそれがシステムとして実現できるのかどうかを判断できる技術力が必要。できるかどうか曖昧なのにできると言ってしまって実はできなかった時のリスクは超高い。
・実現可否の判断とほぼ同時にどの程度の工数がかかるかをはじき出せることが重要。
・仕様上出来ないといった言葉はSEにとって魔法のような言葉だが、あまり多用すると顧客満足度がだだ下がってしまう。出来ないにしても妥協案を提示できるかどうかが重要。
・要件が明らかに想定される作業工数を超えそうな程膨らんだ場合の妥協案を提示できるかが重要。（フェーズを分けて対応する。追加費用を請求するなど。）
・実は要件をたくさん出してくれるお客の方がその時は大変ではあるが整理して優先度をつけたりすれば後々楽。要件をなかなか出してくれない（システム化したいことが明確じゃない）お客の方がプロジェクトは苦戦しやすい。
・顧客要件遅れによるプロジェクト遅延について顧客とスケジュールの引き直しが握れるかが重要。
・要件定義で顧客要件を確定しておかないと後でひっくり返されてプロジェクトが火を噴くことがある。議事録などのエビデンスを取っておくのが地味に大事。
などなど…
個人的には考えるのは嫌いじゃないので要件定義などの上流工程は割と好きだったりします✨
上記をうまく考慮しつつ顧客もこちらもWINWINになれる方法を模索してる今日この頃でしたぁ(*´ー｀*)
でゎでゎ✨
