使用言語はTypeScriptで統一。フルスタックであることを重視したdiniiの技術選定指針

開発組織が採用するプログラミング言語やアーキテクチャ、組織構造には、企業の経営方針やビジネスモデルが反映されるケースが多いです。たとえば「マルチプロダクト展開をしたい」「特定事業を短期間でグロースさせたい」といったコンセプトを掲げているならば、それに適した技術選定や組織設計が行われるのです。

「飲食をもっと楽しくおもしろく」というミッションのもと、飲食店向けのモバイルオーダーやID-POSを開発・提供する株式会社dinii（ダイニー）も、事業やプロダクトを成長させるために適切な技術や組織構造を選択してきた企業。これまで取り組んできた意思決定について、取締役CTOの大友一樹さんとエンジニアリングマネージャーの浦山裕史さんに聞きました。

飲食店向けに幅広いサービスを提供する

――diniiが提供している事業について教えてください。

大友：当社は主に飲食店向けのサービスを提供している企業です。モバイルオーダーPOSの「ダイニー」が主力サービスですが、それ以外にも飲食店経営者が直面するさまざまな課題を解決するとか、飲食店を利用する消費者がより良い体験を得られるようにするためのサービスも幅広く提供しています。

たとえば、POSレジシステムやスタッフが使用するハンディ端末、キッチンでの注文内容を表示するプリンター、最近では決済サービスも提供しています。また、私たちは「ダイニー」を通じて飲食店に来店した方の情報を収集できるため、そのデータをもとにしたCRMシステムも提供しています。diniiは飲食店での各種業務をテクノロジーで総合的に支援する会社です。

――他社製のモバイルオーダーサービスと比べて、「ダイニー」の特徴はどのような点にありますか？

大友：当社のモバイルオーダーサービスの特長は、消費者の体験を重視して開発しているところにあります。他社サービスの場合、注文を自動化・効率化することのみにフォーカスしていることがほとんどですが、私たちのサービスは画面の使い勝手が良く、メニューのおすすめをしたり来店回数に応じて特典を提供したりと、消費者が楽しみながらモバイルオーダーを使用できる点が高く評価されています。

また、「ダイニー」ではモバイルオーダーの利用と同時に、消費者が店舗の会員となります。これにより、性別・生年月日・来店回数・最終来店日・よく注文するメニューなど会員の細やかな属性情報を取得できます。こうした点は他のサービスでは実現できていない、「ダイニー」固有の特徴になっています。

採用技術をTypeScriptで揃える

――Webメディア「what we use」のインタビューでは、各企業が取り組んできた技術的・組織的意思決定のなかで印象に残るものや、そこから得た学びを話していただきます。

大友：私たちは合計で20種類くらいのサービスを提供しており、そのすべてをTypeScriptで開発しています。フロントエンドやバックエンド、モバイルのいずれもTypeScriptであり、かつバックエンドはHasura*などを用いてGraphQLのAPIを構築しています。「エンジニアがフルスタックにどの領域でも担当できること」を重視した技術選定が特徴です。

*…dinii社のメンバーは「Hasura User Group Tokyo」の運営にも携わるなど、Hasuraのコミュニティ活動も積極的に行っています。

――なぜ、このような技術選定にしたのでしょうか？

大友：diniiでは創業当初から飲食業という事業ドメインのなかで、テクノロジーを用いてさまざまなチャレンジをしてきました。そして、どのような事業を行う場合でも複数のシステムを開発します。たとえば、テイクアウトやデリバリーの注文ができるプラットフォームを実現する場合には、最低でも消費者側と店舗側の2種類のシステムが必要です。

事業をスタートしたばかりの頃はすべてTypeScriptではなく、例を挙げるとモバイルアプリはAndroid・iOSそれぞれのネイティブアプリとして作っていました。ですが、今後もさらにシステムが増えていくならば「極力、採用する技術を統一したほうが良いだろう」という見立てをしていたんです。そこで、事業が一定以上に成長しそうだと見越したタイミングで、あらためてTypeScriptで全面的に書き直しました。

――モバイルアプリのシステム移行にあたり、工夫したことはありますか？

