2020年2月10日（月）のオンラインセミナーでは、営業支援AIシステムの開発や日本初のAIニュースメディア「AINOW」の立ち上げ〜グロース、AIに特化したアクセラレータープログラム「AI.accelerator」にて技術担当のメンターを務めるなど、AI領域で活躍される傍ら、UXデザインの専門家でもある ディップ株式会社 亀田さんにご登壇いただき、データ/AI領域においてもUXの考え方が重要であるということを、ご自身が経験した失敗談も交えてお話しいただきました。

UXデザインを活用した仮説から考えるデータ分析とは？

本日は「データサイエンティストを目指す方必須！UXデザインを活用した仮説から考えるデータ分析とは？」というテーマでお話していきます。まず簡単に自己紹介です。

私は「ディップ株式会社」という会社で、後ほどご説明する「dip Robotics」という攻めの情シス(情報システム)部隊の責任者をしている亀田と申します。人間中心設計専門家という資格を持っているのですが、普段はUXデザイナーとして外部等で活動しています。

経歴としては、最初の4年はプログラマーとエンジニア、さらにはアプリのプロダクトオーナーも経験しました。その後、新規事業の立ち上げを行い、近年はAINOWという人工知能のニュースメディアの立ち上げや、AIの開発、あとはデジタルトランスフォーメーションのプロジェクト責任者を務めるなど、テクノロジーをビジネスに活かすようなことをしている人間です。

そしてディップという会社ですが、最近では乃木坂46を起用したCMでもおなじみのバイトルという情報求人サイトを運営しています。簡単に会社の紹介をさせていただくと、弊社は「Labor force solution company」ということで、人・AI・RPAの両面から労働力を供給している総合商社です。

ホームページでは弊社のロゴで遊ぶこともできて、スマホではなぞったときにロゴがインタラクティブに変化します。お時間がある方はぜひ遊んでみてください。

その他にも「AINOW」という人工知能のニュースやメディアも運営していますので、ご覧いただければと思います。

What’s Robotics?

先ほどお話したRoboticsですが、この組織はUXを中心に考えて営業支援を行う、企画から開発もできるスペシャリスト集団ということで活動しています。バイトルのための営業パーソンは約1,700人いるのですが、その営業パーソンを支えている組織です。

本日は営業支援システムを行っている中で失敗したことを話しながら、仮説の話をさせていただければと考えています。

よく「情シスとの立ち位置はどうなっているのか？」とご質問いただくので簡単にまとめてみました。弊社の場合は情シスがインフラの守りを固めるもので、RoboticsはAIや最新テクノロジーで攻めるもの、というポジションをとっています。このような立ち位置になっています。

本日は仮説の話を中心に進めていきますが、分析者ではない方にも参考になる内容です。全ての職種の方に通じるお話ですので、ぜひご覧いただければと思います。

本日のアジェンダは大きく3つありまして、

• AI開発プロジェクトの失敗事例
• 仮説の作り方
• UXデザインを活かしたプロジェクトの挽回例

という構成でお話します。

前半は営業支援を行うときに失敗したAIプロジェクトの事例をご紹介して、そこで学んだ仮説の作り方をお伝えします。後半のパートでは、仮説を活かしてどのようにAI開発のプロジェクトを立て直していったのか、その挽回の事例をお話ししたいと思います。

その中でUXデザインが大事だったなと改めて思うこともあったので、UXデザインのお話もさせていただきます。

---

【無料ダウンロード】ユーザビリティテストの基本

数あるUXリサーチ手法の中でも最初に始めやすい「ユーザビリティテスト」の「基本的な設計・実査・分析の流れ」と「実施の進め方や注意点」を解説します。

ユーザビリティテストの基本 を見てみる＞＞

約1,000プロジェクト

事例に入る前に、まず「約1,000プロジェクト」という数字が何か分かるでしょうか？実はこれは、今まで失敗したプロジェクトの数です。新規事業やアイデア出しなど諸々含めての数ですが、とりあえずたくさん失敗してきました。

「スライドを作ってプレゼンしたけどダメだった」「ランディングページを作ったけど全く応募者が来ない」「プレスリリースが出て、何ヶ月も用意して作ったのに応募者・登録者数が10人」こうしたものもたくさんあって、その中でどうしたら上手くいくのかずっと考えてきました。

その中で「仮説の生成」がとても重要だと気づいたので、本日はそのお話をさせていただきます。PDCAを回すなど仮説の検証はたくさんあるのですが、まずは一番はじめの仮説生成が大切だということです。

営業支援AIの失敗

