「PMFは“起きちゃうもの”」タイミーCTOが語るリアルと急成長を支えた開発組織

2018年8月にローンチし、急成長を続けているスポットワークサービスのタイミー。そのプロダクト誕生前夜から開発に関わってきたCTOのkameikeさんは「この成長は、創業から1年足らずで、スタートアップの成否を左右するPMF（プロダクト・マーケット・フィット：※1）を迎えたからこそ」と振り返ります。

タイミーはどうやって、1年未満という短期間でのPMFを実現したのでしょうか。「PMFは狙って起こすものじゃなく、“起きちゃう”もの。PMFには2つのシグナルがあった」と語るkameikeさんに、急成長スタートアップの「PMF後の開発組織のリアル」を伺いました。

（※1）PMF（プロダクト・マーケット・フィット）：ビジネスにおいて、顧客のニーズを満たす商品を提供できており、かつ潜在顧客が多数いる市場に適合できている状態を指す。スタートアップの成否を左右するともいわれる

• keyboard_arrow_down 「アプリ立ち上げに30秒かかっても離脱しない」。PMFが“起きちゃった”瞬間
• keyboard_arrow_down 個社カスタマイズはしなくていい。PMFを示す2つのシグナル
• keyboard_arrow_down 急激なスケールに耐えうる形を模索、「チームトポロジー」に辿り着く
• keyboard_arrow_down カオスな変化も楽しめるのは「つくること」を楽しめる人

――タイミーは創業後すぐにPMFを達成したそうですが、当時はどのような状況でしたか？

kameike：タイミーがリリースされたのは2018年8月で、PMFしていると自覚したのは2019年2月でした。ちょうどシリーズAの調達を終えた頃です。

当時の私は、週1でプロダクト開発や採用の手伝いなどにコミットする業務委託でした。PMFへの焦りもあり、開発メンバーとビジネス書の輪読会などをして「どうしたらPMFできるだろう」と話し合っているようなフェーズでした。しかし2019年2月のあるとき、同じように経営メンバーとPMFを目指してディスカッションしていたところ、元COO副社長川島（諒一）さんに「もうPMFしてると思うよ」と言われたんです。

意外なひと言に驚きましたが、よく考えると「確かにそうだな」と納得できる状況でした。というのも、事業者向け働き手向けに必要な機能もそろっていなかったため、これからPMFだと考えていました。そんな中、川島さんの一言で、少数であれ小さなプロダクトを雇い手、働き手がしっかり使い続けてくれていると言う事実を実感し、PMFを自覚しました。

プロダクトは決して「快適」と言える状態ではありませんでしたが、働く人も事業者も、タイミーを求め続けてくれていた。これは、タイミーで体験できる働き方や雇用のあり方が「唯一無二である」と感じてもらっている証拠だと思いました。また、当時はアプリの作りも良くなく、30秒ぐらいトップ画面を開くことに時間がかかったことがあるんですが、事業数値に一切影響がなかったと言うこともありました「他に代替手段がないなら、アプリを開くのに30秒かかっても待ってくれるんだ」と。

感覚としては「PMFが起きちゃった」という感じでした。

── 「PMFが“起きちゃった”」というと？

kameike：多くの方は、「PMFは、練りに練った戦略と、創意工夫と努力を尽くしてたどり着くもの」だと思っているのではないでしょうか。実際、私自身もそう思っていました。

けれど、そのサービスに対するニーズが巨大なら、プロダクトや組織が未熟でも、PMFは気づかぬうちにやってきてしまうんだということです。

――kameikeさんは、PMFを実感してから3カ月後の2019年5月に入社されました。なぜこのタイミングだったのでしょうか？

kameike：当時は、サービスがこれまで以上にスケールすることが見えてきたので、スケールを支えるシステムの土台を大急ぎで整えなくてはならないという状況でした。

