Timee Product Team Blog

タイミー開発者ブログ

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

  • はじめに
  • 以前のデータ基盤
  • 3つの問題解決と振り返り
    • 問題1: データパイプラインの更新遅延
      • 解決策
      • 実装
      • 振り返り
    • 問題2: 分析チームへのクエリ修正依頼の増加
      • 解決策
      • 実装
      • 振り返り
    • 問題3: ETLパイプラインにおける加工処理の負債
      • 解決策
      • 実装
      • 振り返り
  • これからの品質に関する改善

はじめに

初めまして、タイミーの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テストとはランダム化比較試験ともいれる実験手法です。検証対象をランダムにグループ化して別々の介入をすることで「介入の効果」を図る手法の一つです。

f:id:timee_dev:20211208173232p:plain

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

続きを読む

小さなチームでマルチモジュール開発をしてみた話

こんにちは、iOSチームの阿久津(@sky_83325)です。

今回も前回の記事に引き続き、マルチモジュール開発についての記事です。

タイミーでは2019年7月より、機能単位でFrameworkを分割するマルチモジュール開発に取り組んできました。 現在では全体の約8割がモジュール分割され、27個のモジュールよりアプリが構成されています。

ここ数年でiOSにおけるマルチモジュール開発に対する関心が高まり、多くのプロジェクトで導入され始めているのではないでしょうか。

マルチモジュール化することで次のような恩恵を受けることが出来ます。

  • ビルド時間の軽減
  • 影響範囲の限定
  • ミニアプリを用いた機能単体での動作確認

このような大きな恩恵がある一方で、なんとなく難しそうなイメージがあったり、大規模な開発チームでのみ採用されてる印象があり、導入を見送られているチームも多いのではないでしょうか。

タイミーでは、1~3名という小規模なチームでマルチモジュール開発を続けてきました。 この記事では、実際にそのような小さなチームで運用してみて感じたこと、学んだことを共有したいと思います。

マルチモジュール開発に興味のある方や、実際に導入を検討されている方の参考になれば幸いです。

  • マルチモジュール開発とは
  • 取り組んだ背景・経緯
    • 目的① ビルド時間の短縮
    • 目的② ミニアプリの導入による開発時のデバッグ効率の向上
  • どのように移行していったのか
    • 構成はFeature x Layer形式を採用
    • 課題① 既存の密結合な実装
    • 課題② 各機能間の画面遷移をどうするか
  • 実際に運用してみてどうだったのか
    • ビルド時間が短縮された
    • 開発時の動作確認が容易になった
    • 実装が矯正された
    • 仕組みとして疎結合な実装が保証された
      • 1. 動作確認(QA)のコストが減った
      • 2. 実装のキャッチアップが容易になった
      • 3. 負債が限定された
  • 終わりに
続きを読む

TypeScript の型を用いたコンポーネントの責務の明確化

はじめまして!フロントエンドエンジニアの樫福 @cashfooooou です。

タイミーでは Next.js × TypeScript で toB 向け管理画面を作成しています。 この記事は、toB向けの管理画面の開発時に筆者が気づいたコンポーネント間の責務の明確化の必要性と、 TypeScript の型を用いて責務の分割をサポートする方法の紹介しています。

続きを読む

大規模なマルチモジュール開発をSwiftPackageに移行して運用してみた

はじめまして、iOSエンジニアの阿久津 @sky_83325 です。

タイミーでは、機能ごとにEmbedded Frameworkに分割して開発するマルチモジュール開発に取り組んでいます。 現在では、本体AppやAppExtensionの他に7つの共通Framework、そして16個の機能Frameworkという規模になってきました。

今回は、そのマルチモジュール開発をEmbedded Frameworkではなく、Swift Packageを利用した方法に乗り換えてみたので、その成果や学びについて共有できればと思います。

続きを読む

タイミーでSLOを導入してみた

こんにちは、サーバサイドエンジニアの@Juju_62qです。 今回は年末から仕込んでいたタイミーのSLOについてと、その時に得た学びを紹介したいと思います。

概略

結論としてタイミーのSLOで大事にしているのは以下の3つです。

  • プロダクトの緩やかな品質低下を検知できるものであること
  • プロダクトの健全性を大局的に把握できるものであること
  • 罰則はSLOを消費する行為に相反する行動を取ること

また、組織で新たなものをやる時は熱量/知識/経験のいずれか2つ以上が必要になることも学びとなりました。

  • 概略
  • SLO(Service Level Objective)とは
  • なぜSLOを作ったのか
    • SLO導入前の状態
    • SLOの役割
  • 導入のために行ったこと
  • タイミーで定義しているSLOについて
    • 利用チームについて
    • SLOでどの範囲を扱うかについて
    • 違反時について
    • SLOの見直しについて
  • SLOを導入してよかったこと
  • 失敗と学び
    • 小さく始める
    • やっていきするときに必要なもの
  • 終わりに
続きを読む

『ユニコーン企業のひみつ』を読んで。サービスの開発のように組織も計測しながら進むことが大切だと感じた

こんにちはタイミーCTOのkameikeです

昨日発売された、『ユニコーン企業のひみつ――Spotifyで学んだソフトウェアづくりと働き方』のレビューです。 書籍の発売前に抽選でもらえるキャンペーンに当選し、献本をいただきました。「謹呈」ののし紙がついた本をいただいたのは初めてでテンションが上がりました。

タイミーも現在の20名のプロダクト組織からスケールしていくフェーズに入ってきており、これはSpotifyが組織モデルを樹立しはじめたタイミングと同じであるため非常に参考になりました。

TL;DR

  • ユニコーン企業のひみつ』にはSpotifyの組織のマインドセット・ルールが書かれており、自律的なチームのヒントが多く含まれています
  • ユニコーン企業のひみつ』に書かれているような組織の実現は継続的な計測と改善がとても大切です
続きを読む