背景と開発の動機：アプリビルド経験の獲得と、既存マッププラットフォームへの観察
Pintio（ピンティオ）の開発を始めた一番の動機は、デザイナーとしての実績の拡張、そしてこれまでに経験がなかった「モバイルアプリのデザインおよびiOSアプリをゼロから自分でリリースする経験」を自発的に獲得することでした。「まずはやってみよう」という技術的な探求心からスタートしました。その中で、実際にシドニーへ渡航する機会があり、現地での飲食店巡りを通じて「もしアプリが多言語化され、通貨を切り替えられる機能があれば、海外滞在時にも実用的なアプリになるのではないか」という着想を得ました。
また、日常的に既存のプラットフォームを観察する中で、いくつかの疑問を持っていました。例えば「食べログ」のような国内サービスは、広告出稿している店舗が上位に表示される構造があり、純粋なユーザー視点ではノイズを感じることがあります。一方、「Googleマップ」は非常に機能が充実しているものの、多機能すぎるがゆえに一般のユーザーがすべての機能を使いこなせていない側面があると考えました。さらに、訪れた場所をピン留めするアプリは存在するものの、「いくら使い、何を食べたか」という詳細なメニューや金額までを併せて記録できるサービスは私が見る限り見当たりませんでした。市場に存在しないということは需要がない可能性もありましたが、だからこそ「機能を引き算した一体型の記録アプリ」を自分で形にしてみる価値があると判断しました。
実装の目的とコア機能：振り返り体験の向上と、AIを用いた実装実験
単に「行った場所」のピンを打つだけでなく、「レシートを読み込ませる」という仕様を選択したことには明確な理由があります。レシートからデータを抽出することで、後から振り返ったときに「この金額だったな」「これを頼んだな」という具体的なメニューと体験の記憶を鮮明に思い出すことができると考えたためです。また、これからのプロダクト開発において「AIを機能として組み込むこと」が開発プロセスやUIにどのような影響を与えるのか、自分自身で直接技術的な実験をしてみたいという目的もありました。
主要な機能はすべて本番環境のコードとして実装され、実際に稼働しています。GPT-4 Visionを活用し、撮影されたレシート写真から店名・品目・金額・日付を自動抽出して支出履歴に反映します。多通貨の変換ロジックについては、外部APIから1日1回為替レートを自動取得して最新のレートで換算する仕組みを構築しました。そのほか、フォローしている友人の訪問先がマップ上へ自動的に表示されるフィード型システムや、今後の機能拡張を見据えたMixpanelのイベントログの仕込みまでをアプリ内に実装しています（現在は初期フェーズのため、本格的なデータ分析の運用は今後の課題です）。
開発中の方向転換（ピボット）：構築過程で見出された3つの意思決定
開発期間において、実際にプロトタイプを作成し検証する中で3回の方向転換を行いました。
1. B2B中心からコンシューマー（B2C）中心への転換
最初は店舗オーナー向けの管理ダッシュボード（Next.jsで実装し、サーバー上で実際に動く状態まで開発済み）を先行して構想していました。しかし、ユーザーが存在しない段階でオーナー側の登録動機が生まれないという問題に直面しました。マーケットプレイスの順序としてユーザー側の需要確立が先決であると判断し、開発の軸をコンシューマー向けアプリへ変更。このモバイルアプリと管理ダッシュボードは、同一のデータベースを完全に共有し、裏側でデータが連動するアーキテクチャとして構築されています。ダッシュボードは、今後のユーザー基盤が整った段階でいつでも展開できるよう保持しています。
2. オーナー登録型からユーザー参加（UGC）型への転換
初期設計では、オーナーが登録した店舗のみをマップに表示する仕様でした。しかし、友人等から「自分の好きな店舗を追加したい」という要望を受け、誰もが店舗を追加できるUGC（ユーザー生成コンテンツ）の仕組みに切り替えました。同時に品質維持のため、「特定の店舗に20人のユニークユーザーから訪問記録が集まった段階で、データベース側で自動的にステータスが切り替わり全体公開される承認ロジック」を実装しています（現在は初期フェーズのため、この基準に到達するユーザー層の獲得がこれからの課題です）。
3. カフェ専門から全飲食店カテゴリへの拡張
発案時はカフェ専用アプリとしてコンセプトを絞っていましたが、検証を進める中で、ユーザーが価値を感じている要素は「カテゴリ」ではなく、「どこで食事をし、いくら使ったかを管理できる体験」であると特定しました。データベース構造は当初から汎用的に設計していたため、大きな移行コストをかけることなく、レストランやバーなど、すべての飲食店カテゴリへと対象範囲を広げました。
デザイン判断とユーザー心理に基づくインターフェースの改善
開発中のTestFlight版を、私の弟や友人などの初期テスターに触ってもらい、彼らの実際の操作や反応から得られたフィードバックを基にUI/UXの改修を行いました。
- レシートスキャンUIの配置：当初は「AIスキャン」と「ギャラリーから選択」を1つのボックス内にまとめていましたが、テスターから「ギャラリーからのアップロード手順が分からない」という反応がありました。要素を縦に並べるとフォームが長くなるため、カメラ起動とギャラリー選択を横並びの等価な選択肢として整理し、迷いのない選択を可能にしました。
- オンボーディングフローの再設計：初期フローではアカウント登録を必須としていましたが、価値を体験する前の離脱リスクが高いと考えました。「ゲストモード」の分岐を追加し、10秒以内にマップへ到達できる動線を確保。まず体験してもらい、その後に登録へ進む流れに改善しました。
- 支出データの心理的リフレーミング：履歴画面に累計支出額を常時表示していた際、テスターから「金額が増えていくのを見ると少し罪悪感がある」というフィードバックを得ました。そこで、支出額の表示切り替え機能を追加。「何店舗訪れたか」という訪問回数を同等のウェイトで表示できるようにし、同じデータを「コスト」ではなく「達成の積み重ね」として知覚できるよう調整しました。
- マイルストーン演出の実装：訪問回数の可視化に加え、10・25・50・100件といった節目に到達した瞬間に、紙吹雪効果とハプティクス（触覚フィードバック）を組み合わせた全画面の演出を実装し、継続的な記録に対する動機付けを行いました。
検証と開発手法：コードを書かない「AIとのペアプログラミング」による実装
12ヶ月の開発において、私の開発手法は従来の「自分でコードを書く」アプローチから、AIに実装を委ねる形へと完全にシフトしました。初期の短期間のみ、React Nativeの構造やパターンを学習するために自身で手を入れてコードを記述しましたが、それ以降はFigmaで作成したデザインやコンセプトを基に、アーキテクチャの設計段階からAI（Claude）に相談しながら構築を進めました。
UIの微調整や配置、ロジックの実装についても、自分で直接手を動かしてコードを書くのではなく、「ここの余白をもう少し広げて」「この要素を右に寄せて」といった自然言語のプロンプトによる指示を出し、AIに直接コードを生成・修正させる手法を採りました。これにより、一人では膨大な時間を要する実装作業を大幅に圧縮。プロダクト全体の体験設計と、AIをコントロールするディレクションに注力しながら、App Storeでの本番リリースまで完走することができました。
振り返りと展望：実行力と今後の仮説検証
この個人開発プロジェクトを通じて、価値を感じる前に手続きを求めない設計や、適切な開発順序、AIをコントロールして実装させる現代的な開発ディレクションなど、プロダクトを市場へ送り出すための多くの教訓を得ました。組織看板のない環境で、一人のデザイナーとしてどこまでプロダクトの裏側までをコントロールできるかという挑戦は、開発の解像度を大きく引き上げる経験となりました。
現在はリリース後の初期フェーズとして、「訪問を記録すること自体に定着価値があれば、ユーザーは能動的に戻ってくるか」という継続率（Week 1 → Week 4 Retention）を追跡・検証しています。もし記録のみで再訪動機が不足する場合は、次の施策として、フォローしている友人の訪問先をマップ上で可視化するソーシャル機能を強化していく計画です。この一連のプロダクト思考と実装ディレクションの経験を、チームでの開発業務にも還元していきます。