ランサーズのデータ活用を手伝っている話

ランサーズ Advent Calendar 2020 24日目の記事です。 昨日は まなみん さんの 「思考発話法でUXリサーチをしてみた話」 でした。

概要

• 社員ではなく、1人のフリーランス人材（ランサー）として、ランサーズ社を手伝っています。
• 「こんなことをやってきたよ！」という話を、書ける範囲で書きます。
• CRM（顧客管理）x データ活用 の案件を主に担当しています。

注意

本稿は筆者個人の見解に基づく内容であり、関係組織を代表するものではありません。 不適切・考慮不足だと感じさせてしまう点があれば、それは筆者個人の責任によるものです。 どうぞ筆者個人宛てにご指摘のコメントをいただけますと幸いです。

もくじ

きっかけ

エムグラムの社長である @tabaty_shacho さんと一緒に働いていた時期がありました。 彼がランサーズ出身だったこともあり、もともと会社として興味を持っていました。

そんな折に @__godgarden__ さんに声を掛けていただき、何度か技術相談に乗りました。 ちょうどランサーズでデータ基盤を作り始めたタイミングだったと記憶しています。 その後しばらくは Keep in Touch の状態でした。

私が独立してから本格的にランサーズのサービスを使い始めました。 気になったところを片っ端からフィードバックしていたところ「そろそろ手伝ってくださいよ！」と面談の場を設けていただきました。

面談ではCSOの @hsonetty さんが辺り一面の壁ホワイトボードに構想を書き殴って（通称・壁画） 私だったらこういった観点で貢献できるかなと提案したところ「じゃあやってみよう」ということになりました。

私自身がサービスのユーザーでもあるので「データ活用によるユーザー体験向上」をテーマとしています。 ただ、直接的にWEBサイトを改善するのではなく、あくまで社内業務の改善を通しての間接的な貢献です。 「CRM」（Customer Relationship Management：顧客との関係性の管理）と呼ばれる分野が近いと思います。

案件1:顧客セグメント可視化

どのくらいのランサーが新しく利用を始めて、どのくらいのランサーが利用をやめたのか、といったデータを可視化しています。

この図は 『たった一人の分析から事業は成長する 実践 顧客起点マーケティング』 で紹介されている「9セグマップ」です。

この図は 『いちばんやさしいグロースハックの教本 人気講師が教える急成長マーケティング戦略』 などで紹介されている「AARRR/海賊指標」です。

これらを参考にして、利用状況ごとにユーザーのセグメントを分類しました。 ダッシュボードツールで ①全体の数値 → ②切り口によるドリルダウン → ③N1（具体的な1人）と順を追って深堀り、課題を特定できるように整備しています。

※余談ですがランサーズ社のBigQueryは非常に使いやすいです。 機微情報を保有していないので安心して作業に取り掛かることができました。

ちゃんとこの構成でデータを管理してくださっている会社だと、10分で欲しいデータに辿り着けるので最高。もしくはデータ未連携であることが一目で分かるのでNextActionをすぐに相談できる。いずれにせよ非常に助かる。https://t.co/FXOTCzjjI1 pic.twitter.com/9xYSVO3RYp

— ゆずたそ (@yuzutas0) 2020年10月21日

フリーランス人材にデータ分析の仕事を依頼するときには

• 「顧客1人1人を観察せずに機械的な集計結果だけを納品する」（役に立たない）
• 「発注者が最初に渡したデータだけでやりくりしていている」（必要な分析に辿り着かない）
• 反対に「まだ信頼関係が築けていないのに権限やデータを次々と要求する」（信頼できない）

といったアンチパターンがあると思っています。 これらを回避するために、仕事の進め方について、2つの工夫を行いました。

1つ目は「N1」にこだわっている点です。

ダッシュボードの構築を始める前に「N1シート」と呼ぶSpreadsheetを作りました。 ランサーさん1人1人が、どのようなカテゴリの仕事を扱っていて、 どのくらいの頻度・金額で案件を受注しているか、といったデータを可視化しています。 このシートを読み、ユーザー理解の解像度を上げてから、モニタリング整備に着手しました。