タイミーの生み出した「スポットワーク」という考え方は当時全く新しい概念だったので、法的にグレーになってしまっている部分がありました。しかしこのサービスがもっと一般化していくことを考えると、法整備が進み、グレーな部分は次第になくなっていくはず。そのタイミングで、今ある巨大なニーズを満たせるサービスになるために、人力でやっていたことを自動化する必要がありました。そういう作業を急ピッチで進めなくてはならない。

では副業として関わっている私はどうする？と一度立ち止まって考えたとき、やはり私は、一緒にタイミーをつくってきたメンバーの皆と、これからももっと良い「ものづくり」をしていきたい、そしてそのために、まず目下の大きなこの課題と、正社員としてしっかりと向き合いたい、と考え入社を決意したのです。

その後、労働条件通知書の電子交付が可能になるなど法改正に合わせたシステムの改修を進め、大きくスケールするための準備は万端になりました。

――PMF前後で、何かわかりやすい変化はあったのでしょうか。

kameike：いま振り返ると「あれがPMFのシグナルだったんだな」と感じるような変化が大きく2つありました。

1つは、サービスの「持続可能性」を高めるために運用や品質に重きが置かれるようになったことです。

PMF前はいわゆる「探索」の時期で、タイミーのビジネスモデルに需要があるのかを確かめるために、新しい機能開発や検証にフォーカスしていました。そのため、可用性などの品質改善の優先順位がそもそも高くなかった。しかしPMFして、サービスの利用数が年3～4倍のペースで伸びていくと「サービスが止まったら、ビジネスに大打撃になる」という共通認識が生まれていきます。それに伴い開発の重心も、障害対応やデータの精緻化、テストコードの増設など、品質を重視し持続可能性を高めるための取り組みに置かれるようになったのです。

kameike：もう1つの変化は、経営陣が「個社カスタマイズ」に乗り気ではなくなったことでした。

一般的にB to Bプロダクトの場合、「この機能を開発したら、このお客様が大規模に導入してくださるかもしれない」と、個社カスタマイズをすることがありますよね。その個社カスタマイズが売上げになるかもしれないし、PMFのヒントが隠されているかもしれないので。ところがPMF後は、新しく機能を開発しなくても、様々なお客様がサービスを導入してくださり、ものすごい勢いで売り上げが伸びていくんです。そういう状況では、個社カスタマイズをしてもそれほど事業成長に寄与しません。すると、経営は個社カスタマイズへの関心が下がってしまいます。

もちろん個社カスタマイズは、ニーズを満たせるプロダクトをつくってPMFを実現するためには必要です。しかしPMF達成後は、そのメリットが一気に少なくなってしまうのです。

――その2点は、プロダクトがPMFを迎えたことをはかるためのチェック項目だと。

kameike：そうですね。「この機能をつくれば売り上げが立つはずだ」「個社カスタマイズに力をいれたらプロダクトが売れるはずだ」という考え方が組織の中で説得力を持っている場合、まだPMFしたとは言えない可能性が高いと思います。

――PMFした頃、タイミーの組織はどのような状況でしたか？

kameike：正社員は5名程度で、週3～4日コミットしてくれる業務委託メンバーが2、3名いるという状態でした。少人数のため当然ながらチーム分けの必要はなく、開発組織として動いているというより、エンジニア個々人がそれぞれ単独で動いている状態でした。一人ひとりが「とにかく目の前のことをがむしゃらにやる」というスタートアップでよくある創業期のフェーズ。わかりやすく、オフィスに寝泊まりしていた時期もありました。

そんなとき突然PMFが訪れたので、PMF後の混乱は正直「気合い」で乗り越えるしかありませんでした。

――その後のサービスの基礎を強固につくっていく段階では、どのような組織設計をしたのですか。

kameike：まず、フロントエンドとバックエンド、SREなど職能別にチームを分けました。2019年9月ごろに、今後の事業成長を見越して自動化対応など基本機能の強化に取り組むべきフェーズになったと判断。2020年にかけてエンジニアの人数を20〜30人に増やしました。

