SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

UIデザイナー兼UXリサーチャーが課題と向きあい得た気づきとは Chatwork・仁科さんが語る

  • このエントリーをはてなブックマークに追加

Chatwork流、デザイナーの業務の取り組みかた

――デザインだけでなく、UXリサーチに興味を持ったきっかけについて教えてください。

アイスタイルに在籍していた当時は私の力不足もあり、ユーザーの声をプロダクトに反映する部分まであまり手を回すことができませんでした。しかし、少人数でプロダクト開発を行っていたAnyPayでの経験やほかのデザイナーの方の発信を見聞きするなかで、ユーザーの声を聞かないと、実際の使用シーンやお困りごとを理解することはできないと痛感したんです。

Chatworkのユーザーさんは、中小企業や非IT系のお仕事をしている方がとくに多いのですが、長くIT界隈で仕事をしてきた私は、そういった方々の働きかたを全然イメージすることができなくて……。そう感じていたときに、デザイン顧問の方とPdMチームでユーザーインタビューを積極的に取り入れるべく動いていることを聞き、私もインタビューを取り入れる提案をしていくようになりました。

――デザイナーはどのような形で業務に取り組んでいるのですか?

取り組みかたは大きく3つあります。ひとつはPdMがさだめた新機能をリリースするためのプロジェクトロードマップがあり、時期がくるとプロジェクトごとにデザイナーがアサインされていくという形です。常にチームの半数ほどのデザイナーがプロジェクトに携わっています。

グループチャット機能では、社内外のユーザーと案件や部署単位で作成し、複数人で会話を進めることが可能。
グループチャット機能では、社内外のユーザーと案件や部署単位で作成し、複数人で会話を進めることが可能。

もうひとつが、コンセプトチームによる改善活動です。ここでは、ユーザーさんから届いたChatworkに対する要望の中から、1~2スプリントほどで改善できそうなものをチームでピックアップして取り組んでいきます。デザイナー1~2名、エンジニア、PdMを固定し、案件を少しずつ変えながら小さな改善に取り組んでいます。

コンセプトチームは、昨年の夏から実験的に始まったためまだ手探りな部分もありますが、同じメンバーだとナレッジが固定されてしまうので、1年単位で変えていくのが理想ではないかと考えています。まずは試してみて、良いところと良くないところを見極めている状態です。

3つめは、ロードマッププロジェクトからも、コンセプトチームからもこぼれてしまいがちな、小さなデザイン負債の返却です。こちらはチームを作らずに、ブラウザ版ならウェブフロントエンド開発部、モバイル版アプリならモバイルアプリケーション開発部というように、それぞれの開発部にデザイナーが改善事項を持ち込み取り組んでいきます。ユーザー価値だけを追い求めてしまうと、ロードマッププロジェクトやコンセプトチームも、積み上がっている小さな不整合を改善することがなかなかできないので、こういった枠組みも用意しています。そこまで手が回らないことも正直多いですが、できる場所を用意し、定着するように活動していくことが大事だと思っています。

過剰な説明が裏目にでたことも デザインとリサーチで心がけていること

――BtoBのプロダクトだからこそ、デザインや情報設計の面で意識していることはありますか?

入社してすぐの失敗談でもあるのですが、わかりやすくしたい、でもこれだけでは伝わらないかもしれないと思うあまり、過剰な説明をつけていたことがありました。Chatworkの強みでもある、非ITの方にもわかりやすく使ってもらえることも大切ですが、ユーザーさんの中にはリテラシーが高い方もいらっしゃる。それに、説明の文字が多くなると逆にどこを読んでいいかわからなくなったりしますよね。過剰にはせず、でもわかりやすいラインがどこなのかを探ることにデザイナーはこだわらなければいけないと痛感しました。

ここにはこの機能がありそうだなという他社さんのベストプラクティスから大きくずらさない。利用率が高い機能は手前にだして、あまり頻度が高くないものは少し下げる。そういったバランスをどのようにとっていくかを、今は意識するようにしています。

――リサーチを進めるうえで工夫していることがあれば教えてください。

意識していることはふたつあります。ひとつめは、どんな方にどういうお話を聞くかという「リクルーティング」です。リサーチにおいて最初につまずきやすいポイントであり、私自身も難しさを痛感した部分です。

まずはとにかくユーザーさんに会うことが大切だと思っていましたが、時間をいただけるユーザーさんを見つける部分がとても大変でした。セールスのチームに依頼し紹介してもらったこともありましたが、こちらが聞きたい機能を使っていなかったり、仮説立てした課題を抱えていないなど、私たちが聞きたいことを聞ける人かつ、話す時間をとれるというふたつの条件をマッチさせることが難しくて……。

Chatworkには、プロダクトを使いこなしてもらうことを目的に、カスタマーサクセス部が運営しているチャットがあります。そこにさまざまな会社のユーザーさんが参加してくれているので「こういう課題をもった方にぜひお話を伺いたいです」といったアナウンスを出すことで、最近はお話を伺える方を担保することができるようになりました。

基本機能のひとつ「タスク管理」では、依頼されたタスクをそのままTo Doとして管理することができる。
基本機能のひとつ「タスク管理」では、依頼されたタスクをそのままTo Doとして管理することができる。

ふたつめは、インタビューでお話を伺ったあと、参加したメンバーは「お話を聞けてよかった。解像度も高まったし、改善していきたい」という熱量が高まるのですが、この気持ちをインタビューに参加していないメンバーにいかに伝えるか、という部分です。インタビューが議事録として文字になった途端、とても熱量が薄れるように感じるんですよね。自身でユーザーさんの情報を知りたいと思わなければ、そもそも議事録を読みこまないと思うので、そこをどうやってほかのメンバーに知ってもらうかについては、まだまだ課題が多いです。

ただ、答えが見えきれていないなかではあるのですが、いろいろな工夫も始めています。「もっとユーザーさんを知りたい部」という、社内の誰でも参加できるチャットをつくりました。そこでインタビュー結果のサマリーなどを定期的に配信したり、ユーザーインタビューを始める前に同席したい人を募ったりしています。機会があれば関わってみたい、と思っているメンバーが巻き込まれやすい場所を作ることは大切なのではないでしょうか。

この記事の続きは、「CreatorZine」に掲載しています。 こちらよりご覧ください。

※CreatorZineへの会員登録(無料)が必要になる場合があります。

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/13385 2020/12/21 08:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング