個人開発しているもの
日々の開発で得た知識を発信しながら、「あったら便利」「作ってみたい」と思ったアイデアを形にしています。
これまでに、グループ旅行アプリ Trip Supporter、スコア管理サービス PointPia、リアルタイム共有サービス JustNow などを開発しました。
さらに、刺繍やオリジナルキャラクターを中心としたアパレルブランド MAD TOMMY WITH... も運営しています。
開発したサービスや技術記事は chicchi.work で紹介しています。
グループ旅行の「確認する手間」を減らしたい
友達や家族と旅行するとき、こんなやり取りが出てきます。
- 「次の集合、何時だっけ？」
- 「今どこにいる？」
- 「さっきのお会計、誰が立て替えた？」
- 「旅行代、もう受け取ったっけ？」
予定はしおり、連絡はチャット、現在地は地図、立て替えたお金はメモ。旅行に必要な情報が分かれると、知りたいことがあるたびに探し直すことになります。
そこで、予定・チャット・地図・写真・費用を、旅行ごとのスペースにまとめるアプリ「Trip Supporter」を個人開発しました。
旅行を計画する人だけに確認や連絡が集中するのではなく、参加する人も必要な情報を自分で見つけられる。そんな使い方を目指しています。
iPhone向けにApp Storeで公開しています。
この記事の機能紹介は、2026年10月31日に確認したApp Storeの公開説明・更新履歴を基準にしています。後半の技術的な話は、開発中のコードも含めた設計の紹介です。
どんなことができるのか
出発前：メンバーを招待して、予定を共有する
旅行を作成し、旅行番号や招待リンクでメンバーを招待できます。管理者の承認が必要な参加方式にも対応しています。
スケジュールには、観光・食事・移動・宿泊などの予定を日程ごとに登録できます。場所だけでなく、画像・費用・メモも一緒に残せます。
たとえば、宿泊の予定に予約情報をメモしておけば、当日にチャットの過去ログを探し直す手間を減らせます。
全日程を1枚の画像にまとめて保存・共有する機能もあります。アプリの中で確認するだけでなく、旅行全体の流れを画像として渡せるようにしています。
旅行中：チャットと地図で、連絡や合流をしやすくする
旅行ごとのチャットで、出発前の相談や当日の予定変更、写真を共有できます。
現在地や地図で選んだ地点を集合場所として登録し、集合日時やメモを添えることもできます。「駅のどこに集まる？」というときに、文章と地点を一緒に残せます。
また、旅行中のメンバーの現在地を地図で確認できます。自由行動のあとに合流したい場面などを想定した機能です。
リアルタイム位置共有は、旅行中かつ有効なチケットがある場合に利用できます。 旅行終了後やチケットの期限切れ後は位置共有を終了し、ゴーストモードで自分の位置共有を停止することもできます。
アプリにはアプリ内購入があります。位置共有の利用条件は、予定やチャットの紹介と分けて明示しています。
旅行後：立て替えた費用と、集金の進み具合を確認する
食事代・交通費・宿泊費などの支出を登録し、金額・通貨・立て替えた人・費用を分ける参加者を管理できます。
「この食事には全員参加」「このタクシーは一部のメンバーだけ」というように、支出ごとに対象者を整理して、精算結果を確認できます。
さらに、集金Botの 「マネタロー」 を用意しました。
割り勘の計算が終わっても、支払ってもらえたかを確認したり、連絡したりする作業は残ります。マネタローは、その後のやり取りを支えるための機能です。
- 割り勘の精算結果から集金を作成する
- 金額と対象メンバーを指定して個別請求する
- 支払期限を設定する
- 支払う人が支払いを報告し、受け取る人が受領を確認する
- リマインドや日時を指定した予約を使う
実際の支払いは、現金や送金サービスなど、アプリの外で行います。 マネタローは自動送金や銀行口座への入金確認を行う機能ではありません。
また、個別請求は割り勘の支出・精算結果に自動反映されないため、同じ費用を重複して請求しないように使い分けます。
どんな技術で作っているか
主な技術構成は次のとおりです。
| 役割 | 使用技術 |
|---|---|
| アプリ | React Native / Expo / TypeScript |
| 認証 | Firebase Authentication |
| 旅行・予定・チャットなどの保存 | Cloud Firestore |
| 位置共有のデータ同期 | Firebase Realtime Database |
| 画像の保存 | Cloud Storage for Firebase |
| サーバー側の処理 | Cloud Functions for Firebase |
| 地図 | Mapbox |
| チケット購入 | RevenueCat |
旅行の予定のように後から見返すデータと、現在地のように繰り返し更新するデータでは、扱い方が異なります。アプリではFirestoreとRealtime Databaseを使い分けています。
開発していて特に考えることが多かったのは、画面に機能を置くことよりも、いつ共有するか、どこまでを完了とするか、切り替えたあとにどの状態を残すかでした。
個人開発で工夫したこと
1. 位置共有は「表示する」だけでなく「止める」まで考える
地図にメンバーの位置を出せても、それだけでは旅行向けの位置共有にはなりません。
旅行の状態、位置情報の権限、アプリが前面にあるか、本人が共有を停止しているかによって、動作を分ける必要があります。
開発中の実装では、前面・バックグラウンドで位置取得の設定を変え、送信側でも経過時間と移動距離を見て更新を判断しています。
ただし、設定した間隔で必ず位置が更新されるわけではありません。位置情報を取得する処理と、取得できた位置を送るか判断する処理を分けて考えています。
位置共有は、使うと便利であることに加えて、本人が共有状態を把握でき、不要になったら止まることまで含めて設計する機能だと感じています。
2. 「支払いました」と「受け取りました」を別の状態にする
集金機能では、支払う人の報告だけで完了にすると、受け取る人が確認する余地がなくなります。
そこで、支払いの状態を次の3つに分けています。
未払い → 支払い報告済み → 受領確認済み
実装上も、それぞれを独立した状態として扱い、操作できる人と遷移前の状態をサーバー側で確認しています。
この区別は、リマインド先にも関わります。支払いを報告済みの人に再び支払いを催促するのではなく、受け取る人へ確認を依頼する必要があります。
単に「完了」というフラグを持つより、誰の行動が終わっていて、次に誰の確認が必要なのかを表すほうが、実際のやり取りに合いました。
3. よく切り替える画面は、切り替えるたびに作り直さない
旅行中は、予定を見て、地図を開き、チャットに戻る、といった操作が続きます。
このたびに画面を破棄して作り直すと、データの再購読や画面状態の初期化が発生しやすくなります。
そのため、ホーム内のタブは初めて開くときにマウントし、訪問済みの画面は保持して表示を切り替える方針にしています。
一方で、画面を保持するとメモリや購読を使い続けます。設定や旅行作成など、頻繁には切り替えない画面まで一律に保持する設計にはしていません。
「どの画面も同じ方法にする」より、旅行中に繰り返す操作に合わせて判断しています。
作ってみて感じたこと
予定、位置共有、割り勘。それぞれは独立した機能に見えますが、1つの旅行にまとめると、機能の間をつなぐ設計が大切になります。
予定を確認して、その場所へ移動する。離れたメンバーと合流する。立て替えた費用を整理して、受け取りまで確認する。
この流れを考えると、「機能を追加した」で終わらず、その前後で利用者が何をするのかまで見直す必要がありました。
個人開発でも、コードを書いてテストが通ったことと、ユーザーが使える形で配信されたことは別です。開発中の変更と公開済みの機能を区別しながら、改善を続けています。
こんな旅行で使ってもらえたら
友人との旅行、家族旅行、自由行動を含むグループ旅行などで、予定・連絡・費用の確認をひとつにまとめたい方に使ってもらえたらうれしいです。
幹事だけが情報を抱えるのではなく、参加する人も「次に何をするか」を自分で確認できる。Trip Supporterで、そんな旅行を支えたいと思っています。
機能・提供条件の確認元：App Storeの公開説明と更新履歴、公式紹介ページ（2026年10月31日確認）。