今回は要望・要求・要件のお話です!
今日のテーマは結局【要件定義】の話になるのですが、何故このようなタイトルにしたのか?
それは、要件定義を実践で利用するには、決められた「テンプレ」ではなく「考え方」を理解する必要があるからなんです。
この考え方の基礎になるのが【要望・要求・要件】だと私は思っています。
さていったいどういう事なのか?本日もいつものノリで解説していきます。
そもそも要件定義って?
超シンプルに言うと、例えば開発などで、アプリの開発を依頼されたとします。
何かを作る為には「設計」が必要なので、以下の様なキメが必要なんです。
お客の要望を聞く → 仕様を決める → “みんなが合意した仕様”で開発開始!
この【みんなが合意した仕様】にあたる部分が
要件定義なんです!
しかし、私が今使わせていただいた、この表現を使うときは気を付けて下さい。
例えば、あなたの上司に「要件定義って解るか?」って聞かれたとします?
その場合、この回答をしてしまうと「お前、要件定義なめてんだろ?」ってきっと言われますw
まずは、イメージしやすく簡単に話しているので、これが答えではありません。
どんなときに要件定義が必要?
基本的に設計が必要なものにはすべて必要です。
よく例にあげられるのは、受託開発のケースですが、プロダクトを使った、運用設計をするときも、要件定義が必要です。
よくある解りやすい例としては・・
・0から作るアプリの開発
・完成品プロダクトの新機能や機能改修
・プロダクトを利用してどう運用するか?
・プロダクトをどの様な設定で導入するか?
などなど・・こんなときに要件定義が必要になります。
先ほどアプリ開発の場合は、こんな流れになる事を、先ほどお話しました。
①お客の要望を聞く
②仕様を決める
③”みんなが合意した仕様”で開発開始!
もし、運用設計の場合は、ざっくりこんなイメージになります。
①お客様の「業務フロー」をヒアリング
②業務フローとサービス仕様を元にルールを決める
③”みんなが合意したルール”で運用開始
何で要件定義が必要なの?
これは炎上経験がある人ほど、よくご存じなのではないでしょうか。
まず、顧客が話す要望は「大まかな要望」にすぎません。
細かい状況を聞かなければ、本当にできるかどうかの判断も、この時点では解りません。
要望を聞いたら、その場でもう1度考えてみましょう。
聞いた要望は現実的に作れるレベルのものでしょうか?
顧客の言う要望に応えれば、本当に抱えてる課題が解決しますか?製品も良くなるんですか?
顧客はこっちのシステムの事情なんて知りません。あくまで自分の目線だけで「あったらいいな」を語るだけです。
この絵は、昔に流行った【プロジェクトあるある】の風刺画なんですが、顧客にヒアリングしたときの状況をうまく表現しています。
※左上の「顧客が説明した要件」に注目
このブランコをみて皆様はどう思いますか?いったいこのブランコで何をしたいんだ?って思いませんか
皆様はブランコの使い方を知ってますから解りますよね。
例えこんな状態だったとしても、以下みたいなノリや事情で、窓口の担当者が、そのまま進めてしまう場合があるんです。
・ブランコの事はよく解ってないけど、お客様の要望は、なんとなく正しい気がしてきた。
・よく解らないから、情報をそのまま横流して、無理やり開発する方向で進めた。
・とりあえず売れる事が重要なので、リスクは考えず前向きに考えた。
・トップダウンで有無を言わさず、訳の解らないブランコを強制的に作る方針になった。
こんな感じで進めると、当然想定外が多数発生します。
すると、どうなるかと言いますと、認識齟齬が関係者各位の間で、山の様に発生して大混乱が生じます。
そして、妥協案による調整を繰りかえした結果、こんなひどいブランコが出来上がる事になります。
これが、顧客が望んだ結果なんでしょうか?こんな事にならない様にする為にも・・
要件定義が必要なんです!
重要なのは、最初の設計段階で、お客様に聞いた事をそのままやるんじゃなくて、一緒に協議してどれだけ「ここに近づけられるか」なんです!
では、どうやって進めていくのか?
具体的な、要件定義の万能なテンプレはハッキリ言ってありません。
0からの開発なのか?、プロダクトの機能追加なのか?、運用設計なのか?
要件定義のやり方は、個人のやり方に任せるのか?会社が用意したテンプレにどんな時でも無理やり乗せるのか?
この様に、要件定義は幅が広く、環境や条件によってやり方が変わるので、臨機応変に考える必要があります。
臨機応変に対応するには、知っておくべき、基礎となる考え方が3つあります。
それこそが・・
要望・要求・要件なんです!
次は、要望・要求・要件の考え方について、説明していきます。
要望・要求・要件
まず要件定義を、図で表すと以下のようになります。
この図が表しているのは、顧客が提示した要望を、システム的にどこまで実現できるか?を絞り込むみたいな意味で見て下さい。
そして、要望・要求・要件はそれぞれ以下の内容を定義します。
要望:何をしてほしいか?
(顧客へのヒアリング)
- 課題:今困っている事とその背景
- ゴール:何ができればゴール?
- 課題解決:〇〇を実装すれば解決するの?
要求:具体にどう実装するか?
(開発への要求)
- UI/UX:利用イメージはどうなる?
- 機能要件:実装可能な機能
- 非機能要件:実装できない機能
- 工数:納期・人/月工数などの割り出し
- 要求定義書の作成:視覚化する
要件:顧客との合意
(開発と顧客の合意)
- 実装する機能:〇〇をここまで作ります。
- 要件定義書:視覚化した資料の提示
- 工数の提示:いつまでに、いくらで
要望→要求→要件の流れ
説明書きだけでは、読んでてもつまらないと思うので、これらをストーリー化して例に当てはめてみます!
まず要望を聞こう!(要望)
ペンギン君は、顧客と開発を繋ぐ、セールスエンジニアです。
象さんの会社(顧客)から、以前納品したアプリの改修依頼がありました。
ちなみに以前納品したのは、出前が注文できるアプリ。
以下を意識する様にして、どんな要望なのかを聞いてみましょう。
- 課題:今困っている事とその背景
- ゴール:何ができればゴール?
- 課題解決:〇〇を実装すれば解決する?
思っているんです。
どんな機能のイメージですか?
近所でチャーハンが食べられる店を、全て表示させるようにしたいんだよ。
注文数がすごく多いから、できるだけ少ない動線で、注文されるようにしたいからだよ
課題:炒飯の検索効率が悪い
ゴール:少ない動線で近所の炒飯の店を検索
課題解決:炒飯ボタンを付けると動線が減る
開発と【要求定義】をしよう!
顧客の要望を持ち帰って、早速開発にこれを視覚化して伝えます。
させて下さい。要求定義も作って来ました!
ペンギン君が出した「要求定義書」
※改修してどうなれば良いか?のイメージ図をラフな絵で提出して視覚化します。
この様に、開発に依頼する内容の決めを【要求定義】といいます。
そして、その要求をまとめたものを【要求定義書】と呼びます。
開発にイメージが伝わればいいので、最近では、割と自由でラフなスタイルで、やってるとこが多いです。
よくこの要求定義に「ER図」と呼ばれるものが使われますが、この辺の話は長くなるので、また今度!
気になる方は別なサイトで「ER図」を検索してみてください!
タグ付けがないから無理だね。
置いてそうな中華屋だけを選択する事は可能。
炒飯だけのボタンがあるのは、
違和感あるから「おすすめ」みたいに
したらいいんじゃない?
双方の合意を取ろう!(要件)
そして開発と協議した内容を今度は顧客に相談しにいきます。
ペンギン君が出した要件定義書
今度は【要求定義】で決めた内容を、顧客(要望の依頼者)に確認をして合意を取ります。
これを【要件定義】といいます。
視覚化された資料を【要件定義書】として提出して、顧客と協議するのがよくあるやり方です。
炒飯を出すのは仕様上厳しいですが、中華店を一覧表示する事はできます
表示されてるのは違和感があるので、レコメンド機能として、表示するのはいかがでしょう?
落とすとこうなるんだね。ちなみにこれにクーポン機能とかつけれる?
プロジェクトを進めるためにも、そこは次のフェーズで検討する形でいかがでしょう?
OKです。そこはこの開発後に考えましょう。
この仕様で作った場合の見積もりと納期を後ほどお知らせいたします。
以上こんな流れです
以上、これが簡単な要件定義の流れなんですが、イメージできましたでしょうか?
本当は、関係者各位と、もっともっと協議が発生するんですが、解りやすくするために、そこは端折ってます。
一番大事ポイントは、関係者各位と脳内同期がとれている事、認識のズレは、開始直前であればあるほど、リカバリがしやすいんです。
口頭だけでの空中戦では、認識のズレが起きやすいので、視覚化して可能な限り、齟齬を無くしていきましょう!
最後に
営業と技術が対立しやすいのは、とてもこの業界に多い話です。
対立する原因の1つに【要件定義】がなされておらず、コミュニケーションがとれていない、という原因がよく挙げられます。
どういう事かと言いますと、例えばお客からの機能改修の要望があって、それを営業から技術に伝えるとき。
- この機能がないのはありえない
- なんでこんな仕様になってるの?
- とにかく色々連携できる機能を作って
みたいに、あまりにも抽象的な感想や、情報を横流しするだけになりがちなケースが、結構多かったりするんです。
これでは、何故こんな風に思ってるのか?どんな機能をどこまで作れば、この問題が解消するのか?が解りません。
例え、少ないヒントを元に開発しても「顧客が望んだものと違う」と後出しの感想を、繰り返すだけでしょう。
そして、開発サイドが、この状況に腹を立てこうなります。
開発は大喜利ではありませんよ!開発を甘くみるんじゃなぁぁい!
なので・・
要件定義を非エンジニアの方も理解できると、この様な事を防げます。
更に、コミュニケーションも、お客様や他部門の方と取りやすくなるのでお勧めです!
コミュニケーションを
取る為のノウハウよ!
営業の目線を理解する事が大事。
今回の内容をもっと学びたい方はこの書籍がおすすめ!