bosyuというサービスをクローズするまでのPM目線の振り返り
bosyuというサービスにプロダクトマネージャーとして関わってきたが、紆余曲折あってサービスをクローズすることとなった。
記憶がまだ残っているうちに、どのような関わりをして、その上で何を学んだかを簡単に残しておくことにした。
関わった経緯
bosyuはもともとBasecampの坪田さんが作られたサービスで、それを株式会社キャスターが事業譲受したものだ。その当時の私はフリーランスとしてキャスター社に関わっていて、日程調整ツールのbiskettを作ったり、採用代行サービスのCASTER BIZ recruitingのお手伝いなんかをしていた。
bosyuが事業譲渡された時点でもキャスター社に関わっていたこともあり、bosyuについて雑に相談を受けたり、bosyuに関わることになるエンジニアメンバーの面接なんかをしたりしていた。（当時、キャスター社にはほぼエンジニアがいなかったため、代わりに面接等をしていた）
2019年の5-6月くらいに、当時やっていた別の仕事が一段落したこともあり、そのタイミングで「他が落ち着いたんだったらbosyuも見てよ」と事業責任者である石倉さんから言われ、「まあ週2日くらいなら、、、」といった感じで引き受けることにした。
当時は別の方がbosyuのPMをされていたのだが、その方の離任するタイミングとも重なり、結果的にはPMが入れ替わる形でジョインすることになった。
ここが2019/7末くらいである。
bosyuに関わったときの初手
面接等々をしていたこともあってチームのほぼ全員と面識があったので、すんなりとチームに馴染むことは出来た。
当時のbosyuとしては、bosyuをキャスター社から独立させて「bosyu社」にしていこうとしていたフェーズで、そこと合わせてこれからの戦略等々を考えているタイミングであった。
議論の流れ等々を見て感じたのは大きくこの2つだった。
・プロジェクトマネジメントが崩壊していた
・魅力的なゴールが作れておらず、メンバーがひとつのゴールに向かえていなかった
プロジェクトマネジメントが崩壊していた理由は、前任者の工数不足が大きな要因に思えた。また、後者のゴールについては戦略等々を考える中で無理矢理にでも早期に決める必要があると感じた。
それゆえに、下記の行動を初手として取った。
・是が非でも無理やりゴールを決めること
・不要なタスクを排除し、プロジェクトとしての秩序を取り戻すこと
具体的にはこのようなことを行った。
・これまでの議論の整理とゴールを無理やり定めるための合宿の設定
・OKRの設定
・過去に積まれたタスクの削除
・上記合宿までの無理矢理のタスクづくり
・既存の問題点の洗い出し
合宿の設定について
合宿等の全員でまとまった時間を取ってものごとを考えていくという行為は、全員の共通認識を持つという点では良いものだと理解している。他方で、人数が増えすぎると勿論機能しない。
このタイミングでのbosyuチームは7-8名程度だったこともあり、合宿という手段で手っ取り早くケリをつけるのが一番良いと判断していた。
合宿はふつうに行うとダレてしまうのが常なので、アジェンダの設定や事前準備にはそれなりに時間をかけた。
また、この合宿にて「CtoCのマイクロタスクのマッチングサービス」にリニューアルするという方向性をFixした。
なお、合宿等はおよそ下記のアジェンダで行うことが多い。
[事前準備]
・メインで話したいテーマの確定
・テーマに対しての各々の考えを事前にまとめてもらう
[情報共有フェーズ]
全員の認識を揃えなければフラットな議論ができないため、最初の1-2時間を使ってこれらを行う。
・これまでの振り返り（定性、定量ともに）
・現状共有（特に、経営レイヤー等から）
[課題検討フェーズ]
テーマについて深堀り。これは状況によってやり方が変わるので割愛。
[次のアクションを決めるフェーズ]
深堀りした内容を元に次のアクションを決めていく。
ここで決まった内容については、よほどのことがない限り異を挟まない。
中長期的なゴールの設定について
短期的な売上を作ることは大切だが、「なぜこの事業をやるのか」という部分を明確にし、関わるメンバー全員で理解しておくことは事業運営上大きくプラスに働く。そのため、可能な限り「一文でまとまる明確なゴール」を作るようにしている。
今回のケースでは合宿という場で全員で決めるということを優先したが、このゴールは1人で決めてしまっても問題ない。ただしその場合は、全員が納得する魅力的なゴールを生み出すことが求められる。
[振り返ってみて]
bosyuの場合は、ここのゴール設定を「理想」に置きすぎたように思えている。サービスの性質として売上に特化したものを置きづらかったというものもあるが、これは中で働くメンバーの性格/考えに依存する部分が大きかった。
自分も「何が何でも売上を作る」というよりは、一定の理想を満たした上で売上を作る方が好きであり、その部分が結果としては裏目に出てしまったというのが実のところといえる。
他方、ここで「理想」を詰めたことは、コアなファンを生み出す上では明らかに良かったと言える。
タラレバではあるが、もう少しバランスを取ったゴール設定ができていれば、また少し違った展開を作れたかもしれない。
OKRの設定について
当時のbosyuチームには、なんとなくの機能リリースの目標感はあったが、明確な短期的なゴールを作れていなかった。
このことがプロジェクトマネジメントの崩壊に繋がっていたこと自明だったので、フレームワークとしてOKRを使う形の目標設定を行うことにした。
OKRに対して強いこだわりはないが、事業の目標設定フレームワークとしては少なからず良いものだと思っている。
他方で、プロダクトチームの目標設定フレームワークとしてはイマイチだと思うことが多い。具体的には下記の部分で問題がある。
・事業の立ち上げフェーズにおいては、XXの機能を作るといったObjectiveを置かざるを得ないケースが多い
・改善フェーズにおいても、KRが機能改修数などになりがち
・数値改善のKRをおいたとしても、PMFに向けて進む中で目標となる数値が変わる事が多い
・既知の事象が増えるに連れ、そのKRの優先度が下がる
プロダクトのNorth Star Metricsが固まって安定的に運用していくフェーズになればOKRは機能しやすいが、PMFを目指すフェーズにおいては運用は難しいなと思う。
極論いえば「PMFさせること」以外のObjectiveしか存在せず、他方でそのObjectiveだけで日々の行動に落とし込める人は限りなくゼロに近い。としたときには他のフレームワークの方が良いと思うが、定性/定量の観点からわかりやすく目標を組み立てられる部分は優れており、これといった対抗馬もないので暫くはOKRに頼ることになるとは思っている。
なお、bosyuチームでは2ヶ月ごとにOKRを変更するという運用にしている。PMFを目指すフェーズにおいて半年では長すぎるし、クオーター（3ヶ月）でも少し長い。他方で1ヶ月だとバタバタしすぎるので、間を取って2ヶ月にしている。個人的にはこの2ヶ月という期間はわりと丁度よいが、ここはチーム構成にもよる。
新しいゴール設定までのタスクについて
PMが入れ替わるタイミングではありがちなのだが、次の明確なゴールが決まるまでの間にプロダクトチームに何をやってもらうかという問題がある。
多くの場合は前任者が定めたタスクをこなしてもらっている間に何かしらのタスクを作ることになるが、bosyuにおいても基本的にはそれに倣った。
他方で今後の方向性を考えたときに「どう考えても無駄」なタスクについては、引き継いだ時点で遠慮なく捨てた。
積まれていてもやらないタスクであれば、捨て去った方が全員の脳内メモリが食われなくて良い。
ここまでが2019/8くらいである。
二手目として必要だったこと
大きなゴールが決まり、CtoCのタスクマッチングサービスにリニューアルしていくことに決めたが、そこを目指すためには問題となる部分が多かった。
機能面での問題は、そもそもとして当時のbosyuには最低限の機能しかなく、わりと大きな改修にならざるを得ないという点だった。
・メッセージをやり取りする機能がない
・お金をやり取りする機能がない
・募集を探す機能がない
流石にこの状態からタスクマッチングサービスを一気に作るのは難しいため、ひとつひとつ倒していくことにした。
また、下記のような問題もあった。
・機能として挙動が変な所/バグに近いような動きが多かった
・数値計測の環境が整っていなかった
・数字をみて判断していくためのマインドセットが整っていなかった
何かを改善していくためには、それが計測可能な状態であることが望ましい。また、数字を見てそれらをジャッジしていくためには、メンバーにおける慣れも必要である。
特にマインドの部分は時間がかかるため、「数値を見ながら機能について考えることが出来るようになる」といったObjectiveを結果的に設定することにした。
機能のアラを取ること
数値を計測するのは当たり前のことのように思えるが、これはなかなかに難しい。そもそもとして「どんな数字を見るべきか」わからないことは多いし、その数字を「どう判断するべきか」がわからないことも多い。
例えばCVRが1%だったとして、これが良い数字なのか悪い数字なのかは、過去の自プロダクト若しくは他社の類似プロダクトとの比較でしかわからない。これらの情報がない段階では正しいジャッジが出来るわけもないため、最低限自プロダクトの過去の数字が取れるように、今を整えていくことを優先するしか無い。
その中で問題になるのが「機能のアラ」である。数値計測環境すら整っていないプロダクトの場合、機能自体に粗い部分があることが多い。そのため、本来的に取得したい数値があったとしても、粗い部分があるがゆえに数値の結果がブレてしまう。
例えば、ユーザーの登録率を取りたいのに、ユーザー登録時に数分の一の確率でエラーとなってしまうバグがあったとすると、本来的な意味で知りたいユーザー登録率の正確な値は当たり前だが取ることは出来ない。
このようなアラを潰していくことは、プロダクト改善の初手としては有効だと個人的には考えている。
[閑話休題]
アラをとるよりも、プロダクトの数値改善に効く部分にフォーカスして大掛かりな改善をすべきだ、という論もある。これは勿論一定正しい。
ただ、「数値改善に効く」という仮説を作るにあたっての前提のデータに「不備」がある状態が「アラのある状態」であって、まずは正しい仮説を立てられるようになること、つまりは「前提のデータを取得するためのアラがない状態」を目指すことを優先すべきだと考えている。
もしくは、数値からの情報は最低限とし、感覚や経験則に頼ってギャンブルで突き進むか。これはこれで、スピード勝負の場合だと良い選択肢だと思っている。
数値計測環境を作ること
上述のような経緯があり、bosyuでも数値計測環境を作ることにした。もちろん当時も最低限のデータは取得できるようになっていたが、リアルタイムのものでなかったり、拡張性にかけていた。データを見つつ改善するという行動が取り辛かったこと、一定の期間を使ってプロダクトを育てていくことを合意していたこともあり、データ分析基盤を優先して作ることにした。
また、Google Analyticsの設定やSearch Consoleの設定など、いかんせん欠けているものも目立ったので、このタイミングで専任のリソースを割り当てて整備することにした。
過去の経験上、片手間でやってもこれらの整備はうまく行かないことが多かったので、短期的にはリソースの無駄と思いつつ、中長期的なことを考えてこの部分にリソースを投下したのは、振り返ってみると正解だったと思う。
そのおかげもあってか、きちんとデータを見ながら議論をするというマインドも自然と育つことに繋がったように思う。
なお、bosyuではRedashというツールを使っている。
Redashはオープンソースで使えるということもあり、サーバー環境を準備すれば無料で使うことが出来る。（とはいえ、GCPやAWS等のそれなりに良いインスタンスが要求されるため、月々数千円の出費となる）
機能としては、クエリの作成/保存、グラフの作成、複数のデータソースからのデータの取得及びそれらのデータのマージ（例えば、Google AnalyticsのデータとMySQLのデータをjoinして集計したりできる）ができ、最低限のBIツールとしての要素を備えていて、良いツールだと思っている。
[数字のとりすぎという問題]
過去に携わっていた仕事では、KPIが数百個あるという地獄みたいなサービスもあった。見るべき数字が多いと、考えるべきことが増えてしまって、フォーカスしきれない。
数値のウォッチという意味では「自動で取得できる」なら見ていてもよいが、日々追っていく数字は数個にしておいた方が良い。でないと、行動に落とし込めない。
機能開発の登り方を考えること
リニューアルに向けての機能開発は、順序がわりと大事だと考えていた。お金のやり取りが出来ても「メッセージ」がやり取りできなければ意味がないし、他の募集を探すことが出来ないと効果が薄いと考えていたからだ。
また、他にも「お金を扱う」からこそのセキュリティ面、規約面、安心して使えるようにするためのサポート面等々の裏側の準備も必要であり、これらをパズルのように組み合わせて実現していく必要があった。
お金のやり取りについては「エスクロー取引」というサービス提供者が一時的にお金を預かる形を選択したこともあり、それに伴う業務フローの整理はわりと面倒であった。ここには法律面からのジャッジ等も含まれるのだが、安心安全に使っていただくためにはうまく手抜きをすることも難しかった。
また、お金を扱う領域に進むという部分はあまり口外するものでもなく、ある種ステルスのような形で進めていた。そのため、外部から見たときに「動きが悟られないようにする」ことも意識しながら、タスクの順序を組み立てていた。
[バックログの管理について]
プロダクトマネージャーの仕事のひとつに、プロダクトバックログの管理というものがある。とはいえここには、個人的にあまり時間を使わないようにしている。
PMFに向けて進むフェーズであれば、日々やることが変わるのが常であり、タスクの優先度をいちいち全部考え直すのは無駄でしかないと考えているからである。
OKRを2ヶ月に区切っていることもあり、この2ヶ月でやるべきことを定めたあとは、メンバーがやりやすい順序でやっていけばいいかな、、、くらいの温度感でエンジニアメンバーにあとは大体任せていた。
どのみち、遅かれ早かれ実装されるので。しかも、2ヶ月以内に。としたときに、その差なんて誤差にすぎないし、外部が関わるものでもない限りは「やりやすいようにやる」が一番パフォーマンスが良いという思想である。
このあたりまで整ったのが、2019/10頃であった。
メンバーの定着について
事業を進めていくためには一定のメンバーが必要であり、そのためには採用活動等を行う必要がある。これはbosyuチームも同じであり、2019年の中盤は採用活動も並行して行っていた。
特に苦戦したのはデザイナー採用であった。良いデザイナーというものはとても希少価値が高く、結果的に自分たちと合うデザイナーさんと一緒にやれるようになるまでは紆余曲折があった。
エンジニアもデザイナーもPMもそうだが、一緒に働いてみるまで相性などはわからない。そのため、少しでも良いので一緒に働く期間を取るしかないのだが、このお試し期間の期待値調整は結構難しい。
相手からするとクビになったようなもので勿論良い気はしないし、他方でその状態を続けていてもお互いにとって良いことは無いしで、短期間でも一緒に働いたからこその判断のし辛さのようなものはあった。
とはいえ、このときの採用活動等々が職業紹介系に振り切った時には勿論活きており、悪いことばかりでもなかった。
なお、2020/2頃から今に至るまで、メンバーはほぼ変わっていないため、この当時行った採用活動自体は良いものだったと言い切れる。
[採用活動とお試しジョイン]
bosyuチームにおける採用活動では、お試しSlackジョインと、実際に何らかのタスクを一緒にやってみるということを結果的に行うようになった。
NDAを結んだ後、Slackはほぼフルオープンで入ってもらっていた。見せて困るものも特に無いし、好きなように見てもらっていた。その結果として合わなければしょうがないし、合うなら良いくらいのドライさはあった。
2020年の後半に、bosyu Jobsの採用として何名かにお試しSlackジョインしてもらったが、結果的には本格入社に至らなかった。PMFを目指すフェーズであって「明確な役割」を与えきれなかったこともあるが、「見て判断して欲しい」という受け身な部分があったことは否めない。
気楽にSlack等々を見てもらうのは良いと思うが、可能な限り積極的に関わり、早めに一緒に小さな仕事をするべきだったと反省している。
報酬を付ける機能のリリースとコロナ禍
2020/1に募集に報酬を付ける機能をリリースし、CtoCのマイクロタスクマッチングサービスとしてのリニューアルを果たした。
「あなたのふつうは、誰かの特別」といったコンセプトは多くのユーザーさんにも受け入れられ、bosyuの利用者数もこのタイミングを機に一気に増えた。
流通金額も徐々に増え、これはこの感じでいけるのでは、、、と思っていた矢先にコロナ禍となった。この辺りの話はこちらのnoteで書いたので詳細は割愛する。
2020/3-4時点では、コロナ禍はどう考えてもbosyuにとって追い風だと考えていた。「オンラインでも働ける」という部分は売りのひとつだと考えており、それが確実に加速されると考えていたからだ。ただこれは結果的に間違っていたのだが、当時の情報からこの部分を正確にジャッジしきれる自信は今もない。
[当時を振り返ってみて]
これは今だから言えることだが、働き手は増えても仕事を生み出す人は増えなかったし（というよりも特定のタイミングでは仕事は減るしかなかった）、オンラインだけで働くというのは日本ではまだまだ早かったように思う。また、bosyu自体はエンタメサービスのひとつとして見られていたことは事実であり、「仕事」というものに割り切れていなかった部分もそこに拍車をかけたのは事実だとは思う。この辺りは、戦略上やむを得ない部分はあったが、ジャッジとしては間違えてしまったようにも思える。
職業紹介系に振り切るというジャッジが遅れたこと
前述のnoteでも記載したように、bosyuの数値が伸びていなかった理由を見つけるのにはわりと時間がかかった。これは2020/8くらいの話。
また、当時外部の方にも相談していたのだが、「特化しきれていないこと」がbosyuというサービスの輪郭をボヤけさせているという問題もあった。要は、これは何のサービスなのかパッと見でわからないという話である。
この部分に関しては、想起のとり方をどうするかという問いであって、特化していく方向に考えてもよいのではという気持ちと、「なんでも募集できる」というポジションを突き詰めるほうが良いのではという気持ちが半々くらいで、うまくジャッジが出来なかった。
他方で、ここに「売上」という基準をもっと重要視して考えていれば、あまり迷うこと無く特化する方向に舵を切ったと思う。その意味では、長期的なゴールにおける売上への意識の低さというものが、結果的に首を絞めたと言っても良い。
また、結果的には職業紹介系に振り切るジャッジをしたが、bosyu Jobsをリリースした2020/11時点でも、bosyuとの並行稼動を考えていた。この時点では、気持ちが割り切れていなかったというのもあるし、「一定のコストは掛かるがコロナ禍もいずれ収束するので耐え忍ぶ時だ」と考えていたことも大きい。
[いま振り返ってみて]
少し残酷ではあったが、bosyu Jobsのリリースのタイミングでbosyuを閉じてしまった方が良かったように思える。開発リソースという観点では「追加開発をしない」というジャッジを早めに行っていたので大きな問題はなかったが、とはいえマインドシェアを一定とられてしまうのは事実であって、もっと早めにフォーカスすべきであった。
他方で、フォーカスするべき対象が職業紹介だったのかでいえば、ここは正直悩ましいと思っている。「bosyuの課題感をベースに事業を再構築する」というアプローチを取ったためにこの結論となったが、この考え方は明確に失敗だったといえる。同じ課題でソリューションを変えるというのは間違ってはいないが、ロジックがとても複雑になるからだ。この辺りはスパっと割り切って、全く新規で考えた方が良かったと思う。
サービスクローズというジャッジまでに考えてきたこと
正直な所、bosyuについて考えることを2020/8-2021/2頃の間は放棄していた。というよりも、打つ手が特になかったので放置していた。最低限の数値のチェックはしていたが、これといって下がるわけでも大きく上がるわけでもなかったので、コロナ禍が収束するのを待とう、、、という消極策に出ていた。事実として、2020年の緊急事態宣言の解除後に一定の数値回復が見られたため、待つしか無いと思っていたのは大きい。
他方で、外部からも見てわかるように、bosyuとbosyu Jobsでは重複する部分も多く、事実としてカニバっていた。利用する企業さんからも「2つのサービスで何が違うんですか？」といったことをよく聞かれていた。
まあそらそうだよなと思う反面、結果的にフォーカスしきれていないことをユーザーさんにも見透かされているなと思い、bosyu Jobsのセールス等を通じてbosyuのクローズというジャッジを徐々に固めていった。
最後まで悩んだのは、極論いえば「放置していても特に問題はない」という部分であった。開発リソースという費用の大部分を占めるものはbosyu Jobsに向いており、bosyuのサーバー費程度であれば特に問題なくペイ出来る状態であったからだ。実はこの辺りは珍しく石倉さんとも判断が割れたのだが、経営としてのジャッジと現場としてのジャッジの差のようなものだったとは思う。
[カニバっていることをどう捉えていたか]
実質的な求人情報に対して労働条件が掲載されていないことを良しとしない文脈は作られつつあるため、直近の多少の領域重複くらいは大きな問題はないと考えていた。というよりも、bosyuというサービスの性質上、全ての求人募集を一律で禁止することは難しく、としたときにはサービスクローズもしくは継続して様子見をするというジャッジしか現実問題としては取れなかった。そのため、2020年時点では後者のジャッジをしたというのが正しい。このジャッジ自体でいえば、あまり良いジャッジではなかったと今は考えている。
[クローズしないというジャッジについての妄想]
このままサービスを続けていくというジャッジも勿論あったわけで、そのジャッジをしたときにどうなったかを妄想すると、結局は「人は募集を作ることが難しい」という問題に行き当たることになる。
応募は簡単だが、募集は難しい。人の行動を変えることは難しくて、それを一定程度の頻度で行って貰う必要があり、その部分ではサービスを大きく変えていく必要があったと考えている。（そのシナリオも勿論準備はしていた）
が、どちらにせよ苦戦したとは思う。コロナ禍が明けたとしても月間流通額でいえば数億円程度なければ事業成立のラインにはたどり着かず、先日上場したココナラの流通総額が年間6-70億であることを鑑みると、マス広告での認知勝負をどこかで仕掛けざるを得ず、市場自体の難易度が高い領域であったことは間違いないと感じている。クラウドワークスの流通総額もYoYで下がってしまったことを考えると、月間数十億円程度の流通総額で頭打ちになり、手数料の値上げ合戦をするしかなかったのかもしれない。
ここまで振り返ってみて思うこと
bosyuというサービスを育てていくにあたって、良くも悪くも「目先の売上」というものから目を背けていたのは自分の反省としては強くある。
ただこれは、サービスとして育てた先にしか売上はついてこないし、そのためにはある程度時間を使って基盤を作るしか無いし、そのためのリソースの投下については経営とも合意が取れている認識だったからである。
他方で、事業として赤字を垂れ流していたのは事実であり（これはメンバーの数等々、外部に公開されている情報からも推測出来ると思うが）、会社の状況が変われば悠長なことを言っていられないというのも正しい判断だと思う。私自身もこの状態で赤字を垂れ流すことにはあまり意味を感じておらず、その意味では引き際としてはしょうがなかったとは思う。
bosyu Jobsの方に力を入れるようになってからはbosyuの数字はあまり見なくなっていたのだが、bosyuの足元の数字だけでいうと実はかなり良い成長をしていたのも事実であった。
検索流入数やリピーターの数は圧倒的な数字として伸びているし、この辺りは関わってきたメンバーは誇っていい数字だと思う。とはいえ、世の中全体の流れには逆らえないし、事業として成立しきれなかったものを残し続けるわけにもいかないし、難しいジャッジだなと思った。
-------
bosyuをクローズすると発表してから、bosyuっぽいサービスが案外ないんだなって話を聞くようになった。
つまりは「かんたんに募集できて、それでいてお金のやり取りもできて、さらに運営会社が怪しくないサービス」は実はとても貴重だったようだ。クローズすることでわかったbosyuの今の価値は、多分ここだった。他方で、これを実現するためのコストがわりと高いということも知っているので、それゆえに貴重なのだと思っている。
-------
敗戦の記録のようなものを書いたが、振り返ってみても当時それぞれの打ち手自体が大きく間違っていたとは思わないし、実は代替不可能なサービスに育つことが出来たという事実も改めて感じることが出来た。
他方で、それでもダメなときはダメなんだろうと改めて思った。個別具体的なジャッジは最適解に近くとも、全体の流れでいえば難しい市場で条件付きで戦っていたのは事実だし、そもそもの市場選択が「目先の売上」という観点では間違っていたというジャッジが正しい。
それを覆すためにいくつか考えていたシナリオはあったけど、そこに行くことが出来なかったのは個人的には結構残念で、力不足だったということに尽きる。
-------
P.S. 敗者ではあるものの、プロダクト相談とか組織とか採用の相談とか本当にいつでも乗るんだけど、ダレからもマジで連絡こないアカウントがこちらです。。。連絡くれていいんやで、、、。
まいにちのご飯代として、よろしくお願いします。