来店予約を受け付け、社内で利用中の外部グループウェアの予定と双方向で連携する店舗予約管理システムを開発しました。施設一覧、日付別・時間枠別の空き検索、予約確定、担当者の自動アサインAPIを実装しています。自動アサインは担当者の区分、受付可能な件数、店舗をまたぐ応援といった業務ルールを組み合わせ、独立した業務ロジック仕様書として文書化。Laravel＋React＋TypeScriptで構築し、OpenAPIを自動公開、LocalStackとMailpitでAWSとメールをローカル完結で検証できるようにしました。
- 業務制約を組み合わせた自動アサインの独立仕様化
- 担当者の区分・受付可能な件数・店舗をまたぐ応援という業務ルールを、コードとは別の業務ロジック仕様書として文書化し、ルール変更時に仕様とコードを突き合わせられるようにしています。
- 外部グループウェアとの双方向同期
- 予約の確定・変更をグループウェアの予定に反映し、グループウェア側の予定も空き判定に反映する双方向連携を実装しました。
- AWSとメールをローカル完結で検証
- LocalStackとMailpitを使い、ストレージやメール送信を含む一連の動作をローカル環境だけで確認できるようにしています。
- OpenAPIの自動公開
- API定義をOpenAPIとして自動公開し、フロントや連携先が常に最新の仕様を参照できるようにしています。
- 空き検索と予約確定をAPIとして分離
- 施設一覧、日付別・時間枠別の空き検索、予約確定、担当者の自動アサインをそれぞれ独立したAPIとして実装しました。自動アサインのルール変更が、空き検索や予約確定の処理に波及しない切り分けです。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
想定例: 自動アサインのルールを「例外」から設計する
担当者の自動割り当ては、通常時のルールよりも例外の扱いで難易度が決まります。担当者が休みのとき、上限に達したとき、その店舗に条件を満たす人がいないときに、誰にどの順で回すのか、あるいは人の判断に戻すのかを、現場の責任者と一緒に洗い出すことが出発点です。ルールをコードに埋め込む前に、業務側が読める仕様書として整理し、変更のたびに仕様書を更新してからコードを直す運用にすると、ルールの認識違いによる割り当てミスを防げます。
想定例: グループウェアと二重管理にならない同期設計
予約システムとグループウェアの予定を双方向で同期する場合、「どちらが正か」を項目ごとに決めておかないと、両側で編集された予定が上書きし合う事故が起きます。予約の枠は予約システムが正、担当者の休暇や社内会議はグループウェアが正、というように所有者を決め、逆方向は参照のみとするのが基本です。連携先のAPI障害時に予約受付を止めるのか、後から同期する前提で受け付け続けるのかも、業務への影響を踏まえて先に決めておきます。
関連するサービス
関連する業種
関連する開発ガイド
- Excel・スプレッドシート業務をWebシステム化するタイミングExcelやスプレッドシートで回している業務が限界に近づくサイン、Webシステム化に向く業務と向かない業務の見分け方、段階的な移行とデータ移行の注意点を整理します。
- 要件定義とは何をすることか — 発注前に整理したい5つのこと要件定義はシステムで何を実現するかを合意する工程です。発注前に整理したい目的と成功条件、現状業務の流れ、利用者と権限、扱うデータ、やらないことの5つを、想定例を交えて解説します。
- 検収（受け入れテスト）で確認すべきことWebシステムの検収で発注側が確認すべきことを、検収条件の確認、テスト項目の作成、ステージングでの実施、不具合の記録と切り分け、検収書の作成の手順で解説し、契約不適合責任との関係も整理します。
他の開発事例
監修: Unlogical Systems合同会社（杉並区・西荻窪）公開