大友：Android・iOSのネイティブアプリとして作っていたものをReact Native・TypeScriptに書き換えたんですが、全機能を実装するまではある程度のリードタイムがかかります。書き換えを完全に行ってから「この機能が不足している」とか「使い勝手が良くない」となるわけにはいかないので「可能な限り早めのタイミングでサービスへのフィードバックをもらうこと」を重視しました。

具体的には、モバイルアプリを導入している店舗に検証作業のお手伝いをお願いし、1日のうち数時間だけReact Native・TypeScript版を使っていただいたうえで改善すべき点をフィードバックしてもらうという運用を行っていました。実店舗での検証を日々行いながら、移行作業を進めましたね。

――採用言語をTypeScriptに統一していることで、組織としてプラスになっていることはありますか？

大友：エンジニアがさまざまな領域をフルスタックに担当できることは強みになっています。私たちのサービスの場合、たとえば「モバイルオーダーで⚪︎⚪︎をしたらレジで⚪︎⚪︎を出し、そしてキッチンプリンターで⚪︎⚪︎をする」といったように複数のシステムにまたがる機能要件が多いんですよね。それを1人ですべて担当できるので、作っているエンジニアも楽しいですしサービス全体を俯瞰的に考える習慣ができました。

浦山：1人のエンジニアがそうした一連の機能改修を担当することで、より開発へのオーナーシップを持てるんですよね。それに、エンジニアとして純粋に成長できる環境だと感じています。

私もそうなんですがdiniiは元メルカリのメンバーが多くて、かつそのメンバーたちは全員がもともとフロントエンドエンジニアでした。でも、私が昨年diniiに入社したときにはバックエンドやインフラをメインで担当するようになっていた人もいて、扱える技術の幅が広がっていることに驚きました。エンジニアがフルスタックでどのようなシステムも担当できることで、より本質的に事業と向き合えますし自分自身のスキルの幅も広げられるのが良いですね。

――この事例を踏まえて、読者へのアドバイスはありますか？

大友：技術選定はビジネスモデルやプロダクト展開と合っているかどうかが重要だと思います。事業展開にあたってそもそも複数のプロダクトが必要ないならば、私たちも違った技術選定をしていた可能性があります。

それに、私たちの場合はものすごくハイトラフィックなシステムではないため、技術選定の軸として「パフォーマンスに優れていること」の優先度が低く、それよりも「開発効率が良くなること」の優先度のほうが高かったです。だからこそ、技術的な差分を抑えたほうがバリューを発揮しやすかったので、この技術選定になったと考えています。

技術スタックではなくミッションでチームを分ける

――次のエピソードもお話しください。

大友：チーム編成についての事例をお話しします。私たちの開発組織は、最初の頃チームがひとつだけで、どのエンジニアもフルスタックですべての作業を担当していました。その状態を3年くらい続けて、人数が10人前後になった段階で、フィーチャーチームとプラットフォームチームに分割したんです。フィーチャーチームは主に機能開発を、プラットフォームチームはシステムの基盤構築や開発効率の向上、システムの信頼性向上などを担います。

当時はプロダクト数やユーザー数が増えており、かつ飲食店のコアな業務に組み込まれていたため、運用やリリースにエンジニアがみんな気を遣っていました。さすがに全員が運用を考えるのはきついので、基盤構築やリリースサイクル改善を専任で見るチームがあったほうが良いと考えたんです。

その後、より各種のデータが蓄積されてきた時期にデータチームが作られました。私たちの事業の強みは、飲食店のデータと消費者のデータの両方を取得できることです。それらのデータを基軸にして、より事業そのものを強化するためのチームです。このチームはデータ基盤を扱うだけではなく、データを活用して新しい価値につなげるためのプロダクトも作っています。

浦山：今後さらに検討したいのは、「フィーチャーチームは本当にひとつのチームのままでいいのか？」という点です。現在、モバイルオーダーやPOSレジなどに加えて新しく決済関連の機能開発もしています。モバイルオーダーやPOSレジの機能が複雑な一方で、最近チームに加わって決済機能の開発をしている人は、モバイルオーダーやPOSレジについての知識をキャッチアップする機会がなかなかないんですよね。フィーチャーチームについても一枚岩で運用を続けるのではなく、特定のミッションなどに基づいてチームを分けて、より効率良く開発・運用を進められるようにするというような施策が必要かもしれません。

――チーム作成において、大切にすべきノウハウはあるでしょうか？

