Letter for SRE (Incident Management)

2024年3月14日 21:58

はじめまして、株式会社 dinii (以後ダイニー) で VP of Technology というロールを担っている karszawa と申します。

この度、ダイニーで SRE (Incident Management) という新規の採用ポジションを公開しました。あまり聞き慣れない名称のポジションなので、このポジションが生まれた背景や、このポジションへの期待について説明します。

1. ダイニーの事業について

文章が長すぎるという方はこちらの動画だけでもご覧ください…！ 💁‍♂️

ダイニーは「すべての人の飲食のインフラになる」というビジョンのもと、飲食店の POS (Point of Sales) のシステムや決済機能の開発に取り組んでいます。飲食店の POS は、簡単に言うと注文とお会計のシステムで、いわゆる「レジ」や「ハンディ」と呼ばれるハードウェアで構成されています。一昔前はかなりゴツめのハードウェアが主流でしたが、近頃は iPad や Android 端末で構成されるサービスも増えています。ダイニーでも iPad と Android のスマートフォンを利用しています。

「ダイニー」は、POS で取得できる「いつ・どの商品が・どんな価格で・いくつ売れたか」という情報に加え、世界で初めて「誰が」という顧客データを紐づけた次世代の POS — “ID-POS” です。ダイニーは、インターネットの小売サービスでは当たり前に実現されている「顧客情報」を、オフラインの世界である飲食業界においても実現しています。

もちろん、データが見れるだけでは「ただ面白いだけ」でそれを活用するかどうかは利用者に委ねられてしまいます。ですが、「ダイニー」では顧客情報を活用した自動での販促やアンケートの実施を行い、実際に飲食店の売上を伸ばしています。

顧客情報を握っているからこそ売上を増やすことができ、POS を握っているからこそ効果を売上として分析することができるのです。施策と効果測定を同時に押さえて売上を伸ばすことができる、というのが「ダイニー」の強みです。

「ダイニー」は2024年3月時点で、累計ユーザー ID 数 1200 万人を獲得し、ここまで T2D3 のペースで成長しています。将来的には日本にある飲食店145万店舗全てで dinii が利用されている、そんな世界観を目指しています。

2. プロダクトの難しさ

ダイニーがやっていることは一言で言ってしまえば「POS を作って ID を取る」だけです。こんなプロダクトのどこに難しさがあるのでしょうか？参入障壁が低くレッドオーシャンなのでしょうか？もちろんそんなことはありません。

まず POS を作るということが難しいです。飲食店の POS に求められる要件は機能的にも非機能的にもハードルが高いです。飲食店業務のバリュエーションは多岐にわたり、それに合わせた機能は無数に必要です。また、飲食店のピークタイムはまさに戦場のような忙しさなので、それを支えるシステムは応答性が高く安定している必要があります。

これに対し、大企業の作る伝統的 POS はイントラネットで稼働するものなので、通信障害やクラウド障害には無縁です。クラウドサービス上で稼働する私達のサービスは、安定性という意味ではどうしても後塵を拝することになってしまいます。

ダイニーはこれまで何度か大規模な障害を発生させてしまいましたが、その際の飲食店への影響は凄まじく、まさに阿鼻叫喚という惨状を生んでしまいました。こんなことは二度と起こしては行けないと強く反省する一方で、インターネットに依存している以上は 100% の可用性は理論的に実現不可能です。ダイニーでは SLO = 99.95% としてサービスを提供していますが、残りの 0.05% の時間でサービスが全く利用できない状態がユーザーに許容されるとは考えていません。ダウンタイムでさえも何とかしてオペレーションを回せるような仕組みを、サポート体制まで含めたサービス全体として担保しなければならないのです。

機能要件に関するトラブルも同様で、それが仮に仕様であったとしても、顧客の業務に支障が生じていればそれを解決するためにあらゆる手段を講じます。こちらもシステムダウンへの対策と同様に、サポート体制も含めたサービス全体として、いかにネガティブ要素を排除して顧客に価値を届けるかという考えを重視しています。

具体的な施策としては以下のようなものを実施しています。

ユーザーサポートでの問い合わせ対応
エンジニアによる24時間のオンコール制度（夜間は電話を取れれば良いので普通に寝れます）
インシデントの対応を反省し再発防止策を講じる週次のポストモーテム
システムメトリクスをエンジニア全員で確認する週次のパフォーマンスレビュー
システムダウンが発生した際を想定した緊急事態訓練

ここまでコストを割いて、サービス全体としての安定性の維持向上に努めているのは、

飲食店のインフラとしてこれだけのことが求められるから
これだけの仕組みを構築することは一朝一夕には不可能で差別化要素になるから

です。

ID-POS という唯一無二の強みを持つダイニーですが、その強みを活かすための「安定性」「信頼性」に関しても ID-POS と同様レベルの関心を持って事業に取り組んでいます。

ダイニーの開発組織について

ダイニーの開発組織の人数構成は次のとおりです（カッコ内が副業等のパートタイムの人数）。

Software Engineer 11 (+8 part time)
Product Manager 3
Designer 3
QA 7

エンジニアは、当初は一つのチームしかありませんでしたが、今は4つのチームに分かれています。

