ユーザーインタビュー参加コストを極小化する仕組み

この記事はタイミーのPMM（Product Marketing Manager）のishinabeが担当します。

PMM??と思った方もいるかもしれないので軽くどんなミッションを持っているのかを説明しておくと、デプス調査や定量分析などなどを絡めて顧客課題やジョブの発見から、その深さ・ボリュームの推定、リリースする機能のマーケットイン（機能に価値を感じてもらえる顧客に機能を認知してもらい使ってもらうこと）あたりを主な任務としてIssue度が高いものから解決しようと動いています。

また、今回の記事のテーマのように、デプス含めた顧客理解を組織にインストールすることも重要なミッションとして捉えています。

※前提、世の中的にもまだ役割がかっちりと定まっている訳ではないので、私も関連チームと会話しつつ模索しながら動いている段階です（この記事の話はどちらかというと世に言うUXリサーチャーっぽい動きかも知れない）。

さて、本題の「ユーザーインタビュー参加コストを極小化する仕組み」お話しです。
なお、以降「ユーザー」→「ワーカー」と表記します。タイミーのサービスのユーザーは、お仕事内容を掲載して働く人を募集する「クライアント」と、お仕事に申し込んで働く「ワーカー」に大別されるためです。

Notion API を使った機能開発 〜最小の実装で作る要望回収システム〜

はじめに

こんにちは、フロントエンドエンジニアの樫福 @cashfooooou です。 タイミーでは toB 向け管理画面を作成しています。

半年ほど前、タイミーでは顧客からのサービスへの要望を集め、管理するシステム（以下、要望回収システム）を作りました。 顧客の課題から新しい機能について考え、顧客により価値のあるものを届けるための施策です。

システムの実装には Notion という SaaS を活用しました。 最小限の実装で良い機能・良い運用が作れたと思っています。

この記事では、要望回収システムの実装に取り組んだ経緯から、実際の運用の例まで紹介します。 同じように顧客の要望回収を行いたい方はもちろん、SaaS を使ったミニマルな機能開発の参考になれば幸いです。

モバイルアプリ開発におけるメトリクスを改善することで、SLO違反の予兆や改善の傾向を認知しやすくした話

はじめに

はじめまして、Androidエンジニアのmurata(@orerus)です。

アイラ系ウイスキーを愛していますが、肝臓が弱まってきた為最近は専ら0.5%ハイボールを愛飲しています。

本記事では、タイミーのモバイルアプリ開発におけるSLO（サービスレベル目標）を設けているメトリクスのちょっとした改善事例について紹介します。

SLOとは何かといった話やタイミーで運用しているSLOについてはこちらの記事にて詳しく紹介していますので是非ご覧ください！

本記事の概略

タイミーのワーカーチームでは、モバイルアプリ開発における指標の一つであるクラッシュフリーレートをSLI（サービスレベル指標）としてSLOの運用を行っています。

しかし、長く運用する中で、SLO運用に期待されている「当たり前品質と攻めたリリースのバランスを取る」「当たり前品質の低下をいち早く検知する」「適切なタイミングでプロダクト品質への改善圧をかける」といった役割が果たされていないと感じられるケースが度々発生していました。

そこで、モバイルアプリ開発メンバーが普段観測しているクラッシュフリーレートのメトリクスを改善することにより問題を解消した事例について紹介します。

目次

タイミーのAndroidアプリ開発で採用しているモジュール分割の取り組みについて

はじめに

はじめまして、Androidエンジニアのsyam(@arus4869)です。

普段は愛知県からフルリモートで勤務していますが、最近は褪せ人として荒野を駆けています。

本記事の概略

本記事では、タイミーのAndroidプロジェクトで挑戦しているモジュール分割の取り組みについて紹介します。

また内容の理解を促すため、マルチモジュールについても軽くおさらいします。

本記事では、以下の方を読者として想定しています。

• 他社のモジュール分割の手法に興味がある方
• マルチモジュールなプロジェクトに挑戦してみたい方

マイクロサービスからモノリシックへ。チャットサーバ移行の道のり

はじめに

はじめまして、バックエンドエンジニアのぽこひで (@pokohide) です。

最近の日課はゲーム実況者「兄者弟者」の「DYING LIGHT 2 STAY HUMAN」と「エルデンリング」を見る事です。

本記事ではタイミーで長年使われていた、マイクロサービスとして切り出されたチャットサーバ（以降、旧チャットサーバと呼びます）をタイミーの中核を担うモノリシックなRuby on Railsサービス（以降、タイミー本体と呼びます）に移行した話です。

今回は移行した経緯、気にした点などを紹介します。

対象にしている読者は以下の方々です。

• レガシーなシステムと向き合っている人
• 無人化システム ※1 に疲弊している人

※1 : 無人化システムとは この記事 に出てくる造語で「誰も詳細は知らないが、なぜか動いているシステム」を意味する

タイミーのデータ基盤品質。これまでとこれから。

はじめに

初めまして、タイミーのDRE (Data Reliability Engineering) チームの土川(@tvtg_24)です。

本記事ではデータ品質の保守に着目してここ1年くらいで試行錯誤したことを振り返っていきたいと思います。

対象にしている読者は以下の方々です。

• データ品質について考えている方
• データ分析の品質担保に困っている方
• ETLからELTへの基盤移行を考えている方

この記事は Data Engineering Study #11「6社のデータエンジニアが振り返る2021」 - connpassで発表させていただいた内容を詳細に説明したものになります。

登壇スライド: データ基盤品質向上のための一年 - Speaker Deck

動画: https://youtu.be/q9HA1S3vmcE?t=7578

ABテストとは？タイミーでのABテスト事例紹介

はじめに

プロダクトチームの克海です。PdMの補佐をしながらプロダクトのデータアナリストをしています。 本記事ではアプリでのABを始めようといしている方に向けてのABテストの実施の流れと事例についてまとめた記事になります。

ABテストとは？

ABテストとはランダム化比較試験ともいれる実験手法です。検証対象をランダムにグループ化して別々の介入をすることで「介入の効果」を図る手法の一つです。

メールマーケティングや広告、ウェブページの改善などのデジタルマーケティングや医学現場でも使われている手法で、多くの実験では変更を加えない「コントロールグループ」と、変更を加える「テストグループ」を作り、実験を行います。実験を開始して2つのグループの違いを検証します。2つのグループに対して介入以外同一条件な状態を作ることで、バイアスがない状態で比較することができます。 実験を繰り返すことで、ユーザーが求めている価値の知見をため、サービスやアプリの最適化していくことができます。今回の記事では、ABテストした流れと結果について記載します。