見出し画像

Letter for SWE (Platform Engineering)

karszawa

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

この度、ダイニーで SWE (Platform Engineering) という新規の採用ポジションを公開しました。ダイニーでは全てのプロダクトで統一の技術（Node.js, React, Cloud Run, PostgreSQL）を採用しており、ソフトウェアの基盤部分を整理することによるスケールメリットが非常に大きいです。この記事では、そんなダイニーにおける基盤開発を担うこのポジションへの期待や「やりがい」について説明します。

※ Platform Engineering という言葉の定義は、この言葉が語られる場所によりまちまちです。この場では Enabling や Architect 的なニュアンスも含んでいます。詳細は本記事で説明していますので、ぜひご一読ください。

先日、同チームの 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. プロダクトの難しさ

2.1 異なる価値観を同一のシステムで両立

上述の通り、ダイニーは、POS というある程度は型が決まっていて安定性が重視されるシステムと、顧客基盤や CRM という飲食業界では未だかつて明確な成功事例が無いシステムを一つのプラットフォーム上で高度に統合することで価値を生み出すプロダクトです。
整理すると下記のようになります。

  • 非機能要件が厳しく安定性が重視される POS

  • どんどんリリースしてフィードバックサイクルを得たい CRM

……これって、全く逆のことを同時にやるということですよね？

2.2 初めからフルセットで作り切る

現状のダイニーは飲食店営業のためのプラットフォームですが、飲食店を支えるプロダクトは多岐にわたります（レジ・ハンディ・ダッシュボード・モバイルオーダー・キッチンディスプレイ等）。これらすべてを提供して初めて POS として導入できるようになるため、サービス開始当初から多数のプロダクトを開発する必要がありました。

スタートアップの限られたリソースで多数のプロダクトを同時に開発するため、ダイニーでは採用する技術を Node.js, React, Cloud Run, PostgreSQL に統一しています。これによって非常に高い効率でプロダクトの立ち上げを実現できました。

今となっては人員の問題は解消しつつありますが、それでもこの体制のメリットは非常に強く感じています。

まず、一人のエンジニアが貢献できる領域がサービスのすべてに及ぶということです。細分化が進んだ組織ではキャッチアップやコミュニケーションに時間がかかり、どうしても自身の担当領域外への貢献コストが大きくなります。ダイニーでは技術を統一しキャッチアップコストを抑え、開発組織全体を小さく留めることでコミュニケーションコストを抑えています。

この点が後に紹介する「SWE (Platform Engineering) のやりがい」にも繋がります。

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

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

  • 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. SWE (Platform Engineering) を募集する背景

Platform Team の責務は、以下の活動を通してサービスの提供価値をシステム面から持続的に維持・向上させていく、ということです。

  • システムアーキテクチャ・ソフトウェアアーキテクチャの整備

  • コードクオリティの維持・向上

  • テスト環境の構築・維持

  • データ基盤の構築・維持

  • 監視体制の構築

Platform Team 設立時は、Feature Team と Platform Team の二つしか無かったため、上記のような機能開発以外のすべてを行うというような大雑把な分類となりました。

このような分類ではこのポジションに対する要求技能があまりに多く、ブランディングも難しいという課題があります。そのため、これまではこのポジションを積極的に募集するということはしていませんでした。たまたま知り合った方がマッチしそうであれば案内していたぐらいです。

状況が変わったのは Feature Team の拡大要請があったためです。飲食店の皆様のおかげで事業的には好調で、それに伴い TAM (Total Available Market) の拡大に、より多くの人員をアサインすることになりました。直接的には Feature Team の拡大が求められているという話なのですが、Feature Team が増員すれば必然的に Platform Team にもより Deep で Wide な活躍が求められるようになります。

より多くの人員がより効率よく開発できるようにするためには、開発の生産性を落とさないさらなる工夫が必要になり、かつ変更に対するより高度な障害耐性が求められるからです。

4. SWE (Platform Engineering) のやりがい

上述の通り、ダイニーではすべてのプロダクトで統一された技術を使用しております。よって、Platform Team の責務としても、クライアントサイド/サーバーサイド/システムアーキテクチャというくくりはなく、システム全体のウィークポイントを解消するというのが方針です。

すべての領域に対しメンバー個人が習熟する難易度は高いですが、メンバー同士の長所を足し合わせるとチーム全体としては十分な範囲をカバーできるという状態を理想としています。もちろん、長所が重なり合うことは人員配置の冗長性を高めるためむしろ好ましいことであり、メンバー個人に対してもより広い領域の専門性を高めていくことは推奨しています。

メンバー個人の立場からすると、自身の専門性を活かしてオリジナリティを発揮することもできますし、チームメンバーの知識を吸収してより広い領域へ貢献することも可能です。専門性は持ちつつも領域は限定しないというポリシーにより、一人のエンジニアが価値貢献できる領域が広まり、エンジニア個々人が事業への貢献を感じられる環境になっていると思います。

筆者の前職のメガベンチャーの話をします。私の前職ではシステムがマイクロサービスとして細分化されており、誰一人としてシステムの全体を把握することは出来ていませんでした（少なくとも私はそのような人に会ったことはありませんでした）。そのような状態ではビジネス全体を俯瞰して適切な箇所に貢献するということは難しく、自身の貢献が事業的にどれだけ意味のあるものなのだろうかと疑問に思うことが多々ありました。この体験を経て、誰もが事業への貢献を強く意識できるような体制を模索した結果、現在のダイニーのアーキテクチャが生まれました。

SWE (Platform Engineering) のメンバーは、自身が開発した仕組みが直ちにすべてのプロダクトに応用でき、それが直ちにすべての顧客や開発メンバーに影響を与えるという面白みを感じられます。もちろん、トラブル時の責任も大きくなりますが、そんなときでも事業への貢献を実感できるという点だけは自信を持ってお約束できます。

5. SWE (Platform Engineering) に求められる技能

ダイニーで使用している技術をより詳細に述べると次のようになります。

  • Client

    • React, React Native, Expo

  • Backend

    • Node.js, NestJS, TypeORM

  • Infrastructure

    • Google Cloud Platform, Cloud Run, AlloyDB, Hasura, Neon

  • CI/CD

    • GitHub Actions, Cloud Build

これらの基盤の上で、20名から将来的には100名程度のエンジニアがプロダクトを開発していけるようなプラットフォームを構築していくことになります。

ここで言う「プラットフォーム」はクライアントで完結したりバックエンドで完結するものではなく、それらを横断してより適切なポイントで課題を解決する構成のことを指しています（上図のすべてということです）。

SWE (Platform Engineering) では、メンバーそれぞれの強みを活かしながらも、特定の領域に閉じることなく、システム上で最も適したところで課題を解決するために必要なアクションを実施していきます。

スタンドアロン対応 = ネットワーク障害やクラウド障害の際に店舗のローカルネットワーク内にて一定の機能を利用可能にする機能。インターネットサービスがオフラインの複数端末で稼働するというとんでもない機能ですが、実際の店舗ではどうしてもそのような状況が発生しうるため万難を排して実装しました。

また、自身が開発したものを開発組織全体に浸透させるためのコミュニケーション能力も必要になります。単純な価値発揮という面では使われないものに意味はありませんし、トラブル時の対応という面でも開発者一人にしか知識が蓄積していなければ人的ボトルネックという別の問題が生じてしまうからです。

作ったものは使われなければ価値がありません。どれだけ難しいものを作ったかという考えではなく、どれだけの価値を提供しているかという発想が常に重要となります。

ダイニーというプロダクトは、飲食店営業に与える影響が非常に大きいミッションクリティカルなサービスです。したがって、大きな変更をいきなり全体公開するということはできず、すべての施策をリスクを評価しながら小さく試していくことになります。状態 A から状態 B に移行する際の中間状態を意識して変更を展開していくという、いわばリリースオペレーション的な発想も重要になります（安全なリリースオペレーションの構築ということ自体が Platform Team の責務でもあります）。

ダイニーという難易度の高いプロダクトにおいて、事業全体に影響を与える基盤構築を担うという経験はそう体験できるものではありません。ダイニーで上手くやれるようになれば、どこに行っても上手くやれます。挑戦者求む。

ダイニーメンバーの高い技術力が評価され外部で登壇する様子
Google Cloud の Champion Innovator にも選出

6. 各チームのメンバー

このポジションでは主にエンジニア向けに活動してもらうことになるため、各チームを代表するメンバーを紹介します（紹介記事準備中のため X のリンクを貼っておきます）。

Platform Team: 畑田さん — Platform Team の開発番長として数多の基盤改善を行ってきました。最近は店舗内のローカルネットワークにて React Native アプリ同士を連携させて注文システムのオフライン対応を実現させました。

Feature Team: 谷藤さん — Feature Team の Tech Lead として機能開発の技術面でのクオリティ担保に努めています。自身も飲食店での業務経験があり、プロダクト自体が大好きです。開発組織で最も大きなチームをまとめ上げて顧客への価値提供に貢献しています。

Data Team: 木村さん — Data Team の Tech Lead としてデータ基盤の改善と顧客向けの分析機能の開発に取り組んでいます。元 Platform Team で、Platform Team の分析部分を Data Team として切り出し、そのままリーダーになってもらいました。

Discovery Team: 木藤さん — Discovery Team 唯一のエンジニアとして爆速で PoC 開発をしています。開発速度が異常に速いというところを買われて Discovery Team を任されていたのですが、いつのまにか顧客と商談してユーザーヒアリングを行ったりしています。開発してる本人が聞きに行ったほうが速いですからね、を体現しています。

7. 働き方/社内の雰囲気

より豊富な会社についての情報はこちらのカルチャーデックをご覧ください。

8. 最後に

事業、プロダクト、組織について少しでも知っていただけたでしょうか？
ダイニーが新規のポジションとして SWE (Platform Engineering) を公開した背景を思いつく限り記載してみましたが、テキストだけではリアル感が伝わりづらいとも思います。というか、語りきれていない「やりがい」が大量にあるので、ぜひ語らせて欲しいです。

「具体的にこれまでどういった課題を解決してきたのか / 今取り組んでいる課題は何か」
「クライアントは得意だがサーバーサイドは経験が薄く、経験がマッチしているか分からない」

という方々、今すぐの転職でなくても構いませんので、情報交換として、30~60分、カジュアル面談のお時間をいただけますと幸いです！

カジュアル面談はこちらまで！（と言いつつ筆者が育休に入ってしまうので CTO 大友のリンクを載せておきます）
※ 筆者 karszawa は 2024-06-01 より対応可能です。

いきなり CTO よりも一度メンバーや人事と話したい…という方は求人票からご連絡ください。

今回の募集と直接関係はありませんが、ソフトウェアエンジニアのその他の求人も載せておきます。


この記事が気に入ったらサポートをしてみませんか？