店舗を開業するにあたり、予約システムをどうするかは早い段階からの課題でした。
当初は、既存の予約サービスを利用するつもりで複数のサービスを比較していました。しかし、必要な会員数や機能を考えると上位プランが必要になり、毎月の負担が大きくなります。
さらに、月会費の決済には別のサービスを使う予定でした。既存の予約サービスに含まれる決済機能を使わない一方で、その機能を含むプランへ料金を支払うことになります。
そこで、紹介を受けたエンジニアへ、予約システムの開発を依頼しました。費用は一括で10万円程度です。
必要な機能は一通り実装され、システムも納品されました。それでも、最終的に本番では使いませんでした。
今回は、なぜ外注を選び、完成したシステムを本番で使わなかったのか、そして、それでも支払った10万円程度を無駄だったとは考えていない理由をまとめます。
既存の予約サービスでは費用と機能が合わなかった
最初に検討したのは、店舗向けに提供されている既存の予約サービスでした。
既存サービスには、予約受付、顧客管理、決済、メール通知など、店舗運営に必要な機能がまとまっています。自分で開発や保守をしなくても利用できることは、大きな利点です。
一方で、私が計画していた店舗では、会員数が増えると早い段階で上位プランへの移行が必要になりました。また、月会費の回収には別の決済サービスを使う予定だったため、予約サービス側の決済機能は必要ありませんでした。
つまり、必要ではない機能を含むプランに毎月料金を支払いながら、別の決済サービスも利用する形になります。
もちろん、既存サービスには開発や保守を任せられる価値があります。ただ、小規模店舗の固定費として考えると、月額料金を継続して負担することには慎重になりました。
10万円程度の一括払いで開発を依頼した
既存サービスを検討していた時期に、エンジニアの紹介を受けました。
月額料金を払い続けるのではなく、一括の開発費でシステムを用意できるのであれば、長期的には負担を抑えられる可能性があります。相談したところ、10万～15万円程度で対応できるという話になり、最終的には10万円程度で依頼しました。
開発を依頼した機能は、単純な予約受付だけではありません。
- 会員管理
- コース管理
- 予約とキャンセル
- 契約回数の付与・消費・繰り越し
- キャンセル待ち
- トレーニングカルテ
- メール通知
- 決済サービスとのデータ連携
- 操作履歴
決済自体は予約システムに組み込まず、外部サービスに任せる設計です。それでも、少人数制の店舗を運営するために必要な機能を並べると、相応の規模になります。
この内容を10万円程度で開発してもらえるのであれば、既存サービスの月額料金と比べて魅力的に感じました。
開発前に要件定義書を渡した
開発を依頼する前に、必要な機能は資料へまとめました。
予約システムの要件定義書だけでなく、画面一覧、画面遷移、会員や予約のステータス、CSVの入出力、定期処理なども整理しています。
誰がどの情報を閲覧・編集できるのか、予約時に回数をどのように仮押さえして、利用後にいつ消費するのか、キャンセル待ちをどの順番で案内するのかといった業務上のルールも記載しました。
開発者へ依頼するときには、頭の中にある希望をそのまま伝えるだけでは認識がずれます。少なくとも、利用者、必要な機能、対象外とする機能、運用上のルールを文章にする必要があります。
今回については、作成していた要件資料を開発前に一通り共有しました。
必要な機能は一通り実装された
納品されたWebシステムには、依頼した機能が一通り実装されていました。
操作性や画面の見せ方に改善したい部分はありましたが、使い勝手に強くこだわらなければ、店舗で利用できる程度の状態にはなっていました。支払い前にも修正に対応していただいています。
したがって、本番で採用しなかった理由は、システムがまったく動かなかったからではありません。納品後に私自身の求めるものが変わったことが、より大きな理由です。
完成後に細部へこだわりたくなった
実際にシステムを操作すると、要件定義書を作っていた段階では見えていなかった部分が気になり始めました。
画面のデザイン、ボタンの配置、会員やトレーナーの操作導線など、文章で機能を定義するだけでは決め切れない部分があります。
また、データベース、メール配信、ホスティングなどについても、機能だけでなく、毎月の運用費を含めて自分で構成を検討したくなりました。
完成品を目の前にして初めて、「ここを変えたい」「この操作はもっと簡単にしたい」という希望が具体的になります。
外注先へ修正を依頼することもできます。しかし、店舗運営を始めると、小さな仕様変更をその都度説明し、見積もりを取り、修正後に確認すること自体が負担になる可能性があります。
Claude Codeで別のシステムを作った
開業準備と並行して、私はClaude Codeを使った開発を学んでいました。
半年に満たない程度の経験でしたが、勉強を兼ねて複数のアプリを作り、指示の出し方やテスト、修正の進め方をある程度理解していました。
そこで、予約システムも試しに作ってみることにしました。
納品されたシステムのソースコードやデザインは受け取っておらず、流用もしていません。外注時に作成した要件定義書をそのままClaude Codeへ読み込ませたわけでもありません。
店舗運営に必要な要件は自分の中にあったため、Claude Codeと対話しながら、技術構成や画面、動作を一つずつ決め、別のシステムとしてスクラッチから作りました。
それまでにClaude Codeを使った経験を積んでいたこともあり、大方の機能は4日程度で実装できました。
ただし、これは誰でも4日で業務システムを作れるという意味ではありません。私はもともとPython、VBA、C、C++などを使った経験があり、Claude Codeを学ぶ過程でも、Web開発、データベース、認証、フロントエンドとバックエンドなどを調べていました。
専門のWebエンジニアではありませんが、出力されたものが意図どおりかを確認し、問題があれば原因を調べるための基礎はありました。
本番では自分で作った方を採用した
最終的に、本番ではClaude Codeを使って作った予約システムを採用しました。
大きかったのは、初期費用の差よりも、開業後の変更へ自分ですぐ対応できることです。
例えば、トレーナーが会員満足を考えながら予約枠を自由に設定できるようにしていましたが、開業後、一枠ずつ設定する作業に時間がかかることが分かりました。
外注していれば、変更したい内容を整理し、再度要件を伝え、修正を依頼して、納品後に確認することになります。自分で管理しているシステムであれば、内容によっては1日で修正、テスト、本番反映まで進められます。
店舗を運営する本人が、現場で感じた不便をそのまま改修へつなげられることは、想像していた以上に大きな利点でした。
一方で、自分で作れば設計がすべて最適になるわけではありません。操作ログを細かく残しすぎたため、データベース容量をもう少し意識すべきだったと感じる部分もあります。
開発の自由度が高い分、設計、テスト、セキュリティ、障害対応の責任も自分で負うことになります。
納品されたシステムには全額を支払った
本番で使わないと決めた後も、開発費の10万円程度は全額支払いました。
依頼した機能は実装され、修正にも対応してもらい、Webシステムとして納品されていたからです。返金を求める理由はないと考えました。
エンジニアとの関係にも問題はありません。本番で採用しなかったのは、納品後に私のこだわりが強くなり、自分で開発・改善できるようになった結果です。
この点は、成果物が希望どおりに完成しなかった場合とは分けて考える必要があります。
10万円程度は開業に間に合わせるための保険でもあった
結果だけを見れば、10万円程度を支払ったシステムを本番で使わなかったことになります。
しかし、私はこの支払いを単純な無駄だったとは考えていません。
開発を依頼した時点では、Claude Codeへの理解が十分ではなく、自分で本番用の予約システムを完成させられる確信もありませんでした。選択肢は、既存サービスを使うか、開発を依頼するかのどちらかに近い状態でした。
もし自分の開発がうまくいかなければ、納品されたシステムを使うことで開業には間に合わせられます。
つまり、外注したシステムは、本番採用しなかったとしても、予約手段がなく開業できないリスクを下げていました。開発に協力してもらったこと自体にも価値があります。
後から別の選択肢が生まれたからといって、当時の判断まで誤りだったとは限りません。
外注するなら変更と保守まで考えておく
今回の経験から、予約システムを選ぶ際には、初期費用と月額料金だけでなく、開業後の変更方法まで考える必要があると分かりました。
外注する場合は、少なくとも次の点を事前に確認しておいた方がよいと思います。
- 納品物に何が含まれるか
- ソースコードが提供されるか
- サーバーやドメインを誰が管理するか
- 月々の運用費を誰が負担するか
- 不具合と仕様変更をどう区別するか
- 修正費用をどのように決めるか
- 保守の期間と対応速度
- 将来、別の開発者へ引き継げるか
- データをどの形式で取り出せるか
- 本番投入前に誰がどのようなテストをするか
詳細な要件定義書を作っても、実際に触って初めて気づくことはあります。完成時点だけでなく、運用開始後に変更が発生することを前提に依頼条件を決める必要があります。
AIで作る場合にもテストは必要になる
Claude Codeを使えば、要件を伝えながら短期間で多くの機能を実装できます。しかし、生成されたコードが店舗の運用に合っているかを判断するのは利用者側です。
今回も、管理者、トレーナー、会員という異なる立場で、認証、予約、キャンセル、キャンセル待ち、回数付与、カルテ、定期処理などの導線を確認しました。
自動テストだけでなく、実際の利用者として操作する受入テストを行ったことで、使いにくい部分を見つけ、改善につなげられました。
AIを使った開発方法、テスト、運用費、開業後の改修については、次の記事で詳しく整理する予定です。
まとめ
私は、既存の予約サービスでは月額料金と必要機能が合わないと考え、紹介を受けたエンジニアへ10万円程度で予約システムの開発を依頼しました。
必要な機能は一通り実装され、システムも納品されました。それでも、完成後に操作性や技術構成への希望が具体化し、Claude Codeで別のシステムを作ったため、本番では採用しませんでした。
今回の経験から得た教訓は、次のとおりです。
- 既存サービスは月額料金だけでなく、不要な機能との組み合わせも確認する
- 外注では、機能要件だけでなく、納品後の変更と保守も決める
- 完成品を操作して初めて分かる要望がある
- 自分で改修できることは、小規模店舗にとって大きな価値になる
- AIで開発しても、受入テストと運用責任はなくならない
- 本番で使わなかった外注も、当時のリスクを下げていたなら無駄とは限らない
安く作れる方法を選ぶことと、安心して運用できる方法を選ぶことは同じではありません。
その時点の知識、使える時間、開業までの期限、保守できる人の有無を踏まえて、既存サービス、外注、自分での開発を比較する必要があると感じています。
