クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

古株なエンジニアが改めてUXの回復に取り組んでいる話

まえおき

みなさんこんにちは、エンジニアの@YusukeIwaki です。2015年の春に入社してもうすぐ4年、気づけば周りのメンバーは半分くらい変わっていて、古株扱いされる身となってきました(苦笑)

半年くらい前までずっとアプリチームでAndroidアプリつくったりスマホアプリ向けのAPIを作ったりしていましたが、2018年11月ごろに、なんかの話の流れで「クラウドワーカーを探す」機能(以下、ワーカー検索)の改善をやることになり、今に至ります。

今回は、直近3ヶ月間くらいのワーカー検索の改善の中で強く意識しているUX改善に対する思いを改めて共有してみようと思います。

※ エンジニアブログにもかかわらず技術的要素は少ないかもしれませんが、あらかじめご了承ください

なぜUX改善なのか

きっかけは読書でした。

これを読み始めて、「あ、自分は "やりかた" とか "機能" にこだわりすぎているのかもしれない」と改めて思い直しました。

機能で数字は上がらない。熱心に使う人がいるから数字が上がる。

これまで自分の身の回りで起きていたこととして、MVP(minimum viable product)のように"やりかた"にこだわり「○○の機能をつけたら△△率が上がった」ことが施策の成果に見えてしまい、実は全く理想的な機能には近づいていなかった、みたいなことが3回ほどありました。

UX改善も "やりかた" と解釈してしまうと、おそらく同じように「□□というペルソナを仮定して○○のデザインとナビゲーションを改善したら△△の数字が上がった」みたいな結果に帰着してしまうでしょう。

いろいろ失敗も重ねつつ機能を作ってきて改めて実感するのが、実際にユーザは機能を気に入っているのではなく、機能を通じた"何か"に共感をしていることがほとんどだということでした。

例えば、初期のクラウドワークスAndroidアプリには「アプリ起動時には前回最後に検索した条件での最新の検索結果が見られる」という機能がありました。これは全く意図して作ったものではなく、実は"初期化漏れのバグ"でした。ところが、なんとなくそのままリリースしてみると「通勤電車の中でパッとスマホアプリを起動して、数秒でいい仕事があるかないかを見れて嬉しい」という効果があり、結果的にはDAUの向上に大きく寄与することになりました。

f:id:YusukeIwaki:20190218111848p:plain

これは要するに、 "検索する機能" そのものや "検索条件を真面目に保存する機能" が求められていたのではなく、 "電車の中で数秒眺めるだけで、いい仕事があるかどうか確認できるお手軽感" が当時のアプリには共感され使われていたのです。

もう少し一般化すると、

  • 何をしたいユーザが
  • なぜ(他のやりかたではなく)そのシステムを使うと決めたのか理由づけを明確にする

のように感情的な背景を深く分析しそれを反映したストーリーを作ることがキモだということです。

そして「UX改善」に取り組む価値は、結果ではなくそのストーリー作りにあります。

「使ってもらえない」という確信があった2018年11月時点でのワーカー検索機能

さて、ワーカー検索の話になるのですが、昨年11月に改善に着手したときは割と散々な状況でした。 検索UIが複雑でソースコード的にも負債だらけでしたが、それ以上に「どう使っていいのかわからない」という絶望感が漂う機能でした。

具体的には、自分が過去にクラウドワークスで副業の案件を(自費で)発注した際の体験をベースに

  • 副業でWebサービスを作る仕事を受けていたのだけど、CSSだけは自力ではどうしてもきれいに書けない。
  • 3年後も使えるような完璧なCSSは求めていない。ある程度メンテがしやすいCSSのベースを1〜2日くらいでサクッと作ってくれる人を探している。
  • 予算的に2万以上は出せない。値切るつもりは全くないが、品質に見合わないお金は出したくない。