モニタリングを整備しようとすると「離脱をいつ判断すれば良いのか」（1週間？1ヶ月？1年？）といった疑問が次々と生じます。 N1のデータを見ていれば、自信を持って「これが適切だ」と判断・提案することができます。

2つ目は段階を追って徐々にデータや権限を共有いただいた点です。

最初はCSVファイルをGoogleDriveにアップロードしていただき、 Google Colaboratory（Colab）で分析を行いました。 発行いただいたGoogleアカウントで作業しています。 ランサーズ社が管理するGoogle Workspaceの内部で作業を完結させました。 必要に応じて権限剥奪や監査ログ確認も出来る状態になっています。

なお、後に集計ロジックを移植することを考えて、Python/Pandasではなく、SQLで集計しました。 Colab（Python/Pandas）でCSVファイルを読み込んだ後、GoogleDrive上にSQLiteファイルを出力。 そのSQLiteに対してSELECTクエリを発行しています。

しばらくはColabやSpreadsheetを活用してアドホックな分析を進めました。 「もっとこういった切り口でも見たい」といった要望に1つ1つ対応しました。 「さすがにそろそろBigQueryやRedashを見てほしい」と関係者が実感したタイミングで権限を追加いただきました。 その間に「データを扱えるだけの作業環境になっている」ことを示すエビデンスを揃えています。

案件2:社内システム改善

部署・システム横断でランサー紹介履歴をチェックできるように仕組みを作りました。

個人情報保護やセキュリティの観点があるので、原則的にはデータを分けることが望ましいとされます。 部署・システムごとにデータを分けていること自体は、健全に事業運営されてきた結果だと思います。

一方で、横断データを手軽に扱えない場合、また別の弊害が生じます。 「同じ人に複数部署から連絡が届く」「前に◯◯案件希望と伝えたのにアンマッチな提案を受ける」など、 利用者にとってBadな体験に繋がるリスクがあります。

そこで「詳細データは別々に管理する」「横断で紹介履歴の有無をチェックする」という折衷案を提案しました。 後者の横断チェックを実現できるようにシステムを構築しました。

履歴チェックはSlackBotを通して行います。 コマンド1つで対象ランサーとの過去のやりとりを探すことが可能です。

スプレッドシートからコピー＆ペーストすると一括検索できます。

また成果を出してしまった pic.twitter.com/S7LPReUdBO

— ゆずたそ (@yuzutas0) 2020年12月10日

最高のUXを実現したことで、ポジティブな感想をいただいています。

各システムのデータをEmbulkでBigQueryに統合しています。 BigQueryに集めたデータをKintoneに反映しています。 @__godgarden__さんと連携しながら進めました。

業務システム（入力箇所）をKintoneに統合してはどうかというアイデアが出ていたので、 ①Kintoneに統合するならそのままKintoneを使う、 ②別のシステムを使うならBigQueryのデータをそちらに流す、 ③何も変えないならシステムはこのまま動き続ける、 といった形で、いずれのパターンにも対応できるシステム構成にしています。

SlackBotはGoogleAppScript（GAS）で動かしています。 GASからKintoneの検索APIを実行して、検索結果をSlackに返します。

Botの実行ログはGASからSpreadsheetに書き出しています。 SpreadsheetのデータをBigQueryに読み込ませて、 利用者数・検索回数・エラー発生数などをダッシュボードに表示しています。 利用者ヒアリングや改善要望と合わせて、改善に活かしています。

「コピー＆ペーストによる一括検索」機能は特に評判が良いのですが、 まさにこの機能は、継続的な改善を通して課題発見・システム開発しました。

案件3:オープンデータ活用

他ならぬ私自身がそうなのですが、登壇スライドやブログを見た人から案件相談を受けることが多いです。 今回も「データ基盤について相談したい」と最初に言われたのは、私のスライドを参考に設計していたからです。

