タイミーの紹介

恩田：タイミーはスキマバイトサービスを運営している会社です。従来の「求人サイト」でも「派遣」でもない、「働きたい時間」と「働いてほしい時間」をマッチングするスキマバイトサービスを提供しています。



ワーカーの皆さんにとっては、今働ける仕事がすぐに見つかり、面接・履歴書なしですぐに働ける。働くときも簡単ステップで、お給料は即日入金というスピード感を実現しています。企業の皆様にとっては、今働ける人がすぐに見つかり、専用の管理画面から1分で募集開始できる手軽さがあります。

おかげさまで、現在スキマバイトサービス利用率でナンバーワンを誇っており、2025年4月時点で導入事業者数は180,000社以上、ワーカー数は1,100万人という規模になっております。

続いて、本日のプレゼンテーションの前提条件にもなる、開発組織について軽く紹介させていただきます。タイミーの開発組織は、チームトポロジーでいうところの複数のStream Aligned Team + Platform Teamで構成されています。



このStream Aligned Teamは、私たちは大きなくくりを「Tribe」と呼んでいて、その中にさらにバリューストリームに沿って分割されたスクワッドが複数存在している構成となっています。

それぞれのStream Aligned Teamは、ある価値提供する継続的な流れを対象として、それぞれが価値を届けることを自律的・高速で行えることを意図したチーム編成をしています。今日の大きなメイントピックでもあるのですが、こういった取り組みの成果や、それを出した結果としてのソフトウェアの品質といったものが、しっかりと自分たちにフィードバックがかかる仕組みを意図した組織設計をしているのが特徴です。

開発生産性の捉え方

開発生産性の話をする前に、タイミーにおけるプロダクト主導型組織の戦略的意図について少し紹介したいと思います。

タイミーのようなプロダクト主導型組織において、プロダクト戦略とは、顧客ニーズに応える新しいプロダクトやサービスをどう生み出して、どう市場に届けるかを策定することを指すと考えています。この戦略的意図を実現するための具体的なアクションプランを、プロダクトイニシアチブと呼んでいます。

この実行計画としてのプロダクトイニシアチブは、アクションプランですので、人的資源や物的資源の投資が必要になります。このリソースを最適に運用し、投資効率を高めることが、結果としてプロダクト戦略の成功を左右します。この投資対生産性は、戦略を支えるリソース管理の役割を果たし、最終的には実現付加価値の生産性という形で売り上げに変換されます。

このプロダクトイニシアチブの実行効率を表現するのが、開発生産性という位置付けです。効率的に進められることによって、限られたリソースで最大の成果を得ることが可能になり、結果として組織の競争力を左右します。



こういった位置づけを踏まえた上で、我々がどういった状態を目指したいのかというと、2つの軸があります。

1つ目は、プロダクトイニシアチブを開発組織が爆速でデリバリーできる状態を維持すること。2つ目は、プロダクトの当たり前の品質をユーザーへ提供することです。

なぜこれを目指すのかというと、試行回数を増やすことが、結果としてPMFを速やかに実現したり、施策単位でも撤退を決められることに強い相関を持つと思っているからです。また、技術負債解消の遅延コストを最小化させたいという思いもあります。

そして最後が、これがキーメッセージになるんですけれども、システム品質と開発生産性は相互作用する関係だと考えているからこそ、このデリバリーを爆速でできる状態と、タイミーユーザー目線の「あたりまえ品質」というところを二軸で置いています。

工業規格から引用すると、システムの品質とは、システムが利害関係者の明示的ニーズ及び暗黙のニーズを満足している度合いです。明示的ニーズは例えばSLAのような契約で明記されているもの、暗黙のニーズは満足度といったものです。

こういったシステムの品質に関する測定可能な特徴を、品質特徴と呼びます。品質特徴には、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性といった分類があります。

このソフトウェア品質は、受益者が異なってきます。例えば保守性（モジュール性、再利用性、解析性、修正性、試験性）の恩恵を受けるのは社内の開発者です。一方で、機能適合性や信頼性、セキュリティなどの恩恵を受けるのは、タイミーを使ってくださるユーザー様になります。



DORAなどのリサーチでも表現されているように、システム品質を上げる取り組みはデリバリーを加速させると考えています。

内部品質への向き合いは、当然デリバリーを加速させる正の相関があります。また、信頼性エンジニアリングの取り組み、SREのプラクティスであるCI/CD、高品質なテスト基盤、リリースエンジニアリング、o11y、IaCなども、結果として生産性に寄与します。