のような気持ちをもって改めてワーカー検索を操作してみたところ、

  • CSS で検索してるのに「PHPできます( ー`дー´)キリッ」というエンジニアがいっぱいでてくる
  • PHPできますエンジニアを除外したいが、その手段がない
    • -PHP などNOT検索はできない
    • 職種の精度がよくない、というのは触っているとわかるので、「職種で絞ると、マークアップができる有能な人も一部除外されそうだ」という不安が拭えない
    • スキルによる検索もまたNOT検索はできない
    • → 全件見ていくしか無い・・・できるか!!!(ノ`Д´)ノ彡┻━┻
  • CSSというキーワード検索で絞り込んでいたはずなのに、職種を絞ったりいろいろしていたら、気づいたらキーワード条件が消えてしまっている... (ノ`Д´)ノ彡┻━┻
  • いくらライトな案件とはいえ1日2日でこなす技量がある人なのかどうか、過去の実績が見えないので判断がつかない

など、信頼を失うには十分すぎるぐらいの問題がありました。これは、UXの改善する以前に「回復」をする必要がありました。

ペルソナやカスタマジャーニーマップなどを新たに作るまでもなく、「自分が使っていただけでもこれだけの不満があるのだから、着実に無くしていくのが絶対に早い」と確信をもち自分なりの改善のスタートを切りました。

UXの回復を支えたもの

本当に必要な機能以外を削ぎ落とす取り組み

UX改善のストーリーづくりにこだわろうとすると「UXを回復をした先には何があるのか」ということに着目したくなります。しかしながら、夢物語を語るにも、2018年11月時点でのワーカー検索機能は仕様も動きも複雑すぎました。

  • キーワード検索って何を対象に検索しているの?
  • 絞り込みの「職種」「仕事カテゴリ」ってどこで設定されているの?
  • 「スキル」のタブが出たり出なかったりするのはなぜ?

などなどの疑問の解消をし、そのうえで無駄があれば削減することが最初にやるべきことでした。

f:id:YusukeIwaki:20190218112925p:plain
「検索対象の情報をワーカーはどの画面でどういう気持ちで設定するか」の整理

今回の改善では、このあたりはPOとデザイナが中心にかなり整理をしてくれました。

あらためて整理をしたことで

  • 「エンジニア・デザイナー」「ライター・事務・その他」という大カテゴリ分けは、検索ナビゲーションとしては不要
  • スキルは単体で絞り込むニーズはほとんどなく、タブごと削除してよさそう
  • 職種とスキルの両方で絞り込める機能が必要

など、不要な部分と必要な部分の明確化ができました。

実際に検索をしてみる会

実際に触ってもらって「この機能は使用感がヤバイ」ということを共感してもらう会を2回開催しました。

↓は、2回目の会のアジェンダのキャプチャです。ネガティブなことは一切書いていない、単純に検索画面を触るだけの会のように見せています(苦笑)

f:id:YusukeIwaki:20190221111957p:plain

ただ1つポイントとして、

  • 暗黙的な要求が生まれるようにする
    • アプリエンジニアだったら、(gitってキーワードでは検索しないだろうけど)当然Gitも使えてほしいよね、など
    • SwiftとObj-Cの両方ができる人を探そうという明示的な属性だけではなく、未だにObj-Cで負債コードを抱えているのを積極的に解消してくれる姿勢の人がいいよね、など

ようなシナリオにしてあります。こうすることで、

f:id:YusukeIwaki:20190221112014p:plain

単にUIがイケてないとか検索精度を確かめるだけのタスクにとどまらず、「検索精度が悪いうえに、次の一手が打てない」という使用感の課題について共通認識をもてたように思います。

現実の実装依存関係を反映した改善ストーリー作り

「理想はこういうUIだ」から入ると、どうしても現実との乖離が激しく「中途半端に表示がバグった状態」みたいなのが生まれてしまいがちです。

今回は、なるべくそうならないように、POやデザイナーがいろいろまとめた改善ストーリー原案に対して、エンジニアが「○○をやるためには△△が先にできていないといけない」という実装の依存関係の情報をできるだけ提供し、それを反映した絵を作ってもらいました。↓

f:id:YusukeIwaki:20190221113318p:plain
まとめページ

この絵はもともと、自分たちが進む方向をなるべくブレないようにする目的で作ったものでしたが、実際にはこれが一番役に立ったのは実はPull Requestのレビューのときでした。「今回のPull Requestは、この絵で言うSTEP2のところの○○の機能です」っていうのを端的に説明するだけで、他チームの人でも絵を見れば改善の方向性がなんとなくわかるので、「あとですぐこの部分は削除するんだったら、(コード的にはいまいちだけど)今すぐ直さなくてもいいですね」みたいな効率的なレビューにつながりました。

また、「STEP1ではここまで」「STEP2ではここまで」という段階的なリリースを前提としたストーリーにしたことで、巨大な(=レビュー不能な)Pull Requestが作られることが少なくなり、結果的には改善をスピーディーにリリースできました。

f:id:YusukeIwaki:20190219223817p:plain

ワーカー検索以外の機能に対する改善活動

改善のマインドやモチベーションを落とさないことを目的として、ワーカー検索以外の機能でも「これ、バグってるんじゃない?」って思われそうなものは積極的に直すor機能を消す取り組みを継続的におこないました。

f:id:YusukeIwaki:20190222102135p:plain

小粒な改善(↑のように数行変えるだけで「おや?」と思う部分が無くせるもの)も最初のうちは結構たくさんありました。

最終的にはモチベーションが続かず、かなり断続的な取り組みになってしまいました。しかし、普段見ない部分のソースコードを見る機会が増えることにこの取り組みは意味がありました。

改善活動やり始めた頃の(ワーカー検索の改善に本格着手する前の)Tweetですがこんなことをつぶやいていました↑ ほんとこれに尽きます。

で、ワーカー検索って改善したの??

残念ながらUX的にはまだまだです。

ただ、UXを回復させていく中で機能を大幅に削ぎ落としたおかげで、難解なソースコードが大幅に簡略化され、改善サイクルを3倍くらい早く回していける状態にはなりました。

おわりに

スキル絞り込み機能(先に書いたストーリーの最後のSTEP)をリリースしたときには「単なるリファクタではなく、単なるUX改善でもなく、両方を融合した素晴らしい取り組みができたぞー!!」ってものすごく自慢げに思っていたのですが、いざその取り組みをブログに書き起こしてみようとしたら、非常にとりとめのないものになってしまいました。

表面的な機能やUIの改善ではなく、ストーリーを組み立てることに注力する姿勢が少しでも共有できていればと思います...。

 

クラウドワークスではUX改善を軸に、サービスを成長させていく仲間を絶賛募集中です。

www.wantedly.com

© 2016 CrowdWorks, Inc., All rights reserved.