こんにちは、サーバサイドエンジニアの@Juju_62qです。 今回は年末から仕込んでいたタイミーのSLOについてと、その時に得た学びを紹介したいと思います。
結論としてタイミーのSLOで大事にしているのは以下の3つです。
また、組織で新たなものをやる時は熱量/知識/経験のいずれか2つ以上が必要になることも学びとなりました。
昨日発売された、『ユニコーン企業のひみつ――Spotifyで学んだソフトウェアづくりと働き方』のレビューです。 書籍の発売前に抽選でもらえるキャンペーンに当選し、献本をいただきました。「謹呈」ののし紙がついた本をいただいたのは初めてでテンションが上がりました。
タイミーも現在の20名のプロダクト組織からスケールしていくフェーズに入ってきており、これは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本目は関連動画からご覧ください。
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つの基軸でモニタリングしていたようです。
調査した内容は以下の図のように、クライテリアごとチームごとのメッシュで健康度がわかるようにモニタリングされます。
指標が下がっているチームに対しては、各セグメントにエキスパートをアサインして、改善を行なっていきます。「自律的なチーム」であるSquadが実態として自律的に振る舞えているか？を指標化し定常的にモニタリングし、改善を行なっていたようです。
Spotifyの「Squad（チーム）は自律していること」が実現できているのであれば、何かを実現するにあたって、チームとチームの間に「依存関係」はなく折衝が発生したり、ブロッキングになることはないはずです。特にTribe(150名程度の部)を跨ぐような依存は自律性を大きく損なってしまいます。
これを防ぐために、Squad（チーム）やTribe(部)の依存関係は以下のシートのように定期的に調査されるとのことです。 このサーベイによりチームや組織の依存を検知して依存を切るような責務の分離やシステムの改修を進めていきます。
これはまさしくシステムを疎結合にするリファクタリングのような行為で、組織の健全性を保つ良いアプローチのように感じました。
「Squadは自律したチームであること」という方針を定め。その方針を指標として計測し、上記ののような観測と実行のサイクルが実行されていることがSpotifyの組織の強さだと感じています。
タイミーも現在の20名のプロダクト組織からスケールしていくフェーズに入ってきており、これはSpotifyが組織モデルを樹立しはじめたタイミングと同じであります。そのためタイミーも何かしらモデルを作り言語化し、計測し改善していくフェーズに入ってきていると思っています。
大きな組織においては「How」を統一して押し付けるのではなく、指標計測を組織としてバックアップし、改善の主体はチームに委ねることはチームの自律性において非常に大切な要素だとこの本を通して改めて感じました。
タイミーはこれから一年程度かけて、組織の拡充を進めるとともに、チームの指標を継続的にFBすることでチームの状態の改善が行える状態を目指していきます。この変遷を一緒に作っていくことに興味がある方は是非、こちらなどからエントリーなどいただければ嬉しいです...! we are hiring...!
英語名『Competing with unicorns』に対して、日本語名『ユニコーン企業のひみつ』になっているのもだいぶマーケティング上の性質の違いを感じます。
英語名だとユニコーン企業が身近な脅威になっている人に響くタイトル、日本語名だと雲の上の存在をの覗く人に響くタイトルになっています。文化の違いというのもあると思いますがユニコーン企業との距離感の違いでもあるのかな？と感じて挑んでいかねばという気持ちになりました。また調べている時に感じたことですが、このスタイル自体2012年に発信されており、Edgeのナレッジを得るという意味だと日本語でトレンドをフォローすること自体かなり速度が遅いなぁという気持ちになっています。
こんにちは、タイミーデリバリー開発チームの宮城です。
この記事はJP_Stripes Advent Calendar 2020の10日目の記事です。
タイミーデリバリーはデリバリーを頼みたい人が安い価格で注文でき、飲食店も安い利用料で注文を受けられるデリバリープラットフォームです。
その決済機能として今回はStripeを導入しました。
この記事では、決済基盤の技術選定/Stripeを活用したクレジットカード決済と各事業者への入金までの流れ/Railsでの具体的な実装内容 をそれぞれタイミーデリバリーでの活用事例として紹介します。
コーポレートエンジニア（兼いろいろ）をやっている @sion_cojp です。
本当はやり遂げた状態を発表したかったのですが、道のりも長かったため、今やっていこうとしてる内容を記事にしてみました。
この記事を見てタイミーのコーポレートエンジニアに興味を持っていただけたら幸いです。
はじめましてこんにちは。
夏が本気を出してきて最近麺類しか口にしていないサーバサイドエンジニアのかしまです。
この度APIにてHTTP Status Codeとは別に、例外に対応するエラーコードを返すよう奮闘したのでその知見を共有したいと思います。
APIにて例外が発生した場合、以下の形式でレスポンスを返すようにします。
{
"errors":
[
{
"code": "code1",
"message": "message1",
},
{
"code": "code2",
"message": "message2",
},
]
}
今回追加したAPIは外部のアプリケーションとの連携に使うため、以下の要件を満たす必要がありました。
そのためエラーメッセージとは別に、コードを返すことにしました。
次の章から実際にどのように実装したかを紹介したいと思います。
続きを読むSREとコーポレートエンジニアをやっている @sion_cojp です。
今回は新オフィスのネットワーク構築を実施したので、こちらについてお話します。
私自身、学生時代の研究や、10年前にデータセンターのネットワーク構築しか経験がないため、所々おかしな点があるかもしれませんが、ご了承ください。
また今回相談に乗ってくださった @kajinari さんに感謝の意を表します。