2022年1月20日にオンラインセミナー「デザイナーが解説する要件定義段階におけるUX/UIデザインの取り入れ方」を開催いたしました。
この記事では当日用いた資料を公開し、ポイントを解説しています。
要件定義における課題の変化
従来の要件定義において主に問題とされていたのは、要件の認識齟齬や漏れなどでした。こうした従来の問題にはさまざまな対策が考えられている一方、最近は下記のような新たな課題が出てきています。
- サービスに重要な要件の取捨選択が難しい
- システム企画者の要望は満たしているのにユーザーの評価が得られない
この問題を解決するために必要なのは、「ユーザーへの価値を定義」することで、そのための「UXデザインによる要件定義」という手法をご紹介します。
NCDCの考えるUX要件定義とは？
NCDCではUX要件定義というフェーズを明確に設けることが、優れたUXを提供するサービスを作るためのポイントだと考えています。
そこで、要件定義を行う中で、まず「UX要件」というものを定義し、その後「業務要件」を定義するという方法をとっています。
なお、「業務要件定義」の意味合いはコンシューマ向けのサービスの場合は「その他すべての範囲の要件定義」と同義であると捉えてください。以下文中では一律に「業務要件定義」として説明します。
UX要件は「ユーザー（ペルソナ）にとって高い価値のある機能」という言葉に言い換えることもできます。それに対して、業務要件はシステムに関わる人全てに必要な機能や、法律、業務ルール上必須な機能であるといえます。
一例として、シフト管理業務アプリケーションをUX要件と業務要件の観点から考えてみます。
UX要件としては「希望シフトや人件費を基準にシフトの自動調整をする」といった、シフト管理者の負担を減らすための機能が考えられます。
その場合、業務要件は、シフト管理者にとって当たり前に必要な「各スタッフの登録」「希望シフトの提出」「連続勤務防止設定」といった機能が挙げられます。
つまり、ユーザーにとってこのサービスを使う価値が生まれる機能がUX要件、サービス自身の実現に必要不可欠な機能が業務要件というイメージです。
UX要件と業務要件を分けて考えることで、下記の通りそれぞれの目的を明確にして議論することが可能になります。
- UX要件ではユーザーへの価値を提供することにフォーカス
- 業務要件では必要な機能をもれなく実現することにフォーカス
そして、UX要件というテーマを意識することがユーザーにとっての価値を考える機会にもなるので、サービス全体のUXが向上すると考えられます。
また、「ユーザーにとって高い価値のある機能」という判断軸が明確となり、最初に挙げた「システム企画者の要望は満たしているのにユーザーの評価が得られない」といった問題の解決が可能になります。
UXデザインを取り入れた要件定義のプロセス
NCDCでは以下のUXデザインプロセスを使用してUX要件を定義しています。
①目的の共有
最初に行う「目的の共有」は、プロジェクトの目的を明確にして合意をするプロセスです。
特別なことはしませんが、非常に重要なプロセスです。何を目的とするのかを関係者間で明確に共有し、最初の段階で認識の齟齬を防ぐことで、後々のプロジェクト進行がスムーズになります。
②ペルソナ
「ペルソナ」とは、ユーザーの典型的なパターンを想像するため、仮想の個人像を「ペルソナ」として定義するプロセスです。
③カスタマージャーニーマップ
「カスタマージャーニーマップ」とは、先に定義したペルソナの行動と、その時の思考を想像し、一つのストーリーとして書き出し、ペルソナの行動・思考を可視化することです。
「ペルソナ」「カスタマージャーニーマップ」については以前の弊社セミナーの中で詳しく説明していますので、ご興味があればこちらのレポートも併せてご覧ください。
資料公開｜実践で違いを生むUX知識「カスタマージャーニーマップの本質とは？」
④インサイト分析
「インサイト分析」は、カスタマージャーニーマップから「ユーザーが無意識に持っている欲求」や、「ユーザーの本音」を導き出すプロセスです。
想像したペルソナの行動や感情から、ペルソナがなぜこの行動にいたっているのか？なぜこうした感情になったのか？をさらに想像して書いていきます。
この部分がサービスの改善の手がかりになります。
⑤UX要件一覧
「UX要件一覧」はカスタマージャーニーマップとインサイト分析から、ペルソナの本音や思考に応えるための解決策を抽出するプロセスになります。ここで具体的な機能のアイデアを抽出し整理します。
UX要件を一覧化する際には、より具体的な機能、期待できる効果や目的、開発の実現性などの軸を設けて、サービスに実装するべき機能を取捨選択していきます。
⑥プロトタイプ
最後に、ユーザーの価値を実現するための「プロトタイプ」を作成して、実際に検証する段階になります。
NCDCではソフトウェアやアプリケーション開発の場合、繰り返し改善と検証を行いやすくするため、主にワイヤーフレームで検証するケースが多いです。
ここで可能な限り検証と改善を繰り返すことで、より良いUXを提供することが可能になります。
漏れを防ぐための業務要件の定義
UX要件定義ができたら、さらに業務要件の定義を行います。
ここからは、システム使用者全てにとって必要な機能を定義する必要があります。
業務要件定義では、UX要件定義の内容を参考にしつつ、漏れがないようにヒアリングや業務フロー・ルールなどから要件を定義していきます。これらを全て整理して、UX要件定義のプロセスと同じようにふたたび解決策を検討します。
業務要件の定義を行う際は、UX要件定義の結果をベースにする以外は、従来通りのすべての要件を洗い出すようなやりかたで問題ありません。
その後作成する業務要件のプロトタイプは、UX要件定義で作成したプロトタイプに合体させます。この時、せっかく先に検証したUXを破壊してしまうような変更をしないように注意して作成します。
以下はUXデザインによる要件定義を取り入れた6ヶ月間のプロジェクトスケジュールの例です。
こちらの例では6ヶ月のうち、最初の2ヶ月でペルソナの理解に努め、残りの4ヶ月でUX要件と業務要件を明確にしていきます。
プロジェクトにもよりますが、UXを重視する場合はスケジュール全体の大体60％程度を目安にUX要件定義フェーズを設けるとよいのではないかと思います。
UX要件定義に必要な体制
UXデザインを取り入れた要件定義をうまく進めるためには、メンバーのスキルや知識も重要です。
NCDCの場合、要件定義段階では主にコンサルタントとデザイナーがプロジェクトに参画することが多いです。プロジェクトによってはエンジニアが入る場合もあります。
コンサルタントとデザイナーが完全分業するのではなく、可能な限りメンバーが全てのプロセスに関わるところも特徴として挙げられます。
図にあるように、一般的にコンサルタントはプロセスの上段が得意領域でデザイナーは下段を得意領域としています。ですがNCDCでは、関わるメンバー全てがこのプロセスに対して一定の知識と経験をもってプロジェクトに参加しています。
こうして完全分業せずチーム全体でカバーすることで、それぞれが持っている知見やスキルを活かしながらUXデザインを取り入れた要件定義が可能になります。
まとめ
ユーザーの本当の要望を満たすためには以下の3点が重要です。
- UX要件定義というフェーズを設ける
UX要件定義の後、業務要件を定義してそれぞれプロトタイプにアウトプットすることでUX/UIを意識した要件定義が可能になります。 - UXデザインプロセスを活用する
ユーザーの本質的な要望やユーザーにとっての価値を明確にすることができます。 - UX/UIデザインに必要なスキル・経験をもつ
メンバーのロールに関係なく、UXデザインのプロセスに必要なスキルと経験もって関わることで、よりよいサービスをつくることが可能になります。
セミナーではこのあと質疑応答のコーナーがあり、セミナー終了後もたくさんのご質問をいただきました。多くの方の参考になりそうな良いご質問が多かったので、別の記事でまとめてご紹介しています。
ぜひ併せてご覧ください。
UX要件定義に関する疑問を解決
UXデザインのご相談はNCDCへ
これから新しいシステムを企画していく方（発注者となる方）、とくに古いやり方を変革し、よりよりUX/UIデザインを取り入れたシステムを実現したい方にとって、ここで紹介した要件定義の進め方は有効な手法の一つになると思います。
NCDCではUX重視した要件定義から実装まで、ワンストップでサービスを提供しています。
デジタルを活用した新規サービスの企画やアプリの開発はNCDCの得意分野なので、もし課題をお持ちの方がいればぜひご相談ください。
また、最近はさまざまな業務用ツールの内製化に取り組まれている企業も多いようで、自社でシステムの設計をするために、UXデザインの基礎知識を知りたいというご相談も増えています。
今回は要件定義にポイントを絞ってお話しましたが、UX/UIデザインに関するもっと多くの知識をお伝えするための研修などもサービスとして提供しています。
こうした内容を社員研修や内製化プロジェクトの一部として取り入れたい方も、ぜひご相談ください。
