こんにちは。タイミーのバックエンドエンジニアの中野です。よくGopherくんに似てると言われます。
本記事では月次で実行している「締め」のバッチ処理に関する一連の技術的改善について掲載します。弊社のプロダクト「タイミー」は著しい事業成長に伴いデータ量が急増してきています。そこで今回はデータ量の急増を背景とした中長期的なバッチ処理の設計改善にどのように取り組んできたのかをご紹介したいと思います。バッチ処理に関する技術的改善の記事は前編・後編の2部構成をとっています。前編はバッチ処理におけるトランザクションの改善をテーマに、後編ではバッチ処理に冪等性の設計を導入したことをご紹介したいと思います。
今回は前編のトランザクションの改善をテーマにご紹介します。すでに本番稼働しているアプリケーションにおいてトランザクションの範囲が大きい場合にどのような問題が発生したのか、そしてどう解決していったのかを中心に取り上げます。
読み手としては、今後データ量の急激な増加が見込まれるプロダクト開発の中長期的な設計・運用を模索している方を想定しています。また読み手に該当しない場合でも、現在タイミーがどのような事業を推進しているのか興味を持ってもらえるように記載しましたので是非最後までお付き合いください。
続きを読むこの記事はタイミーのPMM（Product Marketing Manager）のishinabeが担当します。
PMM??と思った方もいるかもしれないので軽くどんなミッションを持っているのかを説明しておくと、デプス調査や定量分析などなどを絡めて顧客課題やジョブの発見から、その深さ・ボリュームの推定、リリースする機能のマーケットイン（機能に価値を感じてもらえる顧客に機能を認知してもらい使ってもらうこと）あたりを主な任務としてIssue度が高いものから解決しようと動いています。
また、今回の記事のテーマのように、デプス含めた顧客理解を組織にインストールすることも重要なミッションとして捉えています。
※前提、世の中的にもまだ役割がかっちりと定まっている訳ではないので、私も関連チームと会話しつつ模索しながら動いている段階です（この記事の話はどちらかというと世に言うUXリサーチャーっぽい動きかも知れない）。
さて、本題の「ユーザーインタビュー参加コストを極小化する仕組み」お話しです。
なお、以降「ユーザー」→「ワーカー」と表記します。タイミーのサービスのユーザーは、お仕事内容を掲載して働く人を募集する「クライアント」と、お仕事に申し込んで働く「ワーカー」に大別されるためです。
こんにちは、フロントエンドエンジニアの樫福 @cashfooooou です。 タイミーでは toB 向け管理画面を作成しています。
半年ほど前、タイミーでは顧客からのサービスへの要望を集め、管理するシステム（以下、要望回収システム）を作りました。 顧客の課題から新しい機能について考え、顧客により価値のあるものを届けるための施策です。
システムの実装には Notion という SaaS を活用しました。 最小限の実装で良い機能・良い運用が作れたと思っています。
この記事では、要望回収システムの実装に取り組んだ経緯から、実際の運用の例まで紹介します。 同じように顧客の要望回収を行いたい方はもちろん、SaaS を使ったミニマルな機能開発の参考になれば幸いです。
はじめまして、Androidエンジニアのmurata(@orerus)です。
アイラ系ウイスキーを愛していますが、肝臓が弱まってきた為最近は専ら0.5%ハイボールを愛飲しています。
本記事では、タイミーのモバイルアプリ開発におけるSLO（サービスレベル目標）を設けているメトリクスのちょっとした改善事例について紹介します。
SLOとは何かといった話やタイミーで運用しているSLOについてはこちらの記事にて詳しく紹介していますので是非ご覧ください！
タイミーのワーカーチームでは、モバイルアプリ開発における指標の一つであるクラッシュフリーレートをSLI（サービスレベル指標）としてSLOの運用を行っています。
しかし、長く運用する中で、SLO運用に期待されている「当たり前品質と攻めたリリースのバランスを取る」「当たり前品質の低下をいち早く検知する」「適切なタイミングでプロダクト品質への改善圧をかける」といった役割が果たされていないと感じられるケースが度々発生していました。
そこで、モバイルアプリ開発メンバーが普段観測しているクラッシュフリーレートのメトリクスを改善することにより問題を解消した事例について紹介します。
はじめまして、Androidエンジニアのsyam(@arus4869)です。
普段は愛知県からフルリモートで勤務していますが、最近は褪せ人として荒野を駆けています。
本記事では、タイミーのAndroidプロジェクトで挑戦しているモジュール分割の取り組みについて紹介します。
また内容の理解を促すため、マルチモジュールについても軽くおさらいします。
本記事では、以下の方を読者として想定しています。
はじめまして、バックエンドエンジニアのぽこひで (@pokohide) です。
最近の日課はゲーム実況者「兄者弟者」の「DYING LIGHT 2 STAY HUMAN」と「エルデンリング」を見る事です。
本記事ではタイミーで長年使われていた、マイクロサービスとして切り出されたチャットサーバ（以降、旧チャットサーバと呼びます）をタイミーの中核を担うモノリシックなRuby on Railsサービス（以降、タイミー本体と呼びます）に移行した話です。
今回は移行した経緯、気にした点などを紹介します。
対象にしている読者は以下の方々です。
※1 : 無人化システムとは この記事 に出てくる造語で「誰も詳細は知らないが、なぜか動いているシステム」を意味する