デザイナーが解説する要件定義段階における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点が重要です。

1. UX要件定義というフェーズを設ける
   UX要件定義の後、業務要件を定義してそれぞれプロトタイプにアウトプットすることでUX/UIを意識した要件定義が可能になります。
2. UXデザインプロセスを活用する
   ユーザーの本質的な要望やユーザーにとっての価値を明確にすることができます。
3. UX/UIデザインに必要なスキル・経験をもつ
   メンバーのロールに関係なく、UXデザインのプロセスに必要なスキルと経験もって関わることで、よりよいサービスをつくることが可能になります。

UXデザインのご相談はNCDCへ

これから新しいシステムを企画していく方（発注者となる方）、とくに古いやり方を変革し、よりよりUX/UIデザインを取り入れたシステムを実現したい方にとって、ここで紹介した要件定義の進め方は有効な手法の一つになると思います。

NCDCではUX重視した要件定義から実装まで、ワンストップでサービスを提供しています。
デジタルを活用した新規サービスの開発はNCDCの得意分野なので、もし課題をお持ちの方がいればぜひご相談ください。UXデザインコンサルティングやモバイル・WebアプリのUX/UIデザイン、UXを重視したモダンなアプリの開発までニーズに応じたご支援が可能です。

また、最近はさまざまな業務用ツールの内製化に取り組まれている企業も多いようで、自社でシステムの設計をするために、UXデザインの基礎知識を知りたいというご相談も増えています。
今回は要件定義にポイントを絞ってお話しましたが、UX/UIデザインに関するもっと多くの知識をお伝えするための研修などもサービスとして提供しています。
こうした内容を社員研修や内製化プロジェクトの一部として取り入れたい方も、ぜひご相談ください。

セミナー資料公開（無料）

本記事は、2022年1月20日に実施したオンラインセミナー「デザイナーが解説する要件定義段階におけるUX/UIデザインの取り入れ方」の内容をもとに要点を解説しています。

セミナー動画やセミナー当日に用いた資料（スライド）は下記リンクからご覧ください。

動画で見る

UX要件定義に関する質問と回答

セミナー「デザイナーが解説する要件定義段階におけるUX/UIデザインの取り入れ方」では、多くのご質問をいただきました。公開できるものをピックアップしてここでご紹介します。（なお、ご質問の文言は当社で編集しています）

UX要件と機能要件の関係

回答
いずれもご質問いただいた通りです。UXを実現するための一要素としての機能となるため、UXを上位として考えます。また、機能を先に決めてしまってその制約の中でUXを考えると「解決策の幅が狭くなる」といえます。
まず「ユーザーにとっての価値がなにか」を明確にして「UX要件」を検討したうえで、次に他の要件を肉付けしていくことで、ユーザーにとって価値あるサービスをつくりやすくなると考えています。

UX重視の要件定義にかかる期間

回答
UX要件定義のフェーズだけで考えると、最短で1日で行うことも可能です。しかし、当然ですが検討範囲は狭く、精度は低いものになります。時間を掛ければかけるほど検討範囲が広く、精度が高くなります。
弊社の参画事例の多くはUX要件定義フェーズで3ヶ月程度かけることが多いです。1日で行う場合は、本当の要件定義を行うというよりは「UX要件定義のやり方を体験してみる研修」というような位置付けで行い、その後もお客様側で継続的にUX要件の検討に取り組んでいただくようなかたちが多いです。
スモールスタートするための具体的な工夫をひとつ挙げると、ペルソナの数を絞る（本来複数必要な場合でも最優先のペルソナひとつだけではじめてみる）という方法が考えられます。

既存サービスの改善への適用

回答
既存サービスや製品の改善事例もあります。基本的にはプロセスは変わらず、UX要件の再定義も業務要件の再定義も行います。しかし、どの程度しっかり時間をとってプロセスを回すかは目標とする改善レベルに依存します。
軽微な改善であれば簡易的なプロセスとなりますし、しっかりした改善目標であれば、セミナーでご説明したレベルでのプロセスを回す場合もあります。
また、既存サービスのUI改善のようなプロジェクトであればヒューリスティック評価という簡易的な改善の方法があります。 セミナーでご説明したようなUXデザインプロセスは用いず、専門家の知識や経験則を用いてUIを改善する方法です。

