TimeTreeの開発・運営メンバーの働き方や大切にしている考え方を紹介するインタビューシリーズ。今回はTimeTreeの黎明期からプロダクト開発や改善に携わってきたCPO（Chief Product Officer）の吉本（Anju）にインタビューします。

CPO就任以降ユーザー課題に徹底して向き合う方針を打ち立てた背景や、新たな開発プロセスを通して見えてきたユーザーニーズ、今後の展望などを聴きました！

CPOとして取り組むプロダクトの価値向上とユーザー課題に向き合う組織づくり

──まずは、これまでTimeTreeでAnjuが何をされてきたか簡単に自己紹介をお願いします。

2015年5月に入社して、これまでプロダクトマネージャーとしてTimeTreeの改善やマーケティングに携わったほか、広告プラットフォーム「TimeTree Ads」やアプリマーケットプレイス「TimeTree Connect」の立ち上げや、日程調整サービス「Tocaly」のプロジェクト立ち上げに携わってきました。

具体的な業務としては、プロダクト改善以外にもCS業務だったり、マーケティングの一貫としてアプリストアのテキストを考えたり、エンジニアリングとデザイン以外のことはなんでもやっていましたね。

プロダクトマネージャー出身なので、マーケティング業務でも出稿するチャネルとか予算に対しての最適化がどうだみたいな、いわゆるマーケティング的な発想ではなく、プロダクトマネージャーらしい感覚を大事にしていました。

例えば、ユーザーインタビューの内容から訴求メッセージをたくさん作って検証したり、テレビCMだと地方でまずやってみて、どんなものが効果が良かったのかデータを取って改善してから全国CMを流すみたいな発想で取り組んでいましたね。

──CPOになってからは、どんな責任や役割を担ってきたのでしょうか？

まだ多くのことができたわけではありませんが、1つはTimeTreeをどのように進化させていくかの方向性を決めること、もう1つはプロダクトをつくる組織づくりに取り組んでいます。

プロダクト開発に関しては、顧客に提供する価値を最大化して利用ユーザーを増やしていくことが自分の役割です。今のTimeTreeが提供できている価値をより大きくすることと、新たな価値を追加していくことの2つの方向からプロダクトの在り方を模索しています。

組織づくりに関しては、ちょっと変わった取り組みをしています。
一般的にプロダクト開発は、機能単位だったり、複数プロダクトがある場合はプロダクト単位だったりでチームを分けるケースが多いですが、TimeTreeでは「ユーザーの課題」単位でチームを作って開発に取り組んでいます。

比較的長く同じプロダクトづくりに関わっていると、顧客のことを見ずに事業として達成したい事業課題に目が行きがちで、「顧客の何を解決するために今開発をしているのか」を忘れがちです。

TimeTreeでは、自分たちがどういう顧客課題にアプローチしているのかを常に意識しながら開発を進めています。このやり方は顧客に寄り添えるメリットがある反面、開発の難易度は高くなります。

──なぜ難易度が高くなるのでしょう？

ユーザーが困っている具体的なシチュエーションを洗い出し、何を解決したらインパクトが大きくなりそうか、プロダクトがより使ってもらえそうかを特定する作業は抽象度が高いんです。加えて、課題の洗い出しからソリューションの検討、効果の検証など、抽象的なことから具体的なことまで一連の作業をチームで実行していくにはかなり幅広いスキルが求められます。

これまでユーザー課題の特定はプロダクトマネージャーのメンバーが主に進めていましたが、現在はエンジニアやデザイナーも一緒になって取り組んでいます。

──企画職以外も含めて全員で、というのはユニークなのではないでしょうか？

そうですね。最近TimeTreeに転職した方からも、新鮮だとよく言われます。
ここは組織としてこだわっているところで、エンジニアやデザイナーもただ作るだけでなく、何を解決しているのかを主体的に考えながら開発に臨んでもらいたいんです。ユーザー課題の背景が共有されていれば新しい仕様の提案をすることもできますし、アイディアの数が増えてより良いものができると考えています。

組織拡大と事業課題起点の開発による弊害

──ユーザー課題を起点にした開発方針をあらためて打ち出したことにはどんな背景があったのでしょうか？

背景は大きく2点あります。1点目は、組織の拡大にプロダクトの開発方法の標準化が追いついていなかったことです。

特にユーザー課題の特定について、課題の解像度を高める作業はひとそれぞれでしたが、組織が小さい頃はお問い合わせ内容やインタビューで得た情報を全員が把握できていて文脈を共有することが簡単でした。しかし、組織が大きくなるにつれて今までの属人的なプロセスでは、開発メンバー全員で課題の認識を揃えたり再現性の高い開発プロセスを作ったりすることが難しくなっていきました。

背景の2点目は、ここ2、3年のTimeTreeの開発が事業課題起点になった結果、ユーザーが望まない機能提供が増えてしまったことです。

──事業課題起点というのはどういうことでしょうか？

例えば、先日機能提供を終了した「Today」は事業課題起点で開発が進んだわかりやすい例でした。

Todayを開発している当時のTimeTreeはビジネスモデルとして広告事業を伸ばすことに力を入れていました。広告効果の向上を目指して、広告表示数を増やしたり、ユーザーの方々が広告を受け入れやすい表示面を作ることが事業課題になっていたんです。

そこで広告の配信面を増やし、読み物などのコンテンツが載ったメディアである「Today」を始めました。

Todayのコンテンツ自体は有益なものが多かったのですが、リリース後しばらくすると、ユーザーがTimeTreeに訪れる理由や求めるものと、読み物としてのコンテンツの相性がよくないことが分かってきました。結果的に機能の利用は限られたユーザーに止まり、事業への貢献も期待した水準には達しませんでした。