さらに、効率性という観点もあります。我々タイミーはクラウド上で構築されており、従量課金制のSaaSを組み合わせて作っているサービスです。システム品質が向上し、無駄なリソース使用が筋肉質になれば、財務的余力も出て、ツールやシステム、人への投資で、さらに開発生産性を高めるループが回っていきます。

ここで、開発生産性やシステム品質を数字で見ることの意味についてお話しします。

弊社としても、Four Keysというのは非常によく見ているのですが、この使い方が重要だと思っています。結局、この数字自体に意味があるかというと、それほど大事なものではないと考えています。むしろ、このパフォーマンスの指標と正の相関の関係のあるケイパビリティやプラクティスに目を向けて、そこから各チームが重要な課題の仮説立てや、検証改善の活動を続けていける仕組みや文化が大事だと思っています。

結果としては、例えばFour KeysやSLIのようなものは、結果指標になると捉えています。



そして、これも大事なところですが、数値化されたソフトウェアの品質や開発生産性を、例えばエンジニア個人やチームの業績評価に用いないということが非常に重要だと思っています。指標を持つことと、その目標として追うことは、明確に区別するべきです。

その上で、そういった指標を正しい方向に動かすために、正の相関があるベストプラクティスから自分たちの組織やアーキテクチャ上、どういったギャップがあるのかというところに目を向けるのが大事だと捉えています。

プロダクトや組織が大きくなってくると、専門性による組織の細分化が起きてきます。タイミーも、現在エンジニアリングメンバーで100人弱まで成長し、さまざまなステークホルダーニーズや安定運用のニーズが出てきています。

そうなってくると、会社やプロダクトが必要とする専門性の深度に応じた、専門性カットのチームが立ち上がってきます。現に弊社としても存在しますし、これ自体は悪いことではないと思っています。

問題なのは、チーム間で注力するパフォーマンス指標が直交し始めると、サイロ化が始まることです。典型例は、安定運用が期待されるOpsとデリバリーや納期コミットが期待されるDevの構図です。



これが発生すると、リリースのフェーズゲート化や特定組織によるレビュー必須化、意思決定のデリゲーションレベル低下といった問題が生じます。

こういった専門性と分業化は、組織の拡大によってはある程度やむを得ないことがあると思っています。それを正しく認識した上で、それがどのタイミングで負債になるのか、解消するべきなのか、ないしは解消するとしたら、どれぐらいその期間がかかってリスクなのか、といったメタ認知が大事だと思っています。

そもそもこういった事態を防ぐために、ソフトウェア品質への向き合い方を社内分業ではない形で取り組み、開発生産性とトレードオフしないことを目的としたプラットフォームエンジニアリングが重要になってきます。これが最近の潮流であり、私たちが目指すところでもあります。



余談ですが、Four Keysが良好であることは、期待付加価値や実現付加価値の生産性を保証しないと思っています。その上で、仕事量の生産性は期待付加価値をより多く試行し顧客に価値を届けるため、その試行回数を増やすための土台となります。また、そもそも試行回数をただ増やすだけのビルドトラップに陥らないためにこそ、冒頭に申し上げた戦略的意図やプロダクトイニシアチブを会社として運用し、それをチームと接続するという構図になっています。

タイミーの開発生産性への取り組みー具体例編

それでは、これらの認識を踏まえた上で、どのような取り組みをしているかについて具体的にお話しします。

大きく4つの軸で取り組みを回しています。1つ目はソフトウェア品質のフィードバックループを回すこと、2つ目はボトルネックに目を向けること、3つ目は一次情報の観察から課題仮説を作ること、4つ目は獲得すべきケイパビリティ・実践すべきプロセスのフレームワークを持つことです。



まず1つ目、ソフトウェア品質のフィードバックループを回すことです。タイミーの開発組織は、各バリューストリームに沿って組成されている機能開発チームが、自分たちの取り組んだ成果物の成果およびソフトウェアの品質が、自分たちにフィードバックがかかることを目指した組織設計をしています。

開発者自身ないしは、それぞれのStream Aligned Teamがデリバリーしたソフトウェアのシステム品質のフィードバックをちゃんと受けることを組織の文化として根付かせています。

具体例としては、各チームが担当するユーザージャーニーの体験悪化のアラートを自分たちで設計・設定し、品質悪化のアラートをトリアージし、改善のためのRunbook整備、ポストモーテムとNext Actionの策定を行っています。

また、テスト設計や品質保証活動を組織内分業をせずにチームで行うことを実践しています。決済関連のチームとマッチング体験をつかさどるチームでは、当然デリバリーにおける品質保証活動の強度が違うため、それぞれがチームごとに考えて行い、フィードバックを受けています。

