はじめに

技術者として、課題があると飛びついて解決してしまうものの、要件を重め受け止めすぎていて、そこまで必要ではなくて結局使われなかったということは、よくあると思います。そういう悲しいお話です。他山の石としていただければ。

要件

メインの予約部分はこんな感じでできました。

ここまで来てふと我に返り・・・

これがとても大きい。

普通にキャンセルしたいときはどう運用するか
当日ドタキャンされたら、一番いい席が空いてしまう
- 演者の気持ち
キャンセルもせず、予約しても来ない（No Show）
先に多めに予約しておいて、必要な部分は後でキャンセルしようという人
- いちおう２席でガードをかけても、何度も繰り返せばできちゃうか
- そこまで厳密にガードをかけるべきか

キャンセルもシステムでできるようにするためには、ログインのような仕組みが必要になります。それは、システムを作る上でもめんどくさいけど、使う人もめんどくさい。それをこれから追加で作るか・・・？

キャンセルの仕組みを作ったとしても、どうせいろいろな課題は残り、結局手運用が結構かかる。

作った私以外は、システム関係者は誰もおらず、GASという言葉すら知らないと思う状況。勝手に私が先走っただけでした。

なので、バグやら何かの変更があったら、私が動かないといけない。~~メンテ嫌い。~~

つまりこういう図式になったということ。そして結果は、Formsを採用に。

GASアプリ＋開発者負荷＋キャンセル問題　vs　Forms＋運用負荷＋キャンセル問題

GASアプリの場合は、（１日で作ったとはいえ）複雑性とバグの潜在可能性、変更の可能性、それらは開発者の私しか対応できない。

Formsの場合は、追加の運用負荷もあるけど、エンジニアでなくても対応はできるレベル。作るのも超簡単。

というわけで、Formsで単純な方がいいよねという判断になりました。

そもそも私も、これからキャンセルの仕組みを追加で作るとしたら、作り終わっても諸々課題が残るとわかっているので、モチベーションがわかない。

結果的にお蔵入りになってしまいましたが、被害としては私の１日空回りだけで済んだので、よかったです。技術的な勉強（GASのReactアプリ、Material UI等）もあったし、必要十分な要件定義・設計をしろという勉強にもなりました。

勢いあまってシステムを作ってしまったけど誰も使わないというのは、エンジニアあるあるだと思いますので、みなさん、走り出す前にちょっと止まってお気をつけて。

ではよきバランス感覚を持った開発者ライフを。