こんにちは、dinii CTO の大友(@dinii_k_otomo)です。

dinii では、次の 50年の飲食インフラとなるべく、飲食店内向けモバイルオーダーと CRM サービス「ダイニー」を開発・運用しています。

先日は、Coral Capital さん主催の Startup Aquarium にも参加させていただき、とても多くの人に dinii を知ってもらうきっかけにもなったかなと思います。ご参加頂いた皆様、どうもありがとうございました！！

dinii は 2018年に創業し、複数回のサービスのピボットを経て、今のプロダクトに落ち着いたのが 2020年のこととなります。
2023年をもって晴れてサービス3年目に突入しますが、2022年は特に大きなサービスのスケールアップとともに、プロダクト開発組織も変化した一年でした。

これまでワンチームを維持してきた dinii が、2022年を通してどのような変化に至ったかの全体像をご紹介できればと思い、今回の記事を書くに至りました。

dinii という会社の今や、2023年に何が起こるか、雰囲気を少しでも感じてもらえれば嬉しいです！！

2022年までの体制と方針の振り返り

では、まず2022年1月当初の体制を振り返ってみます。

当時の体制や方針については、以下の記事でも紹介していますので、是非ご覧ください。

これが、2023年1月時点ではこのようになりました。

全社人数で言うと、4倍ほどになっており、とても大きな変化が起きた一年でした。
なお、これだけの採用を実現できた背景には、「採用承諾率約90%」を維持できた HR チームの大活躍もありましたので、こちらも別記事にてぜひご紹介できればと思います。

2022年を振り返ると、今まで通りの組織体制では通用しなくなる部分が多く発生し、そのたびに試行錯誤をした一年だったと思います。
今回はその中でも、特に大きな取り組みを３つほど取り上げさせていただきたいと思います。

1. Platform team の立ち上げ

まず最初に、エンジニアのワンチームを2つのチームに分割し、既存チームを Feature team、新規チームを Platform team として立ち上げた話です。

エンジニアのチーム体制は、当初から少人数で、飲食を支えるマルチプロダクトを最大効率で開発する方針を貫いていました。
プロダクト開発に関わる全員が全体像を常に把握し、スピーディな開発が実現できていたと思います。
プロダクト数は19種類ほど(モノレポのパッケージ数換算)になっており、プロダクトの数としては非常に多い状態でした。
立ち上げ当初を支えた技術については、以下のスライドでも紹介しているため、ぜひご覧ください！

全エンジニアが同じチームで、ひとつのスクラムチームを組み開発をしていた時のメリットとデメリットを振り返ってみます。

ワンチーム体制のメリット・デメリットの振り返り

メリット

• エンジニアの職務分掌がなく、全員が最大効率での開発を維持できる

  • リソースの取り合いやタスクの受け渡しがないため、その仕組自体を考える必要がない。

• 技術範囲におけるコンテキストスイッチが最小限のため、プロダクトの提供価値に集中しやすい。

  • ある程度プロダクトの企画を考える人がいなくても自走できる環境。

デメリット

• 開発リソースがプロダクト開発に集中しがちで、生産性や技術負債、サービスのメンテナンスに関心を寄せづらい。

  • 2022年中盤くらいから、技術基盤に対して継続投資したい事項に対してリソース確保が難しくなっていった。

    • 例: パッケージのアップデート、インフラのメンテナンス、パフォーマンスチューニングなど。

  • 技術基盤を気にしながら、プロダクト開発や顧客の解像度を上げる活動をエンジニア全員が等しく実施するのは認知負荷が高い。

• 各エンジニアの得意領域を活かす体制が組みづらくなる

  • 全員にフルスタック & プロダクト開発 & 技術基盤が要求される

  • 例えば、設計やアーキテクチャが得意なメンバーと、顧客価値を考えることが得意なメンバーに課せられるミッションが同じ

2022年の中盤までは、上記のメリットの方がデメリットを上回っていた状態でしたが、サービスの規模と複雑性が増すにつれて、徐々にデメリットが無視できない状態になってきておりました。
そのため、このデメリットを解消するため、dinii として初めて開発チームの分割に着手しました。
当時フルタイムのエンジニアは4名ではありましたが、それぞれの得意領域に合わせて2名ずつ、Feature team と Platform team へのアサインを実施しました。