大友：チームを作るということは、そのチームに対して持続的にリソースを割くということです。逆に言えば、特定の課題がリソースを割くべき規模にまで大きくなっていない限りは、基本的にはチームを作るべきではないと思っています。チームが増えると、それだけマネジメントも大変になってしまいますから。

浦山：チームを増やしてマネジメントコストだけが上がるというのは避けたいですね。大事なのは、技術スタックなどでチームを分けるのではなくミッションでチームを分けることで、1つの目的を達成するために1つのチームがフルスタックにオーナーシップを持って担当できることがdiniiの良さだと思っています。

複数のサービスをスピーディーに立ち上げ、運用していく

――事業展開に合わせて、組織の形もまた変わっていくのですね。

大友：そうですね。私たちは飲食店という事業ドメインのなかで、今後はさらに取り扱う領域も広げていく予定です。既存事業で扱っている領域だけではなく、今後は金融関係の事業や飲食店で働く方々向けのHR領域、サードパーティー企業も巻き込んだ事業展開などやりたいことがたくさんあるんですね。これに伴って、複数のさまざまなフェーズのプロダクト開発を同時並行で進められる組織体制が必要になります。

すでに、ディスカバリーチームという新規事業立ち上げに特化したチームも存在しています。このチームはプロダクトマネージャーとデザイナー、エンジニアを1人ずつで組成されていて、このメンバーでミニマムのプロダクトを作ります。ディスカバリーチームの制度を導入してから半年以上が経ちますが、かなりワークしている実感がありますね。

浦山：今後の組織設計においては、「プロダクトのフェーズごとに、担当チームをどう切り替えていくか」を考えていかなければならないと思っています。たとえばディスカバリーチームは立ち上げに特化していますが、そのプロダクトがPMFしてグロースさせていくフェーズでは、中長期的なプロダクト開発に適したチームに開発の担当をバトンタッチするなども考えられます。

また、各チームで伸ばせるスキルや個々人の適性、各メンバーの今後のキャリアプランなどはさまざまですから、長所を活かすとか成長につながるようなアサインを検討したいです。特定のチームで働いている人が別のチームにも移れるようにして成長の機会を生み出すとか、専門的なスキルを持つ人はその領域に特化したキャリアパスを歩めるようにするとか。事業の成長とメンバーの活躍を両立できる組織にしていきたいですね。

飲食業界全体に価値を届ける

――diniiの今後のビジョンについて教えてください。

大友：「飲食業界のすべての領域に価値提供していく」という価値観が、diniiの事業の根本にあります。私たちは飲食店と消費者両方のデータを持っていますし、システムが飲食店のコアの業務に入り込んでいます。よく「外食産業はデジタル化が進んでいない」とか「従業員の待遇が悪く離職率が高い」などの課題が語られますが、私たちの事業にはそれらの課題を解決できるポテンシャルがあると思っています。

特徴的な例として、「ダイニー」には店員に投げ銭ができる「推しエール」という機能があります。これによって、店員のやる気が上がりますし離職率の低減に貢献します。店員のなかには、この機能によって月間数万円ほどの収入を得ている人もいるそうです。

テクノロジーが少し加わるだけで「一生懸命に接客をすれば報われる」という理にかなった好循環が生まれています。こうしたポジティブな変化を、飲食業界全体で起こしていきたいです。

――今後の事業展開が楽しみですね。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的・組織的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

大友：エンジニアは他の職種と比べても、インターネットや本などで得られる情報の量が多いですし、それを学ぶことでスキル向上につながります。それに、OSSという存在も大きいと思っていて、「世の中のエコシステムに頼ったもん勝ち」だと思うんですよ。エンジニアという仕事は、賢い人たちが残してくれた資産の恩恵にあずかりやすい職種だと思うので、その利点を最大限に活かすためにも、いろいろな事業を知ることには価値があると感じます。

浦山：単にベストプラクティスを知るだけではなく、「企業や組織がどのような状況に置かれていて、そうした背景があったなかでどんな意図で何をして、結果どうなったのか」をセットで知ることで、エンジニアは効果的にスキルを向上させられると思っています。そうした背景を学ぶのは自分自身が体験するのが一番良いんですけれど、本やWeb記事で事例を読むことによって、それに近いことを追体験できるのは良いですよね。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul