店が自分で選んで入れるアドオン

モジュールは、飲食店とホテルとクリニックと物販店のために一つのアプリを作るという問題への Korat の答えです。難しさは、正直に作れば「ログインを共有する4つのアプリ」になることです。不正直に作れば、設定画面があまりに大きくて、どの商売も自分に関係のないものばかりを見ることになる一つのアプリになります。Korat は第三の道を取ります。業種がモジュールを選び、モジュールが画面を組み立て、公開ページもオーナーコンソールも「飲食店とは何か」をコードに埋め込んで知ってはいません。

モジュール契約

モジュールは決まった一式を宣言し、アプリは残りをそこから組み立てます。id、担当する業種（そのモジュールがある店に適用されるかを決めます）、ラベルとカタログの見出し、客向けページの先頭に出る一つのボタンである主要な行動ボタン、そしてカタログ画面——飲食ならメニュー、宿泊なら部屋タイプ、クリニックならサービス、物販なら商品です。

さらに4つの宣言は任意で、この仕組みが元を取るのはそこです。モジュールは権限を宣言でき、それはスタッフの役割に割り当てられる新しい権限になります。コンソールのタイルはオーナーのダッシュボードの並びに現れます。専用のコンソール画面も持てます。そして客に見えるページのセクションは店の公開ページに差し込まれます。4つとも宣言しないモジュールは純粋なカタログで、4つとも宣言するモジュールはアプリの両側を同時に組み替えます。

共有の UI キットもあります——主要ボタン、カタログの行、チップ、セクションラベル、空状態——モジュールはそこから組むことが期待されています。様式のための様式ではありません。別々に書かれたモジュールを、埋め込みウィジェットではなくアプリの一部に見せているのがこれです。

4つのコアモジュールとは、業種そのもののこと

4つのコアモジュールはアドオンではありません。業種が意味しているものそのものです。飲食はレストランとカフェを担当します。宿泊は宿・ホテル・リゾート・アパート・コンドミニアム・一軒家を担当します——6つのラベルに一つのモジュール。コンドミニアムの賃貸とゲストハウスの一泊が違うのは言葉であって仕組みではないからです。サービスはサービスとクリニックを担当し、クリニックはコードを分岐させずに画面を予約・患者・施術コースに呼び替えます。物販は物販を担当します。

これらが巨大な一画面の中の分岐ではなくモジュールであるおかげで、飲食モジュールの厨房ディスプレイやオプショングループは、ホテルには存在しません。フラグの裏に隠れているのでも、無効化されているのでもなく、ありません。店に見える面積は、その店が自分を何だと宣言したかの関数です。

追加インストールできる7つのアドオン、どの業種でも使えます

コアモジュールの上に7つのアドオンが載り、いずれも業種を問わず使えます。いちばん面白いのはチーム権限です。他のモジュールから組み上がっているからです。インストール済みのすべてのモジュールが宣言した権限から権限エディタを構築するので、新しいモジュールを入れれば、誰かが一覧を更新しなくてもその権限がエディタに現れます。

支払いチャネルは、受け付けるチャネルを設定するコンソールのタイルと、公開ページに出る客向けの一覧を足します——一つのアドオンが2つの宣言枠を通じて両側に書き込みます。会員・サブスクリプションは、客が店のページから直接買えるプランを持ち込みます。更新リマインダーは、会員やコースが生む後追いを扱います。あとから加わった三つが、この契約がこれまで背負ったなかで最も重いものです。プロジェクトとタスクはビジネスの作業ボードで、プロジェクト、タスク、担当者、ステータス、コメント、通知を持ちます。資材と生産は本物の在庫台帳で、資材、入庫、調整、廃棄、版を持つ部品表、製造指示、棚卸しを扱います。オートメーションはビジネス自身が書く「もし〜なら」の規則で、トリガーとアクションのカタログ、過去データでの検証、何も書き込まないドライラン、1回あたりの処理上限を備えます。7つのどれも、第三者が使うのと同じ契約に対して書かれた自社製のモジュールです。意図的な規律です。契約は、その作者自身も縛られてはじめて本物になるからです。

インストールとアンインストールは店ごと

アドオンはオーナーコンソールの中のプラグインストアから管理し、インストールは一つのビジネスに閉じます。2店舗を運営するオーナーは、片方にだけ会員機能を入れられて、2つのダッシュボードは本当に違うものになります。

アンインストールは確認の裏にあり、その確認は具体的なことを言います。データは削除されません。 これは聞こえるより重要です。アンインストールのボタンで人がためらうのは、それが破壊的だと想定するからです。だから使っていないモジュールを入れたままにして、コンソールが誰も開かないタイルで埋まります。何が起きないかを伝えることが、そのボタンを使えるものにします。アンインストール後、そのアドオンは何も提供しません——タイルも、役割エディタの権限も、公開ページのセクションも——けれども記録は再インストールをまたいで残ります。

今はまだ、これではないもの

サードパーティのプラグインは開放されていません。空の「近日公開」棚でほのめかすのではなく、プラグインストア自身がそう書いています。今日あるのは、本物の契約と、それに対して書かれた4つのコアモジュールと7つの自社製アドオンからなるモジュール型の構造で、すべてが同じ登録経路を通って読み込まれます。外部からの提出は次の段階として掲げているものであって、稼働中のマーケットプレイスではありません。開発者ポータルも、審査の列も、公開された SDK もありません。

こう書くのは、アーキテクチャこそが面白い部分であり、それは今日の事実だからです。マーケットプレイスは未来についての主張です。契約の試験は、完全に契約だけに対して書かれたモジュール——タイル、権限、ページのセクションを持ち、コア側のコードに一切触れないもの——がアプリの一部としてふるまうかどうかです。4つがそうふるまっています。それを外部に開くのは、技術というより方針と審査の問題であり、まだ解けていません。

機能フラグではなくモジュールである理由

機能フラグは何かを消します。モジュールは何かを差し出します。違いが表れるのは権限エディタです。フラグなら、誰かが全権限の一覧を保守し、拡張するのを覚えていなければなりません。契約なら、チーム権限のアドオンが各モジュールに「何を宣言しているか」を尋ね、その答えからエディタを組み立てるので、一覧が古びることがありません。同じやり方がダッシュボードの並びにも公開ページにも当てはまります。どれも機能を列挙せず、すべて尋ねます。

これは新しい業種を足す費用も抑えます。Korat がまだ扱っていない業種を足すことは、モジュールを一つ書くことです。担当する業種、カタログ、主要ボタン、そして必要な任意の枠を宣言する——コンソールにもページの描画にも権限の仕組みにも触れません。それが、スーパーアプリを特例のゆっくりした堆積ではなく、扱えるものにしていることです。

必須の宣言

id · 担当する業種 · ラベル · カタログの見出し · 主要な行動ボタン · カタログ画面

任意の宣言

権限 · コンソールのタイル · コンソール画面 · 客向けページのセクション

コアモジュール

飲食 · 宿泊 · サービス · 物販

アドオン

チーム権限 · 支払いチャネル · 会員・サブスクリプション · 更新リマインダー

インストールの範囲

店ごと

アンインストール

データは削除されないと明記した確認の裏

サードパーティ

未開放——自社製アドオンのみ

ここに並ぶ拡張はすべて一次開発です。順番待ちや駐車場のようなモジュールも外部の開発者が書いたものではないので、第三者が店のデータに触れる入口自体が存在しません。

入れたあとにどの従業員から見えるかは、マイ職場と同じ担当者ごとの権限で決まります。