社内での自社プラットフォームとの付き合い方
この記事は、Showcase Gig Advent Calendar 2021 10日目の記事です。
こんにちは。Showcase Gigの大井です。
ビジネスデザイン(通称 BD)事業本部のシステム開発を管掌しています。
私が所属するBD事業本部は様々な企業様とアライアンスを組んで新規事業を展開したり、既存事業をDXで改善するソリューション事業を展開しています。
また弊社にはBD事業以外に「O:der Platform」と自社プロダクト「O:der」の開発・運用・セールスを担うO:der事業本部があります。
今回は、BD事業とO:der事業のそれぞれでよくあがる課題等を踏まえ、全社の利益、延いてはすべてのお客様、ステークホルダーの利益になる関係性を探ります。
O:derプロダクト事業側のエンジニアチームが担う、「O:der Platform」の詳細については 2日目の記事 をご参照いただきたいのですが、「O:der Platform」といっても、Platform、O:der、InstoreやPOS連携サービス・・・など様々な機能と自社プロダクトを開発しており人数も多いです。
その一方で、BD事業側のエンジニアチームは最近組成されました。 もともと１つのエンジニア組織でプラットフォーム、自社プロダクト、BD事業の案件の開発をしていましたが、事業目的の違いが明確になりつつあるため分離してそれぞれに合わせた組織作りを行うことになりました。 BD事業を一緒に働いてくれる作り上げてくれるエンジニアも募集中なので少し気になった方は気軽にご連絡ください。
さて、10日目となる今回は、異なる事業の開発組織がどのように自社プラットフォームを開発し、利用すべきか、どんな課題があるのかここ半年くらいで思ったことを書きます。
BD事業のソリューション開発とO:der事業の「O:der Platform」開発について
上はすべてO:der事業側のエンジニアチームが開発しているものになります。
BD事業側が作っているプロダクトやシステムは下の絵のようにO:der Platformを活用した様々なカスタマイズ案件を開発しています。
OMOソリューションの紹介ページにもある言葉ですが、私たちはモバイルオーダープラットフォームのアセットを活用したご提案を得意としています。
実績のあるO:der PlatformやO:der製品を最大限活用して様々なシステムを構築していると言えます。
ほぼそのまま活用できるもの（セミカスタマイズ）や、プラットフォームの一部のみ利用可能なフルカスタマイズなど案件毎に様々です。
私たちエンジニアチームはビジネスサイドや企画営業が頑張って獲得してきた案件をPMチームとともに、具体的なシステム構築方法を決め、工数を出し、スケジュールとリソースを調整したうえでクリエイティブチームと連携して最高のUI/UXと安定したシステムを開発します。
ここで重要なのが自社プラットフォームの機能を十分把握し、プラットフォーム開発側とのコミュニケーションが良好に取れている事です。
O:der Platform
「O:der Platform」はオンラインからの注文を受け付け、決済や店内機器との連携を受け持ってくれます。 また、商品マスタや店舗マスタ、会員基盤など、個別に作るとコストのかかる機能をAPIとして提供しています。
O:der Platformに対応した自社プロダクト
O:der Table（店内モバイルオーダー）
O:der ToGo（テイクアウトモバイルオーダー）
O:der Kiosk（次世代タッチパネル型注文決済端末）
利用する側は「何を任せられるか」をしっかり把握している必要があります。 プラットフォームは日々進化しており、機能の充実も進んでいます。 これらを踏まえ我々BD事業本部はお客様へのオーダーメイドなフルカスタム案件においてもなるべくプラットフォームの機能を活用してエコに開発をしたいと考えます。 お客様においても弊社プラットフォームを活用することによるメリットとして、実績のある注文、店内機器制御システムを利用できる事があげられます。 結果、高品質でコストパフォーマンスに優れたご提案とシステムの納品が可能となります。
ちょっと困った話
2日目でプラットフォームの設計方針について以下のように語られています。
「テイクアウトやイートインという注文の形態によらない、プリミティブな「注文」を受け付ける、プラットフォームのコア機能です。主たる責務は、注文・会計・決済、マスタデータの管理、そしてプラットフォームの拡張性の担保です。」
また
「このサービスはO:der Platformの心臓部として、シンプルさを保つことを意識して開発を進めています。」
とある通り、プラットフォームはシンプルに各種機能を提供してくれますが、利用側のサービスやロジックはあんまり知らないからうまく使ってね。
サービスに依存するのはNGだよ、例えば汎用的でない機能の追加をサービスのために追加や改修はしないよ、ということになります。
とても分かります。
変にプラットフォームが気を利かせて逆に依存してしまうとプラットフォームを利用している様々なサービスに影響が出て破綻してしまいます。
しかし、実際には納期が厳しいのでモバイルオーダーテイクアウトプロダクトのO:der ToGoを魔改造させてくれ、頼む！そこをなんとか！
と感じる時もあります。
もちろんNGです。
そうは言ってもBD事業本部では保守するシステムも増える一方だといずれ破綻するので、どうしたらエコに開発できるのか、どうやったらO:derと仲良くなれるのかを考えます。
ここで最近開発している自社サービスを１つ紹介します。
The Label Fruit（ラベルフルーツ）でプラットフォームと関わった例
こちらの記事にある通り、まだオープン前ですが以下のような機能が必要になっています。
モバイルオーダー
ボトルや味のパーソナルカスタマイズ
カスタムラベルの自動印刷
デジタルアート演出が楽しめる実店舗のロッカーで受け取り（BOPISロッカー）
今回のThe Label Fruitはオープン日まで余裕がなかったこともあり、O:der ToGoをThe Label Fruit仕様に一部機能を追加して対応しようと考えていました。
O:der ToGoに相乗りする作戦失敗
しかし、猛反対されそれは違うなと考え直して2ndパーティアプリケーションとしてThe Label Fruit専用サービスを構築する方向に舵を切りました。
ただし、その時点ですでに時間的余裕がありません。
O:der ToGoをベースに構築し、必要なカスタマイズUI、ロッカー、デジタルサイネージ、カスタムラベルの合成と自動印刷など機能を整理して作っていきました。
スマートロッカーをプラットフォーム標準に取り込んでもらう
O:der ToGoをベースにしているのでそのままO:der Platformの機能はフルで活用できましたが、今回のスマートロッカーとの連携機能はまだありませんでした。
スマートロッカー連携機能を我々が短期間で作るのは無理があるため、O:der事業側のPdMやきくち (@_pochi)さんや林 (howyi)さんに相談してInstoreにロッカー連携機能を追加してもらうことになりました。
なぜロッカー機能がプラットフォームに採用してもらえたかというと、最近社内でよく耳にする「提供態」や「受け取り方法」の１つとして、ロッカーはO:derの標準として採用価値があると判断したからです。
さらにInstoreはgRPC Server Streamingにて、すでにKitchen Displayなどの店舗機器に対して注文や提供ステータスなどをリアルタイムに通知するしくみを持っていたため、デジタルサイネージやデジタルアート演出にも活用できました。
これでかなりハードルの高かった部分が解決しました。
林さんありがとう。
他には、プラットフォーム側はまだ2ndパーティアプリケーションの管理メニューを受け入れるプラグインのしくみを開発中だったため、探りさぐり、O:der事業のエンジニアと相談しながら開発を進めました。
無事リリースできそうなのでうれしいです。
得られたもの
プラットフォームと自社プロダクトを開発する開発組織と、それを利用して開発をする組織のスタンスの違いが時には断絶を生む事もあります。 しかし、今回のように正面から議論を重ね、時には意見が合わなかったりしても、プラットフォームやサービスの成長を事業部を超えてお互いに考えられると自然にどちらの得ではなく、全体の利益として協力しあえるものだなと実感しました。
- プラットフォームに無理に機能改修を頼んでもカオスになるだけだしそもそも受け入れられない
- 標準プロダクトに無理に乗ろうとしてもカオスになるだけだしそもそも受け入れられない
- 自分たちが目指す開発方法が明確になってきた
まとめ
自社プラットフォームをお持ちの似たような経験をされているエンジニアの方もたくさんいるでしょう。
結局大した事は何も書いていないですが、一例として参考になれば幸いです。