立ち上げに際しては、dinii よりもフェーズ感の進んだ開発組織のインフラチーム、SRE チーム、アーキテクトチームの立ち位置、ミッション、目標設定、ロードマップなどを様々参考にさせていただきつつ進めさせていただきました。相談に乗っていただいた方々、ありがとうございました。

Feature team & Platform team 体制での良かったこと・伸びしろ

良かったこと

• プロダクト開発の速度を大きく損ねることなく、dinii の複雑なマルチプロダクトのサービス品質、エンジニアの生産性に向き合うリソースを確保できた。

• 元々全員がプロダクト開発に関わっていたため、いざという時に feature team の直接的な加勢も可能。

  • チーム分けのチャレンジに対するリスクヘッジが柔軟に出来た。

伸びしろ

• チームを分けたことによるチーム間の綱引きは徐々に発生

  • これは Platform ? Feature ? となるタスクが発生。

• Platform team が Feature team の動向を意識しながらの立ち回り

  • Feature team がプロダクト開発に集中できた一方、システムとしてはモノレポ・モノリスのため、コンフリクトのリスクに対しては Platform team 側が配慮する立ち回り。

• Platform team の負荷が徐々に増加

  • 例えば、データベースに関わる仕様レビューはすべて Platform team へ。コードオーナーが Platform team に偏る、など、開発プロセエス上の様々な負荷が Platform team にかかってしまう場合が出てきた。

  • その都度、レビューの仕組みやルールの改善、チームごとのベロシティの調整など、仕組みの試行錯誤で改善に取り組んだ。

などなど、各種良かった点、これから改善すべき点がありますが、全体を通して見れば、チームの役割分担としてはとてもワークしたのではないか？と半年を振り返って思います。
その結果として、2022年末の取り組みでは、大規模なインフラの移管作業やコア機能の負債返却を Platform team が遂行しつつ、並行して Feature team が過去最大の数の新規のプロダクト機能をリーンにリリースできました。
各メンバーの得意領域をうまく活かしつつ、仕組みが不十分な点は相互に協力関係を保ちながら徐々にチームの仕組みを作っていけたことが成功要因だったと思います。
Feature team & Platform team のみなさん、本当にお疲れさまでした！

2. Data Ops team の立ち上げ

続いて、プロダクトの直接的な開発ではないですが、dinii の根幹価値に関わる ID-POS データの活用に関わる取り組みです。

dinii では、飲食店の ID-POS データが多く蓄積されています。飲食における ID-POS データは、いままで業界に全くなかったデータであり、その活用の可能性はとても大きいです。

ID-POS は、飲食店の方も想像もしなかったようなデータ活用の可能性を秘めており、そのデータの活用促進が dinii としてもとても重要なイシューでした。

2022年末には、「消費者のアカウント数で300万人」を突破しており、現在はさらにそこから2倍に近いデータの規模にまで拡大し続けています。

つまり、数百万人の喫食情報が dinii の ID-POS データには溜まっていることになります。
これのデータあると、例えば、「常連さんの売れ筋商品とは？」「あなたの好みに合わせたおすすめメニューはコレ」など、今まで EC サイトなどのオンライン上でしか体験できなかったようなことが、リアルな一般飲食店でも実現できる可能性を秘めています。

2022年の中盤から、このような ID-POS データをうまく活用したいニーズが高まってきましたが、その膨大かつ複雑なデータを統合的に扱うには、どうしてもエンジニアの工数と、ビジネスチームの知見を組み合わせる必要があり、実現に苦労していました。

いきなり大規模なデータ分析基盤、データ分析チームを立ち上げることも現実的ではなかった中で、社内で SQL やデータ分析に強みのあるメンバーを兼任で集め、新たに Data Ops チームを立ち上げることとしました。

重厚なデータ分析基盤の構築はせず、全てのデータを BigQuery に集約できること、BigQuery を経由してデータ利活用を実施すること、など、最小限の方針でスタートしました。

役割分担としては、BigQuery に全てのデータを統合する範囲を Platform チームが、データを実際に活用支援する部分を Data Ops チームが担うことでスムーズな連携が実現しました。
現在では多くの飲食店にデータを活用した成功事例を届けることが出来始めています。
Data Ops チームの成功要因としては、Data Ops を兼任した、元々 SQL やデータ活用、及び飲食の知見を広くキャッチアップしていた PdM の存在が大きな後押しとなりました。

今後も dinii のデータ活用の幅はどんどん広がっていくため、Data Ops やデータ基盤の進展を行っていく2023年となることでしょう。
dinii での面白いデータ活用の事例も日々多く増えてきているため、また別記事にて取り上げさせていただきたいと思います。

3. 提供価値に応じた PdM/Designer/SWE のチーム分け

PdM / Designer の当時の体制について

dinii では、プロダクト開発に関わる職種として PdM と Designer があります。2022年当初ではまだまだ人数が小規模だったため、組織的な取り組みはせず、各人の自律性に任せた活躍をしていました。

2022年前半のうちに、PdM、Designer 共に数名の増員があり、徐々に組織的な動きにもトライし始めました。
主には、

• デザインマスターの整備

• プロダクトマネジメントにおけるワークフローの整備

に取り組みました。
これらについてもまた別記事にて是非個別にご紹介できればと思います。

また、2022年は、dinii の全く新しい価値提供にもチャレンジした年となりました。

dinii ではこれまで、飲食の新しいインフラとして、従来の POS システムに加えて、モバイルオーダー、及び ID-POS 基盤の整備を行ってきました。
2022年には新たに「dinii connect」という、ID-POS データとモバイルオーダーによるオンラインの顧客接点をフル活用した、「飲食の新しい CRM」を実現するプロダクトに着手しました。
またさらに、これまでなかなか改善の手を入れられてこなかった、モバイルオーダー自体の体験向上施策にも多く取り組みました。
その結果、誰に向けた、何の提供価値なのか？という面でも新しい軸が誕生したことで、よりプロダクトマネジメントにも多様性が求められるようになりました。

プロダクトマネジメントにおける役割分担のトライ

dinii のサービスは、飲食店を訪れる一般消費者だけでなく、飲食店の経営に関わるすべての方も顧客となります。
そのため、そのサービスを使っていただく顧客に応じて、何を重視したプロダクトづくりをすべきかが大きく異なります。
これまでは、その全てをワンチームで考え、プロダクトを作ってきましたが、その規模や複雑性が大きくなるにつれて、段々と全てを効果的に進めることが難しくなってきました。

そのため、2022年の後半からは、「誰のための、何の価値提供/課題解決か」に応じた、プロダクト企画チームの役割分担にもトライし始めました。
大きく3つのチームで PdM / Designer / SWE が役割分担し、活動する試みをスタートしました。

この各チームごとに、PdM と Designer をアサインし、顧客調査や仮説検証の立案を独立に実施出来るようになりました。
合わせて、エンジニアも各チームにアサインし、プロダクトづくりの早いタイミングから関わることを意識した体制となっています。
そのため、企画の早期の段階で技術観点のレビューが自然と入るようになり、実装段階での大幅な手戻りを抑制することにつながっています。

一方で、実装段階ではあくまで Feature team が全てのプロダクト開発を担っているため、実装段階での属人化も抑制された状態となっています。
今後は、上記の「誰に」「何を」の軸がさらに細分化・深化していき、都度このドメインに応じたチーム分けを行っていくことでしょう。

今後の展望

さて、ここまでで、2022年のプロダクト開発に関わる組織面の変化をかいつまんでご紹介いたしました。
これまでの完全ワンチーム体制から、大幅に人数も増え、少しずつ組織化も行われた一年だったかと思います。

dinii はまだまだこれからすべての飲食に関わる人々に対して多くのプロダクト、価値提供をしていく組織です。
日本において、ここまでの多層化したプロダクトが求められる市場や領域はかなり特徴的だと思いますし、そこに対してどのような組織体制や技術でもって実現していくか？は、とてもチャレンジングで、やりがいのあるテーマだと感じています。

まだまだ dinii のチーム作りは始まったばかりです。ぜひ dinii の初期メンバーとして一緒に飲食をもっと楽しく面白くしてくれる方を大募集しています！