同様に、実力のあるソフトウェアデベロッパーであれば、ランサーズのプラットフォーム内の自己紹介・実績だけでなく、 GitHubやQiitaのアウトプットを見せたほうが（見たほうが）話が早いと感じるのではないでしょうか。 このように職種によってはオープンデータを活用することで体験を改善できるかもしれません。

一方、外部データとの紐付けはセンシティブなトピックでもあります。 いきなりの実践投入ではなく、独立したサービスを作る要領で、PoC的にプロジェクトを展開しました。

オープンデータ活用の鉄則として2つのリスクがあるので、それぞれのリスクを検証しました。

1つ目は「誰のどの課題をどう解決できるか」です。 よくある話なのですが「データを使えばこういうことも実現できる」と妄想だけ広がるものの、 ターゲットやイシュー設定の解像度が荒く、具体的な話を進められずに頓挫することがあります。

そこで、インタビュー・市場リサーチを行い、ユースケースシナリオを洗い出し、顧客課題の仮説をまとめました。 それぞれの課題に対して、極端に振り切ったプロダクト案を複数提案し、インパクトのある領域を絞り込みました。 その上でFigmaのモックアップを作り、ウォークスルーテストを行って、UX・ソリューションの仮説をまとめました。 進め方は 『400のプロジェクトを同時に進める 佐藤オオキのスピード仕事術』 という書籍を参考にしています。

ランサーズ卒業生である @hiroyanumata さんと連携して進めました。 「なぜこの項目を強調するのか？」「なぜこの色を採用するのか？」とロジカルにUIを解説できる凄腕デザイナーです。

2つ目は「必要なデータを安定して収集できるか」です。 よくある話なのですが 「こういうデータが公開されている」「こういうふうに活用できるはずだ」と考えて開発を始めたところ 「このケースに該当するデータは取り扱っていない」「◯◯と◯◯を区別できない」「この量を使うには◯◯円の課金が必要」 といった想定外の制約で頓挫することがあります。

軽微なデータ収集システムを開発するだけでも、実態を検証することが可能です。 スクリプトを書いて、手元の環境で実行して、集めたデータをSpreadsheetに貼り付けて、中身を確認しました。 そのデータをFigmaのモックアップに当てることで、データとUXが綺麗に繋がるかをテストしました。 繋がらない項目については、どのようなロジックで処理するか、どのようなデータで代替できるかを確認しました。

これまたランサーズ卒業生である @zyunnosuke さんと連携して検証を進めました。 書籍『個人開発をはじめよう！』を一緒に執筆した仲で、その際もスクレイピングについて書いてもらいました。 スクレイピングやWebAPI利用などのオープンデータ収集は、トラブルの温床になりやすい分野です。 経験豊富なzyunnosukeさんに頼りながら案件を進めました。

個人開発をはじめよう！クリエイター25人の実践エピソード (技術の泉シリーズ（NextPublishing）)

その他:データプラットフォームのメンテナンス性向上

メインの案件ではありませんが、他の観点でも貢献しています。 その1つがBigQueryやRedashなどのデータプラットフォームの管理についてです。

• BigQueryのどのテーブルがいつ参照されているか
• RedashからBigQueryにどのSQLをいつ発行しているか

これらの情報がAuditLogとして保存されているので、ダッシュボードに可視化しました。 利用されていないテーブル（データマート）や重複発行しているSQLを見つけやすくなります。

ランサーズ社がすごいのはここから先で、もともと月に1回ほどBigQueryやRedashのデータをクリーニングしていたそうです。 納品したとき「クリーニングの日に使いますね」と当たり前のように言われて 「えっ、ちゃんとクリーニングの日を設けているのですか」と驚きました。 メンテナンス作業は、言うは易し、行うは難し、です。 ランサーズ社のオペレーショナル・エクセレンスの片鱗を垣間見ました。

ちなみにBigQueryの利用状況は以下の記事を応用すると可視化できます。

yuzutas0.hatenablog.com

また、メール配信システムの設計や、機械学習に必要なタグ付けの問題など、いくつか個別案件の相談にも乗りました。 壁打ち相手として活用してもらえているのかなと思います。

意識していること