ここからが前半のパートで、営業支援AIの失敗の話をしていきたいと思います。どのようなことをしたプロジェクトかというと、「営業の生産性向上に繋がるAIを作成できないか？」という依頼が来たのです。

確かに私自身このようなものがあれば欲しいなと感じましたし、営業パーソンは日本にたくさんいるので、完成したら外販したいなと思ったほどワクワクしました。そういうわけでプロジェクトを進めていくことになります。

当時はちょうど2016年頃でしたので、ワトソンなどの海外のAIやGoogleのテンサーフローが出てきて、ディープラーニングも流行った時期でした。「AIだと何かできそうだな」という思いもあり、とても期待してプロジェクトを開始したわけです。そんなプロジェクトのお話をこれからしていきます。

簡単にプロジェクトのおさらいをしたいと思います。AIの開発は色々なやり方がありますが、私たちは以下の図のようなう5つのステップで行っています。実装の前の4ステップが長いのですが、現在はこのような流れで開発していますね。

この流れをもう少し細かく見ていくと、さらに以下の10個のステップに分けられると考えています。

これはAIに限らず、分析系の課題は全てあてはまるのではないかなと思います。この中で上手くいくパターンもあれば、上手くいかないパターンもあります。そして上手くいったモデルを使って、⑨まで行って上手くいかなかったら②に戻る。こんなことを行っていくのが分析かなと思います。実際に私たちもこの流れで進めていきました。

実際にはじめてみると、顧客データベースであるCRM内のデータに問題があることが分かりました。CRM内にはデータがたくさんあると思い、ベンダーさんも揃えていたのですが、現実はそう上手く行かなかったのです。

まずは営業パーソンがデータを自由に登録できるようになっていたので、重複しているお客さんがたくさんいました。CRMは運用していましたが、すべての商談データが入っているかというと、現実は難しく…現場の手元リストとデータが一致していないのではないか、という事例も見受けられました。

他にも商談ログなどがたくさん入ってくるのですが、なぜか受注ばかりで失注のログがほとんどないのです。あとは、テレアポをしているはずなのですが、電話不通という記録がありませんでした。皆電話がつながってアポが取れた、受注ができたと入力している。こんなに成績が良い会社だったかなと思ったほどです。とはいえデータは一応あるので、それでやってみようかなと思って分析を始めました。

先に結果だけお伝えします。3ヶ月で約1000万円かけて行ったのですが、精度が55%ほどのリストが作られました。分析の手順は一般的な手順です。AI開発とデータ分析の手法にしっかり沿って行ったのですが、「3ヶ月やってこれか」とみんなが思いましたね。これが私たちのAI開発における一番はじめの失敗となりました。

データ分析における仮説パターン

新規事業でたくさん失敗も実績もあったので、もう一度立ち返ってみようと思って以下のように仮説を整理してみました。

例えば今回のパターンですと、一番上に「予測してテレアポを取れるリストが欲しい」という事象があるわけです。そして何かこの変数・特徴を使おうという仮説①があって、その中でも①A・①B・①Cと何パターンかに分かれます。

仮説②・仮説③といった別の変数を使ったものも出てくるかと思うのですが、さらに仮説①の中でもデータを集めなければいけないものもあれば、データを集めて分析までしなければいけない仮説もある。あとは、そもそもデータに価値があるか確認しなければいけない仮説もあるわけです。

検証方法はその仮説の中でもたくさん出てくるとは思いますが、今回私が行ったのは仮説①のB です。つまりデータを収集して分析しようとしました。当時AIブームでしたので「とりあえずAIに頼ったら何かできそうだな」とみんな思っていたのです。

先程ご説明したデータ分析の流れでは、仮説を考えて戻るということがありましたが、この場合は仮説①Bの中でぐるぐる戻ります。データを集めて分析したが結果が出ない。ではまた戻ってデータを集めてこよう。このような形でぐるぐる回しました。これで3ヶ月かかってしまったのです。

AI開発というバイアスがあったことで、先にデータを見つけて分析してしまいました。実際スライドの右のように仮説②・仮説③という可能性もあったと思うのですが、この仮説①Bから抜け出せなかったわけです。今思うから分かるのですが、このようなどつぼにはまってしまいました。

仮説パターンの正解

実際この後も分析の手法が違うのかなと思って試行錯誤しました。そして分析を行う前に、そもそも手でデータを作ってみようかなと思い、仮説①Cという一番簡単なものを行ってみたのです。データの価値があるか確認するというものですね。

具体的には会社の概要やステータス、従業員数などをまとめた、営業パーソンが欲しいと思うリストを100個ほどExcelで自作してみました。これを営業パーソンに渡したところ大変好評で、そして電話をしてみるとアポが取れたのです。

