「要件定義」のまえに、「要求定義」
多くのアクセスがあったので無料化しました
要求定義テンプレも記事内でDLできます。
はじめに
はじめましてUX プランナーのShoty(@shoty_k2)です。
今回は「要求定義」をつかった、UX デザインについてご紹介します。
実践用テンプレートも記事内にて配布しておりますので、参考にしてください。
「要求定義」とは
要求定義とは、「事業や施策によって実現したいこと」です。ユーザーにどのような状態になって欲しいのか・何をしてほしいのか、ビジネスで何が必要なのかなどを取り決めることです。
要求定義という言葉は、もともとはシステム開発の現場では頻繁に使われている単語で、非技術者の企画者がシステムに求める仕様を定義することです。
「要件定義」と「要求定義」の違い
多くの方が「要件定義」という言葉を聞いたことがあるかと思いますが、「要件定義」と「要求定義」の違いについてご存知でしょうか？
★要件定義
-実装すべき機能や満たすべき性能をきめること
-書き方は「〜すべき」
★要求定義
-施策によって実現したい内容をきめること
-書き方は「〜したい」、「〜になってほしい」
当然のことですが、プロジェクトで実現・達成したいことを先に決めて機能を考えていきます。つまり「要件定義」のまえに、「要求定義」をすることが重要になります。
なぜ 、「要求定義」が大切なのか
企業がビジネス、マーケティング、デザイン、テクノロジー....多様な視点を考慮しながら統合的に価値創出していく時代になりました。
とりわけUXデザインもビジネスやマーケティングとは切り離して考えることができません。つまり、多様なメンバーや視点を活かしながら体験設計をしてビジネスを成功に導くことが求められているといえます。
そして昨今はAIから与えられた・引き出した情報をどのように活かし、統合していくべきかというのにも通ずるところがあります。
「要求定義」を実践すると、下記のような効果あります。
★「要求定義」の効果
・メンバーの目線をすり合い、プロジェクトの成功基準が明確になる
・体験設計・デザインの方向性が定まりやすい
このような難しい環境の中で、”プロジェクトが思ったように進まない”といった、プロジェクト推進や価値創出における課題解決をサポートをしてくれます。
力を発揮するプロジェクトタイプ
「要求定義」はメンバー間で意見をすり合わせる時間をじっくり取れない、要求の優先順位が明確になりにくいプロジェクトにオススメです。
★「要求定義」オススメ案件
・短期集中型である
・多数の内部・外部ステークホルダーがいる
・ビジネス、マーケティング、デザインといった様々なチームメンバーが関係する
なぜ、UX Designer/UX Plannerがやるのか
"要求定義は本来、企画がやるべきでは！？”と思われた方もいるかと思います。その疑問に対する答えは、「Yes, but No」です！
極論誰がやってもいいのですが、UX デザイナー/プランナーがリードして要求定義を明確すると、プロジェクトが成功に一歩近づくのではないかと思っています。
UXの領域は顧客体験の可視化にとどまらず、顧客体験設計をつかった戦略の具体化・可視化を行うビジネスデザインまで広がっています。その中で、プロジェクトで実現したことに対してデザインの力をつかって働きかけをする必要があります。
★ビジネスデザイン
ビジネス戦略：顧客規模が大きいのか、儲かるのか、上位戦略と連携できているのか
マーケティング戦略：顧客に選んでもらえるのか、どのようにブランディングしていくか
エクスペリエンス戦略：使い続けてもらえるのか、どんな体験を提供していきたいのか
※ビジネスデザインのために必要な観点は他にもございますが、上流工程でUXデザインに関わりの深い３つに絞っています。
上記の図からわかるように、ビジネスデザインとクリエイティブ・デザインを行き来するのがUX Desinger/UX Plannerです。(青い部分)
上述したようにビジネスデザインを行い、具体的にその要求から「要件定義」をします。そしてデザイナーと共にどのように表現していくべきか悩み、モノを作る中で課題や論点があればビジネスデザインにフェードバックをかけていきます。
このように一丸となって前に進んでいくことが、プロジェクトの成功確率を上げるカギになると個人的に信じています。
やや抽象的な話になってしまいましたが、「要求定義」は新規事業創出からサービスの改善のプランニングと幅広く使えます。
次は、具体的なやり方を紹介していきます。
※ここでのクリエイティブ・デザインは、「デザイナーがそれぞれの要求を、私たちが見たり・触れたりするプロダクトや画面として形づくり、顧客の課題を解決すること」という意味合いで使用しています。
MoSCoWを使った要求定義のやりかた
要求についてディスカッションすると、担当者ごとに"あれも実現したい”、“これもできたらいいよね！”と夢が溢れかえることがあります。
そんなときは叶えるべき要求を、MoSCoWというフレームワークをつかって明文化していきます。
実践用テンプレートを作成しましたので、是非ダウンロードして活用してみてください。
Google スライド/ PowerPoint 版
スライドを開く
PDF版
Figma版
MoSCoWとは？
英語の助動詞のMust/Should/Could/Won'tに頭文字を取った造語です。
これら４つの項目に沿って、要求を優先順位付けします。
Must：必ず満たさなければならないこと
Should：可能であれば、満たすとよいこと
Could：他に影響を与えない限り、満たしても良いこと
Won't：今回は見送り、変更しないこと
ここで非常に大切なことは...
Must：たくさん詰め込むことは厳禁！1〜2つに
-実現したいことが多すぎると、プロジェクトが瞑想します。
Won't：計画的に見送る勇気を！
-計画的にやらないこと、追い求めないことをメンバーで握りましょう。MustとWon'tが並ぶとプロジェクトも輪郭もくっきります。
さいごに
恥ずかしながら、私が「要求定義」という言葉を知ったのは、社会人になって数年後のことでした。
当時プロジェクトがうまく進まないことを同じチームの先輩に相談した際に、教えてもらいました。
まちがなく「要求定義」は、「要件定義」を急いで空回りしていた私への処方箋となりました。先輩には非常に感謝しております。
自戒をこめて
「要件定義」のまえに「要求定義」を。
★応援の印にご購入いただいた方々、誠にありがとうございます。
このnoteが役に立ったらTwitterでシェアしてください!
Twitter: @shoty_k2
昨日より多くの方にアクセスいただいてるようなので、有料記事やめて無料化しておいたでぇ〜
— しょーてぃー / Experience Designer & Prompt Designer (@shoty_k2) June 16, 2023
要求定義のパワポ テンプレも
記事内でDLできるようになってるよ
多くの人に届きますよーに。
「要件定義」の前に、「要求定義」https://t.co/qulIC0D7Bm
↓私について
いいなと思ったら応援しよう！