『図解＆事例で学ぶ入社１年目の教科書』 に書いてあるようなことを意識しています。 未だに読み直しています。

• 少しでもリスクを感じたらすぐ相談
• 即断・即決・即実行
• やることは全部書いておく
• 話したことをメモしておく

といった点です。 はっきり言って複数案件の細部を記憶するのは無理です。 いかに「脳を使わずに作業できるか」という観点で、仕事の進め方をハックしています。

スイッチングコストを0にするには、常に頭を空っぽにして、 決めた時間に作業着手して、決めたタスクを完了させて、 次の作業時間に経緯をすぐ思い出せるように全ての情報をメモしておく、に限ります。

これは「ランサーズの仕事だから」というよりは「複数のクライアントを抱えての仕事だから」ですね。 気持ちとしては「0.1の稼働」で「120%の価値貢献」ができるような仕組み作りを心掛けています。 会社員時代と同じように（むしろそれ以上に）「価値貢献できなければ追放される」という覚悟で向き合っています。

大変なところ

これも「ランサーズの仕事だから」というよりは「複数のクライアントを抱えての仕事だから」ですが

• 話が進んで一気に要望が寄せられると整理が大変になる！
  • そこまで話が進むのは良いこと！
  • そこまで信頼していただけているのは良いこと！
  • 可能性が10倍に広がったと感じる時間と、実現のための1歩1歩に落とし込む時間を、繰り返すようなイメージですかね！
• 他の案件が炎上すると玉突きで一気に大変になる！
  • 無理のない計画を立てよう！
  • プロフェッショナルとして納期を守ろう！
  • せめてやばそうだったらアラートをあげよう！
  • 早め早めにアウトプットを共有して手戻りを回避しよう！
  • 他の人のせいにしない！ 他の人が遅延しないように頻繁に声を掛けたり、 他の人が遅延しても吸収できるように調整したり、 自分に出来ることはいくらでもある！ベストを尽くそう！

といった点は否定できません。 簡単ではないですね。 裏を返せばチャンスでもあります。 安定してパフォーマンスを出せれば、それだけで（相対的には）高い評価をいただけるのかな、と思います。

感想

以上「こんなことをやってきたよ！」という話を、書ける範囲で書きました。

率直な感想としては「一緒に仕事をやっていて楽しい」です。 強引にまとめると、2つの理由があるのかなと思います。

1つ目は「攻め」の観点で「貢献できている感」です。 残念ながらPoCや業務改善は成果を数字で表しにくいです。 にも関わらず「貢献できている感」があるのは、 ツールを使ったメンバーから「助かりました」といったお礼コメントをいただけたり、 CPOの @nakajiman さんが「ずっとやりたかった試みを次々と実現できている」と社内にPRしてくださっているからです。 合わせて「もっとこうしてほしい」とフィードバックをいただけるので、改善サイクルを回しやすいです。

2つ目は「守り」の観点で「分かってくれている感」です。 上場直後ということもあり、厳しく締めるところは締めているのですが、 一方で、柔軟に便宜を図ってくださっていると感じることがあります。 VPoEである @terukura さんが中心となって、 フリーランスエンジニア1人1人との面談を重ねながら、外部人材を活用できるように組織整備を行っているとのことです。 このAdventCalendarもその一環で打診いただきました。

結果として「社員ではない人間がこのような形でアウトプットできている」という事実に繋がっています。 ランサー1人1人を大切にしている会社なのだなぁとポジティブに思っています。

宣伝/自己PR

ということで、

• 顧客セグメント可視化
• 社内システム改善
• オープンデータ活用
• データ基盤のメンテナンス
• フリーランス活用

について相談したいという会社様は、ぜひランサーズで発注してください。

また、

• システム開発
• データ分析
• SQL・Python
• 副業・独立

に興味を持っている個人の方は、ぜひMENTAでメンタリングを応募してください。

さらにさらに、ランサーズ VPoE の @terukura さんと共同で来年のデブサミにも登壇します。 よかったらぜひご参加ください。

以上です！明日はついにラスト！締めを飾るのは @iritec_jp さんです！