要件定義を理解しよう！
「要件定義が出来ていない！」IT業界では、これ本当にどこ行ってもよく聞くキーワードではないでしょうか。
要件定義は重要なキーワードです。ある程度知っておけば、商談もスムーズにすすむかもしれません！
この記事で、少しだけかいつまんで書かせていただきますが、詳しくはこの本を読むといいかもしれません！
要件定義をザックリ言うと？
例えば、超シンプルに言うと開発などで、アプリの開発を依頼されたとします。何かを作る為には「設計」が必要なので、以下の様なキメが必要なんです。
お客の要望を聞く → 仕様を決める → ”みんなが合意した仕様"で開発開始！
まずは "みんなが合意した仕様" にあたる部分が要件定義と思って下さい。
ではなぜ要件定義が必要なのでしょう？
これは炎上経験がある人ほど、よくご存じなのではないでしょうか。
まず、顧客が話す要望は「大まかな要望」にすぎません。細かい状況を聞かなければ、本当にできるかどうかの判断も、この時点では解りません。
なので、要望を聞いたら、その場でもう1度考えてみましょう。
・現実的に作れるレベルのものでしょうか？
・本当に抱えてる課題が解決しますか？
・製品は本当に良くなりますか？
顧客はこっちのシステムの事情なんて知りません。あくまで自分の目線だけで「あったらいいな」を語るだけなので、手段と目的の狭間で混乱しやすいんです。
例えばこの絵は、昔に流行った【プロジェクトあるある】の風刺画なんですが、顧客にヒアリングしたときの状況をうまく表現しています。
左上の「顧客が説明した要件」に注目してみてください。このブランコをみて皆様はどう思いますか？いったいこのブランコで何をしたいんだ？って思いませんか？
皆様はブランコの使い方を知ってますから解りますよね。
例えこんな状態だったとしても、以下みたいなノリや事情で、窓口の担当者が、そのまま進めてしまう場合があるんです。
・直観的に正しい気がするからOK！
・エイヤー！ですすめるカルチャー
・数字重視でリスクは考えず前向きに考えた。
・トップダウンで作る方針になった。
こんな感じで進めると、当然想定外が多数発生します。
すると、どうなるかと言いますと、認識齟齬が関係者各位の間で、山の様に発生して大混乱が生じます。
そして、妥協案による調整を繰りかえした結果、こんなひどいブランコが出来上がる事になります。
これが、顧客が望んだ結果なんでしょうか？
こんな事にならない様にする為にも要件定義が必要なんです！
ここまで話して興味をお持ちになった方、詳細を知りたい方は書籍、そこまで細かくなくていいよって方は私の別ブログがおススメです！
是非読んでみてください！
私の記事に価値を感じてくれたら、寄付をいただけると嬉しいです。 サポートは「誰かがお金を出してくれるような記事をかけているか」の基準としたいので、高いとか安いとかどうでも良いです。100円大歓迎！