この記事はクラウドワークス アドベントカレンダー13日目の記事です。
はじめまして、プロダクト開発部にて、crowdworks.jpのプロダクトマネジメントを担当している西村（通称チャンタマ）です。
突然ですが皆さんのサービスでは、KPIをどのように定めていますか？
一般的には、事業部全体の売上目標から因数分解して、特定の指標（会員登録数・継続率など）をKPIとしておくことが多いかと思います。 crowdworks.jpの開発チームでも、長らくそのようなKPIの立て方をしていました。
しかしながらサービスの特性や組織設計も関係して、様々な弊害が生じるようになりKPIの立て方を見直す必要性を感じるようになりました。
したがって今期からは、サービスの「成長モデル」を定義し、サービスが抱える様々な問題に対してどのように優先度をつけていくか、その開発スタイルも考え直してみました。
今回は成長モデル作成のプロセスと背景をご紹介します。
複数の開発チームを抱えるプロダクトマネージャーの方、サービス全体の開発方針、優先度の意思決定をする立場にある方などに参考にしていただけると嬉しいです。
サービスを＜体験の循環＞としてとらえる
いきなり結論という感じですが、今回の取り組みの中で一番重要と考えているのが、サービスを＜体験の循環＞としてとらえるということです。
crowdworks.jpというサービスは、お仕事を依頼したいクライアントさんとお仕事をしたいワーカーさんがインターネット上で仕事を受発注できる、仕事のマッチングサービスです。
今回我々が作成した成長モデルは以下のようになりました。
一方、成長モデルを定義する前に主に使用されていたのは以下のような因数分解形式でした。
いかがでしょうか。 モデル図に落とし込んだ方が、 体験の相互作用とKPIの繋がり が一目瞭然ではないでしょうか？ 逆に因数分解されたKPIでは「ロジックとしては分かるけど、結果的にどういう体験につながるの？」といった疑問が残るアウトプットだったように思われます。
ユーザーは一連の体験＝循環を通してサービスに対して満足し、利用し続けてくれるはずです。 その仮説を踏まえて、基本的にはいちKPIにフォーカスするのではなく サービス全体のバランスを見ながら、サービス満足度に対するROIの高い順に着手していく といった方針を基軸に据えて、方針決定や組織設計などに取り組んでいます。
といっても、そもそも現在はサービス満足度のような指標をちゃんと取れていないので、まずはそこから取り組んでいる最中です...。
成長モデル定義のプロセス
成長モデル定義のプロセスは、noteのCXOである深津さんが書かれたnoteにおけるコア体験と相互作用メモという記事の内容を（勝手ながら）ほぼ踏襲させていただきました。 一部、上記の記事に使われている言葉もお借りしながらプロセスの紹介をします。
1. 最優先のユーザー体験を定める
この2つの相互作用があれば、最小構成モデルとしてエコシステムが機能する
という最優先のユーザー体験を最初に定めました。
2. ユーザーの行動という側面に落とし込む
このフェーズでは非常に議論が白熱しました。
ポイントは、noteでは4項目のサイクルであったのに対し、crowdworks.jpでは5項目にした点です。
一般的に”記事”は、そのほとんどは一度投稿されたら常にWeb上にあり、いつでも読める状態にあります。 投稿された記事のことを在庫として捉えると、在庫が増えることはあっても減ることはあまり無いでしょう。
一方crowdworks.jpがワーカーさんに対して提供している”仕事”は、他の契約相手が先に決まってしまえば応募できなくなってしまいます。 逆も同様に、ワーカーさんが働ける時間には限りがあるので、依頼したい人が見つかっても本当に依頼できるかどうかはその人の稼働状況次第です。
ここで最初に定義した「最優先のユーザー体験」に立ち返ると、
- 仕事を頼めて助かる
- 報酬が得られて嬉しい
と定義されており、受発注者ともに 実際に契約できる相手に出会えること（＝マッチング）が必要条件 になると判断できます。 仕事が増えただけでも、ワーカーの人数が増えただけでも不十分で、マッチングが成立してやっと循環のモデルが出来上がると考えました。
したがって、常に希望の仕事があるとは限らない、ぴったりなワーカーさんが見つかるとは限らない、という状況の中でいかに効率良くマッチングできるかどうか、という観点は外せないポイントだと考えたため、5項目にすることに決めました。
3. 要素の関係性を精緻化する
主にシェアや認知、継続などの要素を追加しました。
ようやくモデルっぽくなりました。
4. KPIをあてはめてみる
最後に、出来上がったモデルにKPIを当てはめてみました。
また、このモデルに基づき月次で指標の推移が確認できるスプレッドシートを作成し、常に全体のバランスの状況が把握できるようになりました。
取り組みの背景：因数分解されたKPIの弊害
今回我々が成長モデルを定義しようとした背景には、因数分解されたKPIによる弊害がいくつかありました。
1.全体を把握せずに、特定指標だけにフォーカスしてしまう
先述の通り、サービスとは＜体験の循環＞によって成り立つはずです。 したがって、1ヶ所だけで100点を取りそのほかは全て20点という状態よりも、全体的に70点くらいを取り続ける方が健全であると考えられます。
因数分解されたKPIでは、どうしても特定の指標だけにフォーカスしてしまい、その前後や周囲にどのような体験がつながっているのかへの考慮がおろそかになりがちです。
我々の場合は、受注者と発注者のマッチングサービスなので両方のバランスが重要なのですが、その時々の需給バランスによっては発注者側しか注視していない時期がありました。 そのために受注者側の体験が低下しているという事態が実際に発生していました。
2.組織も特定KPIフォーカスの前提で設計されているので、期中に重要度が変更されても柔軟に対応しづらい
クラウドワークスでは、事業部の目標・KPIに基づいて各チームごとにやることを決め、半期ごとの個人目標設定に盛り込まれる形式で目標設定が行われていました。
ところが先ほどのように期中で施策に取り組む中で、他のテーマの重要度が上がってきた時に
- チームのテーマ外だから
- チームメンバーの技術スタック的に難しいから
- 触ったことのないテーマなのでROIが出せないから
といった理由で取り組みが後回しになる状況が発生していました。
開発組織が少人数・多チームという状況になっていたことも背景にあったため、その反省を活かして今期からは大人数・少チームになるよう組織変更を行いました。 結果的には、技術スタックやcrowdworks.jpにおける開発での経験有無の偏りといった課題はひとまず解消されました。
またチームが取り組むテーマに関しても、基本的には満足度を表現できるような指標を目標として置き、細かい施策に関しては優先的な指標は存在するものの基本的には期中で柔軟に変更できるようにしました。
もちろん、広い範囲の課題をカバーできるようになった反面、大人数であるがゆえにコンテキストが増えて情報共有・把握が大変という課題も新たに生まれてきています。 （現在ほとんどのチームはエンジニア4~5名 ＋チームによってはPO、デザイナーも追加）
crowdworks.jpにて採用しているスクラム開発の慣習では1チームあたり3~9人が望ましいとされているので、もう少し人が増えてきたらチームを分割する必要も出てくるかもしれません。 今享受できているメリットを維持しつつ、どのようにスリムなチームを保っていくか、といった点は今後の研究課題となりそうです。
おわりに：「森も見ながら木を見る」プロダクトマネジメントへ
クラウドワークスにおいて、プロダクトマネジメントを行う部署が明確に設置されたのはつい数年前のことです。 それから様々な試行錯誤を経てきましたが、一番強く感じた事は「バランス感」の重要性でした。
事業のフェーズによっては、プロダクトを作り込むことよりも営業やマーケティングでユーザーを獲得することが重要視されることももちろんあると思います。 とはいえ、どのタイミングになったら技術的負債解消に取り組むか？いつ社内オペレーションの改善に取り組むか？いつ違反対策に取り組むか？そのような観点も失ってはいけません。
本来はプロダクトマネージャーないしプロダクトマネジメントを担う部署が全体を把握し、バランスを意識しながらも短期・中期・長期で戦略を立てるべきところと考えます。 しかし長らく組織として「サービスとは＜体験の循環＞だ」という認識がなかったため、全体のバランスを把握しようとする動きもなければ、それに基づいた戦略を考えることもできていませんでした。
それらの観点が重要だと理解していても、戦略に盛り込む人がいなければいつまでもそれらは後回しになります。その結果起こることは、返済のできない技術的負債、オペレーション崩壊によるリスク、違反ユーザーが蔓延るサービス、などです。
「今じゃない」事は往々にしてありますが、「じゃあいつなのか？」を常に考えて戦略を立てることはプロダクトマネージャーの責任の一つだと感じます。
成長モデルを軸に、「森も見ながら木を見る」プロダクトマネジメントへシフトし、持続的に成長し続けられるプロダクト・組織を目指していきたいと思います。