結果的に分析しなくても、人の手でAIが生成すべきリストは作れました。それも何か特別な変数を使ったわけではありません。求人の場合にはバイトルの他にも、タウンワークやフロムエーとなどたくさん媒体があります。他の媒体にも掲載している会社は予算がたくさんあると考えて、そのリストを自分で作っただけでした。そうするとやはり予算があって人手に困っているため、テレアポをするとつながるわけです。

しかしこれをAIに行わせると「過去の応募傾向から～した方がいい」「このエリアは～がいい」など出てくるのですが全く精度が出ません。それなら手で作ったほうが早いという結果が得られて、改めて仮説が大事だということを学びました。

反対にあらかじめ仮説を一つに決めてしまうと、どこまでで失敗したのか評価ができない。そんなことも改めて反省しました。

私はゲームがすごく好きなのでRPGをよくするのですが、仮説を最初に引くことはセーブポイントに近いなと思いました。そこでしっかりセーブをしておくと、全滅しても戻れる。もしセーブしないとゼロに戻ってしまうこともあれば、抜け出せなくなってしまうこともある。そんなイメージかなと思います。

1つ目のパートをまとめますと「検証方法よりも仮説生成が成功確率に大きく関わっている」ここに気づいたというお話でした。

---

無料DL｜「もう打ち手がない」ときのUXリサーチ～調査手法の効果的な選び方～

「Webサイトやサービス改善したいが、効果的な打ち手がなく悩んでいる」方に、解決手段の一つとしてのUXリサーチの調査手法の選び方をお伝えします。

ダウンロード（無料）

---

仮説の作り方

それでは中盤に入りまして、仮説の作り方の話に移りたいと思います。先ほどのデータ分析や新規事業の失敗を経験して「失敗の科学」はかなり分析してきました。しかし世の中の書籍を調べてみると、実はデータ分析の失敗に関する書籍はあまり多くありません。

新規事業の失敗の本はたくさんあるのですが、データ分析のものは少なくて、特に仮説をテーマにしたものはもっと少ないです。

仮説立案と検証に必要な3つの論理的思考法

そんな中でも「アブダクション―仮説と発見の論理」という本が参考になりました。この本は作られて数十年経っていますが、今でも十分に通用する内容です。

この本で出てくるのは論理的思考法です。ここを改めてみなさんと振り返ってきたいと思います。

今回仮説の話をするにあたって、改めて良い事例がないかと調べてみたのですが「【図解】どっちがどっちだったか混乱する、帰納法と演繹法。」というnoteの事例が非常に分かりやすかったので参考にさせていただきました。

論理的思考というと演繹・帰納法がやはり一般的です。分析の中でも必然的にこの2つを使っている方は多いですし、分析に限らずビジネスでも使うと思います。実は今回お話しする「仮説的推論」というものが、この中にセットとしてあるのです。図の一番右にあるA・B・Cということから、前例を見て結論を出すという方法なのですが、これを見てもわからないので具体例を出してご説明します。

この仮説的推論は「アブダクション」という名前で呼ばれていて、事例はこちらのスライドになります。noteの中で非常に分かりやすく説明されていたので、ここに野菜の例を持ってきました。

まず演繹法では「野菜は栄養がある。にんじんは野菜だ。にんじんには栄養がある。」という考え方をしています。

一方で帰納法では「ナス・にんじん・トマトなどがある。これらは野菜だ。つまり野菜には栄養がある。」という形で考えます。

それでは仮説的推論の場合はどうかというと、口内炎というテーマと、にんじんとトマトという野菜の種類を一緒に見ていきます。

今までは栄養と考えていたものを、一旦βカロテンと仮説的に絞って、これが口内炎に効くのではないかと仮説を考えるのです。少し似ているようではあるものの、実はこの仮説というものは他の分析手法と密接に関わってくるので、後ほど詳しくお話ししていきたいと思います。

その前にアブダクションはいつからあるのか、その歴史を調べてみました。起源をたどっていくと、記号学の確立者で哲学者のパースさんが作ったそうです。

演繹・帰納・仮説はいつからあったのか見ていくと、倫理で出てきたアリストテレスやベーコンといった哲学者が作った手法でして、これが今もビジネス等で活かされています。それぞれ「デダクション」「インダクション」「アブダクション」と呼ばれています。

この推論の使い分けを表にするとこのようになります。3つの推論の話をしてきましたが、分析的なものは演繹法。そして拡張的推論と呼ばれているのが、帰納法とアブダクションと呼ばれているようです。

これを実際科学的にどう組み合わせていくのかというと、まずはアブダクション・仮説を考えます。次に演繹法を使うことで、仮説を具体的に変換してみる。

そして最後は、帰納的な方法で事実から検証する。これで上手くいけば良いのですが、行かなければまた仮説に戻ります。科学的に言うと難しいですが、このように行うそうです。

明日から使える3つのテクニック

しかしこんなこと言っても難しいので、明日から使える3つのテクニックを簡単にまとめたのでこれだけ覚えてもらえばと思います。

1つ目が確証バイアスを疑うということ。確証バイアスとは何かと言われる方もいると思いますが、言い換えると「解決したい問題から考えられる説明を推測する」ということです。例えば「自分が考えた仮説と違う方法・種類は無いのか」「これはできないのではないか」「逆にできるのではないか」といったように四則演算のイメージですね。

「+ – × ÷」のような形で、自分が考えた仮説を疑ってみるのです。書籍では「反証で考える」と表現されています。

私の場合は、仮説を「AIを開発する」という1つに絞ってしまいました。「本当にAIを作る必要があるのか？」という反証を私ができていたら、1000万円を3ヶ月でロスせずに済んだ可能性もあるかなと考えています。このように自分を否定するやり方です。

確証バイアスを使ったとしても、他にそうではない仮説がたくさん出てくることもあります。その場合にどれから始めたら一番時間が短くて、成果が得られるのか。実際には次の4つを使うと良いそうです。

まずは最も理にかなった説明を与えるもの。そしてそれが検証できるのか。データがしっかりあって検証する人がいるということ。3番目が単純なこと。難しい仮説を検証するのは複雑になってしまうので、単純であることが必要です。そして4つ目が経済性。今申し上げた時間と費用ですね。

上の1から3を選んでいくと、必然的に4番になるのかなと思うのですが、このような費用や時間が節約できる仮説であることが選ぶ基準になってきます。

こちらは先ほどの図に似ていますが、仮説を選んだ時点でその検証の運命は決まっているのかなと思っています。

今回の場合は仮説を1つ選びましたが、その時点で運命は決まっていました。その仮説を抜け出すという発想がなかったので、3ヶ月で1000万円ロスしてしまったわけです。そうではなくて、それ以外にしっかりと他の仮説が見えているかどうかが大事だと思います。この図ですとDだけではなくて、他の仮説を考えているのか。その仮説はどれぐらいのステップがあるのだろうか。

はじめはわからないと思いますが、こうしたことを推論していくのです。これを洗い出すことが非常に大事だなと考えています。

これを実際にAIのモデルで使ってみるとどうなるのか、冒頭にあったモデルにはめていきます。まずはAIの要件整理ですね。「本当にAIを作る必要があるのか」という話です。

今回はAIを使ってアポが取れるリストを作るということでしたが、本当にこれが必要なのか仮説を考えて検証します。現実では基礎集計して、精度が悪いモデルなのに作ってしまったのですが、はじめの段階で分かっていれば要件整理はクリアしていたわけです。

これは基礎集計についても同じです。この集計の中でも仮説があってそれを検証する。モデル設計に関しても同じで、このモデルは本当に実用的なのか仮説を考えて検証する。モデルの検証でももちろん検証しますし、実装の仕方1つをとっても仮説だと思います。

「既存のプロジェクトのどこに入れれば良いのか」「どこに入れた方が学習しやすいのか」など、どこでも仮説が出てくるのです。やはり最初の仮説だけでいいというわけではありません。

あとは速さも重要です。先ほど経済性という話をしましたが、それも考えていかないとAIを作るまで時間がかかって仕方がありません。したがって速さも大事です。

仮説を活かすためのUX

それでは最後のパートに移りたいと思います。ここまで申し上げた失敗をもとに、仮説を出す大切さを学んできました。そしてここでようやくUXという言葉が出てきます。

改めて分析以外の手法でアポが取れる仕組みを考えた

まずは先ほどお話したように、確証バイアスを疑いました。つまり「AIを作るのだ」という発想を外して考えていったわけです。分析する以外の手法を考えることにしました。

そしてはじめにお伝えしましたが、CRMのデータは正しくありませんでした。データが全て揃っていなくて、重複も多かったので前処理で非常に苦戦しました。そもそもデータがないのに無理やり分析したことが間違いだったわけです。そこで今回はデータ取得から始めてみようかなということを考えました。

まずは現場を知ることから

ここからUXのようなことが始まるのですが、改めて「現場を知る」ことからやり直すことになります。私たちは営業の部店が全国で36拠点もあるのですが、ある1つの拠点に絞って行いました。そこは神田のオフィスだったのですが、3ヶ月間張り付きで営業と同じような仕事をすることで、実際にどのように営業をしているのか確認していきました。

やはり現場で確認すると、不満が多かったのはCRMでした。そもそもデータが重複している、良い結果しか入っていないということは、上長に良い報告をしたいだけのツールになっていたというわけです。したがって現場では使われていません。

よくある話ではあるのですが、営業の方はエンジニアとは違って右脳思考の方が多いです。良いものをすぐ使って、自分にメリットがなければ切り捨てる。そういう方が多いので、本当に不満が多かったです。

さらに、営業組織のあるあるですが、トップダウンになっていました。使えと言われたから、いやいやだけど仕方なく使う。そんな状態が蔓延していました。したがって、そもそも分析や現場に入って何か作る前に、営業パーソンにメリットを感じてもらう、営業パーソンの信頼を得る必要があると感じました。

エンジニアが要件を詰めても営業目線がないので表面的になりがち

過去を振り返っていくと、このような営業支援やテクノロジーの導入は、エンジニアが主導で行っていたことが多いと思います。エンジニアがツールを導入しようとするのですが、そもそも営業を知らない人が現場で導入しようとしても上手くいきません。これはよくある話ですね。

それでは実際どこに着目していけば良いかというと、やはり課題なのかなと思います。現場でCRMに不満が出ていた一方で、営業パーソンがとても困っていたのも事実です。したがってそこにテクノロジーを使おうかなと考えていきました。

ツール・AI・RPA何でもそうだと思うのですが「良いテクノロジーを入れても使われない」「1,000万円使ってもダメだった」という事例はいっぱいあると思います。これはほとんどこういうことで生まれているのではないでしょうか。ツールをどんどん導入すればするほど悪循環になっていくわけです。

そして今あるツールの半分を捨てました。そのツールを改善するのも無理だなと思ったので、ゼロから「営業パーソンが一番嬉しい事はなんだろう」と考えることにしました。

ここでやっとUXの話が出てきます。ここからは、UXをどう使ったかという話をしていきたいと思います。

UXデザインとは

改めてUXデザインとは何なのか振り返ってみたいと思いますが、これもわかりやすい図を借りてきました。

こちらはWebの例ですが、このような定義をされているところも多いのかなと思います。ビジネスを分かっていて、デザインの知識もあって、テクノロジーも理解している。こうした人がUXデザイナーではないかと言われています。これだけでもなかなかハイスペックな人ですね。

デザイナーでディレクターに行きたい人もいっぱいいるでしょうし、コーダーの方やフロントエンドのエンジニアの方で、ディレクションをしたいという方も多いと思います。だからこそ、ここまで来てようやくUXデザイナーだという定義を見ます。

私の場合はエンジニアから新規事業を経験していて、プロダクトオーナー寄りのUXデザイナーなので、UIに関してデザインの知識はあまり強くありません。ビジネスやテクノロジー、検証するスキルに関しては人より多く経験している。そんなUXデザインの領域に足を突っ込んでいます。ここに関してはそれぞれの会社で定義があると思います。

さらにUXと言えばグッドパッチさんだと思うのですが、私もグッドパッチさんと一緒にお仕事をした際に優秀な方がたくさんいるなと感じましたし、フレームワークも教えていただきました。

その中で、ユーザ体験に関わるデザインの5階層モデルというものがあります。表層・骨格・構造・要件・戦略といったものですが、これらは一つ一つの定義がたくさんあって難しいです。ここではこれを使わなくてもできる3つの方法をご紹介します。

1.課題と仮説をしっかり整理

1つ目が当たり前かもしれませんが、「課題と仮説をしっかり整理する」ということ。今回のプロジェクトで実際にどんな課題が出ていたがご紹介すると、

• お客さんを探すのに時間がかかる
• 上長に商談結果を報告するのに、毎回メールを打つのが面倒
• CRMのツールはパソコンでしか使えないので、帰社するかカフェに入らなければいけない
• CRMのサイト自体がとても重くて検索しづらい
• 商談を終えるたびに自分の顧客を探す必要があって、その検索だけで30秒以上かかる。そして入力する項目が非常に多いので入力にも1分ほどかかってしまう。結果的に1社に1分半も費やすことになる

このように、CRMの入力がとても面倒なものだとわかりました。その他にもテレアポをするのが面倒、営業のノルマに追われるのが面倒、といった営業の課題や不満をたくさん書き出していきました。

これをもとに仮説のロジックツリーを作ってみたのですが、スライドではその一部を抜粋しています。

今回は「CRMに不満がある」ということに着目して「何が不満なのか」を深掘りした部分をピックアップしました。この前段階では「そもそもCRMが不満なのか？」ということを反証していたので、CRMではない仮説というのがこの上にはたくさんあります。

