体制構築もアーキテクチャ設計も、“投資”の観点が重要。タイミーCTOに「スケールする仕組み作り」を学ぶ

2017年の設立以来、「一人ひとりの時間を豊かに」というビジョンのもと、事業の成長を遂げてきた株式会社タイミー。同社は「働きたい時間」と「働いてほしい時間」をマッチングするスキマバイトサービス「タイミー」を提供しています。「タイミー」は登録ワーカー数が500万人を突破し、利用企業は約46,000社。また、事業開始時は5人だったタイミーの社員数も、2022年には546人に到達。2023年中に1,000人規模を目指しています。

急拡大を実現できた裏側には、開発組織において数多くの「スケールする仕組み作り」の工夫がありました。今回はタイミーの執行役員CTOである亀田彗さんに、これまで行ってきた意思決定のなかで、印象に残るものを聞きました。

モノリシックなRailsアプリとして構築されている「タイミー」

――亀田さんがタイミーで担当されている業務についてまずは教えてください。

私がタイミーに参画したのは2019年5月で、会社のフェーズとしてシリーズAの資金調達が終わった頃、アーリー期でした。会社全体で社員が30名、エンジニアが5名くらいの規模でしたね。私は入社してしばらくの間CTOではなくCPOを担い、プロダクトマネジメントの体制を整えていました。当時は「何をどのタイミングでどう作っていくか」についての課題が重要で、それを解決する必要があったためです。2020年からは、開発組織やシステムのアーキテクチャ・品質などの課題を解決することにより注力したいと考え、CTOにロールチェンジしました。

タイミーの特徴として「タイミー」という単一プロダクトだけで事業成長をさせてきたことが挙げられます。かなり成長率の高いビジネスを実現できているので、マルチプロダクトでクロスセルなどによって売り上げのトップラインを作るのではなく、スケールしているプロダクトをより大きな幹にしていくことにフォーカスする技術的な意思決定が多いです。

また、他にも技術的な特徴として、Ruby on Railsの巨大なモノリシックアプリケーションとして「タイミー」のシステムを構築していることがあります。開発組織が大きくなるなかで、モノリシックなアプリケーションでいかにして開発・運用をうまく進めるかといった方針を考えています。

Four Keysを重視。デプロイ頻度は月間約200回

――ここからは過去に取り組んできた技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきたいです。

まず、タイミーがこれまで注力してきた施策で、成功したと考えていることからお話しします。タイミーはFour Keys*の指標がすごく良い状況なんですよね。特に良好な数値が出ているのがデプロイの頻度で、調子の良いときは月間約200回程度になっています。

*…ソフトウェア開発チームのパフォーマンスを示す4つの指標。「デプロイの頻度」「変更のリードタイム」「変更障害率」「サービス復元時間」から構成される。

もちろん、最初からこの体制を実現できていたわけではありません。私が入社して間もない頃は、週次くらいの頻度で手作業のデプロイを行っていました。でも、なるべく細かく頻繁にデプロイするほうが1回あたりの変更の差分も小さくなりますし、問題があった際の検知や切り戻しも容易になります。そこで、デプロイ頻度を高める方針を選びました。

最も理想的な状態は、mainブランチにコードがマージされた際にデプロイされることです。しかし、手作業での週次デプロイからいきなりその状態に変えるのは、技術的な変化が大き過ぎて開発組織の混乱が起きてしまうと思いました。そこで、SREのメンバーと一緒に取り組んだのが、まずデプロイをChatOpsに変えることでした。

デプロイ対象となるブランチやコミットハッシュなどをSlack上で指示すると、デプロイできる仕組みを構築しました。なぜこれがFour Keysの向上に貢献したかというと、デプロイの頻度を開発者自身がコントロールできるんですよね。ChatOpsを導入して間もない頃はまだ不安も大きいので、「まずは1日1回だけChatOpsでデプロイしよう」といった運用を行います。そこから、慣れてきたら徐々にデプロイ頻度を高めていくことができます。

この事例では、開発者たちがデプロイ頻度を段階的に変化させて、ブランチの運用ルールもより良い形に変えていきました。そうして徐々に運用を改善し、2年後くらいには「mainブランチにコードがマージされた際にデプロイ」に切り替えることができました。

