前置き

メインサービスcrowdworks.jpのユーザーサポート支援チーム、名称UDXに所属していました、薄井と申します。

UDXチームはユーザーサポートチームの課題解決を技術的に支援することを主な目的として活動していましたが、この度、期が変わったタイミングでその活動に一区切りをつけることになりました。

本記事では、チーム発足から解散するまで、期間にして2023年5月から2025年9月までの2年余りで取り組んだ主な施策の振り返りを記していきます。なお、一連の施策の成果として月間100時間を超える業務工数削減を実現しております。

チームメンバーは、エンジニア3~4名（途中で初期メンバーは全員卒業）、プロダクトオーナー1名（+2024年9月までプロダクトオーナーアシスタント1名）で構成されていました。

筆者がUDXチームに加わったのはチーム発足から約1年後の2024年6月になります。初めの1年については直接の記憶はなく、記録を見て文をしたためております。そのため、2024年6月以前以後で期間を分けて紹介したいと思います。

なお記事中にて技術面の言及はそれほどなされません。あらかじめご了承ください。

取り組んだ施策の振り返り

2023年5月〜2024年5月

この期間での取り組みは以下の通りです。順に紹介させていただきます。

管理画面のサービス外連絡申請管理機能にて一覧の表示件数を増やす
管理画面の仕事案件公開前目視チェック機能を改善する
管理画面の出金申請管理機能にてステータスの修正ができるようにする
管理画面の本人確認申請管理機能にて申請否認理由の入力方法を見直す
ワーカーの未出金報酬一覧にて出金ステータスが出金審査中の場合の表示を見直す
管理画面の仕事管理機能にて募集中断理由を保存・確認できるようにする
インボイス発行条件の注釈をクライアント側の応募・相談～契約完了までのやり取りの画面に表示する
機械学習で仕事案件の公開可否を判断する機能を追加する

管理画面のサービス外連絡申請管理機能にて一覧の表示件数を増やす

まとめて承認・否認を行える件数を増やすため、表示件数を20件から100件にしました。これで月7時間のユーザーサポートの業務工数の削減になりました。

管理画面の仕事案件公開前目視チェック機能を改善する

仕事詳細内のNGワードを発見しやすくなるようにスタイルを変更
公開とする判断になりやすいセグメントの絞り込み機能を追加
まとめてアクションを行える機能を追加

などの機能改善を行い、月54時間のユーザーサポートの業務工数の削減になりました。

管理画面の出金申請管理機能にてステータスの修正ができるようにする

ステータスを出金待ちに更新するとユーザに通知が行くため、一度ステータスを出金待ちにしたら管理画面からはステータスの修正を受け付けないのが当時の仕様でした。

ただ、ユーザの状況が変わったりヒューマンエラーが生じたりでステータスの修正が必要になるケースはしばしば発生します。それがクイック出金の申請であれば緊急でテクニカルサポートによるデータ修正が必要になりエンジニアに依頼が差し込まれていました。急な差し込みは当然、エンジニアの作業効率の悪化や開発スケジュールの遅延に繋がります。

緊急のテクニカルサポートが不要になったのがこの施策での成果になります。

管理画面の本人確認申請管理機能にて申請否認理由の入力方法を見直す

本人確認申請審査フォームでは、否認理由のパターンごとにチェックボックスを設けて入力を簡便に行えるようにしています。昨今においてパターンが認められているがチェックボックスが無いケースについて自由入力欄でフォローする必要が出ていたため、これを改善しました。

ついでに生年月日に和暦・西暦の併記の追加などして、月13時間のユーザーサポートの業務工数の削減になりました。

ワーカーの未出金報酬一覧にて出金ステータスが出金審査中の場合の表示を見直す

ユーザが直近のタイミングでの出金を希望していた場合、その出金に紐づく報酬が確定すると、出金ステータスが出金審査中となり各報酬でそう表示されます。ただ審査の実際のタイミングは、まず直近の締め日まで最短で1日、最長で15日前後、そこから振込日まで15日前後あるため、長いと1ヶ月先になります。一応、審査のタイミングについては説明書きもされているのですがほとんど認識されず、「いつまで審査中なのか」「何か問題があるのか」といった問い合わせが発生していました。そこで、もう少し細かく表示制御を行うようにし、説明も補足を加えました。具体的には、お知らせブログ(https://blog.crowdworks.jp/archives/5386/) で紹介された際の内容が詳しいでしょう。

同時にクライアントの返金履歴についても同様の変更を行い、月4時間のユーザーサポートの業務工数の削減になりました。

管理画面の仕事管理機能にて募集中断理由の保存・確認ができるようにする

利用規約に違反している仕事案件については、ユーザーサポートが管理画面から仕事の募集を中断しています。利用規約に違反といっても程度は様々なので、中断理由が知りたいという問い合わせも発生します。ただ、管理画面には理由を記載する機能は設けていなかったので、個々のケースについては担当者の記憶が頼りで、問い合わせ対応に時間がかかっていました。そこで、管理画面で理由を保存・確認できるようにし、またクライアントに対しても各仕事の画面で仕事ガイドラインの大項目のどれに引っかかったのかはわかるようにしました。

成果としては、中断理由が蓄積されるようになったことで、違反パターンの分析が可能になり、今後の改善や取り締まりの判断材料として活用できる基盤が整いました。業務工数の削減については、入力の手間が増えたため差し引きで月1時間となりました。

インボイス発行条件の注釈をクライアント側の応募・相談～契約完了までのやり取りの画面に表示する

一時期は色んなチームがインボイス対応に追われていました。同時にインボイスに関する問い合わせも増加していました。インボイスの問い合わせの8割はクライアントのもの、さらにその内6割が発行条件に関してだったため、クライアント側の画面に注釈を表示しました。

リリース後、クライアントからのインボイス発行条件に関する問い合わせは71%削減されました。

機械学習で仕事案件の公開可否を判断する機能を追加する

仕事案件は人の目視によるチェックを経て公開されますが、これが平均6時間以内に行われることをユーザに案内しています。

ただ、この目視チェックの業務は逼迫しており、しかもこれ以上ユーザーサポートのみで業務改善を図るのは困難な状況でした。既に2023年6月に色々手を入れたのは先に述べた通りです。

そこで、機械学習によるチェックを取り入れることとなりました。違反案件検知の機械学習モデルの作成と運用については別の専門チームが担当しております。当チームではサービスに組み込む作業を行ないました。

リリース後、月15時間のユーザーサポートの業務工数の削減になりました。

2024年6月〜2025年9月

この期間での取り組みは以下の通りです。順に紹介させていただきます。

同一内容の仕事の複数投稿の場合に公開を差し止める機能を追加する
連絡催促申請から連絡催促依頼に機能を変更する
AIエージェントのPoC
メッセージ機能における短縮URLの利用制限を追加する
本人確認申請機能を改善する
着信認証サービスのAPIメジャーバージョンアップに対応する
メッセージ機能の利用においての規約違反への対策

同一内容の仕事の複数投稿の場合に公開を差し止める機能を追加する

先にて機械学習判断で公開を承認する機能を導入しましたが、それによって公開が自動・短時間で行われるようになったため、内容が同一・酷似の仕事を大量に投稿する違反行為が目立つようになりました。複数投稿は他のクライアントの仕事案件をワーカーが認知することを阻害します。なので取り締まりの必要があります。

ただ、対策が必要になってから割とすぐに諸事情でチーム施策の開発をしばらく中断して別件に掛かる必要があり、その間に影響を看過できないとして仕事依頼ガイドラインの改訂(https://blog.crowdworks.jp/archives/5927/) と取り締まり運用の変更が発生しました。

複数投稿という違反行為に当てはまる仕事案件の公開を防ぐのはあるべき機能なのでリリースは後日に行いましたが、当初に期待されていた成果は見込めない状態でした。鉄は熱いうちに打ちたい！　・・・が、そうできないこともしばしば起こります。

連絡催促申請から連絡催促依頼に機能を変更する

連絡催促申請機能が実装された当時ならいざ知らず、現在においてはユーザー理由で否認されることはないので、人による承認を挟まずに済むように自動化しました。お知らせブログ(https://blog.crowdworks.jp/archives/6076/) でも告知を行いました。

この施策、2024年7月末に着手し始めたのですが、度重なる先送りの末、9ヶ月先の2025年3月にリリースされました。

AIエージェントのPoC

AI活用は当社でも大変ホットな話題ですが、AIエージェントのPoCを行うにあたって社内の定常業務が多いユーザーサポートの業務効率化を対象にするのが良いだろうとなり、当チームで請け負うことになりました。開発期間は、2025年2月から調査を始めて、3月の初めにAzure AI Serviceにアカウントを作って、6月末で幕引きとなりました。Azure AI Serviceを採用したのは当時の時点でSalesforceとの連携を考えてのことでしたが、この界隈、日進月歩で進化しているので今だったらまた別の選択肢を採択するのかもしれません。

具体的な題材としては、ユーザーの問い合わせに対して回答のメール文面の自動生成、というものでした。

回答の結構な割合がメールテンプレートの利用とFAQからの引用でできているため、RAGでいい感じにできたらいいな〜といった考えでした。ただ、6月に一旦動くものができたとき、実運用に必要な精度を確保できておらず精度改善をするとしても一朝一夕で終わるはずもない、といった具合でした。元々AIの知識が豊富だったわけでもない当チームでは、今後の改善の確証が得られないとしてPoCに留めるという運びになりました。・・・その後の割とすぐに、そもそもチーム自体が解散となるのが決定したわけですが。

メッセージ機能における短縮URLの利用制限を追加する

AIエージェントPoC期間中、エンジニア全員がそれに専念できたわけではなく、かくいう自分が他のことをやっておりました。SalesforceAPIのバージョンアップ対応とか、一部有料オプションの不具合の解消とか、などなど。中でも特筆すべきが、見出しに書かれている通りです。お知らせブログ(https://blog.crowdworks.jp/archives/6152/) にも掲載されました。

なお短縮URL制限も含む、メッセージ機能の利用においての規約違反への対策全般については、根が深い話であり後ほどまとめて記述したいと思います。

本人確認申請機能を改善する

管理画面側については約2年ぶりの手入れになります。まず、提出画像と審査フォームを横に並べるようにし、加えて提出画像の表示サイズを大きくしました。これで審査がだいぶ進めやすくなりました。また、前回分では含まれなかった住民票の和暦・西暦の併記の追加や、否認理由のグルーピングなども行いました。

また、ユーザー側の本人確認申請機能にも手を入れました。具体的には、本人確認書類の画像を提出してもらう際の注意事項の表示で、事例紹介のイラストの見直しと、位置の変更を行いました。社内での取り組み共有の場で用いた画像が説明がわかりやすいと思うので掲載します。

トータルで月14時間のユーザーサポートの業務工数の削減になりました。

着信認証サービスのAPIメジャーバージョンアップに対応する

クライアントが仕事の公開を初めて行う際には着信認証を求めています。

利用中の着信認証サービスでAPIのメジャーバージョンアップがあり、それに伴って作業が必要になったため対応しました。コード変更のボリュームは大したことはなかったのですが、何しろ動作確認に手間がかかり・・・テストでカバーできるのは一部だし・・・。結局、9月末ギリギリで対応しました。

メッセージ機能の利用においての規約違反への対策

crowdworks.jpは利用者が多く、メッセージ機能は規約に違反した文面が投稿されることもしばしばあります。というより、昨今ではむしろ激化しており、対策の必要の緊急度・重要度が弥増しています。ユーザーに対しての注意喚起も追加しております。

規約違反の文面の投稿を特徴的な表現で検知し、投稿の抑止を行う機能も増えました。先に述べたメッセージでの短縮URLの利用禁止もそれに含まれます。他の機能では、投稿者の利用停止を自動で行う機能が多いです。中には、大きな期待をもって開発した機能を実際にリリースしたら期待と成果とにギャップが生じたということもありました。現在は他のチームが改善を引き継いでいます。

後書き

以上、取り組んだ施策の振り返りを行なってまいりました。記事を書くためにやったことを見直していて、時間の経過を感じる点がありました。1~2年後に同じ機能の改善を行なっていたり。渦中にいると過去のことも含めて全体を見るのはなかなかできていないものということでしょう。

ところで、卒業した初期メンバーが、チーム立ち上げ当時のブログ記事を書いてくれていました。

今後チームでやりたいこととして、ミッションの見直しやスクラムの改善などが挙げられています。本記事では施策に注目しチーム運営については述べなかったのですが、ミッションの見直しは実施しましたし、スクラムの改善も相当力を入れて取り組んでました。スクラムについては、途中、開発施策とのバランスが悪いのでは？という意見が出るほど前のめりでやっていました。しかし、チームの成熟度は高められたのだろうか・・・？　中々難しいことも多かったです。とはいえ、失敗もまた経験。2年の取り組みを通じて培った経験を今後も続くチーム開発にて活かしていければと思います。

最後に、クラウドワークスグループでは共に働く仲間を募集しております。ご興味のある方は以下のリンクから採用情報をご確認ください。