このとき職能でチームを分けたのは、システムの構造上バックエンドで解決しなければならない課題を多く抱えていたからです。当時は主に、給与計算や支払い、労働条件通知書の発行等の自動化や、最低賃金の変更などへの対応など、事業者側に提供する根幹機能の開発に取り組んでいました。これらの機能は、働く人の個人情報や事業者の機密情報など、高い機密性が求められるデータを扱います。また、働く人と事業者の双方にとってのサービス利便性を底上げする機能でもあるため、高い信頼性を担保しなくてはなりません。そのため、バックエンドの設計や開発をより慎重に行う必要がありました。

サービス提供の命綱がバックエンドにある以上、バックエンドの課題はフロントエンドの課題よりも優先度が上がりやすくなります。そのため、バックエンドにリソースを集中させる形をとりました。

――職能別にチームを分けた結果、何が起こりましたか？

kameike：バックエンドにリソースを集中できたことで、必須だと考えていた自動化などの開発を短期間でできるようになりました。それに、フロントエンドの設計やコードも洗練されました。フロントエンドではバックログの流量が比較的少なかったからこそ、技術投資としてリアーキテクチャリング等の開発に時間を割くことができたのです。今までがむしゃらに開発してきた中で溜まった負債を返済し、品質も高められたと思います。

一方で、バックエンドとフロントエンドを別のチームで開発すると、片方が仕様を固め、片方がそれに合わせるという構図になりやすい側面もあります。そのため、プロダクトの仕様に裁量が持てなくなり、ユーザーへの提供価値を追い求めづらくなっていってしまいました。

そこで2020年の10月ごろ、ステークホルダー別のチーム分けに変えることにしました。具体的には、個人ユーザー向けの機能開発を担う「ワーカーチーム」と、事業者向けの機能を開発する「クライアントチーム」の2つです。しかし、働く人と事業者の両方が使う機能の開発などの際、2チームの開発がコンフリクトし、品質もスピードも落ちてしまったのです。

――色々なチームの分け方を試してきたんですね。

kameike：そうですね。「PMFしちゃった」状態だったので、当初はその後の急激なスケールに対応できる組織のあり方を、十分に考えられていませんでした。ただ、一貫して「顧客価値の提供に最適なチーム組成」を追求し、チームの分け方について試行錯誤を続けてきたと思います。

「顧客価値の最大化」に最適化したチームの分け方を決めるには、少なくともビジネス寄りのプロダクトマネジメントの視点と、技術マネジメントの視点の2つが必要だと考えています。プロダクトの売上やユーザー数など事業インパクトばかりを重視すると、技術マネジメントが十分にできなくなります。反対に技術マネジメント側に偏りすぎると、顧客体験を追求しきれず使いにくいサービスになってしまいがちです。このバランスに特に配慮して様々なチームの分け方を試したのですが、しっくりくる分け方にならなかった。悶々と悩んでいたときに出会ったのが、「チームトポロジー」でした。

チームトポロジーとは、開発のスピードを高めて価値提供が行われるまでの時間を短くするための組織設計モデルやその考え方をまとめたものです。顧客への価値提供に直結する領域については、設計から開発、運用に至るまでの意思決定を一つのチーム内で行える「ストリームアラインドチーム」を構成します。その上で、各チームの開発速度や品質を担保するために「イネイブリングチーム・プラットフォームチーム」がインフラやツールなどの基盤を整え、それらを活用できるようにする、という考え方です。これはまさに「顧客価値の最大化」のためにやるべきことだし、僕が実現したかったことにぴったりだと思いました。そして2021年の冬ごろから、チームトポロジーに則ってチームを分け直したんです。

――どのようにチームトポロジーに則ったチーム分けをしたのでしょうか。

kameike：ビジネスプロセスの中で「ストリームアラインドチーム」をどこに置くべきかを見極めることからはじめました。