――この事例を踏まえて、読者の方々に伝えたい学びはありますか？

まず、先ほども述べましたが開発者にデプロイの裁量があることは重要です。タイミーではトップダウンでデプロイのルールを決めるのではなく現場に委ねることで、徐々に改善のサイクルが回るようになりました。それから、デプロイ頻度の向上は必ずシステム監視の強化とセットで行うことです。デプロイしたものに不具合があった際に、なるべくすぐに気づけるような体制を構築しています。

加えて、タイミーでは初期フェーズからSREのスキルを持った人が各チームにいる状況を実現しています。これにより、障害のアラートが発生した際にSREのスキルを有するメンバーを中心として対応するので、障害発生時のオーナーシップをそのチームが持ってくれるようになるんですよ。そうすることで、デプロイとその後の対応について、特定のチームが責任を持ってフィードバックサイクルを回す仕組みが実現できます。

この事例についてまとめると「システムや組織に対して行った投資が、その後のリターンとして返ってくるのか」という観点が重要です。タイミーは単一のプロダクトを扱っており、数年後も必ずそのプロダクトが事業の中核として存在しているはずなので、監視やデプロイの改善に投資をすれば必ずリターンがあるんですよ。やみくもに開発・運用体制の改善を行うのではなくて、「その改善が投資対象として適切かどうか」を考えるほうがいいです。

マイクロサービスからモノリシックへの移行

――では、次の事例についても伺います。

「タイミー」では事業者とワーカーとがマッチングすると、メッセージを通じてやりとりができます。メッセージ機能をもともとはマイクロサービスとして切り出しており、そのサービスではアカウントの認証やプロフィール情報の保存、メッセージの送受信、既読の有無の管理などを担っていました。

サービスの機能の関心を分離することで、「タイミー」のビジネスの全体的なコンテクストをあまり理解していない方でもメッセージ機能を開発できるようにしたい、というモチベーションに基づいてマイクロサービス化をしていたんです。

しかし、マイクロサービスとして切り出したことにより複数の課題が発生したため、結果的には「タイミー」の本体側のサービスに取り込んでモノリシックな構造に移行することを決めました。発生した課題の詳細や移行の流れなどは「マイクロサービスからモノリシックへ。メッセージサーバ移行の道のり」というブログに記載しています。

もともと「メッセージ」はサブドメインの領域だったんですが、サービスが成長していくにつれて予想よりもはるかにユースケースが広がったんですよね。それに伴い、たとえば「タイミー」本体のシステムとの連携が複雑になったり、単一機能を提供することを前提とした設計のため追加の開発が困難になったりと、マイクロサービス化したことでいくつも課題が発生していました。

――読者のなかにも「自分たちも特定機能をマイクロサービスにしたけれど、課題が発生しておりモノリシックに移行しようか迷っている」という方もいらっしゃると思います。そういった方に伝えたいことはありますか？

この課題についても、やはり「その事業ドメインやシステムに対して継続的に投資したいかどうか」が一番大事だと思っています。たとえば、仮に設計面に課題のある機能だったとしても、今後あまりユースケースが広がる見込みのないシステムだとすれば、コストをかけて戻す必要はないという判断になるかもしれません。一方で、その機能で今後多くの拡張が行われることが見えているのならば、できるだけ早く適切なアーキテクチャに移行したほうが、アジリティを向上させやすいと思うんですよね。

ポストモーテム改善のために、CTOを巻き込む

――他の技術的な取り組みとしては何が挙げられますか？

タイミーの開発組織では、開発と運用がうまく結合する状態を目指しています。「タイミー 」は事業者とワーカーとのマッチングに加えて労務管理や給与支払いなども行うので、サービスのバリューチェーンが長いです。それらの一連の流れが何かの原因で止まると、ビジネス全体が停止するリスクを抱えています。

かつ、「タイミー 」は前年比で募集人数が3倍以上くらいのペースで成長しているプロダクトなので、それに伴って開発や運用の課題も増えていきます。発生している障害や運用の負荷などに真正面から向き合って、課題を継続的に解消していかなければサービスが立ち行かなくなる可能性があるんです。そのための施策として、ポストモーテム*1の実施やトイル*2の洗い出し・手作業の削減などにはかなり力を入れています。