プラットフォームエンジニアリング的な取り組みとしては、フィードバックを楽に、かつ早く受け取れるような各種改善や開発者体験を提供しています。具体例として、コードベースとユーザージャーニー体験アラートのマッピング、複数チームが並列で精度高く検証できる環境の提供などがあります。

2つ目は、ボトルネックに目を向けることです。ボトルネックとは、業務プロセス全体の中で最も処理速度が遅く、全体の効率を低下させている原因のことです。開発生産性の軸で考えたときに、複数の切り口があります。



コーディング工程は目が向きやすく、AIエージェントなどで加速させやすい部分ですが、コーディング工程の前後に目を向けることが重要です。ビジネス要件の把握コスト、コードベース把握のコスト、レビューのコスト、手動テストのコスト、リリースのコストなど、どこに開発工程のボトルネックが潜んでいるかに目を向けて、定性定量の情報をもとに改善を繰り返していきます。

また、顧客価値を送り届ける間の社内業務プロセスにボトルネックが発生していないかという切り口もあります。部分的に完成した仕事、タスク切り替え、待機、非標準的な作業や手作業などがあります。特に「常にxxチームに作業依頼が必要」といった状態は、パフォーマンス指標の直交が原因で生まれた可能性があるので注意が必要です。

ユーザージャーニー軸では、タイミーのワーカー・クライアント双方のクリティカルユーザージャーニーに基づいたモニタリングと目標信頼性・パフォーマンスの設定から、技術ボトルネックの特定と対応を繰り返しています。

アーキテクチャ・データフロー軸では、ユーザージャーニー上重要な処理がSPOFな実行基盤となっていないか、システムの可用性をクラウドコストとトレードオフにできる構成になっているか、カスケード障害の発生がありえる箇所はないかといった観点で改善を繰り返しています。

タイミーでは現在、Devin、Cursor、GitHub Copilot、Claude Codeなどを使っています。これらのソリューションは、開発工程全体のボトルネックに目を向けていないと、本当に出したいインパクトは限定的になり得ると考えています。

そのため、開発工程の頭からのAI適用を考える必要性が出てきています。現在は、コーディング業務での利用を中心に、Flaky Testの解消サポート、テストケース作成の自動化・簡素化、PRの自動サマリー作成とレビューなどでも利用しています。

3つ目は、一次情報の観察から課題仮説を作ること。ソフトウェア品質や開発生産性にまつわる定性・定量の一次情報を収集することが重要です。特に定量情報だけではなく、開発者からの意見といった定性情報も、ボトルネック特定の重要な情報源です。



タイミーでは、システムのパフォーマンスの定量情報を定期的にチェックして課題仮説を立てる活動や、開発者のアンケートで定性観点でのボトルネックや困りごとの情報収集を継続して行っています。

これらの活動を形骸化させないように、目的意識を持って組織に根付かせることが重要です。いわゆるOODAループ、観測と状況判断、仮説立て、アクションプラン策定と実行、再観察をひたすら回していくことが組織として重要だと考えています。

4つ目は、獲得すべきケイパビリティ・実践すべきプロセスのフレームワークを持つことです。DORAのコアモデルのような、信頼性や開発生産性と強い相関関係があるプラクティスやフレームワークを活用しています。セキュリティについては、NISTやCIS Control Frameworkのようなセキュリティフレームワーク、コストについてはFinOpsのようなメソドロジーを参考にしています。



弊社では、特にDORAのコアモデルやセキュリティフレームワークを意識しながら、課題仮説の切り口として使っています。巨人の肩に乗ることが重要だと考えています。

まとめ

本日お話しした内容をまとめさせていただきます。

タイミーの開発組織が目指すところは、プロダクト開発組織がプロダクトイニシアチブを爆速でデリバリーできる状態を維持し、プロダクトの「あたりまえ品質」をユーザーへ提供することです。

どう目指すのかという点では、4つの軸で取り組んでいます。1つ目はソフトウェア品質のフィードバックループを回すこと、2つ目はボトルネックに目を向けること、3つ目は一次情報の観測から課題仮説を作ること、4つ目は獲得すべきケイパビリティ・実践すべきプラクティスのフレームワークを持つことです。

今日いろいろなことをお話ししましたが、まだまだできていないことが多いのが実情です。そこで、タイミーではさまざまな職種で積極採用中です。本日のカンファレンスにブースも出展しておりますので、もしよろしければお気軽にお立ち寄りください。いろいろお話しできると嬉しく思います。ご清聴ありがとうございました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です