私たちは Hata-Raku（勤怠）、GuestNote（来店アンケート）、Shif-Match（シフト作成）、LocaNote（MEO・SNS運用）という4つのSaaSを自社開発しています。それぞれ別の課題から生まれた製品ですが、店舗の現場で使っていると「この2つがつながっていたら便利なのに」という場面に何度も出会います。
GuestNoteで集めた来店アンケートの評価と、LocaNoteで管理しているGoogleマップやInstagramの発信を並べて見たい。Shif-Matchで組んだシフトと、勤怠システムの実績の打刻を突き合わせたい。どちらも実際にお客様からご要望をいただき、連携機能として作り込みました。
そのときに私たちが最初に決めたのは、機能の作り方よりも先に「何を渡して、何を渡さないか」という線引きでした。
渡すのは数字だけ、中身は持ち込まない
GuestNoteとLocaNoteの連携では、取り込む情報を日別の回答数・平均評価・Googleマップへの遷移数・AI下書きの利用数といった数字だけに絞っています。お客様が自由記述欄に書いてくださった感想そのものは、LocaNote側には持ち込みません。
Shif-MatchとキングオブタイムのCSV連携も同じ考え方です。渡すのは確定したシフトの時間と、打刻の実績という「結果の数字」だけです。スタッフの個人的な事情や、シフト作成時のやり取りの履歴は連携の対象にしていません。
最初にこの機能を設計したときは、自由記述もまとめて取り込んで一画面で見られたほうが親切ではないかという案もありました。ただ、それを採らなかった理由が2つあります。
なぜ数字だけに絞るのか
ひとつは、片方が止まっても、もう片方が動き続けられることです。 中身まで持ち込む設計にすると、連携先のシステムの不具合や仕様変更が、もう一方の本来の機能にまで影響しかねません。数字だけのやり取りであれば、依存する範囲が最初から小さく、どちらかを単体で使い続けることもできます。実際、GuestNoteだけをお使いでLocaNoteをまだ導入されていないお客様も多く、連携は「あれば便利な拡張」であって「ないと動かない前提」にはしていません。
もうひとつは、どこに何の情報があるかを、作る側も使う側も迷わずに説明できることです。 お客様からの自由記述や、スタッフの個人的な希望の中身は、集めた目的の中でだけ扱う。集計した数字は、傾向をつかむために別の画面でも見られるようにする。この役割分担が最初から言葉にできていると、「このデータはどこまで見られますか」というご質問にもその場でお答えできます。権限の設計やお客様への説明のしやすさは、後から整えるより先に決めておくほうが、結局は作業量が少なく済みます。
明日から当てはめられること
複数のシステムをつなぎたくなったとき、私たちは次の順番で考えるようにしています。
- まず、本当に必要なのは生データか集計値かを問い直す。たいていの「並べて見たい」は、集計値だけで足ります。
- 渡す項目を先にリストにして、それ以外は渡さないと決める。 後から「ついでにこれも」を足すと、線引きはすぐに崩れます。
- 連携先が止まっても、連携元は単体で動くかを確認する。 動かないなら、それは連携ではなく統合であり、設計の重さが変わります。
自社で複数のSaaSを運用していると、つなぎたくなる誘惑は常にあります。ただ、つなぐこと自体が目的ではなく、お店の判断に使える形で数字が並ぶことが目的です。渡すものを絞る判断は地味ですが、後から見返したときに「あのとき絞っておいてよかった」と思える決め方だと考えています。