世界対応の観光アプリを、独学で1人で開発・リリースまでした話(後編)
Photo by Yura Fresh on Unsplash
目次
本当に1人で観光アプリを作れるのか?
きっかけ
「今、どこか空いてるお店あるかな?」から始まったアイデア
「次にどこに行く?」という迷いがストレスになる
“行きたい場所”をつなぎ、見える化する仕組みがあればいい
「店はSNSで探すけれど、ルートまでは考えられていない」—— 友人の声が構想を後押し
無数の壁
ゴールが見えた?
ようやく登録完了、でもゴールはまだ先
新たな言語との出会い
ゴールが見えた
インフラとの出会い
日の目を見たアプリ
余談:アプリ名に込めた想い
https://ajumpworld.com
本当に1人で観光アプリを作れるのか?
開発知識もチームもなく、あるのは「こういうサービスがあったらいいのに」という思いだけ。そんな私が1年3ヶ月かけてリリースまでたどり着くまでの話、後編ではその裏側をすべて語ります。
きっかけ
「今、どこか空いてるお店あるかな?」から始まったアイデア
ある日、友人と夜ご飯を食べに出かけたときのことでした。
2軒目を探そうとした頃には、すでに時刻は深夜0時を回っており、「今、どこか空いているお店はあるかな?」と話しながら、なんとなく街を歩き回ってみることに。
しかし、なかなか営業中のお店が見つからず、時間だけが無駄に過ぎていきました。
スマホで検索してみても、定休日や営業時間の情報はまちまちで、思った以上にスムーズにお店を決められない。
このとき私は、「今、開いているお店がすぐに見つかるような仕組みがあればいいのに」と強く感じました。
「次にどこに行く?」という迷いがストレスになる
とはいえ、営業中のお店を探す機能自体は、Google Mapなどでもある程度カバーされています。
しかし振り返ってみると、実際の課題は「営業中かどうか」の情報を確認したあとにやってきました。
結局、「どこに行こうか」と迷ってしまい、なかなか決められない——そんな時間が、じわじわとストレスになっていたのです。
特に飲みや観光など、1軒目を終えた後の「次にどこへ行くか問題」は、多くの人にとっても共通の悩みではないでしょうか?
「どうすれば、この“次どこ行く?”の迷いを減らせるだろう」
そう考えた私は、アイデアを一歩先に進めることにしました。
“行きたい場所”をつなぎ、見える化する仕組みがあればいい
もし、行きたいお店やスポットを「プラン」として線でつなぎ、視覚的に整理・共有できる仕組みがあったらどうでしょうか。
ルートや順番をあらかじめイメージできれば、移動や判断に迷わず、もっと快適にその場を楽しめるはず。
さらに、「ワイン好きのための飲み歩きプラン」や「観光初心者向けの尾道半日旅」など、テーマや目的に沿ったプランを他の人から参考にできるようにすれば、地元の人にも観光客にも役立つのではないか。
こうして生まれたのが、単なる地図アプリではなく、**体験を軸にした「旅のプランを作成・共有できるWebアプリ」**という構想でした。
「店はSNSで探すけれど、ルートまでは考えられていない」—— 友人の声が構想を後押し
その後、旅行好きの友人たちに「旅先でどのようにお店やルートを決めているか」をヒアリングしてみたところ、興味深い声が返ってきました。
「お店はInstagramやSNSで見つけてるけど、どの順番で回るかとか、効率のいいルートを考えるのって案外難しいんだよね」
たしかに、SNSで見つけた魅力的な場所も、地図上での位置関係や移動のしやすさまで含めて考えるのは手間がかかります。
結果として、「どう回るか」で時間を取られてしまい、せっかくの旅や時間を楽しみきれない場面があることに気づきました。
このフィードバックを受けて、私の中でのアプリ構想は一層具体化・加速していきました。
さらに、私自身が留学していた経験から、海外で行き先を探すときの大変さも思い出しました。
現地の情報が英語ばかりで、内容を理解することに精一杯になり、肝心な情報にたどり着けないことが多かったのです。
だからこのアプリは、日本語にも英語にも対応し、訪日外国人にも、日本人の海外旅行にも使えるような多言語対応の設計にしようと決めました。
ただし、この時点では、そういったアプリを開発するだけのスキルも経験も全くなく、
「どうやって作ればいいのか」「どんな技術を使えばできるのか」さえ、まだ手探りの状態でした。
無数の壁
開発を始めて、すぐに重大な壁に直面しました。
学習に使っていた教材はあくまで基礎的な内容であり、実際のアプリ開発に必要なユーザー設計や構成、機能設計にはまったく応用が利かないことに気づいたのです。
※ 技術的な詳細については、別記事で改めて紹介します。
まずは、モデル定義や画像処理、ユーザー登録機能の実装に取り組みましたが、
これらの実装が終わるまでに、すでに約半年が経過していました。
その半年間、ChatGPTをフル活用しながら、ゼロから完全独学で設計と実装を進めるという、想像以上にハードな道のりでした。
とにかく、毎日毎日ひたすら調べ続けました。
わからないことがあれば細かく分解し、それぞれの要素を一つひとつ調べて理解する。
理解できたら今度は、それらをどう繋げればアプリとして成立するのか、全体を俯瞰して再構築する。
そんなことの繰り返しです。
ChatGPTの回答も、最初は「正しそうに見えて間違っている」「条件が少し違えば動かない」ことが多々あり、
提示されたコードをそのまま使うのではなく、“なぜそう書くのか”を理解しないと、前に進めない状況でした。
一つのコードを完全に理解するまでに、何日も費やしたこともありました。
一つのメソッドの理解のために、別の知識の理解が必要であったり、さらにそれの理解のために必要な知識があったりと、ときには答えがあるのかさえわからないような迷路に入り込むこともありました。
それでも少しずつ、確実に、前に進んでいたのです。
下記は初期に考案したアプリ全体の概要です。(UIは開発しながらどんどん変わっていったのですが、機能的な部分は大部分を実装できたと思います。)
ゴールが見えた?
ユーザー登録の設計や、基本的なモデル定義がひと通り終わった頃。
「もしかして、このままいけばリリースも近いのでは?」と、ほんの少し希望が見えた時期がありました。
テンプレートやビューの実装に取りかかり、学習用の教材に出てくるレベルであれば、
なんとなく進められそうな気がしていたのです。
けれど、それは甘い考えでした。
実際のサービスで使うには、セキュリティや運用面をしっかり考慮しなければなりません。
特にメール認証の部分では、仮登録用のメール送信処理や、本登録リンクへの署名付きトークンの発行など、
一つひとつが手探りの連続で、細かく調べながらの実装となりました。
本登録のテンプレートまで作成し、ようやく「これでひと区切り」と思ったのも束の間、
今度は国際対応の設計という新たな壁に直面します。
私のアプリは、訪日外国人だけでなく、日本人が海外旅行をする場合でも使えるようにしたいと考えていたため、
日本のお店だけでなく、海外のお店も登録できる設計にする必要がありました。
ここで問題になったのが、「住所フォーマット」の違いです。
日本なら都道府県 → 市区町村 → 番地という順番で済みますが、国が変われば並び順や項目も異なります。
しかも、私は店舗間の距離を自動で計算し、最適な旅行プランを組める機能を実装したかったため、
正確な座標(緯度・経度)を住所から取得する処理が不可欠でした。
そのため、Google Maps Geocoding API を使って住所から座標を取得する設計にしたのですが、
APIに渡す住所は、その国ごとのフォーマットに適した並び順に変換する必要があることに気づきます。
ここでも、ただ機能を実現するだけでなく、将来的に他国の住所にも簡単に対応できるよう、
保守性を高めた柔軟な設計まで意識しました。
「どうすれば、各国の住所フォーマットを追加しやすくできるか?」
「ユーザーがどの国を選んでも、正しい形式で自動処理できるようにするには?」
このような問いに答えるべく、また一から設計を考え直し、何度も調べ直しては実装を進めていきました。
ようやく登録完了、でもゴールはまだ先
なんとかお店の登録機能が完成し、実際にデータが保存された瞬間の感動は、今でもはっきりと覚えています。
「やっとここまで来た」と、半年以上の努力が報われた瞬間でした。
しかし、その感動も束の間。
ふと冷静に考えると、まだまだやることは山積みです。
- 一般ユーザーの登録と認証
- プラン作成機能
- レビューの投稿
- カスタマーサポート問い合わせ
- お店情報の更新/削除処理 …などなど
“完成”というゴールは、まだはるか彼方にありました。
新たな言語との出会い
そんな中、次に私を待っていたのがJavaScriptとの出会いでした。
名前だけは知っていましたし、Webフロントでよく使われることも知っていましたが、
正直「HTMLとCSSだけでなんとかなる」と甘く見ていたところがあり、学習を避けていました。
ですが、お店登録のUIを作り込む中で、どうしてもJavaScriptの力が必要になり、
その場で勉強を始め、理解しながらアプリに組み込んでいくことになりました。
とくに、プラン作成機能では「非同期処理によって画面遷移をせずに操作できる快適なUI」が必要で、
JavaScriptはもはや欠かせない存在に。
とはいえ、まだ理解も浅く、実装のたびにエラーの嵐。
そのたびにネットで調べ、ChatGPTを駆使して、自分で試して、試して、試して…。
一歩進んで二歩下がるような日々が続きましたが、
それでも少しずつ「自分の手で思い通りの動きが作れる」ようになっていきました。
ゴールが見えた
プラン作成機能や、お店へのレビュー投稿、さらには各種機能の**CRUD(作成・取得・更新・削除)**処理など、
必要とされる機能を一通り実装し終えた頃——
ようやく「完成」という二文字が、現実味を帯びてきました。
振り返れば、ここまで1年と2ヶ月以上。
一つひとつの画面に翻訳ファイルを組み込み、
全ページ・全機能にわたる国際化対応も、地道に仕上げてきました。
ようやく、「リリースできる」「このアプリを世に出せる」という気持ちが高まった瞬間でした。
しかし、ふと立ち止まって気づきます。
“ローカル環境で動いている”ことと、“本番で運用する”ことは、まったく別の話であると。
実際のユーザーに使ってもらうには、
セキュリティ・パフォーマンス・ログ監視・メール送信・HTTPS化・デプロイ手順など、
まだまだ乗り越えるべき課題が数多く残っていました。
もちろん、開発当初から「サービスとして使える品質」を目指してきたため、
セキュリティや拡張性には細かく工夫を凝らしてきました。
ただ、それでもなお、“ローカルを飛び出し、世界中のユーザーに触れてもらう”という最終段階は、
それまでの開発とはまったく別のスキルと視点が求められるものでした。
本番環境での運用、デプロイ、運営体制——
それはまた新たな学びと試行錯誤の始まりだったのです。
インフラとの出会い
ここまで、設計、コーディング、国際化、セキュリティ——
すべてを独学・一人で取り組んできました。
そして、ついに最後の大きな関門である「インフラ」との出会いが訪れます。
私は最初から、インフラには AWS を使うと決めていました。
理由は明確で、AWSは世界トップシェアのクラウドサービスであり、
多くの企業が導入していることから、将来エンジニアとして働く際にも必ず役立つと考えたからです。
たとえ操作が難しくても、それを乗り越えるだけの価値がある。
そう信じて、AWSを選択しました。
設定は、ルートユーザーを使わずIAMユーザーで操作するなど、基本的なセキュリティの考え方から丁寧に学び、
同時に、コストをできるだけ抑えるインフラ構成を慎重に検討していきました。
ただ安さを追い求めるのではなく、必要なセキュリティや運用性は妥協せず取り入れる。
その方針のもと、ログ監視のためにCloudWatch Logsへの転送はマスト要件とし、
ログの構成や権限管理も細かく詰めていきました。
途中、ファイルやディレクトリのパーミッション不足によるエラーに何度も苦しみました。
「なぜこのファイルだけ読み込まれない?」
「この権限なら通れるはずでは…?」
ディレクトリのx(実行)権限がないことで中に入れない、
CloudWatch Agentが特定のJSON設定を読み込めずに失敗する、
サービスの起動ユーザーに適切なアクセスがない——
そんな小さな“罠”に何度もつまずきながら、
地道に一つずつ調べ、確認し、解決する日々が続きました。
それでも、諦めずに取り組み続け、
ついにすべての設定が整い、インフラ構築が完了。
この瞬間、アプリはようやく「本番環境に立った」のです。
日の目を見たアプリ
構想から約1年3ヶ月。
ようやく私のアプリが世に出る日が訪れました。
本当に長い道のりでした。
でも、諦めずにここまにやり切って本当に良かった。
自分の頭の中のアイディアが、形となり、実際に公開されたという経験は、
何にも代えがたい感動と達成感を与えてくれました。
けれど、これはゴールではなく、むしろスタートラインに過ぎません。
すでにいくつかのお店・一般ユーザーの方にご登録いただき、
少しずつ、実際の価値をサービスとして届けられるようになってきています。
これからは、さらなる改善・運用・そしてユーザーへの価値提供のために、
また新しい壁を一つ一つ越えていく必要があると強く感じています。
「継続は力なり」と言いますが、
独学・完全個人でここまで開発・リリースできたことは、
間違いなく今後の自分の糧となる、大きな自信になりました。
この経験を、これからの人生、そして将来所属する企業でも活かしていきたいと思っています。
最後までお読みいただき、ありがとうございました。
現在、私は就職活動中です。
このアプリを通して、自分がどんなことに向き合い、何を成し遂げてきたのかが少しでも伝われば幸いです。
余談:アプリ名に込めた想い
私が開発したアプリのURLはこちらです:
https://ajumpworld.com
アプリ名「AjumpWorld」には、私なりの造語の意味が込められています。
「Ajump」は、英語の略語 “ASAP(As Soon As Possible)” のように、
**「できるだけ早く」旅に出よう!**という想いと、
旅立ちをイメージしたアクション動詞 “jump”(飛び出す) を掛け合わせて作った造語です。
そして、私のアプリは国際化(i18n)対応を意識して開発しているため、
日本国内だけでなく、世界中の人々が使えるサービスを目指しています。
そこに「World」を組み合わせて、完成したのが:
🌍 AjumpWorld
“できるだけ早く、世界に飛び出そう。”
一見キャッチーな名前ですが、そこには私自身の留学経験や、旅への情熱も込められています。
アプリを通じて、一人でも多くの人が新しい場所へ、
新しい体験へ「飛び出していく」きっかけを提供できたら嬉しいです。
*開発の中盤くらいに自分で作成したデザイン(開発をしながらデザインを変えたので一部は違いますが、ベースにしたものです)
*2024年12月18日時点でのお店の登録画面の実装状況
*2024年12月31日時点でのお店の写真登録の表示がうまくいかない時のスクリーンショット
*2025年5月22日ホームの画面の構築に着手
*2025年7月23日、リリースしてから自分のブラウザで表示(日付は23日ですが18日に公開しております。)