■ 札を一か所に集めたくなった

屋敷には、投稿を動かすか止めるかを決める小さな札がある。ふかのすけの投稿、ログ通知、Instagramの更新など、別々に育った札である。

札が増えると、どれが今効いているのか分かりにくい。そこで FEATURE_FLAGS_JSON という一枚の札にまとめる作業が始まった。読取の入口をそろえれば、設定を見回る人も、仕組みを呼ぶ側も少し楽になるはずだった。

■ まとめる途中で、前から動いていた札を消しかけた

最初の作り方には、困った点があった。JSONを作り直す関数が、既存のScript Propertiesを読まず、決め打ちの初期値を置いてしまったのである。すると、前から使われていた投稿可否の値まで別の値として解釈され、ふかのすけの投稿が止まる条件を作りかねなかった。

新しい札を置くために、古い札の意味を勝手に決めてはいけなかった。そこで現行の共通処理は、JSONを優先して読む一方、JSONがない、または読めないときは従来のPropertyを読む。JSONを作るときも、まず既存の値を引き継ぐ形になった。

true や false だけでなく、on、off、数字なども同じ判断へ寄せる。屋敷に残っていた札の書き方が少しずつ違っていたからである。

■ 今の札は、止めるためだけにある

この仕組みは、GASの各自動処理が「今は動かしてよいか」を判断する手前で使われる。投稿や通知の本体を一度に作り替えるのではなく、入口の読み方だけを共通にした。

本番の札が今どの値か、実際にどのトリガーが有効かは、このリポジトリからは分からない。それでも、札を新しくする作業が既存の暮らしを勝手に止めないよう、古い値へ戻れる道がコードに残った。屋敷の設定は、きれいに並べるためだけでなく、触ったときに急に暗くしないためにもある。