GitHub m-nakamura145
Comment4
Like
Created atMarch 22, 2019 17:56
Updated atMarch 22, 2019 17:56

Questions and feedbacks (4)

m-nakamura145
m-nakamura145 commented 4 months

予約機能はどんどん仕様が増えていく印象があるのですが、どれを実装する・しないの判断はどのようにするのでしょうか?

現在はプロダクトオーナーが存在しているので基本サービスの台帳に関してはその人がある程度優先度を決めて判断しています。

Like(0)

m-nakamura145
m-nakamura145 commented 4 months

飲食店では予約のキャンセルに対する対応(ドタキャン・幹事と連絡が取れないなど)が大きな問題になってくるかと思いますが、そういった問題に対する対策や防止手段などは考えられたりしているのでしょうか? または、トレタ経由の予約は一般の予約システムに比べてキャンセル率が低いなどの話がありましたら興味があります。

プロダクト的な話では http://lp.toretel.toreta.in/ このようなサービスを提供し、お客様に予約確認を促すサービスを提供しています。 また、仕組み的な話では https://corp.toreta.in/news/2017-02-09/ このような仕組みを提供しています。

トレタ経由だからといって他の予約システムと比べてキャンセル率が低いというデータは現状存在しません。

Like(0)

m-nakamura145
m-nakamura145 commented 4 months

設計思想がスマートなのですが、そこに至るまでの要件定義をどのように進めるか教えて欲しいです。すごい泥臭そうで。

弊社代表は元々飲食店を経営していて現場の課題を一番知っている人間でした。代表自ら最所はプロダクトオーナーとしてGitHub上で議論したり、当時CTOの増井さんや一番目のエンジニアとかなり密に議論して初期設計を行ったのがここまで成長できた理由かなと思います。

コアな機能開発に関してはこの機能はどんな課題を解いているか?の部分をprojectチームでなんども議論して認識を合わせてから開発しています。また、会社に飲食店出身者も多いので実際にオペレーションを聞いたりしたり、導入して頂いてる店舗様に直接ヒアリングしたりも日常的に行っています

Like(0)

m-nakamura145
m-nakamura145 commented 4 months

新旧複数の在庫モデルが並行して存在していると思うのですがそこの整合性はどうやってとられているのでしょうか(ダブルブッキングの防止など)

整合性自体はロジックとして正しいかを単体テストをとにかく厚めに書くところと、DBでlockを取って同時に更新しないようにできるだけならないようにコード側で努力しています。

Like(0)

This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano