ユーザー満足度に注力するプロダクト開発におけるエンジニアの役割

はじめに

こんにちは、crowdworks.jpの開発をしているエンジニアの駒井です。

プロダクト開発において、ユーザー満足度は最も重要な指標の一つです。私たちのチームではこの満足度をプロダクトゴールとして設定し、開発を進めてきました。本記事では、そのような環境下でエンジニアとしてどのように価値を提供してきたか、具体的な取り組みと成果を共有させていただきます。

※なぜユーザー満足度をプロダクトゴールに設定したのかについては、チームの PO が書いた下記の記事をあわせてご覧ください。

note.com

チーム戦略

ユーザー満足度をプロダクトゴールとして追うにあたり、下記の 2 つの軸で戦略を決めました。

仕事の発注（クライアントの体験）の改善
仕事の検索（ワーカーの体験）の改善

それぞれの軸に対して、私たちは開発チームを内部で 2 つ（発注と検索）に分割することを決定しました。これは単なる人数の都合ではなく、各チームが特定の領域に深く関われるようにするための戦略的な判断でもあります。

仕事の発注（クライアントの体験）の改善事例

次に具体的な事例を紹介します。仕事の発注体験では、有料オプション「急募」の価値がワーカーにもクライアントにも十分伝わっておらず、機能に一貫性がないという課題がありました。

Before

仕事依頼画面：
- シンプルに訴求が弱い。
仕事検索画面：
- 急募オプションが付与された仕事には「急募」というラベルが付帯し他の仕事に比べて目立つようなデザインで検索結果に表示されるようにはなっていたが、上位表示などがされるわけではなく、新着順などにしない限り見つかりづらい状態。
- また、「急募」の検索絞り込みによって表示される仕事は、依頼画面の「この仕事の特徴（旧特記事項）」で急募が選択されている場合であり、オプションとは無関係である。

After

改善後には、クライアントにとって価値のある PR 体験（露出体験）を提供することができるようになりました。

仕事依頼画面：
- 訴求内容の改善。「オプションをつける」ボタンの付与。
仕事検索画面：
- 仕事検索画面で急募を絞り込んだ際に、急募オプションの仕事が表示されるようになった。
- さらに絞り込み条件を整備し、ワークスタイルに合わせて仕事を検索できるようになった。

また、最終的な UI になるまでには段階を踏んでリリースしました。仕事依頼画面の「この仕事の特徴（旧特記事項）」の中で修正後に残らない項目（複数人募集など）に関しては、修正後のリリースまでの間に仕事が作成されている可能性がありました。そのままデザイナーから頂いたデザインを実装すると、古い項目で募集された仕事の露出機会が失われてしまいます。そのため、先に仕事依頼画面の修正のみをリリースすることで古い項目で仕事が募集されないようにし、そこから募集終了までの 14 日間は古い選択肢も検索条件として残しておき、新旧両条件が表示されている状態にしました。

小さなことかもしれませんが、このように実装前に PO やデザイナーと相談して実装方法やリリーススケジュールを決めることがユーザー体験にもつながるため非常に重要であると思っています。

仕事の検索（ワーカーの体験）の改善事例

次に仕事の検索体験の事例です。下記のようにユーザーから複数検索の方法が分からない・知らない旨のご意見が届いていました。

ユーザーからのご意見①

検索機能で案件を探す際に特定条件の案件を複数除外したいのですが、除外キーワードに入れてもヒットしてしまいます複数条件指定することは出来ない仕様ですか？複数指定できる場合はやり方を知りたいです。複数指定不可であれば、今後対応の検討して欲しいです。

ユーザーからのご意見②

含めないキーワードで「アンケート」と指定しています。他にもたくさん打ち込めたら助かります。

他にも、除外キーワード検索できることを知らずに「Canva -20 代」と検索エリアに打ち込んでいるユーザーもいれば、「アンケート,20代,女性」とカンマで区切ってしまっているユーザーもいます。

Before

キーワードをスペースで区切ることで複数語検索ができ、通常のキーワード検索では AND 検索になり、除外キーワード検索では OR 検索になりますが、現状の UI ではこれが伝わりません。また、除外検索がデフォルトでは畳まれており、チェックをつけるまで除外検索機能に気付いていないユーザーもいます。

旧キーワード検索

After

改善後は下記 2 つのアプローチによって正しく複数語検索できるユーザーが増え、除外検索を使いたい人が使えるようになりました。

「キーワードをスペースで区切ることで複数語検索ができる」ことをユーザーに伝える
除外検索を表に出す

新キーワード検索

またこちらに関しては、実際にユーザー様からお喜びの声をいただくことができました。

ユーザーからの声

ユーザー満足度を軸とした開発におけるエンジニアの役割

こういった事例を通して、ユーザー満足度を軸とした開発におけるエンジニアの役割について私なりに考えてみました。

① チーム協業

私たちのチームではプランニングの前に必ずバックログリファインメントを行い、PO が施策の内容や優先度について説明を行います。その際、エンジニアとして要件定義の段階から積極的に関与することを心がけました。具体的には下記のようなことを行いました。

技術的な実現可能性の早期確認
代替案の提示と議論
プロトタイプの作成による事前検証

この過程で、エンジニアの視点を活かしながらより良い解決策を見出すことができました。急募オプションの改善プロジェクトはその例で、実装前に PO やデザイナーと相談して実装方法やリリーススケジュールを決めることができ、ユーザー体験を損なわずに開発を行うことができました。

② 徹底的なユーザー理解

また私たちのチームではユーザーを招待したスプリントレビューを行っており、基本的には職種を問わずチームの PO やデザイナー、エンジニアが全員参加しています。これにより、行った施策の効果や課題を全員がより深く理解し、より良いプロダクトを作ることができます。インタビュアーは PO やデザイナーが担当することが多いですが、可能であればエンジニアも担当することでよりユーザーに近い視点を持って開発を行うことができるようになると思っています。少し前ですが私もインタビュアーを担当したことがあり、自分が開発した機能に対してエンジニアの視点で気になる質問等を聞くことができたので、非常に有意義な経験になりました。

③ 技術的な価値提供

発注チームの急募オプションの改善では既存のユーザー体験を損なわないよう、以下のような技術的なアプローチを取りました。

古い仕様での検索条件の一時的な保持
新旧の検索ロジックの並行運用
データの移行と整合性の確保

また、改善事例では取り上げませんでしたが、検索チームでは「職種に合ったおすすめカテゴリから仕事を探せる」機能も開発しました。職種別に直近の自主応募総数をカテゴリ別に集計するなどの重い処理が発生するため、初めはスロークエリが発生してしまいましたが、クエリチューニングを重ねてパフォーマンスを改善しました。

これらの技術的な取り組みは、直接的な UI 改善と合わせて、総合的なユーザー体験の向上に貢献していると思っています。