UXデザインを要求整理・要件定義へ落とし込む①
開発の現場でUXデザインを実施する上で、気をつけたいのが、デザインしたユーザー体験を、プロダクトまできちんと反映させることです。
エンジニアがUXデザインを行なっている、あるいは、企画のフェーズから並走してくれていれば、プロダクトへ落とし込むことは比較的容易です。
しかし、企画職やデザイナー職、リサーチャーなどの非エンジニア職のみでUXデザインフェーズを行う場合、ユーザー要求をシステム要求へ繋ぎ、システム要件定義ができるようにしなければなりません。
1.連携を分断する組織の壁
企画部や開発部など、担当分野によって部署が異なる会社は結構多いのではないでしょうか？
組織の大小や事業形態（事業会社か受託会社か）に関わらず、コンセプト部分と実際の開発とでメンバーがガラリと変わってしまうことがあります。
同じ社内であれば（かつ、部署間で仲が悪くなければ）、コミュニケーションを密に取ったり、ある程度並走ができれば、そう大きく内容が乖離することは避けられますが、外注する場合や、捌かなくてはいけない案件が多く、完全に分業せざるを得ないなど、どうしても連携が難しい場合があります。
そこで重要になってくるのが、要求整理・要件定義のフェーズです。
2.要求整理で起こる落球
要求整理とは、利用ユーザーの立場で考えてビジネス要件を整理することです。続く要件定義のフェーズでは、この要求整理を基に、機能に落とし込み、その要件定義を基に、具体的にどうシステムを組むのか設計がされ、実装へと繋がっていきます。
外注や、社内でも完全に縦割り構造の場合、この要求整理から、開発ベンダーないし、開発部が入ってくるのですが、会社によっては、けっこうここで落球が発生します。
初期から並走していない場合、開発側は、発注者がどのようなシステムを要求しているのか、ヒアリングに行き、ここで全容を把握するわけで、開発側は当然、利用ユーザーの立場で考えてビジネス要件が整理できたものが発注者から聞けるものと思って進めるのですが、実際には、「利用ユーザーの立場で考えて」の部分が抜けていたり、「利用ユーザー」自体がゴムのユーザーで、ユーザーの実態から乖離していたりします。
また、開発に不慣れな発注者の場合、そもそもどういったビジネス要件を出すべきなのかが判らず、開発ベンダーの力を借りて要件を作成してもらおうと受身になっている場合があります。その場合、事業にあまり詳しくない開発ベンダーが把握していない（あるいはできない）内容のビジネス要件が落ちてしまいます。
こういったことがあると、運が悪いと、開発したもののあまり使ってもらえなかったり、運用コストが高くなってしまったりします。
また、利用ユーザーの立場で考えるのはモノが出来上がってからにしようと、テストのあたりで、初めてユーザー評価を実施する現場がたまにあるようですが、こういった現場ではユーザー評価の結果を受け、リリース日が迫っている中急遽変更が入ったり、「実はユーザーの実態に合っていないのでは？」と思いながらリリースを迎える、悲しい事態になります。
こういったことが起こらないよう、UXデザイナーが企画の早い段階から入り、実装に入るまで、ある程度並走・ハンドリングを行うのが大事なのではないかなと思います。
3.要求整理とUXデザインはどう関わるのか
要求整理とは、利用ユーザーの立場で考えてビジネス要件を整理することと先に述べましたが、ここがまさにUXデザインの部分かなと思います。
UXデザインは、UIデザインやユーザビリティの文脈で語られることが多いので、エンドユーザー寄りのイメージがある方もいらっしゃるかもしれませんが、実際にはビジネスとして成立をさせなければいけないので、エンドユーザーのみ見るのではなく、ユーザーの要求に合っている、かつ、自社（受託の場合はクライアント）が強みを発揮できるところでサービスを考えていきます。
UXデザインのフェーズで言うと、前半戦のユーザー調査が終わり、ユーザー体験設計に入った最初のところにあたります。
ここで一旦、ユーザーと自社のビジネスのwin-winになるところを考えることで、要求整理に繋がります。
私は、構造化シナリオ法を用いることが多いのですが、構造化シナリオ法のバリューシナリオ作成の際に行います。また、シナリオの文字文字しさが嫌厭されるシーンもあるので、合わせてValue Proposition Canvasを使って図式化をして、把握しやすくすることもあります。
4.「ユーザー」という言葉の罠
さて、「ユーザーと自社のビジネスのwin-winになるところを考える」という話をしましたが、具体的にユーザーとは誰でしょうか？
開発系の本を読んでいると、「ユーザー」という言葉に首を捻ることがある。「ユーザー ＝ エンドユーザー」ではなく、「ユーザー ＝ クライアント」の文脈で書かれていることがしばしばあるからです。
対して、UXデザイナーは「ユーザー ＝ エンドユーザー」で考えがちなので、エンジニア畑の方と話していると、時々会話が噛み合わないなという時があり、訊いてみたら「ユーザー ＝ クライアント」で相手は話をしていた、なんてこともありました。
どちらが間違い、ということはなく、「ユーザー」と一口に言ってもいろいろあります。
ISO/IEC 25010:2011によると、ユーザーには、直接システムを操作する“直接ユーザー”と、直接システムを操作しないが出力を受け取る“間接ユーザー”があり、直接ユーザーの中でも、“一次ユーザー”とメンテナンスを行う“二次ユーザー”がいます。
例えば、クライアント企業の社内の経費精算システムの開発であれば、下図のように、社員の誰かがどこかのユーザーに当てはまるので、「ユーザー ＝ クライアント」と言えるでしょう。
ECサイトなど、BtoCサービスの場合は、エンドユーザーが触るものと、ビジネスサイドのユーザーが触る管理画面と一次ユーザーにも、2種類のユーザーがいます。
このように、何のサービスを提供するかで、ユーザーが何種類いるか（※ペルソナではなくユーザー）を明らかにした上で、各ユーザーに受け入れられるものを設計・製造していく必要があります。
私は現在、PHRのアプリをつくる機会が多いのですが、ものによっては、ユーザーのパターンが多いです。コミュニケーションの齟齬を起こさないよう、「ユーザー」というざっくりしたくくりではなく、「どのユーザー」かで話すように最近はしています。
どんなユーザーの種類がいるのかは、UXデザインでは、多くの場合、一番初期のユーザー調査の前のビジネス要件定義の段階で行います。（まったく未知の新しい分野の場合は、どんなユーザーがいるのかをまず調査してみる、と言うケースもあります。）
逆に言えば、開発を外出しする場合、開発メンバーが入るのはユーザー評価以降になるため、UXデザインを行なっておけば、要求整理の段階で、「利用ユーザーの立場で考えてビジネス要件が整理」された状態になっているはずなので、あとは、UXデザインでカバーできていない、システム独自に関わるものを明確化していけば、精度の高い要求整理ができあがります。