*1…システムやサービスで発生した不具合や障害の振り返りを行う事後検証。

*2…プロダクションサービスを動作させることに関する業務で、手作業でくり返し行われ、自動化することが可能であり、戦術的に長期的な価値を持たずに作業量がサービスの成長に比例する傾向を持つもの。

――ポストモーテムは具体的にどういった運用形態をとっていますか？

何かしら顧客に影響があったものは、ほぼすべてポストモーテムを実施しています。そして、ポストモーテムのコンテンツは、不具合や障害への対応が適切にできたかという振り返りと根本解決のための取り組みという2軸に分かれています。

タイミーでは「ポストモーテムを行う際には、CTOの私を巻き込んでほしい」とメンバーに伝えています。最近は私が忙しすぎて参加できないケースもありますが、それでも可能な限り参加したいと考えています。それによって何をしたいかというと、障害が起きたことに対する改善のサイクルが、現場レイヤーだけではなくリソースアロケーションの権限を持ったレイヤーでも回るようにしたいんですよね。

要するに「障害が起きたらCTOを巻き込んでポストモーテムをしてほしい」と伝えておくと、CTOも徐々に「障害発生の対応にかなり時間を取られているから、対策を行うための人を配置しよう」というモチベーションが起きるんですよね。だから、もしも自社のポストモーテムの改善を行いたいならば、CTOや場合によってはCEOなどを参加させることをおすすめします。

長い時間軸でシステムに携わることで、得られる学びがある

――「タイミー」の開発・運用を通じて得てきた知見が山ほどあるのですね。

他にも、いま挑戦中でまだ結果が出ていない取り組みがいくつかあります。具体的には、モジュラモノリス化やマイクロサービス化などを行って、アプリケーションの各機能をより疎結合にして独立的に開発やデプロイ、スケールができないかと検討しているところです。

タイミーは開発組織の人数がすごい勢いで増えています。このペースで人が増えていくと、モノリシックなアプリケーションでは徐々に問題が生じてくるはずなんですよね。制約を取り払うために、そろそろサービスを分けていくべき時期だと判断しています。

タイミーが扱っている事業ドメインがビジネスとして確実にグロースしていくこと、かつそれがものすごいボリュームであることが見えています。だからこそ、それに適した体制を構築するには、開発プロセスへの投資だけではなく技術的な投資も必要になってきます。

モジュラモノリス化やマイクロサービス化もそうですし、最近ではSPA化を完了させました。そういった取り組みを積み重ねていくことで、より良いものづくりができるんだろうなと考えています。

――かつてはマイクロサービス化に失敗したけれど、事業としてのフェーズが変わったことでマイクロサービス化に適したタイミングが来たとは。不思議なものですね。

最適なアーキテクチャのあり方は、会社や組織の状況に応じて変わりますからね。かつては正解だと思っていたことが時間の経過とともに失敗になることもありますし、その逆もあります。

だからこそ、アーキテクチャ設計などに携わる人は、数年単位という長い時間軸で事業やシステムに携わることで、経験から得る学びを最大化できると思います。自分たちの行った技術的な意思決定がその後どのように評価されるのか。成功も失敗も含めて、意思決定をした結果と長いサイクルで向き合うことで、実のある知見を得ることができます。

――たくさんの学びがあるインタビューでした。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

成功事例だけではなく、失敗事例もたくさん学ぶことが大事です。それによって、実行可能性が上がっていくんですよね。エンジニアリングもプロダクトマネジメントも、良いとされている理論・手法は世の中に数多くあります。そして、「その理論・手法を取り入れることでどのような失敗が起こり得るか、それはなぜかという知識を持っていること」と「その理論・手法を自分たちの組織にうまく適用できるかどうか」には密接な関係があります。

私自身も、駆け出しのエンジニアだった頃はさまざまな理論や手法を学んで、「これを組織に導入しよう」と行動しては失敗して、ショックを受けていました。でも、数々の事例からエッセンスを学び取っていくことで、より良い技術的な意思決定が徐々にできるようになってきました。そのための学びを得るうえでも、失敗に対する耐性をつけるという意味でも、インタビューやコラムを通じて他の人たちの事例を知ることには価値があると思いますね。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul