- シェルフィー株式会社
- プロダクトマネージャー
- 緒方 周平
数値データだけでは不十分!サービス開発で失敗しないための、ユーザーヒアリングとは
今回のソリューション:【ユーザーヒアリング・行動観察】
〜シェルフィー株式会社が、ユーザーヒアリングや行動観察を用いて、サービスの改善を進めている事例〜
サービス開発で失敗をしないためには、「ユーザー」を知ることが不可欠だ。Webサービスやアプリにおいて、その一番簡単な手段は、解析ソフトを使って、ユーザーの行動を「数値データ」として見ることだろう。
だが、シェルフィー株式会社でプロダクトマネージャー(PM)を務める、緒方周平さんは、「そのような数値データだけでは十分ではない」と語る。
店舗オーナーと内装業者のマッチング事業である「シェルフィー」のようなBtoBのサービスでは、BtoCと比べるとユーザーの数が少ない分、その傾向は顕著だという。
今回は、緒方さんと、同社でデザイナー 兼 Webマーケターを務める石川鉄平さんに、同社での「ユーザーヒアリング」と「行動観察」の取り組みについて、詳しくお話を伺った。
デザインはあくまで手段!「目的」も考えるデザイナーに
緒方 大学時代に友人と会社を立ち上げ、そこで3年ほどデザイナーをしていました。弊社には2年ほど前にデザイナーとして入社しましたが、スタートアップなので、やることの幅がどんどんと広がっていき、いまはプロダクトマネージャー(PM)を務めています。
石川 僕は美大出身で、大学卒業後はWebも紙媒体も、そして内装もやるデザイン事務所で、デザイナーとして2年ほど働きました。
シェルフィーには昨年の10月に入社して、肩書きは一応デザイナーなのですが、いまはWebでの集客、いわゆるWebマーケティングを中心に担当しています。
緒方 結局のところ、デザインは「手段」でしかなく、何のためにデザインをするのかという「目的」の方がより重要です。
石川にとってのデザインの目的はWebでの問い合わせを増やすことですし、僕の場合は、プロダクトを成功に導くことです。弊社では、デザイナーがその「目的」の部分も考える形で役割を持っています。
建築業界の「プロジェクト管理」の課題を解決するために
緒方 今回僕が「ユーザーヒアリング」に取り組んだのは、弊社で開発しているプロジェクト管理ツールの改善のためです。
弊社は、店舗を運営されている方と、内装業者さんのマッチングを主事業としています。
その事業を進める中で、建築業界はクライアント、設計・施工会社の他にも電気、水道といった専門業者や不動産関係者など、1回の工事に関わるステークホルダーが多く、そのためにコミュニケーションや予定調整に課題があることが分かってきて…。
その部分の課題を解決するために、チャット、スケジューラー、ファイル共有システムを備えた「プロジェクト管理ツール」の開発に踏み切ったんです。
▼ 「プロジェクト管理ツール」の実際の画面
実際にβ版を使ってもらい「ユーザーヒアリング」を実行
緒方 開発が決まったのは2015年9月でしたが、最初は紙に手書きでプロトタイプを作って、お付き合いがある業者さんに、「こんなのどうですか?」とヒアリングをしました。
ただ、建築業界は必ずしもITに親しんでいる方ばかりではないので、紙上ではイメージが湧かなかったらしく、あまり有益な情報は得られませんでした。
そこで3ヶ月ほどでβ版を作って、実際にテストプロジェクトを回して使ってもらいながら、ヒアリングする方式に切り替えました。
BtoCではよく使われるプロトタイピングツールも一度使用してみたのですが、こちらが設定したひとつの導線が中心になってしまうところがあってユーザーの行動を規定しすぎてしまうので良くないな、と。
今回のような複雑なプロダクトにはプロトタイピングツールは向かないと思ったので、バックエンドまで実装したβ版を作成してからヒアリングをすることにしたんです。
全ターゲットに漏れなく対応できるよう、セグメント化する
緒方 弊社の場合、ペルソナ(※ターゲットユーザー)は、すでにお付き合いがある設計や施工の業者さんたちだったため、新たに考える必要はありませんでした。
ただ、プロダクトをすべての業者さんに抜け漏れなく対応できるものとするため、業者さんを「会社規模の大小」「ITと親しんでいるか否か」の2軸で4つに分類して、それぞれから1社ずつ、ヒアリングを行いました。
従業員数が100名以上でITツールを普段から使うような会社さんと、従業員が5名以下でITに苦手意識を持っている会社さんとでは求めるものが全く違うからです。
単に要望を聞くことより、ユーザーの目線に立つことが重要
緒方 とはいえ、そこでいただいた全ての要望を反映するわけではありません。そもそも業者さんごとに業務フローが違うので、全ての要望を吸い上げているときりがない。
▼ 実際にあがった要望を整理したスプレッドシート
さらにいうと、そもそも僕たちには、建築業界にITを取り入れて、業務を効率化していきたいという思いがある。すると現にあるフローに基づいた要望を、全て吸い上げていては目的が達成できません。
そういった意味では、ユーザーの要望よりも、自分たちが考えたプロダクトの「あるべき姿」を優先しなければならないんですね。
ただ、その「あるべき姿」だけでは、今度は逆に独りよがりになってしまうので…。それをユーザーの現実とすり合わせるために、ユーザーヒアリングがあるのだと考えています。
そこで重視していたのが、言葉としてでてくる無数の「要望」に注目するのではなく、ユーザーの生活リズムや仕事環境に注目して、「ユーザーのライフスタイルを理解する」ことでした。
多くの「質問項目」よりも、「雑談」にこそ突破口がある
緒方 もちろん、ヒアリングにあたって「質問項目」は用意していくのですが、「ユーザーのライフスタイルを理解する」という観点では、ひたすら質問を繰り返すよりも、雑談をして、業界の愚痴なども含めていろいろと聞いていく中でこそ、見えてくるものが多かったです。
例えば、業者さんの中には、1日に一度もPCを開かず、連絡はスマホのLINEで行うという人もいた。ITに親しみがない人は、仕事においてはスマホよりPCを使うのではと思っていたのですが、それが偏見だったと明らかになったんです。
そこで、もともとプロジェクト管理ツールはPCベースで考えていたのですが、スマホも重視するよう方針を変更しました。
他に、ユーザーヒアリングをもとに行った改修としては、閲覧権限の設定機能の追加ですね。
多くのステークホルダーがいるなかで、「見積書はお客さん以外には見せたくない」「専門業者には該当工事の情報だけ見せたい」といった、「どの情報を誰に見せて良いのか」という部分は、建築工事においては非常にクリティカルな問題であることが分かりました。
お問合せ用のLPの最適化のために「行動観察」を実施
石川 僕は「行動観察」を担当しています。緒方による「ユーザーヒアリング」は、すでに弊社へ問い合わせたお客さんと業者さんが使う、ツールについてのものです。
それに対して、僕がやっている「行動観察」は、まだ弊社のサービスを利用していない、潜在顧客である店舗さんなどが、Web上で弊社にお問い合わせをするLP(※ランディングページ)について実施しています。
お問い合わせをしようと思ったユーザーが、登録フォームなどで離脱せず、しっかりお問い合わせを完了できるようなページを作っていくために「行動観察」を行っています。
アナリティクスだけでは仮説と施策の正しさを確かめられず
石川 以前は、Googleアナリティクスの数値データを見て改善を行っていたのですが、それだと、どのページがユーザーが離脱するネックになっているかは分かっても、「なぜそうなのか」がわからないんですよ。
もちろん、そこについて仮説を立てて改善の施策を実施するのですが、弊社のようなBtoBの事業の場合、BtoCの事業のように、何万というユーザーがやってくるわけではないので、施策の効果も数字としてすぐに出るわけでもなく…。
結局、仮説と施策が正しかったのかがよくわからなかったんです。であればユーザーに直接聞くことで、仮説と施策をより正確に検証できるのではと考え、「行動観察」を始めました。
「行動観察」を実施する上での、様々な工夫とは?
石川 対象は、以前実際にお問い合わせをしてくださったお客さんたちです。実際にお問い合わせをした人こそ、弊社がそこに仕様を合わせるべき最適なターゲットだと考えたためです。
そのような人たちに、「どんな悩みを抱えていて、どんな検索ワードで弊社のLPにやってきたのか」ということを再現するため、お問い合わせ当時の状況を思い出してもらい、状況を事細かに設定していきます。
その上で、「自然な行動を観察したいので、普段しないことは絶対にしないでくださいね」と何度も念押しします。
ただ、それでもやはり気を遣ってなのか、みんな頑張ってくれて、今のところ全員が離脱せずにお問い合わせにまで到達しています(笑)。
「それでは無意味じゃないか」と思われるかもしれませんが、そうではありません。「思考発話」という方法を用いて、行動観察中、考えていることをそのまま言葉にしてもらっていて、それを録音しているんです。
例えばちょっと画像が多いページだと、「このページはなんだろう…」「自分は何をすれば良いのか分からない…」といった声がよく聞かれました。
さらに、画面も録画しているので、行動観察終了後、つまずいていたところを中心に「ここどうだったんですか?」みたいに質問をしています。すると、LPの問題点を洗い出すことができるんですね。
その結果、例えば、工事の希望時期を入力するフォームが改善されました。カレンダーで期間の始点と終点を入力する形式にしていたのですが、みんなつまずいていたんです。
そこで、プルダウンで時期を選ぶ形にUIを先祖返りさせました。ユーザーのITリテラシーに合わせて、あえて「UIを退化させる」ということも弊社ではよく行います。
他にも、ページのセクション間の余白が大きすぎると、それでページが終わったと思ってしまって、ユーザーがそれ以上スクロールしないという事実など、実際に見なければ分からない離脱の要因が判明しました。
BtoBサービスでは「数値データの分析」では足りない!
緒方 いま、石川が言ってくれた、「数値データ」の不十分さというのは大事な視点だと思います。BtoBサービスは、コンバージョンあたりの収益が大きい代わりに、BtoCサービスと比べてユーザー数が少ないという特徴があります。
そのため、数値データの分析では、改善施策のための仮説立てにも、施策の効果検証にも、十分な母数が集まりにくい。
ただその代わりに、BtoBサービスでは、対面での面談や、継続的な取引などのおかげで、お客様と強固な関係ができていることが多いと思います。逆にBtoCだと特定のユーザーとそこまでの関係性を築くのは難しいですよね。
であれば、その特性を活用して、まさに自社にとってターゲットど真ん中であるお客様に、いろいろと尋ねることで、数値データの不十分さを補うことができると思うんです。
弊社としては、今後とも、ユーザーヒアリングや行動観察など、ユーザーと直接触れる調査の手段を活用し、建築業界を深く理解した上で、ITの力と人ならではの力をうまく使って、業界に変革を起こしていきたいと思っています。(了)