要件定義の前に【要望・要求・要件】を理解しよう！
お世話になっております。 食×IT 複合作家の内田です。食のお話を楽しみにフォローしている方は、今回はジャンルが違いすみません🙇♂️
今回は要望・要求・要件のお話です！
今日のテーマは「要件定義」の話になるのですが「要件定義」の基礎となるのは【要望・要求・要件】なので、今回はこんなタイトルにしています。
そもそも要件定義って？
要件定義を超シンプルに言うと、例えば開発などで、アプリの開発を依頼されたとします。依頼を受けたら、何を作るか以下の流れで話し合い、仕様の「決め」を行います。
お客の要望を聞く → 仕様を決める → みんなが合意した仕様で開発開始！
ざっくり言うとこの「みんなが合意した仕様」にあたる部分が【要件定義】なんです！
しかし、この表現を使うときは気を付けて下さい。例えば、あなたの上司に「君は要件定義を理解しているか？」って聞かれたとします。
そのときに、このような回答をしてしまうと「お前、要件定義なめてんだろ？」って言われてしまうかもしれません・・🤣
これは、イメージするための簡単な解説なので、要件定義を語るには、もう少し理解を深める必要があります。
どんなときに要件定義が必要？
基本的に設計が必要なものには、すべて要件定義が必要です。よく例にあげられるのは、受託開発のケースですが、運用設計をするときなどでも、要件定義が必要です。
▼よくある例
・0から作るアプリの開発
・完成品プロダクトの新機能や機能改修
・プロダクトを利用してどう運用するか？
・プロダクトをどの様な設定で導入するか？
何で要件定義が必要なの？
これはトラブル経験がある人ほど、よくご存じだと思います。例えば何らかのシステムを作って欲しいと、相談があったとします。
ここでまず、最初に何が欲しいか？何がしたいか？などをヒアリングするのですが、ここで顧客が話す内容は「ざっくりとした要望」にすぎません。
しかしながら、こんな情報不足のまま、勢いで話が進んでしまうケースは、IT業界には多々あるのです。
具体的にどういう事かといいますと。
この絵は、昔流行った【プロジェクトあるある】の風刺画なんですが、顧客にヒアリングしたときの状況を、うまく表現しています。
※左上の「顧客が説明した要件」に注目。
このブランコをみて皆様はどう思いますか？
このブランコで一体何するつもりだろう？・・・って思いませんか？皆様はブランコの使い方を知っているので、このように思うのは当然です。
しかし、そんな事実があったとしても、こんな風に考えて進める人が、普通にいるのです（私の体験談）
・何となくアリな気がするから進めるべき
・何も考えずそのまま横流しでOK
・売上最優先、リスクは前向きに考よう
・トップダウンだからとにかくやれ
このようにすすめると、当然想定外が多数発生します、
すると、どうなるかと言いますと、関係者各位の間で大混乱が生じます。
そして、妥協案による調整を繰りかえした結果、こんなひどいブランコが出来上がる事になります。これは顧客が望んだ結果なんでしょうか？
そうなんです！こんな結果にならない様に、要件定義が必要なんです！
重要なのは、最初の設計段階で、お客様に聞いた事をそのままやるんじゃなくて、一緒に協議してどれだけ「ここに近づけられるか」なんです。
では、どうやって進めていくのか？
具体的な、要件定義の万能なテンプレはありません。
要件定義は幅が広く、環境や条件によってやり方が変わるので、臨機応変に考える必要があります。
そのために必要な考え方は３つ！
それが【要望・要求・要件】なんです。やっとここからが、本題！
要望・要求・要件
まず要件定義を、図で表すと以下のようになります。
この図は、顧客が提示した「要望」を、もしシステムにしたらどこまで実現できるか？を開発チームに確認（要求）して、顧客に合意がとれた結果が「要件」である・・という事を表現しています。
要は、叩き台を作り、これを叩いて叩いて確認して・・全体の合意が取れるまで、方針を絞り込みなさいよ・・という図なんです。
要望・要求・要件はそれぞれ以下の内容を定義します。
・要望：何をしてほしいか？
（顧客へのヒアリング）
・要求：具体にどう実装するか？
（開発への要求）
・要件：提案者・開発・顧客の合意
（全体の合意）
要望→要求→要件の流れ
説明書きだけでは、わかりずらいと思うので、これらをストーリー化してみました😆
まず要望を聞こう！【要望】
私は顧客とディスカッションをして、要望を整理するセールスエンジニアです。ある日、顧客から、以前納品したアプリの改修依頼がありました。
ちなみに以前納品したのは、出前が注文できるアプリ。
以下をヒアリングして、要望を顧客から引き出したいと思います。
課題：今困っている事とその背景
ゴール：何ができればゴール？
課題解決：〇〇を実装すれば解決する？
※左が提案者（私）で右が顧客
とりあえず以下3点が何となく聞けたので、これを持ち帰ります。
課題：炒飯の検索効率が悪い
ゴール：少ない動線で近所の炒飯の店を検索
解決策：炒飯ボタンで動線が減るかも？
次は開発チームと【要求】を詰める
早速、開発チームにヒアリングした内容を視覚化して伝えます。
まずは顧客から聞いた「あったらいいな」をラフな絵で視覚化して、開発チームに見せてみました。
※要求定義書
左が提案者（私）で右が開発チームの人
この様に、開発に相談して、要求を伝える事を【要求定義】そして、その要求をまとめた資料を【要求定義書】と呼びます。
開発チームに相談したところ、このようなご意見がありました。
最終合意を取ろう！【要件定義】
開発チームと協議した内容をマージして資料にしたので、次はこれを持って顧客に相談しにいきます！
最終確認のため、視覚化した資料を【要件定義書】と呼びます。
※要件定義書
※左が提案者（私）で右が顧客
このように、最後に開発と決めた方針を、顧客に確認をして合意を取る事を【要件定義】といいます。
以上、こんな流れです。
これが要件定義の流れなのですが、イメージできましたでしょうか？
要件を確認する際、依頼された内容と、別な要望がでるって事、よくあるのですが、話が分散すると、本題が停滞してしまうので、ここは優先度を整理しながら確実に進めましょう。
最後に
一番大事ポイントは、自社と他社、関係者全員と、脳内同期がとれている事です。認識のズレは後で発覚すると、大きな問題につながりますが、早い段階であれば、いくらでもリカバリができます。
また、口頭だけの議論は、認識のズレが起きやすいので、資料を作り決定事項を視覚化して、可能な限り同じ認識を保つ事が、要件定義の神髄だと私は思っています！
以上、要望・要求・要件について解説させていただきました！
IT業界で学んだお役立ち情報は、こちらのマガジンにまとめていきます！
現在こちらの別ブログ（よっしーTECH）から、IT業界に関するお役立ち記事をエキスポート > リライトしながら、移行中ですので今後ともよろしくお願いいたします✨
この記事が参加している募集
ほとんどの記事を無料で公開しているので、めっちゃ投げ銭欲しいです！100円大歓迎！