前回までのあらすじ
システム開発会社に「半年・最低500万円」と言われて諦めていた予約システム。それを、お盆休みにClaudeへ投げかけた「レンタルスペースの予約システムってオリジナルで作れる？」という一言から作り始めることになりました。
初日にモックアップで予約カレンダーが動き、「いける」と確信したところまでが前回です。
今回は、そこから本格的に作り始めるまでに何を決めたのか、という準備編です。
私はプログラマーではありません。ここから先は、聞いたこともない単語との戦いでした。
「Cloudflare」「GitHub」と言われても
初日にモックアップが動いたことで気持ちは固まりました。では実際に作っていきましょう、という段になったとき、次々と知らない名前が出てきます。
Cloudflare。GitHub。
正直に書きます。最初はまったく戸惑いました。
名前を聞いたことがある程度のものもあれば、初めて見る単語もある。何より困ったのは、それぞれのツールがこの制作の中でどんな役割を担うのか、そこすら分かっていなかったことです。
さらに言えば、そもそもどんなツールを使えばこのシステムが実現できるのか、どんなプログラミング言語で作られることになるのか——その全体像が、着手の時点で何ひとつ見えていませんでした。
普通に考えれば、ここで止まります。分からないものを使って何かを作るなど、無理な話です。
そこで私は、作り始める前にまずこう頼みました。
「これらのツールが、この制作の中でどう活かされるのかを教えてください」
専門用語なしで説明してもらえたことが、一番の安心でした
ここが、この準備段階で一番ありがたかった点です。
Claudeは、私のようなノンプログラマーに対して、専門用語をほとんど使わずに説明してくれました。 しかも、例え話を交えて。
前回書いたとおり、最初のやり取りでClaudeは私の知識レベルを確認していました。プログラマーではない、WEB屋ではあるがクリエイティブと営業寄りだ、と正直に伝えてあった。その情報が、説明の仕方に反映されていたのだと思います。
人に仕事を頼むときと同じです。相手のレベルが分かっていれば、説明の粒度を合わせられる。分からないまま進めると、専門用語だけが飛び交って話が噛み合わなくなります。
実際にどう説明されたのか、印象に残っているものを2つ紹介します。
Cloudflareは「お店のコンシェルジュ」
Cloudflareについては、お店のコンシェルジュに例えて教えてくれました。
お店にはたくさんの人が訪れます。その全員を、まずコンシェルジュがさばく。
「メニューをください」と言われたら、これは簡単な用件なので、その場でさっと対応して終わらせる。
一方、「この料理を注文したい」という話であれば、内容をきちんと確認して、奥の料理人に通す。
——これがCloudflareの役割だ、という説明でした。
この例え話で、ようやく腑に落ちました。軽い要求はその場で返し、重い処理だけを奥に流す。 だから速いし、コストも抑えられる。
技術的に正確な説明を受けていたら、たぶん理解できていませんでした。
そして今回の構成では、Cloudflareの役割はこの「さばく係」だけにとどまりませんでした。
予約を受け付けて処理する部分も、データを保管する部分も、同じくCloudflareの上で動いています。先ほどの例えでいえば、入口のコンシェルジュだけでなく、厨房も倉庫も同じ建物の中にあるという状態です。
だからこそ、後で書くように、月額700円という金額で収まっています。
GitHubは「戻れる生産管理」
GitHubについても、最初は何のことか分かりませんでした。
教わった内容を私の言葉で書くと、こうなります。
システムを作っていく過程で、どこをどう変えたかという履歴をすべて記録しておいて、万が一トラブルがあっても前の状態に戻せるようにする、生産管理のようなツール。
さらに、制作に関わるドキュメント類もここに格納しておける。
そして、これが無料で使えるということも教えてもらいました。
この時点では、まだ実感はありませんでした。「戻れる」と言われても、何から戻る必要があるのか分かっていなかったからです。保険のようなものだろう、という理解で進めました。
（その理解が甘かったことは、後の回で書くことになります）
もうひとつの役割は、後から分かりました
GitHubには、私が当初理解していなかった、もうひとつ大きな役割がありました。
最初のうち、私は作ったファイルを毎回自分でアップロードしていました。手作業です。変更するたびに、同じことを繰り返していました。
2日目か3日目あたりだったと思います。ふと思って、聞いてみたのです。
「もしかして、サーバーにアップするのをClaude君にお願いすることは可能？」
すると、GitHubに上げれば、そこから直接反映できるというではありませんか。
正直、驚きました。そこまでやってくれるのか、と。
これを設定してからは、毎回のアップロード作業が不要になりました。こちらは開発そのものに集中できる。 地味な話に聞こえるかもしれませんが、2週間という期間を考えると、この時間短縮は決して小さくありませんでした。
しかも、これが2日目か3日目の出来事だったのが大きかった。残りの10日以上、ずっとその恩恵を受けられたからです。もし最終日に気づいていたら、2週間の大半を手作業に費やしていたことになります。
ここで学んだことがあります。AIは、聞かれないことは教えてくれません。 面倒だと感じたら、その場で聞いてみる。この習慣が、後の工程でも何度も効いてきました。
つまりGitHubは、履歴を残す保険であると同時に、作ったものが公開されるまでの通り道でもあったわけです。
WordPressを使わなかった理由は、正直「勘」です
それまで私たちは、WordPressのプラグイン「Bookly」で予約を受けていました。当然、新しいシステムもWordPressの上で作るという選択肢はあったはずです。
しかし、今回はWordPressを採用しませんでした。
正直に書くと、明確な技術的根拠があったわけではありません。
ただ、これまでの記事でも書いてきたとおり、レンタルスペースの予約システムは非常に複雑です。時間軸での計算、曜日ごとに変わる料金、オプションの在庫、複数の決済手段、キャンセル料の自動計算。
一般的なWEB制作レベルのプラットフォームでは、到底耐えられないだろう。
そういう感覚的な思いがありました。10年以上運営してきた中で、既存のサービスが「最後の一歩」で届かない場面を何度も見てきた。その経験から来た勘です。
技術の判断はできませんでしたが、「この要件は重い」という感覚だけは持っていました。 結果として、この判断は正しかったと思っています。
そして、お金の話
準備段階で、私がはっきり確認したことがあります。コストです。
なにしろ「半年・500万円」という数字を先に聞いている身です。今回はいくらかかるのか。ここは着手前に質問しました。
そして、思いのほか安く済むことに驚きました。
Claudeの利用料：月額30,000円
まず、Claude自体の契約です。私は上位のプランを契約しました。月額30,000円のものです。
無料のプランでは、すぐに使える量を使い果たしてしまい、前に進みませんでした。
ここは正直に書いておきます。「AIがあれば作れます」という話はよく聞きますが、実務で使うシステムを作ろうとすると、無料の範囲では足りません。
ただ、私は迷いませんでした。
500万円かかると言われていたものが、月額30,000円で進むのであれば、微々たるものです。
比較対象があったから即決できました。逆に、あの見積もりを知らなければ、月3万円を高いと感じていたかもしれません。
サーバー代：月額700円
もうひとつ気にしていたのが、稼働し始めてからのランニングコストです。
当初の私の想像では、AWSのようなサービスを契約して、毎月何万円も払うことになるのだろうと思っていました。
ところが、Claudeから提案されたCloudflareを使った構成では、そうはなりませんでした。
実際のサーバー代は、月額700円です。
複数のレンタルスペースの予約を受け、決済が走り、メールが飛び、Googleカレンダーと同期している。それで月700円。
ここで、運用面の不安が消えました。作れたはいいが維持できない、という事態にはならないと分かったからです。
GitHub：無料
前述のとおり、GitHubは無料で使えました。
数字を並べると、こうなります
準備段階で見えたコストを整理すると、こうなります。
| 項目 | 費用 |
|---|---|
| 当初のシステム開発会社の見積もり | 半年・最低500万円 |
| Claude（開発期間中） | 月額30,000円 |
| Cloudflare（稼働後のサーバー代） | 月額700円 |
| GitHub | 無料 |
念のため申し添えますが、私はシステム開発会社の見積もりが不当だったとは思っていません。
真面目に作ればそれだけかかる、というのは今なら余計によく分かります。この後の回で書いていきますが、レンタルスペースの予約システムは本当に複雑です。
ただ、前提が変わったのだと思います。
準備編でやったことは、結局ひとつだけ
振り返ってみると、この準備段階で私がやったことは、実はひとつだけでした。
分からないものを、分からないままにしなかった。
Cloudflareが何をするのか。GitHubが何のためにあるのか。なぜその構成なのか。いくらかかるのか。
技術的に完全に理解したわけではありません。今でもコードの中身は読めません。
でも、それぞれが何の役割を担っているかだけは、自分の言葉で説明できる状態にしてから着手しました。
これは結果的に、非常に大きかったと思います。役割が分かっていれば、トラブルが起きたときに「どこの話をしているのか」が見当つきます。全部を丸投げしていたら、後の工程で必ず止まっていたはずです。
分からないことを聞くのに、AIは向いています。何度聞いても嫌な顔をされません。「こんな初歩的なことを聞いていいのか」という遠慮が要らないのは、ノンプログラマーにとって決定的な利点でした。
そして、スクリーンショットを見せるだけで伝わる
もうひとつ、これは本当に助かったことがあります。
画面のスクリーンショットを見せるだけで、内容を理解してくれるのです。
これがどれだけ大きいことか、少し説明させてください。
人に相談するときには、普通まず自分の状況を言葉にしなければなりません。何がどうなって、どこで止まっているのか。ところが私のようなノンプログラマーは、そもそも何が問題なのかが分かりません。 用語を知らないので、症状を説明することすらできない。
ここが、素人にとって一番高い壁だと思います。
でもスクリーンショットなら、分からないまま渡せます。画面をそのまま見せて、読み取ってもらう。
トラブルシューティングと言っても、私の場合はトラブルの内容自体が分かっていません。それでも前に進むために、スクリーンショットを多用しました。
理解していなくても前に進める。 これが、開発そのものに集中できた大きな理由です。
次回：#3 予約カレンダーと顧客導線
次回からは、いよいよ実装の話に入ります。
まずは、すべての出発点となった予約カレンダーです。なぜ日本のお客様は「カレンダーから入りたい」のか。そして、そのカレンダーを作るうえで何が難しかったのか。
「◯△✕で空きを表示する」という、たったそれだけのことが、意外な難所でした。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった（この記事）
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事