Feature Team (2022/06~) → 機能開発全般を担当
Platform Team (2022/06~) → アーキテクチャの改善や監視基盤の構築
Discovery Team (2023/08~) → 新規事業の PoC 開発
Data Team (2023/12~) → 分析機能の開発とデータ基盤の改善

プロダクトサイドのメンバーはメガベンチャーから移籍してきたメンバーが多く、高効率でリーンな開発を行っています。また、採用技術としては Hasura など非常にテクニカルなものを採用している一方で、技術は手段としか考えておらず、常に顧客への価値提供を第一に考えています。顧客により大きな価値をより素早く提供するにはどうすれば良いかという価値観が浸透しているため、生産的で創造的な議論が生まれやすいです。

トラブル対応を行うための専任のメンバーは設けておらず、むしろすべてのメンバーが積極的にトラブル対応や再発防止に取り組むべきだと考えています。ダイニーというプロダクトを開発するにあたり、トラブル時の対応を洗練させるということが事業上の強みにもなっていくからです。

3. SRE (Incident Management) を募集する背景

すべてのメンバーがトラブル対応や再発防止に関心を持つべきとはいえ、組織の拡大に伴い全体を把握するということが物理的に難しくなってきました。それにより、あるところではユーザーの関心の薄い箇所を改善しようと取り組んでしまったり、あるところではユーザーの関心が非常に強いにも関わらず問題を放置してしまったりということが発生してしまっています。

更に、対応品質の維持は難題です。日の浅いメンバーは飲食店の業務に詳しくないため、上述のようなトラブル対応が事業としての価値の源泉ですらあるという発想は持ち得ず、対応が後手に回ってしまったりすることがあります。更に、プロダクトの機能がどんどん増えてキャッチアップのコストも増大していますし、単純に「知らないので大事だと思わなかった」という事象が発生しやすくなっています。

こういった背景において、インシデント対応の品質の向上や、そもそもインシデントを発生させないような体制の構築にリーダーシップを持ち、組織を先導していくポジションが必要になりつつあります。

現状ではこういった取り組みは VP of Technology である筆者や、監視体制に責務を持つ Platform Team のメンバーで分業で行っています。ただし、リソースの都合もあり、それに対し常に集中できているとは言い難い状況です。

こういった背景において、この度 SRE (Incident Management) というロールを募集することになりました。所属は Platform Team となり、これまで安定性の維持向上に努めてきたメンバーと協力しつつ業務に取り組んで頂くことになります。

4. SRE (Incident Management) に任せたいこと

再掲ですが、ダイニーではユーザーのトラブルに対処するためだけの仕組みとして次の施策を実施しています。

ユーザーサポートでの問い合わせ対応
エンジニアによる24時間のオンコール制度（夜間は電話を取れれば良いので普通に寝れます）
インシデントの対応を反省し再発防止策を講じる週次のポストモーテム
システムメトリクスをエンジニア全員で確認する週次のパフォーマンスレビュー
システムダウンが発生した際を想定した緊急事態訓練

初めはこれらの施策の対応品質を徐々に改善していくというのがお仕事になります。もちろん、これとは全く異なる方向性の施策でユーザーのトラブルを減少させることが出来るのであれば、それらにも積極的に取り組むべきと考えています。むしろ、エンジニアやシステムという枠に囚われず、ユーザーの課題を解消するためのあらゆる手段を柔軟な発想力で提案できるという素質は、非常に高く評価させて頂きます。

事業を支える根幹である「トラブル対応」を専門で主体的に改善していけるポジションです。会社全体としても、そういったユーザーのネガティブ側面を減らすことにコストを割くべきという思想は徹底的に浸透していますので、その推進には全面的なバックアップを受けられます。

5. SRE (Incident Management) に求められる技能

これまでの文章でこのポジションがどうして必要とされているかを徹底的に説明していますので、そこから逆算してどのような経歴が望ましいかは想像に難くないかと思います。

ここでは簡単に要素技術を上げるに留めておきますが、何れも入社後にキャッチアップして頂ければ良いと考えています。

Node.js, TypeScript の知識
Google Cloud でのモニタリング経験
Slack, Notion, Retool を利用した社内ツールの開発経験

やはり何よりも重要なのは、顧客の課題を理解しそれに徹底的に向き合うマインドです。その思想さえ持ち合わせていれば、必要な技術を必要なタイミングでキャッチアップしたり、会社組織全体をその方向性に推進させていくのは自ずと達成できることだと考えています。

6. メンバー

プロダクト組織外でも、顧客の価値に向き合うという思想は当然ながら浸透しています。何も SRE が一人でインシデントに向き合う必要はなく、すべての人が「安定性」「信頼性」に向き合っている中で、テクニカルな面から組織を先導していくというイメージが実態に近いと思います。
ここではそういった面でも信頼できるビジネスサイドメンバーを紹介します。

伝説の営業マン益子さん: 外食におけるシステム作りに向き合って20年。どんなトラブルが起こっても「ピンチはチャンス」を体現してくれます。

アカウントセールス中川さん: 現場を理解するためにシフトイン。とにかく現場に足を運ぼうというカルチャーを体現してくれています。

元ユーザーサポート倉地さん: ユーザーからの問い合わせの一次受けとして数多のトラブルを解決してきました。現在は全社随一のサポート力を見込まれ関西支部でアカウントセールスを担当しています。