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

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

新規事業の決済機能としてStripeを導入する上で考えたこと全て

こんにちは、タイミーデリバリー開発チームの宮城です。
この記事はJP_Stripes Advent Calendar 2020の10日目の記事です。

タイミーデリバリーはデリバリーを頼みたい人が安い価格で注文でき、飲食店も安い利用料で注文を受けられるデリバリープラットフォームです。
その決済機能として今回はStripeを導入しました。
この記事では、決済基盤の技術選定/Stripeを活用したクレジットカード決済と各事業者への入金までの流れ/Railsでの具体的な実装内容 をそれぞれタイミーデリバリーでの活用事例として紹介します。

  • 導入にあたった背景
  • 決済基盤の技術選定基準
  • Stripeでできること
  • PCI DSSについて
  • 利用したStripeの機能
    • Custom Account
  • Stripe SDKを利用したRails/Swiftでの実装内容
    • PaymentIntent
    • Customer
    • Account
      • Connected Accountが決済を行えるようになるまで
    • 決済の全体像
    • DBに保存する情報とStripeで保持する情報の整合性担保
      • 仮登録フェーズ(Try)
      • 確定フェーズ(Confirm/Cancel)
    • stripe-ruby-mockを使ったTesting
    • 返金処理・経理業務
      • Stripeダッシュボードでの返金処理
      • API経由による返金処理
      • 返金のタイミング
      • 入金について
  • よかったこと
    • 決済に関するトラブルが非常に少なかった
    • ドキュメント、サポート、開発ツールが手厚い
  • 失敗したこと
    • 事業者に直接Stripeダッシュボードを見てもらった方が楽なケースが多かった
    • 事業者のStripeへの登録における実装がかなり重く、Expressで提供されているAccountLinkを使った方が良さそう
    • 今アカウントを選ぶとした場合の判断基準
  • 終わりに
続きを読む

増え続けるXaaSのユーザ管理をソフトウェア化していくお話

コーポレートエンジニア(兼いろいろ)をやっている @sion_cojp です。

本当はやり遂げた状態を発表したかったのですが、道のりも長かったため、今やっていこうとしてる内容を記事にしてみました。

この記事を見てタイミーのコーポレートエンジニアに興味を持っていただけたら幸いです。

  • TL;DR
  • 増え続けるXaaS、ユーザ管理、複雑化
  • 残されない手順書
  • 我々がやりたいこと
  • なぜterraform?
  • terraformで管理していくための課題
  • 課題を解決してみる
  • さらにソフトウェア化できそうなところ
  • APIがないXaaS
  • 最後に

TL;DR

  • XaaSユーザ管理を全てterraformにしていく
  • 名前とroleさえ設定してapplyすれば権限付与できる形式にしたい
続きを読む