KDDIグループ元執行役員が語る「ユーザ中心主義」組織改革の軌跡～オンラインセミナーまとめ～
「社内でUX改善の取り組みを推進したい」とお考えの現場担当者の方からよくお聞きするご相談は、「UX改善の重要性を実際にどう社内浸透させたらいいのかわからない」というお声です。
2019年12月12日に開催したオンラインセミナーでは、KDDI株式会社で全社のUXデザイン責任者を務めた後、グループ会社である株式会社mediba執行役員 兼CXO（当時）として「ユーザ中心主義」への社内文化変革を担う岡 昌樹さんをお招きしました。
岡さんには、同社での「ユーザ中心主義」改革の軌跡として、UXデザイン導入の取り組みの中で「やったこと」5つを具体的にご紹介いただきました。スモールステップで確実に、社内体制に「UX」を取り入れるヒント満載です。
【オンラインセミナー動画】KDDIグループ執行役員が語る「ユーザ中心主義」組織改革の軌跡
目次
実際にやったこと やってみてどうだったか 今どうやっているのか
私はかれこれ10年弱ユーザリサーチやインタビューを自分でやったり、教えたり、アイデアを出しています。前職からユーザの価値や不満、自分の思い込みに気づく為に定性的なユーザリサーチの重要性を感じていました。
medibaの執行役員の中でも特に顧客とお会いすることが多いほうですが、medibaでは年間で1000人インタビューを目指しています。ユーザが抱えている不満から自分がやりたいことをもらっています。
そこで本日は
- 組織にUXデザインを導入する上で実際にやったこと
- やってみてどうだったか
- 今medibaでどうやっているのか
を紹介したいと思います。
やったこと1 全員でユーザのことだけを考える日
日々の業務の中でユーザのことを考えることはありますが、チームや組織が大きくなる中で個々がバラバラに考えていても弱いですよね。そこで、お祭りっぽくやってしまえ！ということでその日一日は全ての業務をやめてもらい、全職種がユーザのことだけを延々と考えるお客様感謝Dayをやってみました。
数字を見たり、ユーザインタビューをしたり、プロトタイピングを見せに行ったり、負債と思ったコードを延々とリファクタリングしてやってみる、などです。
例えば上の写真は、ユーザが電車に乗りながら、僕たちの開発したアプリを使うシーンを再現したところです。ユーザのことだけを考えてデザインしたり開発したりインタビューしたり…皆でやると初めてのインタビューでも恥ずかしくなく楽しめて良かったのですが、お祭りなので継続は難しかったです。
ただ、とっかかりにはとても良い方法なので、オススメです。
やったこと2 目的を持って目標を立てる
かつては目標は個人で立てていましたが、目的に対し目標は立てるべきと考えています。ユーザに提供したい体験があり、その為の目標を立てても、なぜか目的を忘れて目標がただの手段になってしまい、目標の数字だけが独り歩きしてしまうことがありました。
明確な目的があり、目標がそこにぶら下がる形にしないとぶれてしまうので、当時はまだ浸透していなかった、OKR(Objectives and Key Resultsの略。目標と目標達成のための主要な成果)のような概念でやってみたいと思い、こんな風に物語の「3人のレンガ職人」に例えてみました。
ある旅人が汗をかきながら重たいレンガを運んでいる3人のレンガ職人に出会い、なぜレンガを積んでいるのかと聞きました。
- 1人目は、「積めと命令されたから」と答えました。
- 2人目は、「お金をもらえるから」と答えました。
- 3人目は、「皆が祈りをささげるための大聖堂を作っている」と答えました。
皆同じレンガを積むという作業でも、3人目の職人は志や明確な目的意識を持っているので、他の2人とは仕上がりに大きな差が出ます。
このように、目標を立てるときに「皆で大聖堂を造ろう！そしてそこに紐づく定量的な目標を立てよう！」と伝えました。しかし結果としては「何を言ってるかわからない、難しい」と言われてしまい、目的は個人のレベルに合わせる必要があると思いました。
正しいことを言ったからとはいえ浸透するかは別で、正しいことであってもそれを伝わる形で伝えなくてはダメと学びました。
やったこと3 UX改善を評価する
UX改善における課題として、以下のものがありました。
- UXデザイン、UXリサーチ、ユーザビリティとは言っても売り上げ施策が勝ってしまい、短期的、定量的証明がしにくい
- 全員でエンジニアリングやデザインすることが必要だが、どうしてもXデザインはデザイナーのタスクになりがち
- ページ速度、行動などを整えるのは大事だが、目に見えない改善評価がしにくい
そこで、BTC(Business Creative Technology)各トップを集めて各サービスのUX改善をそれぞれの視点で評価していこうとしました。
例えば表示速度(Technology)を改善してもBusiness、Creativeの方たちから見ると凄さがわからないので、三権分立しそれぞれのサービス改善のために必要なフィードバックを毎月行いました。
1カ月目はまずはユーザインタビューやユーザビリティテストによる定量的な分析から今顧客はどのような課題や不満を抱いてるかを発見し、改善の計画をします。
2～6カ月目でつねに改善サイクルを回しながら、計画と実績を見つつBTCのトップ人材が毎月レビュー会でフィードバックをしていき、その積み上げが最終評価になる形です。
サービスのちょっとした見えにくいUXの改善を継続的に最終評価まで繋げることが出来たのと、期末にいきなり評価が下るよりも毎月フィードバックがあることで皆にとって納得感のある評価になりました。
- デザイン以外の評価が出来た
- 別サービスの改善活動、実施方法がわかり役に立った
- 評価/フィードバックのループで目線が合う
- 短期施策に走らず、中長期的にUX改善が出来た
等の点で、上層部の意見が合えば取り組みやすい方法でとても効果がありました。
やったこと4 ユーザビリティ検証のフロー化
経営トップからサービスが使いにくいと言われたので、ユーザビリティテストをフロー化し行おうと思いました。
ユーザビリティテストは実際のユーザに使ってもらい「ちゃんと使えるか」「エラーが起きないか」を見るのですが、私自身が初めてユーザビリティテストをした時は「こんな使い方するんだ」と驚き、目の前で困っている姿を見るととても直したくなったので、皆も同様にユーザビリティテストを行えばいいサービスを作りたくなると信じていました。
図のように、UXチームは企画段階で相談にのりながら、開発リリーステストの段階でユーザビリティテストを実施し、ユーザビリティテストでのバグ、エラーを直してからリリースしよう、というフローを作りました。
UXチームが中心になりながらサービスを作っている人と一緒にやっていき、プロトタイプやモックの段階でテストするケースもあれば、ユーザビリティテストに開発側の人にも参加してもらい、どれだけユーザが困っているかを見てもらいながら修正に繋げていきました。
しかし驚くことに全く修正されずにリリースされてしまいました。そこで我々はリリースを止める権利を取りましたが、それでもリスク受容承認がされてしまい自分の甘さを感じました。
何が悪かったかというと、会社の力学として、ユーザが困っているということよりも上から言われたとおりにやる、期限を守るということのほうが圧倒的に強かったことです。そこで変えるべきものはプロセスではなく価値観だったと気づきました。
私はユーザビリティテストを行えば多くの人がサービスを良くしたい、直したくなると思っていましたが、それだけではなく、価値観にアプローチする必要がありました。
やったこと5 会社全体をユーザ中心にしていく
図はニューロ・ロジカル・レベルというNLP（神経言語プログラミング）のモデルです。上に行けば行くほど変えることは難しいが変わったときに影響度が大きく、下に行けば行くほど変えることは出来ても影響度が低い。
大事なこと、行動の目的である「価値」の部分を変えないと、何をするかという「行動」が変わらないと考えました。
例えば私はユーザビリティテストという行動を半年に1回、年に1回など行いましたが、そのような頻度が少ない非日常的な行動を変えたところで価値観のところまで到達することは難しいです。
そこよりも「使いやすいものを提供したい」「ユーザが困らないようにしたい」という価値観をどう醸成すべきかを考えるべきだったと気づきました。
そこで3つほど大きく変えていて、会社をどう位置付けするか、個人・組織の目標・評価を変えていく取り組みをしています。まずmedibaはKDDIグループにおけるサービスデザインの会社になろうと位置付けました。もともと広告の会社でしたがモノづくり、サービスデザインの会社になるんだという位置づけです
創るヒトをつくる
次にプロセスを改善するのではなくサービスを正しく創れるヒトをつくっていくという取り組みをしました。
medibaのミッションとして「ヒトに“HAPPY”を」を掲げていて、その成果がサービス売り上げになると考えています。創るヒトを創った結果、良いコミュニケーションが生まれ、良いチームが生まれ、良いサービスが創られた結果、ヒトをHAPPYにできるのだ、だから僕たちは創るヒトを創ろうというところをKGI(Key Goal Indicatorの略で「経営目標達成指標」)に近くしました。
創るヒトをつくるためにどうしたらいいか？を考えると、日本の会社は打席に立たせずに打率を上げろ、という風潮があると思いますが、私自身は打席に立ってバットを振り、初めて打率が上がると思っているので、バットを振る回数を増やしていき、それを皆のナレッジにしていけば創るヒトをつくれるのではないかと考えました。
定性、定量調査についてはUXリサーチをして課題の発見数や施策数を定量的な目標にしています。まずはたくさんの施策を打てる状況を作り、失敗成功を振り返りながら進めるようにしました。最近ではうまくいかなかったことを皆が認められることになってきました。
共通のナレッジ数も蓄えられるし「なぜうまくいかなかったか」「どこの仮説が間違ってたのか」など振り返ることができるので、組織で調査をして、検証の為にリリースをして、どんどん共有をしていき、創るヒトが増えていけば再現性が上がるのでは、と組織の目標や制度を変えていきました。実際には試作数や調査数を定量的な目標に持っています。
他にも本社を移転した際には、社員インタビューを20数名実施し「どう働きたいのか」という価値マップを作りHCD(人間中心設計)を回したり、プロトタイピングを作ったりで全社で当たり前のようにユーザの意見を導入しています。
人事制度リデザイン
小さな組織を作り意思決定が出来るようにしたり、職種を分類して、スキルとバリューの2軸で給料を決めています。売り上げという目標で評価するというよりは、UXデザインを通してのスキルと会社で掲げているバリューが伸びるということは能力が伸びているということと捉えて給料を決めています。
例えばレアルマドリードや巨人はいい選手を多数雇いますが、優勝出来なければ監督、つまり経営の責任と思っており、スキルとバリューが伸びているのに売り上げが伸びないのは経営の責任なので、メンバーはスキルとバリューをどんどん高めていこう、という振り切った人事制度にしています。
このようにmedibaは「当たり前にユーザ中心」ということを価値としたことでユーザインタビューをする上でのハードルや摩擦が無く、とてもやりやすいです。
UXデザインの浸透を通じて
仕事とは何か？
一概に言えませんが、仕事(W) = 力(F) × 距離(s)の方式と捉えています。例えばユーザビリティテストを実施しても改善が出来なかったということは仕事として何もできていない状態だと思っています。
重い荷物を押しても移動距離が0なら仕事は0。そこには大きな摩擦が存在したし、それを乗り越えることが出来なかったということです。
自分自身のミッションとして「UXデザインの摩擦を0にしたい」と思っています。それが仕事であり、組織を作ることであり、UXを浸透させることだと思っていて、これからもやっていければと思っています。
質疑応答
Q.リサーチをしても生かされるような体制ができていないため、リサーチチーム自体作れない状況にあります。デザインや開発体制など含めて、どのように作り浸透させたらいいか教えてください。
中国の保険会社では、CEOの横にUXチームを置き、医者に対して不信感を持つことの多い中国人に、保険を売る前にまずは医者の評価をするアプリを作りインストールしてもらいました。
そこから医者にかかる人たちの保険、というところでカスタマージャーニーを描いていき、その時に組織のデザイン自体も大きく変えていったというケースもあります。
そういった開発体制や組織にしていくのは一つの手ですが大変ではあります。しかしひとつのプロダクト、サービスのプロダクトマネージャーの横にUXデザイナー、リサーチャを置くのは大事だと思います。
私がコンサルしている大きなIT企業でも、プロダクトマネージャーとUXデザイナーが基本的に対になりながら意思決定をしている組織があります。
Q.プロダクトディスカバリーと、ユーザテストなどデリバリーのためのUXリサーチの使い分けはどうしていますか？
新しいサービスを作りたいときはユーザリサーチをすることもありますが、一方で新しいサービスばかり作っていくというわけでもないので、リサーチせずにLPだけ作って出してみる、というやりかたもしています。
あくまでも「リサーチは学習効率が高いほうを選ぼう」と考えていて、例えばサービスを作るために何億もかかるなら不確実性を減らすために確実にリサーチしていますが、一方でエンジニアとデザイナーひとりずつで3週間でプロトタイピングやクローズドベータを作れるようなら、リサーチするよりも作って学習したほうが早いので、そうしています。
Q.ユーザリサーチなどからの学びや発見をどのような方法で社内に共有していますか？
Confluenceなどのツールを使いナレッジを共有してます。余談ですが今はアイデアテスティングのような、小さなプロダクト、アイデアをどう検証するかというフェーズが盛り上がってきていますよね。
アイデアテスティングの本ではアイデアを検証する方法がたくさんtipsになっています。想像するに今までリサーチをして顧客の課題を発見しようとしてきたが、一方でそこからサービスを作りデリバリーするに至れない人が多かったのではないかと感じており、「課題を発見するだけでなく、アイデアをどう検証するか」が必要だということで盛り上がってきている気がします。
Q.BTCモデルでサービスを毎月FBしていく流れがありましたが、複数のサービスを同時並行で進めたのか、1サービスずつ進めたのか、どちらでしたか？
管轄している事業本部の全サービスで10サービス程度を一気に進めてました。この半年でやるべきUX改善のプロセスを皆で回すことができる状態を作っていました。
Q.UX改善の取り組みにおいてエンジニアなど他職種の巻き込みかたはどうしたら良いですか？
ウォーターフォールの下流のほうにエンジニアやデザイナーを置くと、やらされている仕事感がでてくるので、UXリサーチやインタビューのタイミングからエンジニアにも来てもらい、一緒にアイデアも出します。
その時にプロトタイプピングを作れるのであれば一緒に検証していきます。上流のフェーズから関わってもらい、顧客を見てもらったり、参加してもらうようにしています。
Q.経営層が「ユーザインタビューよりまずは作って試したらいいのでは」という考えなのですが、説得するにはどうした良いですか？
ユーザインタビューは手段であり、機会や課題を発見したり、リスクを減らすためにやっています。これで良かったのだと発見してそこに向かっていく確かめ算のような方法なので、HAPPYな感覚だと思います。
Q.インタビューやリサーチの重要性を理解していない、ウォーターフォール型の古き良き慣習を良いと思っている経営層を理解させる為の説明の仕方について教えてください
自己否定になってしまうケースもあるので理解させるのは難しいですよね。私は仲間に入れちゃえ、共犯者にしよう、というような感覚でやっています。
例えばリサーチの予算を作っていくことは大事ですが、品質管理などのいくつかの会社の中における移動させられるお金を「UXに関わることだから」と言って集めて投資していくと、経営層への報告義務が出てきます。経営層はお金を使っていると自覚すると止められなくなるので仲間になっていきます。
あとはユーザビリティテストの動画を編集して良く見せています。テロップをつけたりして。
Q.経営層に向けて「UXデザイン志向の組織浸透」について数字のコミットを行ったか伺いたいです
アプリとかサービスで言うと、アクティブ率を評価しました。NPSのようなものを指標化しながら追いかけていきました。ただコミットというのは無かったです。
Q.指標としてアクティブ率やNPSがあると思いますがが、それ以外に有効だったものはありますか？
画一的な指標は無いと思います。なぜNPSを使ったかというと、あるサービスにおける顧客の解約率とNPSの相関が一番高かったので追いかけました。
しかし「何のサービスか」によって全然違ってくるので、メディア系であればアクティブ率も大事だし、アプリであればプッシュ通知で開いた数というよりはユーザが能動的に開いた数のアクティブ率を追いかけるとダークにならずに済むと思います。
自分たちのサービスで顧客体験の改善したいことやゴールはなんだろう？ということを考え、よりたくさん使ってほしい、ちょこちょこ使ってほしい、月次でお買い物して欲しい…などいくつかある中でそれをブレイクダウンしていったときにどうなるか、相関が高いのはなんだろう？ということを指標化より言語化していくことが大事なのではないでしょうか。
Q.UXをより良くするうえで大事にしていることは何でしょうか？
まずは自分の思い込みを取り払う上で顧客に会いに行くことを徹底したほうがいいと思います。
デザインシンキングのステップの最初は共感、エンパシーだということが忘れられているように思います。顧客の困ってることに対し、強い共感を得て、自分の課題として解決していく、という風に捉えるのが一番大事と思います。
Q.クラウドサービスを扱っていますがUXを真剣に検討したことが無く、開発者がインターフェースを決めてしまっています。外部にユーザインタフェースのコンサルを依頼する場合の選定する際の注意点を教えてください
いきなりプロを入れて一時的に改善しても、クラウドサービスはライフタイムも長く、セールスからカスタマーサクセスまで含めてUXという概念であり、ユーザインタフェースはあくまでその一部と思うので、まずは見よう見まねで自分たちで顧客の声を聴きながらやってみるといいと思います。
Q.UXリサーチから実装に至るまで、それぞれのタスクにおいてチームメンバーはどのように関わっていますか？
皆でリサーチ設計をしています。UXリサーチの実査、分析はUXリサーチャが中心ですが、分析はKJ法(データをカードに記述し、カードをグループごとにまとめて、図解し論文等にまとめていく方法)で他の担当者も呼びながらやっています。
UXリサーチ後の要求出しについてはチームでバリュープロポジションキャンバス(自社の製品やサービスと顧客のニーズとのあいだのズレを解消するためのフレームワーク)でユーザの痛み、ユーザの価値、ユーザが叶えたいジョブを出しながら、どう対応していくかを皆でワークショップ的に考えることが多いです。
絞り込みはデザインスプリントの手法に近いですが、投票やアイデアにシールを貼ったりして「これをやる」と決めたらアジャイルのタスクボードに載せて実装に進む形なので、多くの人が関わって欲しいのはリサーチ設計より実査や仮説出し、絞り込みの部分です。
ユーザが言語化できない課題もあると思いますが、どう見つけていますか？
確かにありますが、結局言語化してもらわないとリサーチにならないですよね。インタビューでの質問方法としてチャンクアップ・チャンクダウン(チャンクは「かたまり」の意味。チャンクダウン＝かたまりを小さく分けること、チャンクアップ＝かたまりをさらに大きくすること)があり、UXリサーチの時に事実を聞くことを中心に理由を聞きますが、それが言語化できないこともあります。
本当に言語化できない課題を発見したいときは、ユーザの行動観察をしたり訪問調査をすることもあります。例えばヨガだとすると使ってるものを持ってきてとお願いすると、持ってきてくれたものからエピソードを聞けますし、親子の調査の時はスマホの写真を見せてもらうことでその瞬間、場面のエピソード記憶を引っ張り出して言語化しやすくなります。
Q.発見したファクトや仮説の中で言葉にしにくいものを社内に共有するための工夫はどうしていますか？
一次情報と二次情報は大きく情報のレベルが違い、二次情報だけで理解してもらうのは難しいので、全部を伝えようとはしていません。ある意味共有できないものとして考えています。
Q.スクラムスプリントの中にリサーチを入れる余地はありますか？
リサーチがどのような概念かによりますが、プロトタイプを社内でまず触ってもらったり見せに行き簡単にユーザビリティテストをしてもらうことはあります。
一方でスクラムスプリントにおけるリサーチで言うと、Twitterを使った簡単なリサーチをしています。Apple Watchの企画を考えるときは 「Apple Watch 楽しい」「Apple Watch やばい」などで検索すると、すごく楽しんでいるユーザが出てきて、その人たちが何をやってるかtweetの共通点をスクリーンショットして並べて出していき、抽象化をしています。ちゃんとしたリサーチというよりアジャイルの形でやっています。
Q.ミドル層でも価値観や会社の方向性を変えていくためにはどうしたら良いですか？
ミドル層の時もそんなに変わらなかったような気もしますが、範囲が違っていたかもしれませんね。プロダクトマネージャーだった時は自分のプロダクトの範囲しかできていなかったりしました。ただミドル層でも結託してUXに関わるお金を集めていくことは出来るのではないでしょうか。
いきなり組織を変えるのは難しいので、経営層の誰かを仲間に巻き込んでいくことが良いと思います。
Q.価値観で社長の想いが強く反映されています。ミドル層以下でもボトムアップで価値観に働きかけるテクニックはありますか？
日常的な行動が変わることにより価値観が変わっていくことが多いので、ボトムアップしていくためには社長などの上の層へ日常的に情報をインプットしていくことが有効だと思います。
Q.UXデザインが全く浸透していない会社の従業員であり、浸透させたいと思っている状況だとして、岡さんならどんな戦略を試みますか？
違う会社に行っちゃうかもな～笑でもまずは数字で可視化をしていく、数字の変化をインプットするところから始めます。
興味を持って見てもらうことが大事なので、サービスの中で取れていない数字やまだNPSを取っていなければまず取ってみて、インプットしていきます。毎日のように見える場にUXに関連するようなコンテンツや指標が見える状態を作っていくことを戦略としてやります。
あとはお金をたくさん集めます。
Q.価値観はそんなに簡単に変わりますか？どのように価値観を変容させていきましたか？
変わったかどうかは正直わかりませんが、インタビューをすることに対して、何の為にやるのか？などという社員はいなくなったので、少なくとも心理的障壁は取り払えたのではないかと思います。
一方でユーザインタビューは無駄だという社員もいますが、少人数の組織ならひとりずつ話すこともできますが、大人数の組織では難しいので、行動をデザインして日常的に皆がその行動をする、という状態を作りました。
Q.UXデザイナーのスキルはどう計っていますか？
UXデザイナーのスキルを5つの定性的な文章にして、知っている、サポートを受けながらできる、ひとりでできる、教えられる…のような段階に分けて評価しています。
スキル全部を細かく分けていませんが、ベースにしているのはHCDネットが出している人間中心設計のコンピタンスマップと言われるものでリサーチの設計、実査、分析、モデリング…などの項目を5つくらいに分けて評価しています。
Q.UXリサーチャにはどのようなスキルが必要ですか？デザイナーとの差分はどこですか？
マインドセットレベルで言うと以下ではないでしょうか。
- 「知ろうとする力」なぜ？を深掘りすることが苦手なタイプもいるがそこで踏ん張って知ろうとする力
- 「観察する力」ユーザが言ってること、やってること、目の動き 手の動きも含め観察していく力
- 「抽象化と構造化」インタビューで得られた事実情報をまとめていき抽象化していく、抽象化することでモデリングが出来て、それを構造的に捉えていくという力。
Q.リサーチするユーザとのコンタクトはどうコーディネートしていますか？客先に行きづらいです
弊社ではパネルを他社に頼むことはあってもUXデザイナーのチームが基本的に自分たちでやっています。他社でBtoBやSaaS系だと営業系を通して連絡してるようですね。実際に来てもらったり行ったりしています。意外と協力してくれる会社が多いのではと思います。
Q.UXとHCDの言葉について人によって解釈が違いますがが共通言語としてどう浸透させていきましたか？
UXもHCDもISOで定義されていますがわかりにくいですよね。教科書的には「UXは個人の体験である」と言われていますが教科書的な定義が重要ではないとも思っています。
一方でズレてるのであれば定義をするより会話をするプロセスのほうが大事ではないでしょうか。君と僕とのUX、HCDの違いってなんだろう？とディスカッションすることにより深まるので、会話をすることのほうが重要ではないでしょうか。
Q.物を作りたいエンジニアに、ユーザ先に出てもらうにはどうしたら良いですか？
弊社では行かせてしまっています。「机の上に答えはない」という考え方を啓蒙していきたいと思っています。
Q.技術サポートや営業でユーザと接している担当者やプロダクトオーナーは、自分が一番ユーザを知っていると思って意思決定しています。逆にユーザが言うことは全て対応しなくては、ということにも繋がっていますがどう対応したら良いでしょうか？
教育に近いですが、ユーザの言ってることを解釈するのがリサーチャやプロダクトマネージャーだと教育しています。ユーザは自分の領域を明確に伝えることが出来ないよねと。
例えばユーザはよくブックマーク機能が欲しいと言いますが、ブックマーク機能がどうして必要かと聞くと、さっき見たコンテンツや商品がもう一度見たいからだ、と答えます。それなら閲覧履歴ではどうしょう？と聞くと、そちらのほうが良いですねとなります。
ユーザが欲しいと言っている機能が明確に要求を叶えるか、というとそうではないよね、と教育しています。
Q.UXデザイナーが5つの項目を満たしているかチェックするのはマネージャーですか？
はい、マネージャーです。
ちょっと変わったポージングで写真に写るのがお好きというお茶目な岡さん。親しみやすいお人柄に終始和やかな雰囲気で、多くのご質問もいただきましたが大変具体的にわかりやすくご教示いただきました♪改めて岡さんありがとうございました(^O^)♪
岡さんも大切にしていらっしゃるアジャイルなUX改善。弊社でもご支援しておりますサービスに関するご質問はお気軽にどうぞ♪
無料DL｜サービス紹介資料
株式会社メンバーズ ポップインサイトカンパニーのサービス資料です。UXリサーチチームが組織に伴走しサービス開発・改善のプロセスにUXリサーチの内製化をご支援します。