Todayの経験は残念ではありましたが、会社全体の学びに繋がりました。事業貢献のためには、事業のKPIに繋がる直接的なアプローチよりも、まずはユーザーに利用されるもの、ユーザーの課題解決に繋がる機能を入れる必要があり、それが達成できて初めてビジネスへの貢献に繋がるんだと強く実感したんです。

ユーザー課題を起点とした開発へ原点回帰

家族を中心としたクローズドなグループにフォーカス

──そうしたプロダクト開発における課題を踏まえて、CPOとして取り組んだことを教えてください。

まず、プロダクトが目指す方針を明確にしました。

根本となるプロダクトミッションは「クローズドなグループの関係と行動を円滑にする」と定めました。これまで、個人間の予定共有以外にも様々な用途でアプリを使ってもらえるように、オープンな公開カレンダーの実装や、習い事グループのような大人数での利用促進にもチャレンジしてきました。一方で、結局どこの誰に向けてプロダクトを作っていくのかの軸は定まりきっていなかったんです。

TimeTreeは、家族を中心とした親密な関係の人が、生活の中で感じる課題を解決するために少人数グループで利用しているケースが大多数です。TimeTreeは特にそうした人たちの強い課題を解決してます。原点に立ち返ったときに、そうした人々により価値を感じていただけるプロダクトにしたいと考えました。

ただ、コアユーザーにだけ使っていただければよいとはもちろん思っていません。コアユーザーの課題解決に取り組んだ結果、例えば他の少人数のグループや、似たような課題を持つ家族以外のユーザー層にも価値や効果が波及していくと思っています。

コアな価値に迷わずアクセスできるシンプルなプロダクトへ

プロダクトミッションの策定後、プロダクトのコンセプトを「どんなユーザーにもわかりやすい、コア価値まで一直線なプロダクト」と定めました。

機能は増えるほど良いと思いがちですが、適切なボリュームで適切な位置に配置しない限り使い勝手はどんどん落ちていきます。TimeTreeは長年アップデートを重ねる中で多機能化や複雑化が進んでいましたし、新しい機能は目立つところに配置して使ってもらおうとすることが多くなっていたんです。

しかし、プロダクトを作る上で最も大事なことは様々な機能がある中でもコアな価値・コアな機能に迷わずアクセスできて、それを簡単に体験できることです。TimeTreeでいえばカレンダーの共有や予定作成がそれにあたります。

コアな機能を繰り返し使ってもらった後で、もっと使いこなしたいとなった時にコメント投稿機能やTodoリスト機能を使ってもらうのが利用のステップだと考えて設計してます。

ユーザー課題を炙り出し、小さく作って大きく育てる

──開発の進め方も変わったのでしょうか？

そうですね。ユーザー課題を起点にしたアプローチにするために、開発プロセスも大きく変更しました。

具体的には、リサーチに時間を使うようにしました。開発プロセスの中にユーザーインタビューやデータ分析を組み込んで、ユーザーがどういう課題を持っているかを定性的・定量的に炙り出し、課題にアプローチするソリューションを考えます。

そして、いろいろな案の中からよりインパクトのあるソリューションを選び、検証可能な形をMVP（※）としてリリースします。小さく作って大きく育てるという方針ですね。

このリリース方針も今までとはがらっと変えた部分です。プロダクトを作り込んで世に出すと時間もかかりますが、かけた時間に比例してヒットするかというとそうとも限りません。

小さく作ってリリースした場合、うまくいったらブラッシュアップすれば良いし、うまくいかなかったら小さいうちに撤退できて、すぐに色々な方向性を試すことができます。その積み重ねでヒット精度が上がっていくんじゃないかなと考えています。

ユーザーの課題解決への道とTimeTreeの意志の道が交わる点を目指す

──大きな方向転換だったんですね。実際に変化や気づきはありましたか？

ユーザーの方々が持っている課題を、今解決できている課題とそうじゃない課題とに整理し、属人的な感覚ではなくチーム共通のフォーマットで共有できたことは大きな変化でしたね。

ユーザー課題がより具体的に見えるようになったので、プロジェクトとしてもユーザーさんに提供するソリューションが考えやすくなりました。

今はTimeTreeでは「仮の予定」を入れづらいという具体的なユーザー課題を解決できる機能や、予定登録がよりスムーズに行える機能の開発を進めています。

──リリースが楽しみです！少し先の未来まで含めて、今後TimeTreeのプロダクト開発をどのようにしていきたいですか？

プロダクトの方向性の軸は2つあると思っています。1つは今やっているユーザーのみなさんが求めているものを理解して、ソリューションを提供していく方向。そしてもう1つはTimeTreeがどうなっていきたいかの「Will」、意志としての軸です。 

これはTimeTreeのビジョンとも言えるもので、ビジョンを実現するために自分たちはどう進化していきたいのかをユーザーニーズと合わせて考えることが重要だと思っています。ユーザーニーズにお応えするだけでは提供できる価値にも上限が来てしまいます。

ユーザーの課題解決の道と我々の意志の道、その交わる点を見つけて進んでいきたいと考えています。

──ありがとうございました！

TimeTreeではたらくメンバーたち

TimeTreeメンバーズではTimeTreeではたらく多様なメンバーの声を紹介しています。はたらく環境、雰囲気、メンバーたちの考えなどを知りたい方はぜひご覧ください！

TimeTreeの採用情報

TimeTreeのミッションに向かって一緒に挑戦してくれる仲間を探しています。くわしくは応募ページをご覧ください。