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

ユニコーン企業のひみつ』はどのようなことが書かれている本なの?

著者であるJonathan Rasmussonは、2014/8/30にSpotifyに入社されていて、Agile-Coachとして入社されたようです。2017年辺りに退職されており、現在Jonathan Rasmussonは、(彼のyoutubeチャンネル見る限り)iOSエンジニアをされている雰囲気を感じています。この本はJonathan RasmussonがSpotifyで経験された4年の経験をしたためた本になっています。

ユニコーン企業の秘密』に書かれているモデルは、2012年頃、30人から250人にスケールした際に樹立されたモデルであり、その後10年程度運用され2600人規模までこの仕組みで組織が運用されているようです。数千人規模までエンジニアを増やしつつ、「デリバリー」を主軸にどう組織サステイナブルな組織を組み立てるか?という試行錯誤の上に到達した組織のモデル・マインドセットが書かれています。

英語が大丈夫な人で購入を迷っている人は是非以下のビデオを見てもらうのがとても良いと思います。以下のような組織構造をベースにするとどのようなカルチャーが育つのか?ということがわかります。2本立てになっていますので2本目は関連動画からご覧ください。

www.youtube.com

ユニコーン企業のひみつ』は誰の役に立つの?

エンジニア・ビジネスパーソンの皆様

Spotifyの例をとってもこのような組織の考え方は10年近く運用されているので、一定「枯れた技術」になったものかなと思っています。そのため「自律的な組織」的な考え方は、今後10年ぐらいで「gitで開発しています」程度にはある程度スタンダードになると思っています。

この体制は「メンバー/チーム」の裁量が大きくなる仕組みの話なので、より大きな責任でよりクリエイティブに働くことが求められていくと思っています。このカルチャーにキャッチアップすることが、今後のキャリアとしてユニコーン企業のような企業で就労を希望する場合には非常に大きな鍵になってくると思っています。カルチャーのサンプルとして是非この本をお勧めしたいです。

技術責任者の皆様

他組織のユースケースが詰まった本として非常に参考になると思っています。自分の組織に展開するヒントが散りばめられています。

経営者やマネージャーの皆様

「ソフトウェアデリバリー」などわかりにくい単語があると思いますがほとんどの章は基本的にググればわかる言葉で構成されています。ユニコーン企業と戦う心づもりがある方は是非に読んでほしいなと思っています。

エンジニア組織に限らずメンテナンスし続けるモデルに対してチームで立ち向かうために

この本はサービス開発におけるSpotifyの価値観が書かれている書籍です。これは「永遠にメンテナンスしないといけないモデル」に向き合う話でもあると思っています。 近年CRMが浸透する中、営業やマーケティングのモデル化が進んでいると感じています。このモデルに対して「銀の弾丸(唯一の正解)」はなく、自社にフィットさせる改善の繰り返しが必要です。この改善を繰り返すためのヒントが多く書かれている本です。

流動性の高い優秀な人と一緒に働くために

エンジニアは人材の流動性がかなり高いため、マッチングが悪いとすぐに転職していく、という経営からのコントロールが難しいセグメントの人材だと思っています。ただ、これはエンジニアが性質上わかりやすく先行しただけで、あらゆる職種で人材の流動性が上がっていくと思っています。 人材の流動性が高まり、自己実現のために働いている方にとって魅力的な組織とはどのような組織なのか?のヒントが多く書かれている本です。

ユニコーン企業のひみつ』の実現に向けてどう取り組むのか?

ユニコーン企業のひみつ』には「こうするといいよ」だったり、「こういう価値観だよ」という内容が中心に書かれています。Spotifyの良さに関しては『ユニコーン企業の秘密』や⬆️のyoutubeの動画にお任せするとして、このモデルが作られた経緯や時期などを調べてみました。

このモデルは2012年に外部に発信されています。*このモデルは仕組み含めての設計から展開まで「アジャイルコーチ」という存在が強く関わってきているようで、このモデルの樹立にはフルタイムのアジャイルコーチであるAnders Ivarssonさんと外部コンサルタントであるHenrik Knibergさん1名でモデルの樹立をしているようです。

日本のスタートアップでは、私の観測範囲においてあまりフルタイムのアジャイルコーチというのは一般的ではないように感じており。おそらく「VPofE」や「EM」のようなロールの方が担う責務になるのかな?と思っています。大切なのは肩書きではなく、組織の改善に対するフルタイムのコミットメントできるロールであり、その責務を担うロールが本書でも言われている「あらゆるレベルでの継続的改善」継続していくことが大切だと感じました。

サービスの開発のように組織も計測しながら進むことが大切だと感じた

Spotifyの組織モデルを調べる中で、Spotifyのデータに基づく改善のカルチャーが組織にも適応されているように感じました。

データとサービスの意思決定の関わりは、『ユニコーン企業のひみつ』内でも多く述べられてお、2章の経営の意思決定をどう扱うか?のBIDDモデル、第8章にはプロダクトの改善でいかにデータを利用するか書かれています。

このデータに対する姿勢は組織運用に対しても展開されているようです。2012年に公開されたペーパーである、Scaling Agile @ Spotify にてその様子を窺い知ることがでます。「サービス開発のように組織をデザインしているなぁ」と特に印象に残っている2つの観点を書きます。

①自律的なチームであることを計測する。改善要求ではなくバックアップする

