2023年のO:der Platform
この記事はShowcase Gig Advent Calendar 2022 24日目の記事です。
こんにちは。Showcace Gig で VP of Technologyという肩書きでお仕事している菊池です。社内ではカピバラと呼ばれています。よろしくお願いします。今日の記事ではO:der Platformの今後の展望についてざっくりお話させてください。
O:der Platformの現在地
Showcase Gigでは、次世代店舗創出プラットフォーム「O:der Platform」を開発、運用しています。
O:der Platformは、マスタデータとトランザクションデータを管理する「Platform Core」と、店舗デバイス向けリアルタイム通信基盤である「Instore」というコンポーネントにより、APIとストリーム通信を利用した柔軟なプロダクト、および連携アプリケーション開発が可能な設計となっています。
なお、これまでは社内にのみAPIなど提供してきましたが、先日の記事でも触れているように、外部Developerに向けたAPI公開なども進んでいます。
さて、O:der Platfromを利用した自社開発プロダクトとしては、
ファミリーレストランや焼肉・居酒屋のような業態で利用されるイートイン後会計に特化した「O:der Table」
カフェやフードコート、あるいはテイクアウトなどといったユースケースで利用される先会計に向けた「O:der ToGo」
ロッカー受け取り＋ラベルカスタマイズが特徴の「The Label Fruit」
などがあります。
どのプロダクトも、注文方法や受け取り方法が大きく異なるプロダクトですが、それぞれのユースケースを実現するためのO:der Platform自体の特注カスタマイズなどは行っていません。
また先日、KIOSK端末やドライブスルー連携などを含めた次世代店舗の取り組みに関するプレスリリースも出しました。こういった連携も、O:der Platform自体の個別機器に特化したカスタマイズは行わず実現可能となっています。
それは上図のように、エンドユーザー向けのプロダクトと、希望の店舗オペレーションなどを実現するための連携アプリケーションを柔軟に組み合わせることが可能となっているためです。
プラットフォームの伸びしろ
…というところで、うまくいった面を前面に押し出してみましたが、プラットフォームとして今後取り組むべき課題はたくさんあります。課題というか、伸び代です。
DeveloperにとってのO:der Platformは、まだ正直使いづらい
現在のO:der Platformでは、プリミティブな機能を提供し、多くのユースケースに柔軟に対応できる設計となっています。この設計のデメリットとして、モバイルオーダーとしてありがちなユースケースを実装したいだけであるにもかかわらず、利用者側の実装コストが高くついてしまうことがありました。
なぜ最初から「使いやすいAPI」をプラットフォームとして実装できなかったかといえば、私たちの中でテイクアウト、イートインといったドメインに対する理解が十分でなかったためです。
いい面、つらかった面それぞれある意思決定でした
プラットフォームとして実装するということは、複数のプロダクトから依存されることを意味し、「安定したAPI」であることを求められます。「安定」の意味するところとして、APIの可用性はもちろんのこと、インターフェースや仕様、振る舞いの安定も含みます。利用しているAPIの細かい挙動がころころ変わってしまっては、利用者としてたまったものではないですよね。
というわけで、プラットフォーム構築当初から「使いやすいAPI」をプラットフォームとして提供することはリスクが大きいと判断し、プラットフォームとしては最小限のプリミティブな要素を提供し、「テイクアウト」「イートイン」といった提供態ごとのドメインはプロダクト側で実装することとしてきました。
そこから1年以上のプロダクト開発・運用を経て、社内の知見やドメインの理解度も高まってきました。それにより、テイクアウトやイートインといった複雑なドメインに向けても「使いやすい、かつ安定したAPI」を提供できる土台が整ってきました。
また事業面でも、今後さらに事業をスケールさせるにあたり、使いやすいプラットフォームAPIを活用していく重要度は高まっています。
まだまだ設計改善の余地がある
先述したようにO:der PlatformはプリミティブなPlatform Coreと、O:der ToGo, O:der Tableといった構成となっています。O:der ToGoとO:der Tableはそれぞれ別システムとして実装しているのですが、両者のいくつかのサブドメインは共通化できる余地があるのではないかと考えています。こういったアーキテクチャの最適化も、開発初期では判断が難しかったものです。
現状の設計を盲信せず、正しく疑っていきたいです。それにより、去年より今年、今年より来年…と、アーキテクチャを研ぎ澄ませていくチャレンジは続けていきます。
エンジニアがチャレンジするための、さらなる環境整備
ありがたいことに、O:der Platformをご利用いただく飲食店、そしてプロダクト・連携アプリケーションは着々と増えていきます。それに伴い、プラットフォームの不具合やシステム障害による影響範囲は日増しに大きく、かつ深刻になっていきます。
したがって高いレベルで安定したプラットフォーム運用が求められるのはもちろんですが、障害を恐れるあまり、縮こまってチャレンジができなくなることは避けなければなりません。
そこで出てくるのはやはりGoogle SRE的な話になるわけですが、幸いそのプラクティスの一部は試験的に運用が始まっています。この運用をより深めていき、チャレンジと信頼性のバランスを適切にコントロールしていきます。
おわりに
以上、現在のO:der Platformができること、そして今後改善していくべきポイントについて、アプリケーション視点強めで書いてみました。
まだまだ未成熟なプラットフォームではありますが、頼もしいメンバーとたくさんのチャレンジを続けています。
果たして1年後のO:der Platformが実際にはどうなっているか、私自身も楽しみです。答え合わせとして、1年後に「どうなったか」をご報告させてください。
それでは、来年のアドベントカレンダーでお会いしましょう。
この記事が気に入ったらサポートをしてみませんか？