fuji

こんにちは、吉岡です。空の写真は、skyseekerさんからお借りしました。素敵な写真ですね。今回の内容とは全く関係ないですが。

今回はUX改善をどのようにスクラム開発に装着させるかについてまとめたいと思います。
UX改善プロセスの手法は「HCDプロセス」という規格にまとめられていますので、まずそのご紹介から。

「HCDプロセス」とは?

HCDとは、Human Centered Designの略で、日本語だと「人間中心設計」と言います。人間にとって使いやすいデザイン・インターフェースをつくっていく、という考え方になります。
そのプロセスは、ISOやJIS規格で標準化されています。

ユーザーにとって価値あるコンテンツを作ったり、ユーザーインターフェースをより使いやすいものに磨き上げるためのプロセス、と私は理解しています。
ここでは、このプロセスを説明しつつ、どうやってスクラム開発に装着するかについて書いていきます。

HCDプロセスの4つのフェーズ

HCDプロセスは、4つのプロセスを循環する循環型プロセスとなっています、「循環型」というところで、ちょっとスクラム開発に似ていませんか?

  • 1.ユーザー利用状況の把握と明示
        * ユーザーインタビューなどして、ニーズを収集、課題(リクルートでは「不」といいます)を洗い出す。
  • 2.ユーザーと組織の要求事項の明示
        * 課題を解決するために、ペルソナ、ユーザーシナリオ、UXフローなどにまとめて可視化します。
  • 3.設計による解決策の作成
        * 解決策を設計に落とし込みます
  • 4.要求事項に対する設計の評価
        * そこで設計したものを、実際ユーザーに触ってもらうなどして、評価します。

4のアウトプットに対し、ユーザーが満足するまで、上記のプロセスを繰り返す、これがHCDプロセスです。
そこで有効性が示された案を、スクラムのプロダクトバックログに掲載すれば、HCDプロセスとスクラム開発が上手く繋がる…はずですが、いくつかクリアしなければならない課題があります。

UX課題の起案時における課題

スクラム開発は、特にエンハンス(運用)フェーズに入ると、ビジネス目標に従って課題を洗い出し、プロダクトバックログに案件リスト(チケット)をまとめ、優先度の高いものから、決まった時間間隔(スプリント)毎に、機能をリリースしていく流れになっていきます。

つまり、プロダクトバックログ上位には、ビジネス上すぐにタッチしなければならない案件(例えば、KPI改善など)が来ることになります。
そこへ、HCDプロセスを経た案件が上位に食い込めるかどうかですが、そのままでは難しいと思います。なぜなら、UX改善施策はKPI改善において即効性のある施策でないことが多いからです。

また、グループインタビューを経て起案をするときのあるある話で、「ヒアリングしたサンプル数が少なくてその意見の妥当性ってあるの?」という疑いの目を向けられる、という話があります。

これらの課題をどうクリアすればいいのでしょうか?

UX課題解決をどう開発につなぐか?

最初の「UX案件がプロダクトバックログ上位に置かれにくい」課題では、UX課題解決がビジネスにとってインパクトがあることを示す必要があります。
それには、今のプロダクトのユーザー行動状況を把握しておく必要があります。UX案件は、ユーザーの行動変化を起こす施策になるからです。

AARRR(※)と呼ばれる、プロダクトを成長させるための指標で、全体のユーザー行動状況をまず把握しましょう。
その次に、注力すべきユーザーのプロダクト内の行動ログを追いかけ、傾向をつかむことが必要になります。こちらのやり方は、クラスタ分析を利用した「UXモニタリング」のようなアプローチでも良いですし、泥臭くユーザーごとのアクセスログから追いかけてもいいと思います。

 ※参考)AARRRモデルとは?|Cybertimes

ユーザー行動の課題について定量的なデータを掘り下げることで、そのUX案件の説得性を補強すると同時に、案件実施後の計測すべきKPIを明らかにするという意味でも、やっておくべき施策になります。

次の課題、「サンプルが少なくて、その課題って本当に事実なの?」という疑いをどうやって晴らすかですが、ユーザビリティの権威ヤコブ・ニールセン博士が2000年に、ユーザーテストは5ユーザーのテストで充分、と提唱されております。(※)

 ※参考)5ユーザーでテストすれば十分な理由 | U-SITE

最近の私の取り組みでは、狩野(かのう)分析法(※)をユーザーインタビューに組み合わせることで、ユーザーが本当に欲しい機能をあぶり出すようにしています。

 ※参考)狩野モデルで要求を分析してみた感想

スクラム開発とHCDプロセスの融合によるメリット

スクラムのプロダクトバックログにはいくつかのフェーズがあると考えています。サービス立ち上げ時は、UVP(Unique Value Proposition,独自の価値提案)から漏れたチケットが大量にあると思いますが、エンハンスが進んでいくうちに、チケットの陳腐化が起きていくと思います。優先度上位のチケットが捌けてしまい、優先度下のチケットが上位に上がってくる状況です。

そんな状況でも、常にユーザーはプロダクトを使い続けていて、何かしら不満を抱えているものです。HCDプロセスとスクラム開発を組み合わせることで、プロダクトバックログの陳腐化を防ぎ、本当の意味でプロダクトの磨きこみができるようになると考えています。

終わりに

駆け足で、UXとスクラムについて書いてきましたが、もっと掘り下げないといけない議論がいくつもあるな、と書きながら感じました。また別の機会に、より深い記事をエントリーしたいと思っております。