CRMの中で見ていった場合には「顧客の管理が面倒」「商談を入れるのが面倒」といった課題が出てきました。そして具体的には何が面倒なのか、どのような解決策があるのかという仮説をどんどん書き出していきます。

場合によってはものを作ってしまうパターンもあれば、そもそもデータ確認をしたら上手くいったパターンなど、仮説の検証方法もたくさんありました。これを地道に全部つぶしていったわけです。今回はプロトタイプを作るという、仮説①Aの手法を選んでみました。

2.カスタマージャーニーを作る

課題や仮説を書き出せたら、2番目にカスタマージャーニーを作ります。

先ほどエンジニアが現場でツールを入れる話をしましたが「誰向けの・何を提供したいのか全く分からない」というのが正直なところだと思います。

営業パーソンがどんな生態系で、どんな人なのかというところを理解しないと始まりません。ここで参考にさせてもらったのは、ワーキングママさんがオムツを検索するというカスタマージャーニーマップです。それを事例としてスライドにも載せていますが、これの営業版を付箋を貼って作っていきました。

カスタマージャーニーに関しては以上にしますが、調べていただくとたくさん出てきますしフォーマットもあります。ただフォーマットがあるとはいえ「行動・感情・課題」の3つを把握することが非常に大事なので。この3つを付箋に出すだけでもいいと思います。

3.本当に課題にフィットしているか？

そして3つ目ですが、仮説と人のペルソナ・行動を見て、本当に課題にはまっているかを見て欲しいなと思っています。こちらは細かい図なので、詳しく解説していきます。

今回の場合は「CRMで顧客を探して商談を入力するのが面倒」という困りごとがありました。そこに対してどんな課題なのか、あなたのアイデアがどんなものかを整理するフレームになっています。

これは普段私が頭の中で考えていることを図にしてみたものです。

これは一般的にLean Diagramと呼ばれていて、新規事業の世界でよく使う手法でもあります。実際に中身を見ていくと、まず左上が「何に・どれぐらい困っているか」ということです。

「検索してCRMを入れるのが面倒」「上長からしつこく言われる」ということが書かれていて、ストレスレベルは10段階中で言うと7。かなり困っている問題だと分かります。

続いて左下では「今はどうやって解決しているか」を考えていきます。現在の解決方法としては、「良い報告を入力するようにしている。報告することで目的をすり替えて実施する。」といったことが行われていました。

その理由としては「そもそも探すのが遅いのに、営業時間が取られるのが面倒」「メリットが分からない」「1時間も取られるのならやりたくない」ということがあげられました。

そして右側が今回のアイデアになります。今回は左側の課題を解決するために「顧客が数秒で見つかって、入力も30秒で終わる」という機能を仮説で考えてみました。先ほどのカスタマージャーニーを作ってみると、今回対象となる1,000人の営業パーソンのうち、半分以上が3年目以内の新卒だと分かりました。つまりスマホ世代なわけですね。こうしたこともあってスマホで提供したいなと思いました。

仮説の検証としてまずインタビューを行ってプロトタイプを作ったのですが、この機能をかなり欲しがってくれたので、困り事は解決できそうだなと感じました。そして右下にアイデアがどれぐらい優れているのか言語化してみます。「顧客を探さない、入力も面倒ではない」ということで、営業パーソンからしたら最高ですね。

一旦ここまでをまとめると、まずは本当に困っていることがあるのか確認しました。2番目で解決方法を調べます。

そして右側で、解決できるアイデアを具体的に書き出します。4番目で優れているところを言語化する。これで材料が揃いました。

そして中央に行くのですが、ここでは「営業の仕事をする上で本当に困っているかどうか」を改めて書き出して整理していきました。

今まで1時間ほどかかっていたものを解決するので、営業生産性としてはインパクトが大きいです。そうしたら実際に試算をしてみます。これはROIを見積もったということです。ここに書いてある通りこの場合は、削減工数が大きいので開発をするという話にはなるのですが、これは分析やUXよりも新規事業に近いですね。それでもここまでやってみて、ようやく本当に作るべきかものかどうかが分かるのかなと思います。

これがUXデザインなのかは一部の流派によって違いはあるかと思いますが、私たちはユーザが体験して使いやすいものは、実際に課題とあっているかまで確認するようにして開発しています。

最終的にはこれが原因だった…

今回は今ご説明した3つの手法で行いました。最終的に何が原因だったかというと、Excelです。本当にExcelは神ツールで、これより使いやすいシステムを作れと言われたら正直作る自信がないほどすごいです。このExcelが現場にたくさんあって、これを使えばいいよねというのが正直なところありました。

