はじめに
技術者として、課題があると飛びついて解決してしまうものの、要件を重め受け止めすぎていて、そこまで必要ではなくて結局使われなかったということは、よくあると思います。そういう悲しいお話です。他山の石としていただければ。
要件
- とある舞台のイベントの席を、有料席として予約したい
- 席は最前列の10席で３回実施、つまり時間差で延べ30席
- 料金は、1席あたり1,000円で、当日現地払い
- それ以外の席は、予約なしで無料
- 予約システムの運用は無料で
- （システム開発者の作業代金も無償で）
私の要件の解釈
- 新幹線や飛行機の席の予約のように、席の並びの絵があって、そこを１つずつポチポチ選んで、予約
- すでに誰かが予約済の場合は、[済]とか表示されていて、選べない
- 予約のために、氏名と連絡先を入れてもらって、Form登録
- 確認のため、本人にメールが飛ぶ
- スマホユーザーが大半
- （無償で働くけど自分の勉強や広告になればいいか）
実装方法
- Google Apps Script（GAS）の、ウェブアプリを作成
- ウェブアプリを、React・TypeScriptで
- 予約情報は、Google Spread SheetをDB代わりに
作ってみた
メインの予約部分はこんな感じでできました。
- 青い椅子のアイコンはボタンで、選択すると色が変わる
- ２席までしか選べないように
- 全席予約を防止、２席という数字は調整可
- 予約済みの場合は、選べないように
- Reactで開発して、GAS上で実現
ここまで来てふと我に返り・・・
課題（といか解釈時の検討漏れ）
1. キャンセルをどうするか問題
これがとても大きい。
- 普通にキャンセルしたいときはどう運用するか
- 当日ドタキャンされたら、一番いい席が空いてしまう
- 演者の気持ち
- 演者の気持ち
- キャンセルもせず、予約しても来ない（No Show）
- 先に多めに予約しておいて、必要な部分は後でキャンセルしようという人
- いちおう２席でガードをかけても、何度も繰り返せばできちゃうか
- そこまで厳密にガードをかけるべきか
キャンセルもシステムでできるようにするためには、ログインのような仕組みが必要になります。それは、システムを作る上でもめんどくさいけど、使う人もめんどくさい。それをこれから追加で作るか・・・？
キャンセルの仕組みを作ったとしても、どうせいろいろな課題は残り、結局手運用が結構かかる。
2. 誰がメンテするの問題
作った私以外は、システム関係者は誰もおらず、GASという言葉すら知らないと思う状況。勝手に私が先走っただけでした。
なので、バグやら何かの変更があったら、私が動かないといけない。メンテ嫌い。
いっぽうGoogle Formsを使うことを考えてみると
- 予約が10席に達したらすぐ、Formsの文面を書き換えて、「売り切れました」と締め切らないといけない
- 書き換えが間に合わず予約が10席を超過してしまった場合に、「ゴメンナサイ」をメールか何かで個別に連絡しないといけない
- キャンセルはメールで受け付けなければならない
- その他、システムを作ったときのキャンセル問題はそのままある
GASアプリ vs Formsで、Formsに軍配
つまりこういう図式になったということ。そして結果は、Formsを採用に。
GASアプリ＋開発者負荷＋キャンセル問題 vs Forms＋運用負荷＋キャンセル問題
GASアプリの場合は、（１日で作ったとはいえ）複雑性とバグの潜在可能性、変更の可能性、それらは開発者の私しか対応できない。
Formsの場合は、追加の運用負荷もあるけど、エンジニアでなくても対応はできるレベル。作るのも超簡単。
というわけで、Formsで単純な方がいいよねという判断になりました。
そもそも私も、これからキャンセルの仕組みを追加で作るとしたら、作り終わっても諸々課題が残るとわかっているので、モチベーションがわかない。
まとめ
結果的にお蔵入りになってしまいましたが、被害としては私の１日空回りだけで済んだので、よかったです。技術的な勉強（GASのReactアプリ、Material UI等）もあったし、必要十分な要件定義・設計をしろという勉強にもなりました。
勢いあまってシステムを作ってしまったけど誰も使わないというのは、エンジニアあるあるだと思いますので、みなさん、走り出す前にちょっと止まってお気をつけて。
ではよきバランス感覚を持った開発者ライフを。