「Squad(チーム)は自律していること」が実現できているかどうか?は掲げるだけではなく計測が必要になります。 Spotifyではチームが自律的であることを、以下の7つの基軸でモニタリングしていたようです。

  • プロダクトオーナー
  • アジャイルコーチ
  • 仕事の影響度の強さ
  • リリース容易性
  • チームに適合するプロセス
  • ミッション
  • 組織的なサポート

調査した内容は以下の図のように、クライテリアごとチームごとのメッシュで健康度がわかるようにモニタリングされます。

f:id:timee_dev:20210426234345p:plain
https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

指標が下がっているチームに対しては、各セグメントにエキスパートをアサインして、改善を行なっていきます。「自律的なチーム」であるSquadが実態として自律的に振る舞えているか?を指標化し定常的にモニタリングし、改善を行なっていたようです。

②組織の依存性を調査し改善していく

Spotifyの「Squad(チーム)は自律していること」が実現できているのであれば、何かを実現するにあたって、チームとチームの間に「依存関係」はなく折衝が発生したり、ブロッキングになることはないはずです。特にTribe(150名程度の部)を跨ぐような依存は自律性を大きく損なってしまいます。

これを防ぐために、Squad(チーム)やTribe(部)の依存関係は以下のシートのように定期的に調査されるとのことです。 このサーベイによりチームや組織の依存を検知して依存を切るような責務の分離やシステムの改修を進めていきます。

f:id:timee_dev:20210426234318p:plain
https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

これはまさしくシステムを疎結合にするリファクタリングのような行為で、組織の健全性を保つ良いアプローチのように感じました。

で、タイミーとどう交わるの?

「Squadは自律したチームであること」という方針を定め。その方針を指標として計測し、上記ののような観測と実行のサイクルが実行されていることがSpotifyの組織の強さだと感じています。

タイミーも現在の20名のプロダクト組織からスケールしていくフェーズに入ってきており、これはSpotifyが組織モデルを樹立しはじめたタイミングと同じであります。そのためタイミーも何かしらモデルを作り言語化し、計測し改善していくフェーズに入ってきていると思っています。

大きな組織においては「How」を統一して押し付けるのではなく、指標計測を組織としてバックアップし、改善の主体はチームに委ねることはチームの自律性において非常に大切な要素だとこの本を通して改めて感じました。

タイミーはこれから一年程度かけて、組織の拡充を進めるとともに、チームの指標を継続的にFBすることでチームの状態の改善が行える状態を目指していきます。この変遷を一緒に作っていくことに興味がある方は是非、こちらなどからエントリーなどいただければ嬉しいです...! we are hiring...!

蛇足🐍 日本語訳と英語名の差分に感じた気持ち

英語名『Competing with unicorns』に対して、日本語名『ユニコーン企業のひみつ』になっているのもだいぶマーケティング上の性質の違いを感じます。

英語名だとユニコーン企業が身近な脅威になっている人に響くタイトル、日本語名だと雲の上の存在をの覗く人に響くタイトルになっています。文化の違いというのもあると思いますがユニコーン企業との距離感の違いでもあるのかな?と感じて挑んでいかねばという気持ちになりました。また調べている時に感じたことですが、このスタイル自体2012年に発信されており、Edgeのナレッジを得るという意味だと日本語でトレンドをフォローすること自体かなり速度が遅いなぁという気持ちになっています。

新規事業の決済機能として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すれば権限付与できる形式にしたい
続きを読む

ECSで通常時とスパイク時のオートスケールを運用する

こんにちは、サーバサイドエンジニアの@Juju_62qです。 今回はタイミーで実践しているECSのオートスケール戦略についてお話ししようと思います。

TL;DR

  • タイミーではTarget Tracking ScalingとStep Scalingを組み合わせてオートスケールをしています
  • Target Tracking Scaling -> 通常のスケールアウト・スケールイン
  • Step Scaling -> スパイク時のスケールアウト
  • 2つを組み合わせることで、様々なリクエストに対し適切なリソースを用意しています
続きを読む

RailsのAPIサーバーのエラーレスポンスで例外に対応するエラーコードを返却する

はじめましてこんにちは。
夏が本気を出してきて最近麺類しか口にしていないサーバサイドエンジニアのかしまです。

この度APIにてHTTP Status Codeとは別に、例外に対応するエラーコードを返すよう奮闘したのでその知見を共有したいと思います。

やりたいこと

APIにて例外が発生した場合、以下の形式でレスポンスを返すようにします。

{
  "errors":
  [
     {
        "code":  "code1",
        "message": "message1",
     },
     {
        "code":  "code2",
        "message": "message2",
     },
  ]
}

Why?

今回追加したAPIは外部のアプリケーションとの連携に使うため、以下の要件を満たす必要がありました。

  • クライアントサイドがハンドリングしやすいような設計にする
  • エラーの識別子は不変であること

そのためエラーメッセージとは別に、コードを返すことにしました。

次の章から実際にどのように実装したかを紹介したいと思います。

続きを読む

オフィスのネットワーク構築についてのお話

SREとコーポレートエンジニアをやっている @sion_cojp です。

今回は新オフィスのネットワーク構築を実施したので、こちらについてお話します。

私自身、学生時代の研究や、10年前にデータセンターのネットワーク構築しか経験がないため、所々おかしな点があるかもしれませんが、ご了承ください。

また今回相談に乗ってくださった @kajinari さんに感謝の意を表します。

TL;DR

  • 旧オフィスはとても不安定なネットワークでしたが
  • coltの回線とmerakiのネットワーク機器で
  • 快適なネットワークができました
  • 予算問題で達成できなかったこと: L3/L2機器 + ネットワーク回線の冗長化
続きを読む