しかしExcelと戦っても勝てないので、共存する道を考えて仮説検証していきました。そして開発したのが「レコリン」という営業のデジタル手帳です。

これはアプリを起動すると訪問すべき顧客がすぐに見つかるので、顧客を探したり作ったりする必要がありません。いつ出稿しそうかというのも、大まかにグラフで出すことができます。さらに商談の入力画面も、ボタンで選ぶだけにしました。6ステップほど選ぶと商談を入力する作業も終わるのです。それほど簡単に上長に報告できる、そんなツールを作っていきました。

営業ファーストを徹底して、不満よりもメリットを大きく

ここで学んだのが「営業ファーストを最大化することが大事」だということです。営業のメリットを考えると先ほどお話ししましたが、これができていないといくら分析してもはまりません。

そういうわけで今回は分析するというテーマで入ったのですが、結果的にはCRMの改修をしてアプリを作っていました。そしてその中ではUXデザインを使って、ユーザさんに寄り添った良いものを作ろうとしたわけです。

その結果CRMの入力数は3倍も増え、利用率はなんと99.7%とほとんどの営業パーソンが使ってくれました。はじめはデータがないという問題もありましたが、現在はデータが多すぎて解析するのが困難になるほど溜まってきています。このように今回は挽回することができました。

こうしてKPIも上がってきたのですが「人を動かすためには、メリット作りが非常に大事」だなと感じました。もちろん仮説検証があってここのメリットに至ったわけですが、導入や分析を急ぐよりも、営業の利便性・メリットを考えた方が近かったです。

最後のまとめになりますが、いくら高性能なAIを作ってもサービスにはなりません。人に寄り添っていないと意味がなくて、そこに来てやっとテクノロジーが生きるのだと思います。失敗をたくさんしてきた中で、AIとUXが実は密接に絡んでいるということを理解しました。

話を聞いてくれる人がいるだけで、テクノロジーは活きていく

一番印象に残っていることをお伝えしたいと思うのですが、基本的にテクノロジーを作る人は営業の現場に来ることはありません。しかしだからこそ私のようなエンジニアが来て親身に話を聞くと、それだけで非常に嬉しかったと言ってくれました。

普段相談しても本社の人は聞いてくれないという不満も言っていたので、現場に会いに行くだけで相談してくれるのです。こういったことが増えていくと、テクノロジーはもっと活きてくるのかなと現場で体験しました。

最後にこのエジソンの言葉が好きなので紹介させてください。この人は失敗ではなくてステップがあったから電球ができたと言っています。この言葉はまさにはまるなと思います。分析でも何でも一緒です。

テクノロジーを使うときには「たくさん失敗しろ」と言われますが、失敗ではなく「たくさんステップを踏め」ということだと思います。つまり仮説検証が大事だと分かりました。

---

無料DL｜「もう打ち手がない」ときのUXリサーチ～調査手法の効果的な選び方～

「Webサイトやサービス改善したいが、効果的な打ち手がなく悩んでいる」方に、解決手段の一つとしてのUXリサーチの調査手法の選び方をお伝えします。

ダウンロード（無料）

質疑応答

Q.業務や業界のドメイン知識が確証バイアスとして働くことで、課題が見えにくくなると思うのですが、その場合は現場に足を運ぶことが必須でしょうか？

そうですね。先ほどお話しした通りで、現場に一番ヒントがありますね。そこで実際に聞くこと、それが大事だと思っています。

Q.各フェーズで仮説を立てるという話でしたが、そのフェーズで立てた仮説が全て上手くいかない場合は、前のフェーズに戻るというプロセスを踏むのでしょうか？

全てがその通りになっているわけではないですが、基本は残しておく方が大事かなと思っています。振り返る場合もあるのですが、何をしたかは意外と忘れてしまうと思います。したがって、それが見えるように可視化するのが大事ですね。

Q.それはチームでやるからですか?それとも1人でも残していくのですか？

1人でも残しますね。チームだからということもありますが、自分でもわからなくなってしますので残しています。

Q.仮説を検証している途中で「無駄かな、これ以上はやめよう」となるときに、どういうことを重視して判断していますか？

大体判断が曖昧になってしまうので、やはりKPIを重視していますね。置けないものもありますが「あらかじめインタビューでこんなことを聞こう」「これが聞けるか聞けないか」「何か作った場合は、コンバージョンレート何%か」こうしたものを置いておくと良し悪しを判断できます。

Q.その基準は何で設定しますか？

例えばまだないプロダクトの場合は、世の中に似たようなものがあればそこから参考にします。インタビューの場合は、他の類似サービスがないのかなど。もちろんひたすら聞いて答えがない場合もあります。そうしたときはAIの判断になる場合もあります。