その結果タイミーが顧客に価値を届けるには、まず2つの領域にストリームアラインドチームを置くべきだということが見えてきました。

1つ目は、「働きたい人と事業者のマッチング」の領域です。顧客視点に立てば、タイミーを使って働く人にとっては「どんな会社で働くか」、その人々に働いてもらう事業者にとっては「誰が働くか」が重要です。この「マッチング」が、タイミーを利用する体験の第一歩であり、働く人にも事業者にも価値を感じてもらう最初のチャンスとなります。

そして2つ目は、高い信頼性が求められる領域。働く人の出退勤や給与支払い、事業者側に提供する労務管理サービスは、いずれも安全性や確実性が必要です。これらも、働く人にとって「簡単に働き先が見つかり、すぐお金がもらえる」、事業者にとって「困ったときにすぐに働いてもらえて、手続きもスムーズ」という、タイミーならではの価値を提供する重要なポイントです。

そこで、働く人と事業者のマッチング領域を担当する「マッチングシステムチーム」、働く人の出退勤や労務管理システムを担当する「スポットワークシステムチーム」という、2つのストリームアラインドチームをつくりました。そしてそれらが共通して使う基盤をつくる「プラットフォームチーム」が、2チームの開発を支えるという3チーム体制としました。

この分け方は今も大きく変わっておらず、今後はこの3チームを支えるために、QAやCI/CDなどを担うプラットフォームチームや、イネーブルメントを担うチームを拡充していく予定です。

――いま振り返って、PMF前に「もっとこうしておけばよかった」と反省していることはありますか？

kameike：まだPMFできていない頃に、複雑な仕様をつくり込んでしまったケースがいくつかありました。本当に大切なのはマーケットに出して反応を見ることなのに、その前に「この機能はきっと顧客に必要だろう」と思い込んで、つくり込みすぎてしまったんです。

その結果システムに複雑さをもたらしてしまって、後から行う新規開発にも影響が出てしまいました。もっとシンプルに考えてつくればよかったなと思います。

――PMF前後にエンジニアに求められることは何だと思いますか？

kameike：PMFのために必要な「探索」に対して、ポジティブに付き合う覚悟ではないでしょうか。矛盾しているように聞こえるかもしれませんが、PMF自体は「しちゃうもの」ですが、そのための「探索」なしには決して達成できません。

探索とは「つくって捨てる」を高速で繰り返す作業で、すでに定まったプロダクトがある場合の開発とは根本的に違います。実際、エンジニアとしてそこにコミットし続けるのはかなりしんどいです。通常のプロダクト開発と違って、信頼性や変更容易性の担保など将来の運用を考えた開発が求められるフェーズではなく、つくったものが顧客の役に立たなければ即刻捨てて次をつくり始める。このサイクルがいつ終わるかわからないというのも、なかなかつらいと思います。

しかし探索の重要性を理解し、探索に最適化した開発にポジティブに向き合えるエンジニアが集まっていれば、より早くPMFを引き寄せられると思います。

――PMFに備えるために、開発組織として準備できることはあるでしょうか？

kameike：サービスがスケールしても、楽しく働き続けられる人を集めることだと思います。それは、あらゆる性質の「つくること」に楽しさを感じられる人です。この「つくること」には、プロダクト開発だけでなく、組織づくりや文化づくり、チームづくりなど、会社、事業、プロダクトにまつわるさまざまな要素が含まれます。

PMFによってもたらされる急激なスケールによって、会社や組織、プロダクトの状況は常に変化にさらされ続けますし、エンジニアの役割や守備範囲もどんどん変化していきます。そのような環境でも、広義の「つくること」を楽しめる人であれば、大きな変化が日々起こっても、役割が変わっても、主体性をもって能力を発揮し楽しみ続けられるのではないでしょうか。

取材：石川 香苗子
執筆：一本 麻衣
編集：光松 瞳、王 雨舟、石川 香苗子
撮影：曽川 拓哉