UX要件定義の進め方

回答
ご質問にあるクライアントとは支援先企業のことを指しており、その先に使用者（ユーザー）がいると仮定して回答します。
当社では、UX要件定義はクライアントと一緒に作業しながら進めていきます（ワークショップ形式と呼んでいます）。したがって、何かかたちができた後でクライアントに確認するのではなく、常にクライアントの確認を入れた状態で進めています。別途確認をする必要はありません。
そしてクライントとの仮説が正しいかどうかはワイヤーフレーム作成後にユーザーテストを行うことで検証します。

回答
もちろんさまざまな制約はあると思いますが、ペルソナやインサイトを共有する必要があるメンバーにはできるだけワークショップの場には参加頂いたほうが良いです。
参加できない場合は後で資料だけ渡すのではなく、ワークショップの議論内容を常に共有していく方が良いと考えています。

回答
その段階で分離をする必要はありません。

回答
弊社の定義しているプロセスの「目的の共有」は最上位の施策の目的を共有するということです。そしてその共有した目的はいつでもどこでも見られようにするという工夫をしています。
ご質問にある目的共有の難しさはもしかすると弊社が定義している目的よりも少し下位、もしくは具体的な目的かもしれません。そのレベルの目的はワークショップを通じて共有していくことが有効だと思います。

回答
プロトタイプによるユーザーテストにて判断します。

ペルソナについてのご質問

回答
使用対象者全てのペルソナを定義する必要はありません。戦略的にターゲットとしたいユーザー層など、特別で快適なユーザー体験を与えたいユーザー層についてペルソナを定義します。そして、戦略的にターゲットとしたユーザー層にも優先順位があると思います。その順番に従って定義することが大切です。

ペルソナの数が増えればジャーニーマップも増えるため、すべてを検討するのは現実的ではないケースもあります。ペルソナをいくつつくるのが妥当かという数の基準はありませんが、ペルソナやジャーニーマップづくりにかかるコストと得られる効果を考慮して判断することはできるのではないでしょうか。

ユニバーサルサービスの場合も基本的な考え方は同様です。
身体的な弱者などへの配慮が必要なケースも多いと思いますが、そうしたユーザーが主要層ではない場合はUX要件定義の対象として優先的には考えず、セミナーでご紹介した業務要件定義のプロセスで要件を補完することが良いと思います。

その他のご質問

回答
基本的には計画段階からUX要件について計画しておくべきです。全てのサービスにUX要件が必要かどうか？重要度はどのくらいか？は個別に異なると思いますし、サービスオーナーの思想によっても異なると思います。一般論として、ユーザーのUXへのニーズは高くなっていると思いますので、その市場のニーズをどのように捉えるか、言い換えると経営判断の領域かと思います。

回答
セミナーでは要件定義の結果が仕様書になるという前提でご説明しています。
UX要件、業務要件のプロセスが進んで行くに従い、仕様書はブラッシュアップ・更新されていきます。

回答
基本的な観点、プロセスはセミナーでご紹介したものと同じと考えています。UXデザインはアプリやサービスだけに特化したものではありません。
また多くの場合、WEBサイトやLPは何かのサービスに関連するものであり、そのサービスのUXを構成する一部になっているはずです。ユーザーとそのサービスの複数あるタッチポイントの中で、WEBサイトやLPがどう貢献すればサービス全体での体験をより良いものにできるかを考えるのが大切だといえます。

回答
一般的なデザイナーの仕事よりもかなり幅広い範囲を担当するので、細かいプロセスの理解や、そのプロセスにおけるユーザー体験のヒアリング実施、ファシリテーション能力などが必要であるのが大変なところです。

以上、弊社主催のセミナー「デザイナーが解説する要件定義段階におけるUX/UIデザインの取り入れ方」でいただいたご質問と回答を紹介しました。皆さまの参考になれば幸いです。