サービス種別を4種から6種に拡張した話

リリースから数週間後、オーナーから連絡が来た。「コーチングのセッションも、同じ予約フォームで受けられるようにしたい」という要望だった。

「何のサービスを追加したいですか」と聞くと、2種類が出てきた。「未来デザインセッション」と「人生を整える対話セッション」だ。どちらも60分のオンラインセッションで、片づけレッスンとは別軸のサービスだった。

作業を始める前に、まず既存のコードを確認した。

最初の設計が試される瞬間

コーチングの予約受付を実装するとき、最初の4サービスがどういう設計になっているかが問われた。

変更前のコードを見た。サービス名と所要時間はマッピングオブジェクトで管理されていた。

const services = {
  '1': '暮らしの作戦会議（無料相談）',
  '2': '片づけレッスン',
  '3': '片づけ講座',
  '4': '片づけ体験セミナー',
};
const durations = { '1':60, '2':300, '3':90, '4':120 };

「5と6を足すだけだ」と分かった。1行ずつ2行追加する。

const services = {
  // ... 既存 ...
  '5': '未来デザインセッション',
  '6': '人生を整える対話セッション',
};
const durations = { ... '5':60, '6':60 };

次にreserve.htmlのドロップダウンに選択肢を2つ追加した。Googleカレンダー追加URLを計算する部分も、同じdurationsオブジェクトを参照していたため変更不要だった。

最後にオーナーに「新しいサービスの予約枠をスプレッドシートに追加してください」と伝えた。日付・時刻・service_idを記入すれば、それが予約受付可能な枠になる。

作業時間は合計で30分かからなかった。

なぜ30分で終わったか

もし最初の設計でサービスをIDで管理していなければ、この拡張は別の作業になっていた。

「if serviceId === '1'」「if serviceId === '2'」という条件分岐でサービスごとの処理を書いていたとしたら、サービスを追加するたびにコードのあちこちに分岐を追記しなければならない。抜け漏れを探すデバッグが発生する。

設計時点で「5種類目が来るかもしれない」と意識していたわけではない。「コードを読みやすくするためにマッピングで管理する」という判断が、結果として拡張しやすい構造を作っていた。

良い設計の恩恵は、変更が来た瞬間に現れる。

オーナーが自分で枠を追加できること

この拡張で技術的に作業したのは開発者（私）の側だけだ。フォームへの選択肢追加とコードの更新は私が行った。しかし枠の管理はオーナーが行う。

「新しいサービスの予約日時を決めたら、スプレッドシートのslotsシートに行を追加してください。service_idは5か6で」と伝えた。

翌日、オーナーが枠を追加した連絡が来た。「できました」という一言だった。スプレッドシートを開いて、日付・時刻を入力する。それだけで新しいサービスが予約できる状態になる。

「私がいなくても使い続けられる」という設計原則が機能した瞬間だった。

*次回は「Googleカレンダー追加ボタンの実装と罠——CalendarAppを使ってはいけなかった」*

*シンプルシステム株式会社代表　伊藤勝彦*