# タイトルコール ようこそ、世界が広がるソフトウェア品質で このチャンネルでは旧エンジニアのサミーが ソフトウェアテストやソフトウェアの品質保証を中心に 日々奮闘していることや考えていることをお話しします。 毎日お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと テストや品質の世界を広げていきます。 # ユーザー体験に対する考え方の共通点と違い。UIデザインとUXデザインの違い。 今回はゲストトークということで、デザイナーの京谷さんをお呼びしております。 よろしくお願いします。 よろしくお願いします。 最初に簡単に自己紹介をお願いします。 今、Voicyという音声プラットフォームを作っているスタートアップで、 UXUIデザイナーをやっております。 私は結構長くて、もうすぐ8年目に突入するんですけれども、 創業メンバーでもあり、一人目のデザイナーでもあるという感じで、 多分本当にずっと長くいるメンバーという形で、 会社とかサービスのいろいろな変化も含めて作ってきたという、 そういった人物になります。 よろしくお願いします。 今回デザイナーさんを呼んだ意図というか、 品質、どっちもユーザー体験みたいな感じで、 品質を作っていくとか思っていくというのは同じなんだと思うんだけど、 もしかしたら視点が違うのかもしれないなと思っているので、 そこの共通点と違う部分というところを見つけられたらいいなというふうに思っています。 大切にしているユーザー体験とか、ユーザーの目線とか、 普段業務でデザインを作るというときに、どういうことを気にされて作っているんですか? ユーザー体験を大事にしているところですよね。 いいユーザー体験ってなんだろうみたいなのが結構難しいなと思っていて、 それぞれのサービスとか事業によっても異なると思うんですけども、 私はデザインをしていく上で、機能的な価値と感情的な価値というところが2つあると思っていて、 機能的な価値というところで言うと、本当に分かりやすく使いやすいとか、 ユーザーがこういうことをしたいということに対してしっかり機能として応えられているとか、 そういったところかなと思うんですけど、 Voicyって今私がデザインしているサービスとしては2Cサービスなので、 結構感情的な価値というところも重要になってくるなと思っていて、 使っていて楽しいとか、ワクワクするとか、思わず日常的に開きたくなるとか、 使っていたら元気が出てくるとか、 そういうのってもちろんサービスを使った結果だから、 デザインでどこまでそれをしてあげられるかというのは分からないんですけど、 でも細かいもしかしたらライティングの言葉遣いだったりとか、 そういったところでも感情って動くのかなと思っていたりして、 その2軸があるということを常に意識して、 ただ分かりやすいとか伝わりやすいとか使いやすいとかだけじゃなくて、 2Cサービスとして感情的な価値も大事にしたいなみたいなところを包括して、 良い体験とか良いアクセサリーとか良いデザインというふうに捉えていますね。 ありがとうございます。 聞いててというか、私目線というかQA目線だと、 今京子さんおっしゃった機能的な価値みたいなところが、 もうちょっとそこが違うなと思って、 ついQA目線だとシステム的な機能が正しいかどうかというところが結構気になっちゃったりとか、 計算結果が正しいとか、もしだったら再生ボタンを押したら、 その意図した、選択した放送が再生されるかみたいな、 そういうところを課金が正しく課金されるかみたいなところが結構機能として気になる部分があったりして、 その次に文言が例えば分かりやすいかとか、 サービスが画面が分かりやすくなっているか伝わりやすいかみたいなのがあるなというところがあるので、 そこが何だろう、相というか分かれているかもしれないですね。 多分一番表層的なところって、感情的価値と機能的価値のどっちが表層なんだろうな、 もう一個深いところに今おっしゃっていたシステムの正しさみたいなところがあって、 かぶっているところもあるし、お互いメインで見ているところは役割が違うみたいな感じになっているのかなと私も今聞いていた。 確かにQAってそうなんだなというふうに思いましたね。 ありがとうございます。 もう一個別の観点で言うと、別なのかな。 デザインって聞くとどうしてもUI、見た目のイメージをどうしても持っているんですけど、 でもUXデザインとかもあると思うので、そもそもデザインって何ですかっていう質問なんですけど。 私も答えられないかも、デザインって何でしょうね。 今本当に広い意味になってきているので、いろんなことがデザインですよね。 デザインっていう言葉そのものを定義するのはちょっと自分の考えだと難しいなと思うんですけど、 UIデザインとUXデザインとかだと結構、私の考えだとUIデザインとUXデザインに包括されていると思っていて、 UXデザインってユーザーさんがこういうゴールに向かうまでの流れ、全体のストーリーを設計していくんですけど、 それって上流の方にいったら、そもそもそのためにはどういう機能が必要なのかっていう、 そもそも何をやるんだ、何が必要なのかっていうところからブレイクダウンしていって、 最後にそれを使うためにUIが必要っていう順番なので、 UXじゃなくてちょっと流度が違うというかUXっていう全体の中の一つ最後のユーザーさんとの接点としてUIデザインが存在するみたいな感じで思ってますね。 だからデザイン全体って言うと本当にグラフィックとかもあるし、 でもはたまたビジネスデザインみたいな言葉もあったりして、 本当にデザインって意味自体だと設計するとか衣装を作るなので、 何かしら形のないものに形を与えるというか設計するという行為が全部デザインなんだと思うんですけど、 私が特に関わっているUXとかUIっていうとそういう意味、デザインの意味っていうのは今申し上げたような内容かなとは思ったりします。 UX、そうですよね。UIデザインはすごくわかりやすくて、形になっているというかフィグマとかであって、 一方でなんだろうな、UXの設計デザインっていうところを見えるかというか形にするみたいなのって結構難しい。 そうですね。だからUXデザイナーの専門性ってどんなスキルがあったらとか、 何ができたらUXデザインができるって言えるのかみたいなところで言うと、 簡単に言うと本当にユーザーさんを一番理解している人みたいな感じだと思っていて、 それこそそのためにユーザーインタビューとかリサーチの活動があったり、 それをサービスの中でユーザーさんはどういう行動をしているのかっていうのを、 カスタマージャーニーマップみたいなもので可視化したりとかっていう形で、 やっぱりそのままサービスの中で見える形にはならない。 それをするのはUIデザイナーの仕事だから、 いろいろユーザーさんに詳しくなっていく、調査していく、 チームに共有するための資料としての可視化されたものっていうのはあるけど、 最後ユーザーさんが触れるところに何かUXデザイナーのアウトプットがあるかっていうと、 集大成がUIデザインになっているみたいな、そんなイメージですかね。 ありがとうございます。ちょっとチャプター変えます。 # UXデザインとシナリオテスト。複数開発チームとの連携するメリデメ。 今お話し聞いていてすごい面白いなと思ったのが、 Qエンジニアとかテストエンジニアの1個の仕事として、 私はシナリオテストという風に言うんですけど、 今回作る新機能とかを使って、ユーザーがどういう風に操作をしていくかとか、 ユーザーがやりたいゴールがあるので、それに対してどうシステムや新機能を使っていくかというので評価をするんですね、新機能。 今お話しされていたUXデザインと対応する、作る側と検証する側のセット、普通になるかなと思ったんですね。 だからUXデザインで最初まだその機能がないときって、ユーザーの動きも何もないから、 そこをシナリオというかこういう動きをするだろうとか、ゴールに向かうためにはこういう流れで操作するだろうみたいなことを設計するっていうのをUXデザインがやっていて、 そこがうまく一貫しているかっていうのをQAの方が検証してくださっているっていう、そこは繋がってそうですね。 ちょっと別のトピック、今日話そうって話してたトピックが別になっちゃうんですけど、 このデザイナーとQnAの連携ってもっとできるような気がしてきて、今話聞いててそこの部分っていうのかもしかしたら、 今自分がシナリオとユーザーシナリオを作るときはあんまりデザイナーさんのそのUXの、例えばカスタマージャーニとかあんまり見てなくて、 独自でこう使うだろうなとか、新しく今回初めてVoiceを使うユーザーさんだったらこう使うだろうとか、 めちゃくちゃ慣れてる人だったらこういう動線でこの機能を使うかもっていう視点で作ってるんですけど、 そこのベースとして情報とインプットとしてカスタマージャーニとか当初考えていたUXデザインの成果物っていうのを、 例えばインプットとして使うっていうのももしかしたらいいのかな、最初の狙いの通りなのかそうじゃないのかっていう。 確かに。多分今聞いててQnAの方が作るシナリオって結構網羅的であることとかも重要なのかなと。 例えば新規の人だったらこうとか。もちろんUXデザインをするときはそこが成り立つかっていうところは見るんですけど、 結構こういうユーザーのための機能みたいなところとかはある種ユーザーをフォーカスして、 それをメインのシナリオとして考えてるみたいなところがちょっと視点が違うのかなっていうのは思ってて。 でもかといってその人しか使えない機能になってはダメなので、一番その人が使って価値を感じるっていうところを中心に作ってるっていうところが役割の違いとしてありそうっていうふうには思いましたね。 確かに確かに。なんかいい例あるかな。 UXデザインのときに今回こういうユーザーにアプローチしたいみたいな人だったりとか、 ペルソナほど具体的じゃないのかな。 そうですね。だから私たちのサービスでいうと、本当にそれこそ新規のリスナーさんとかまだ使い始めて浅い方なのか、 すごく使い込んでいる方でたくさんコンテンツを聞いてくれてる人なのかっていうところでまず大きく違っていて、 結構ざっくりそういう活動量、サービスの中での活動量みたいなところで分けることが多いかもしれないけど、 プラットフォームの特徴としてはコンテンツも多種多様あるから、 例えばこういう系のコンテンツを聞いてる人とか、そういうような聞き方をすることもあるとか、 あるいはVC以外に普段こういうSNSを使っている人とか、そういう聞き方で、 よく言われるような何歳でどういう職業をしててみたいなペルソナは、 なかなかサービスのプラットフォームで本当にコンテンツに人がひも付くっていう構図になっているから、 職業とか人数で分けるのは違うけれども、結構サービスとの関わり方みたいなところで分類して、 今例えば本当にたくさん聞いてる人が聞きやすくなる機能だよねとか、 もっとその方たちがコミュニティを盛り上げていけるような機能だよねとか、 あるいは新しく入ってきた人がよりコンテンツに興味を持って聞きたいと思ってくれるような設計だよねとか、 そういうことが多いかもしれないですね。 確かに。その観点は真似をさせてもらいたいです。 ぜひぜひ。 確かに。ありがとうございます。 今回もう一個トピックを考えていて、デザイナーさんとキミエンジニアの一個の共通点、 形式的な共通点として複数の開発チームに対してアプローチというか、 連携をしながら自分の仕事を進めていくという共通点があるかなと思っていて、 実際どうですかというか、複数チームとやり取りするで、各案件のフェーズも違ったりするので大変ですか? そうですね。多分ファミリーさんも大変だと思うんですけど、 機構を切り替えるみたいなのはちょっと、今だからいろんな、進行度合いも違ったりとか、 細かいんですけどプロジェクトの名前が似てたりとか、今何の話だっけとか、 そういう切り替えみたいなところは結構難しさはあったりはします。 でも良さもあって、複数やっているからこそ、もちろん一個のプロジェクトは分かれているとはいえ、 一つのプラットフォーム上、一つのサービス上で起こっていることだから、 それ全体的に見れているというところは良さでもあるなと思って、 関係するじゃないですか、絶対違うプロジェクトでも。 だからそういう視点で、こっちがこうなったらこっちがこうなるなみたいな、 そういうことに気づけたりとか、そういうのは私は結構大変だけど部分的に見るよりも、 全体的に見る方が、より気づけたりとか、より良くしていけるという視点になれるなという良さも感じています。 そうですね、確かにコンテキストスイッチは結構、分かります。 Qtmはのんちゃんもいるので、多少分担している方もいるんですけど、確かに確かに。 良さというところもすごい一緒だなと思っていて、 例えば開発の進め方だったりとか、 お互いのプロジェクト、プロジェクトAとBで似たような箇所に手を入れる時があるので、 その時にそれぞれの機能の関連性とか整合性みたいなところを確認しなきゃいけないよねとか、 それぞれの機能の組み合わせで挙動がどうなるか確認しなきゃいけないよねというのは、 両方見ているからこそ気づきやすいのかなというのが確かに思ったりします。 結構プロダクトも分かれてたりするじゃないですか。 でも、進め方としていいなと思っているのは、 プロダクトごとに担当がついているという縦割りじゃなくて、 一つのプロジェクトでこういう体験を作るってなった時に、 プロダクトも飛び越えて横断的に開発するっていうのは、 それもそれでまた大変さはあるんだけれども、 これまで私、話すれちゃうかもしれないんですけど、 結構大きい会社で働いていたことが多かったので、 すごくそういうのがチームごとにも晴れちゃっていて、 そうすると、この体験を作るにはこのプロダクトだけじゃなくて、 あっちのプロダクトのここのちょっと直したいんだけどな、 みたいなことってすごいあるんだけど、 そこを超えるのがめちゃめちゃ大変だったんですよね。 全体横断して重宝無尽で動けるっていうのは、 やり方としてはすごくUXを作るっていう意味だとめっちゃいいなって思ってますね。 確かに。 私もその前の会社は一箇所大きくて、 プロダクト間のそれこそUIの統一性とかが全くないというか、 ユーザーからするとちょっと使いづらい、 勤怠のシステムと給与のシステムで見た目が違って、 なかなかそこの合わせようみたいなプロジェクトが立ち上がらなくて、 みたいなのもありました。 ということで、時間になってきたので締めたいと思います。 今回はデザイナーのキュアさんにお越しいただきました。 ありがとうございました。 ツイてもいろいろあって勉強になったので、もっと連携していけばいいなと思いました。 ありがとうございます。 ありがとうございました。 # #206のコメント返し😍 コメント返しのコーナーです。今回は206話目のコメントを開始します。 1週間前の206話目では、プロジェクト管理の失敗談についてお話をしました。 コメントは、みずけんさんからいただいております。いつもコメントありがとうございます。 失敗をちゃんと失敗と唱えて、きちんと自分のこととして振り返って、 次に活かそうとされているのは素晴らしいなと思います。 自分はそんな風にできているかな?失敗は仕組みで改善ですね。 はい、その通りでございます。 自分の学びを個人の反省としてするのももちろん大事だし、 組織としてどういう風に成し組みにできたら、 次は失敗しないだろうか、同じ失敗をしないだろうかという観点もすごく大事ですよね。 今回結構勇気を出して自分の失敗談を話したんですけど、 喋っているうちに収録しながら喋っていて落ち込んでくるみたいな、 そんなこともありましたが、 でも次の過程にしないといけないですよね。 100発、100中というのはありえないので、 失敗から何を学んで次に活かしていくかということは大事にしていきたいなと考えております。 はい、ということでコメント開始でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回もですね、週末版ゆる会です。 おすすめの紅茶ブランドを参戦についてお話をします。 私、紅茶が好きなんですよね。 ということで、たまには紅茶の話でもしてみようかなと考えております。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は 是非、画面右下、ハートマークでいいねを押していただけると、とっても励みになります。 またですね、今オフ会を絶賛企画中でございます。 読書会と食事会をします。 ソフトウェアですとしなんしを一緒にやめませんか。 新しい仲間とお出会いませんか。 興味のある方は、チャンネルページに固定してある放送をお聞きください。 今、Googleフォームにて、参加可能な日程を調査しております。 提出の期日が明日かな、7月13日日曜日の正午となりますので、 お忘れずに提出をお願いします。 それではまた明日、お会いしましょう。 ごきげんよう。