この記事はCrowdWorks Advent Calendar 2017の6日目の記事です。
クラウドワークスでプロダクトオーナーをやっております@yo-iidaです。
最近いろいろなリリースやニュースでAIや機械学習を活用しましたという事例を多く見かけます。実際それによってこれまでにない画期的な体験を実現しているなぁと思うものもあれば、既存のアルゴリズムでもできたのでは？と思うようなものもあります。
昨今のAIブームは言葉自体が一人歩きしてバズワード化してしまっているかんじもありますが、技術的には大変興味深い分野でもあります。弊社でも機械学習をサービスに利用できないかという観点では、すでに悪質案件の自動検出1について実績があり、全社的にこの分野への注目度が上がってきています。
そんな中、悪質案件対策が機械学習によって高い精度で実現できたので今度は機械学習でいいかんじにマッチングできるようにしようという話が出るのは時間の問題でした。
今回はこのようなふわっとしたミッションと高い技術的ハードルがあるプロジェクトにおいて、プロダクトオーナーとして色々と試行錯誤した話をお伝えできればと思います。
どういうプロジェクトなの？
これまで私たちは仕事検索機能まわりを軸にワーカー視点でのマッチング体験の改善を行ってきておりました。
地道な機能改善によってすこしずつ数字の変化も出てきていましたが、大きなブレイクスルーを起こすことは難しく、抜本的に体験を変えにいく必要があるという結論に達しました。
ここから、 ユーザーはたくさんの仕事の中から自分がやりたい仕事を探すのが困難であることが課題で、これを解決するためにユーザーの嗜好性に合わせたレコメンドによってやりたい仕事にストレスなく出会えることが価値である という仮説を元に、悪質案件対策の開発メンバーとマッチング改善の開発メンバー、それからデザイナーとプロダクトオーナーが集まり、レコメンドを軸に新しいマッチングの体験を作っていくことになりました。
プロジェクト発足当時の先の見えなさが半端ない
発足当時のチームメンバーの気持ちはこんなかんじだったと思われます。
機械学習をやったことがないメンバー
「詳しいことはわからないけどいろいろなサービス上のデータ（閲覧履歴とか、応募履歴とか、契約履歴とか、プロフィール情報とか、、、）をたくさんインプットすれば謎アルゴリズムによっていいかんじのレコメンドができる、、のかな？😅」
機械学習をやったことがあるメンバー
「それを実現するためには教師となるデータが十分にあって、適切に正規化などの前処理が行えていて、何個もアルゴリズムを試して、パラメータのチューニングして、最初は精度出ないからうまく進めるためには、、、と、色々あってまずは問題設定と要求を整理したい・・😓」
このように機械学習がなんなのかがブラックボックスになってしまっており、機械学習の知識がないメンバーは機械学習の問題設定に必要なものがわからないし、機械学習の経験メンバーは「いいかんじに」と言っている要求をどう紐解けば開発を進めていけるのか考えづらい、、という状況が発生していました。
それに加えて、今回からはデザイナーのほうからデザイン手法についてユーザビリティテストなどこれまでやっていなかった新しいプロセスで進めていきたいというモチベーション2がありました。
プロダクトオーナーとしては作るものをどう決めるか、それから各メンバーの連携をどうやっていくかというところが非常に難しく、どこから考えていけばよいのかも手探りすぎて心配しかありませんでした。
わからないなりに手探りでやってみたこと
そもそも機械学習とはどういうものかエンジニアとプロダクトオーナーでキャッチアップした上で議論を進める
機械学習という言葉が先行しているかんじは否めないですが、まずは機械学習がどういうものなのかを知った上で議論していく必要があると考えたため、機械学習経験のあるメンバーに初心者向けレクチャーをやってもらいました。
言葉の定義（クラス分類とクラスタリングの違いとか）や、メジャーな手法・プロセスを知ることで、やったことがない人にとってはどういう用語で会話するべきなのかがイメージできるようになり、その後のコミュニケーションがスムーズになりました。プロダクトオーナーとしてもチームが今何をやろうとしているのか理解が進み、方針の検討・議論などがやりやすくなりました。
レコメンドについてチーム全員で体系的な知識をつける
今回ユーザーに届ける体験はレコメンドが軸になります。なので、機械学習の前にこちらの知識をインプットする必要があります。すこし手段から目的に近づいてきました。
レコメンドと一口にいってもそのアプローチは多岐にわたり、ユーザーの属性やコンテキストによって取りうる選択肢が変わります。
そこで、その選択肢や考え方について以下の資料を教材にデザイナーも含めた全員で輪読の形式で読書会を行いました。
この中で出てくる、推薦の個人化の度合いによる分類や、ユーザーの嗜好データをどのように得るか、などは現在のUXの設計にも非常に役立っており実施してよかった取り組みです。
簡単なものですがその時に作った資料も公開しておきます。
ちなみに、レコメンドという課題を機械学習でどう解いていくかは難しいところで、例えば嗜好性別にユーザーを分類し、それぞれのユーザーのグループが好むであろう仕事をレコメンドするというアプローチで考えれば、仕事の分類問題として機械学習で扱うことができそうです。
しかしながらこのアプローチは精度の高いものが実現できるかが不透明で、本当にユーザーに必要だったものはなんだったのかを考えた結果、後々このアプローチは変えていくことになります。
理想のユーザー体験の可視化・言語化
最も重要だったのがこのプロセスです。レコメンドもある観点では手段に過ぎません。ユーザーがほしいと思っているものを作るのが我々のやるべきことなのでこれを知ることができて初めて機械学習やレコメンドといった手段の議論に入れます。ようやく目的にたどり着きました。
このプロセスにおいて実施したのは、
- ペルソナの設定
- カスタマージャーニーマップの作成
- ユーザーストーリー（と受け入れ条件）の作成
です。
この手法はもともとデザイナーがこれまでやれていなかった手法を今回の開発で試したいというモチベーションがありデザイナー主導で進めてもらっていたのですが、私としても知見化し開発プロセス自体をブラッシュアップしていきたいと考えていたので一緒に進めることで開発とのつなぎこみ方を考えながら進めることができました。
ペルソナの設定は全体戦略としてどういう方向に注力していくかという話も絡んでくるのでプロダクトオーナーとしてはそういった経営観点のレイヤーの議論も踏まえ方向性を決める必要があります。
そういった意味でも初期からデザイナーと一緒に走り出すのがよいでしょう。
ユーザビリティテストによる仮説検証
カスタマージャーニーマップやユーザーストーリーも作っただけでは仮説に過ぎないのでそれを検証するのがこのプロセスです。
- ユーザーストーリーを元にプロトタイプの作成
- ユーザビリティテストの実施
- テスト結果分析とプロトタイプへのフィードバック
よかった点としては、ユーザービリティテストにはエンジニアも一緒に入って、実際にユーザーと話すことでエンジニアもユーザーの声を知るということができたという点です。普段あまりそういった機会がないので作ろうとしているものがユーザーに届いた時にどんなことが起こるのかを知ることができたのは大きな収穫だったと思います。
また、このプロセスで最も価値があるのは仮説検証からの分析によって作ろうとしているものの確度を高めることができることです。
「レコメンドの結果こういう情報を表示しておけばユーザーの応募コストが下がるだろう」
といった仮説に対して
「全然みていなかった」 とか
「みてもあまり参考にならない、むしろこういう情報出して欲しい」 とか
事実ベースで様々なフィードバックを得ることができます。
それを元に解決策を考えプロトタイプに落とし込んでいきます。
この手法については17日のデザイナーが執筆予定のアドベントカレンダーの記事でも深く掘り下げてご紹介する予定です。
機械学習というワードに囚われずユーザーにとっての価値を考える
いろいろと手探りでやってきた中で見えてきたのは、ユーザーが求めているものは機械学習によるレコメンドエンジンではないということです。もっといえばユーザーにとって裏側に機械学習が使われているかどうかはどうでもいいということです。
言葉にすると当たり前に聞こえますが、大きなミッションの中で開発を進めていると結構な確率でそれが見えなくなってしまうと思います。
一人歩きしがちな機械学習というワードはいったん忘れて、ユーザーの価値ベースで考えてそれを最短で確実に届ける方法を考えるとその手段に機械学習が選ばれるのは稀なケースでしょう。
実際にユーザービリティテストを行って仮説検証ができていればプロトタイプの確度は高いものにできます。それを確実に実現するためには、まずはルールベースで実装しきってしまうのが現実的な解だよなぁというのがここ2ヶ月ほど走ってきて思っているところです。
とはいえ機械学習を完全にやらないというわけではありません。現状は試行錯誤は並行して進めて機械学習で置き換えることにより精度が向上するということがわかったら順次置き換えて行くという方針をとっています。このような並列の試行錯誤をどういうアーキテクチャでやっていくといいのかはまた別の話ですが、、
しかしながらルールベースで一度作りきったものはその後の基準となり、ゆくゆく機械学習によるアルゴリズムで置き換えた場合にどれだけ精度が向上したかを数字で比較できるようになります。そういった観点でもまずはルールベースではじめてみるのは悪くない選択肢だと思います。
機械学習が絡んでくるプロジェクトでプロダクトオーナーに求められること
一つ目はデザイン観点とデータ分析観点からのゴール設定です。
何はともあれ、まずはどういった世界を実現したいのかを形にする必要があります。
- UXの仮説検証から精度の高い仮説を導く
- データ分析から精度の高い仮説を導く
UXの仮説検証はデザイナーと一緒に進めてユーザーストーリーなども一緒に考えていくのがよいでしょう。また、ユーザーストーリーを考える上でユーザーの傾向やニーズをデータから読み取らないといけないケースもあります。そこまで複雑ではない分析であればSQLで事足りるし、重回帰分析などもう少し複雑になればPythonやRなどで分析することもあるでしょう。
仮説のための根拠をいかに集められるかがプロダクトオーナーの大事な仕事だと考えています。
二つ目はLean UXの考えを取り入れて開発を進めるとよさそうということです。
これまで述べてきたように手段が先行しがちなプロジェクトではなによりユーザーの価値を意識して進めて行くことが重要になってきます。
今回手探りで進めてきたことは特に何かを参考にしたわけではなく、これまでのスクラムの知識にデザイナーの提案を組み合わせて進めてきており、私自身はLean UXのことは知らなかったわけですが、後になって読んでみると取り組んできたことと近いことが書いてありました。
ユーザーの価値にフォーカスするという共通言語の上で、デザイナーも推薦アルゴリズムについて深く知って体験を設計するし、エンジニアもユーザーのニーズを直に聞いた上でアーキテクチャを考えていくような機能横断的なチームづくりをすることで、着実にゴールにたどり着けるようになると思います。
三つ目はチームの学習サイクルのトップスピードを保つことです。
手探りの中でデザインや開発を進めることになるので、1週間単位で振り返っていては軌道修正が困難になります。毎日軌道修正ができるくらいのコミュニケーションを意識しておかないとリリース直前になってたくさんの問題が発覚してプロジェクトが失敗するということは容易に起こりうると思います。
このために、デイリースクラムや1on1で課題を検知しそれを解決するためのアクションをその日のうちに実施していくことが重要です。
最後に
機械学習は技術的負債になりやすく、高利子のクレジットカードのようなものだと言われていたりします。えいやで導入してもそのあとの運用もそれ以上に大変になっていくと思われます3。
プロダクトを持続的に発展させることができ、ユーザーとビジネスサイド、そして開発チーム、みんなが幸せになるようにプロダクトオーナーとして最適な選択をし続けていきたいですね。