Q.大規模に実験する場合に小さくユーザテストなどなさっているのであれば、その手法についても教えてください。

ここは人それぞれ得意不得意あると思うのですが、私はインタビューが一番効くなと思っています。聞き方だけでもテクニックがあるのですが、やはり何かを作ると検証するのが遅くなってしまいます。お金がかからずに自分の体一つでできる。それが一番速くて小さくできるのではないかなと考えて動いています。

Q.インタビューの対象者はどのようにして見つけてきますか？

今回の場合は営業だったのですぐ会いに行くことができました。仮に新規事業の場合ですと、自分でお客さんをリクルーティングするところから始めます。例えば不動産の新規事業の際には、実際に家を探している人を会社の中で見つけたり、不動産の営業パーソンに家を借りに行くていで会いに行ったりしました。

まずは何でもいいので手段を選ばずに会いに行く。会えるのであれば謝礼を払うなど、泥臭いですがそのように見つけています。

Q.インタビューなどの訂正調査と、ツールの利用データなどの定量調査がどうしてもそれぞれに進んでしまいます(企画から分析プロセスで上手く連携できないことに課題を感じています)。亀田さんの主観で構いませんので、両方を上手く進めていく理想イメージ、実現のためのコツを教えてください。

私の場合は定性から定量というやり方が多いですね。定量から行う場合もあるのですが、基本はやはり定性でヒントを集めて、それを定量的に検証してつなげています。

もちろん毎回全て同じ検証をしているわけではなくて、そのときに必要な手法を選択するようにしています。

Q.今回データを正しく取得するために、そもそもアプリケーションを作られたという話でした。アプリケーション改めて設計する際に、中長期的なスケールを見越して新たなデータ取得などは追加されましたでしょうか？

鋭い質問ですね。中長期のスケールは何が来るか分からなかったので、拡張性があるように設計はしました。もちろん営業データを取りたいがために、1回ツールを作ったのはその通りなのですが。商談項目はボタンで押すようになっているので、そこの項目が増やせるようにマスターを作るといった工夫はしていますね。

Q.定性効果の検証はどうされていますか？

定性は基本ヒントを探る場だと思っているので、その結果を定量で検証するやり方が多いです。また、先程のテレアポのリストを作った話ですと、定性的な反応や感情を見るようにしています。

何となく使いやすい・嬉しいという反応はあまりいらなくて、本当に喜んでくれるかどうか。それを見極めるのは大変ですが、すごく喜んでくれたときの反応は見るようにしていて、人の表情を見ることも多いかもしれないですね。

Q.以前あるプロジェクトで本当に困ったのですが、仮説を立てるときに企画・情シス・ユーザ部門の壁がありました。「ユーザにヒアリングしたいのですが協力していただけますか？」「いや結果が出てからユーザ部門に持っていきたい。」といった場合、亀田さんならどうしますか？

リアルな悩みですね。確かに今回も似たようなケースではあって、私は新規事業を行う人間としてこの場合営業の現場に入りました。「なぜ新規事業の人が営業現場に来るのか」「私たちが作ったプロセスがあるので邪魔しないでください」といった営業企画の反発はありました。

私の場合は知り合いの営業パーソンが何人かいたので、部長さんを飲みに誘いましたね。「こういうことを考えているから、営業にインタビューさせてよ」と言って懐に入る。そしてその営業パーソンと協力して、先に結果を作ってしまうのです。

最初にExcelリストを作って2人で上手くいきました。そして4人に使ってもらって、次は6人。その後、課・部という形で広げていきました。

「懐に入ってお土産を持っていく」とよく言っているのですが、仲良くなって信頼してもらうのが一番早いかなと思います。

Q.何事も小さく入る、手段を選ばずにまず飛び込むといったことが大事なのですね。

そうですね。分析者やエンジニアですとこの思想はあまりなかったのですが、やはり新規事業をやったときに大きくこけたのが大きいですね。なぜ使われないのかなと思った時に、その経験が今のAIやUXなどのテーマでも使えるのかなと考えています。

以上、たくさんご質問をいただいた皆さま、詳細にご回答いただいた亀田さん、どうもありがとうございました。

また、弊社UXリサーチャがご支援致しますアジャイルUXリサーチにもお問い合わせお待ちしております。サービスについて問い合わせる＞＞

無料DL｜サービス紹介資料

株式会社メンバーズ ポップインサイトカンパニーのサービス資料です。UXリサーチチームが組織に伴走しサービス開発・改善のプロセスにUXリサーチの内製化をご支援します。

ダウンロード（無料）