ID:85232さん

# ＃プロジェクト経験概要 個人開発として、ユーザーが見た夢を記録・管理し、AIを利用して内容を分析できるiOSアプリ「Dream Lucid Now」を企画・設計・開発し、App Storeへリリースしました。 このプロジェクトでは、これまでの個人開発とは異なり、**Subscriptionを利用したPremiumアプリの開発**を一つの技術テーマとしました。 RevenueCatを導入し、App Store Subscriptionの購入・復元・Premium状態管理を実装しました。Premium機能についてはClient側の表示制御だけに依存せず、Firebase Cloud FunctionsからRevenueCat APIを利用してSubscription状態を確認し、有効なPremiumユーザーだけがAI分析を利用できるBackend構成としました。 AI機能にはGoogle CloudのVertex AI / Geminiを利用しました。ユーザーが入力した夢の内容をBackendからGeminiへ送り、自然言語の文章をそのまま表示するだけではなく、AIから返される結果をアプリ内で扱いやすい構造化データとして受け取り、型安全なModelへ変換する仕組みを実装しました。 Firebase Cloud FunctionsをAI APIとの中間Backendとして利用し、Vertex AIへのアクセスをアプリから直接行わない構成にしました。またFirebase App Checkを導入し、正規のアプリから送信されたRequestのみBackendで処理するようにしました。 ユーザー認証にはSign in with Appleを実装し、ユーザーごとに夢の記録やPremium状態を管理しました。 さらに本プロジェクトでは、単発のアプリとして開発するだけでなく、**今後の個人アプリをより高速かつ安全に開発するための共通Template**としてArchitectureを設計しました。 Claude Code向けのArchitecture DocumentationやSkillsを整備し、Authentication、Subscription、Backend連携、共通UI Componentなど、他のアプリでも再利用できる構成へ整理しました。 機能だけではなくUI / UXにも重点を置き、夢・睡眠というテーマに合わせたVisual DesignやAnimation、画面遷移を作り込み、App Storeの商品ページについてもScreenshotや説明を含めてプロダクト全体の見せ方を意識して制作しました。 # ＃チーム情報 ・個人開発：1名 ・企画、Architecture設計、UI / UX、実装、テスト、App Storeリリースまで一人で担当 ・Flutterによるアプリ開発 ・Firebase Authentication ・Sign in with Apple ・Firebase Cloud Functions ・Firebase App Check ・RevenueCatによるSubscription管理 ・Vertex AI / GeminiによるAI分析 ・AI Responseの構造化・型安全なParsing ・Unit Test / Widget Test等の自動テスト ・Claude Codeを活用したAI-Assisted Development ・再利用可能なApp Architecture / Component設計 ・App Store商品ページの制作・改善 単にDream Lucid Nowを完成させるだけではなく、今後の個人開発でも利用できる基盤を構築することを目的の一つとしました。 # ＃開発・実装内容A ## 【概要】 RevenueCatを利用したSubscription / Premium機能の開発 ## 【どのような機能の開発・実装か】 このプロジェクトでは初めて本格的にSubscription型のPremiumアプリを開発しました。 RevenueCatを利用してApp Store Subscriptionを管理し、 ・Premium Planの購入 ・購入状態の復元 ・Subscription状態の取得 ・Premium / Freeによる機能制御 を実装しました。 AIによる夢分析についてはPremiumユーザー向け機能としました。 ## 【課題・問題点】 Subscriptionは単純な「購入済み / 未購入」のBooleanではなく、 ・新規購入 ・更新 ・解約 ・期限切れ ・購入復元 ・別端末でのログイン ・App Store上の状態変更 など、複数の状態を考慮する必要があります。 また、Client側だけでPremium判定を行うと改ざんされる可能性があり、有料のAI APIを不正に利用されるリスクもありました。 ## 【打ち手・使用した技術】 ・RevenueCat SDKをFlutterへ導入 ・App Store Subscriptionとの連携 ・Entitlementを利用したPremium状態管理 ・購入 / 復元Flowを実装 ・RevenueCat上のSubscription状態とアプリUIを連携 ・AI Request時にはCloud Functions側でもRevenueCat APIからPremium状態を確認 ・Client側だけの判定に依存しないBackend Authorizationを実装 ## 【成果】 初めてSubscription型アプリを0から設計・実装し、購入・復元・Premium状態管理まで一連の課金Flowを構築しました。 また、有料機能へのアクセス判定をBackendでも行うことで、UIを隠すだけの実装ではなく、実際のAPI利用までPremium状態によって制御できる構成にしました。 # ＃開発・実装内容B ## 【概要】 Vertex AI / Geminiを利用した夢分析機能の開発 ## 【どのような機能の開発・実装か】 ユーザーが記録した夢の内容をAIへ送り、その夢について分析した結果をアプリ上で確認できる機能を開発しました。 Google CloudのVertex AI経由でGeminiを利用し、夢の文章からアプリで利用する分析結果を生成しました。 単純にAIから返されたTextをそのまま画面へ表示するのではなく、アプリ側で扱いやすい構造へ変換して利用しています。 ## 【課題・問題点】 LLMの出力は通常のREST API Responseとは異なり、常に完全に同じ形式で返されるとは限りません。 アプリでは分析結果の各項目をそれぞれ別のUI Componentとして表示したかったため、AIのResponseをそのままStringとして利用するのではなく、一定のData Structureとして扱う必要がありました。 また、想定外のResponseが返った場合でもアプリがCrashしないようにする必要がありました。 ## 【打ち手・使用した技術】 ・Vertex AI / Geminiを利用したAI分析 ・Firebase Cloud FunctionsからAI Endpointを呼び出す構成を設計 ・Prompt上で期待するResponse Structureを明確化 ・AI Responseをアプリ用のData Modelへ変換 ・Parsing時のValidationを実装 ・不足項目・不正なResponseに対するFallback処理を実装 ・AI Responseを型付きModelとしてUIへ渡す構成を採用 ・AI呼び出し部分とUI / Business Logicを分離 ## 【成果】 LLMを単純なChat機能として組み込むだけではなく、**AIを既存の型付きApplication Architectureの一部として扱う方法**を実践しました。 これにより、AI出力を複数のUI Componentで安全に利用でき、今後PromptやModelを変更してもアプリ全体への影響を限定できる構成にしました。 # ＃開発・実装内容C ## 【概要】 Firebase Cloud Functions / App Checkを利用した安全なAI Backendの構築 ## 【どのような機能の開発・実装か】 Vertex AIへのRequestをFlutterアプリから直接送信するのではなく、Firebase Cloud FunctionsをBackendとして利用しました。 アプリからCloud Functionsへ夢のデータを送信し、Backend側で、 1. Requestの検証 2. ユーザー状態の確認 3. Premium状態の確認 4. GeminiへのRequest 5. Responseの加工 6. Clientへの返却 を行うFlowを構築しました。 ## 【課題・問題点】 AI APIをClientから直接利用すると、 ・API利用を不正に実行される可能性がある ・PromptやBackend LogicがClientへ露出する ・Premiumでないユーザーでも直接Endpointを呼べる可能性がある ・AI利用料金が発生するAPIを第三者に悪用される可能性がある という問題があります。 ## 【打ち手・使用した技術】 ・Firebase Cloud FunctionsをBackendとして利用 ・AI APIへのアクセスをServer Sideへ限定 ・Firebase App Checkを導入 ・正規アプリからのRequestかをBackend側で確認 ・Authenticated Userの情報を確認 ・RevenueCat APIからPremium状態をServer Sideで確認 ・Premium UserのみVertex AIを呼び出せるFlowを構築 ・Client側へSecretやAI API Access情報を持たせない構成を採用 ## 【成果】 Authentication、App Check、RevenueCat、Cloud Functions、Vertex AIを組み合わせ、AI APIを直接Clientへ公開しない安全なArchitectureを構築しました。 特にAI利用にはAPI Costが発生するため、Premium判定をServer Sideで行うことで、不正利用によるコスト増加を抑えられる構成にしました。 # ＃開発・実装内容D ## 【概要】 Sign in with Appleを利用したユーザー認証 ## 【どのような機能の開発・実装か】 ユーザーごとに夢の履歴やPremium状態を管理するため、Sign in with Appleを利用したAuthenticationを実装しました。 Firebase Authenticationと連携し、Apple Accountを使って簡単にアカウントを作成・ログインできるようにしました。 ## 【課題・問題点】 ユーザーが夢という個人的な内容を記録するアプリのため、できるだけ簡単で信頼できるAuthentication Flowが必要でした。 また、Authentication状態をSubscriptionやBackend API Accessとも連携する必要がありました。 ## 【打ち手・使用した技術】 ・Sign in with Appleを実装 ・Firebase Authenticationとの連携 ・Authentication状態をアプリ全体で管理 ・User IDを夢データと関連付け ・Cloud Functions側でもAuthenticated Userを確認 ・User / Subscription / AI Requestを同じAccount単位で管理 ## 【成果】 ユーザーが複雑なPasswordを新しく作る必要なくApple Accountから利用開始できるAuthentication Flowを構築しました。 また、AuthenticationをPremium状態やAI Backendと統合することで、User単位で安全に機能を提供できる構成にしました。 # ＃開発・実装内容E ## 【概要】 夢の記録・管理・AI分析を一つの体験として設計 ## 【どのような機能の開発・実装か】 ユーザーが起床後に夢の内容を記録し、後から履歴として見返したり、必要に応じてAI分析を実行できる機能を実装しました。 AI機能だけを独立させるのではなく、 **夢を記録する → 保存する → 振り返る → AIで分析する** という一連のUser Flowとして設計しました。 ## 【課題・問題点】 夢は起床後すぐに忘れてしまいやすいため、記録時に複雑な入力を要求すると利用しづらくなります。 一方で、記録した内容を後から振り返る際には、情報が整理されている必要があります。 ## 【打ち手・使用した技術】 ・入力までの操作Stepをできるだけ少なく設計 ・Dream Entryを再利用可能なModelとして設計 ・Dream DetailとAI分析結果を連携 ・過去のDreamを見返しやすいUIを設計 ・AI分析を既存Dream Dataへ紐付ける構成にした ・Loading / Error / Premium制限時の状態も含めてUXを設計 ## 【成果】 AI機能単体のDemoではなく、夢を継続的に記録・保存・振り返り、その延長としてAI分析を利用できる一つのプロダクトとして完成させました。 # ＃開発・実装内容F ## 【概要】 Unit / Widget Testを中心とした品質担保 ## 【どのような機能の開発・実装か】 個人開発でも変更を安全に行えるよう、Subscription Logic、AI Response Parsing、状態管理、UIなどについて自動テストを作成しました。 特にSubscriptionやAI Responseは外部サービスに依存するため、実サービスへ毎回アクセスしなくても各状態を再現できるように設計しました。 ## 【課題・問題点】 SubscriptionやAI APIでは、 ・Premium ・Free ・Expired ・API Error ・不正Response ・Loading ・Authenticationなし など多くの状態が存在します。 これらを手動だけで確認すると、機能追加時のRegressionを見逃しやすくなります。 ## 【打ち手・使用した技術】 ・Business LogicのUnit Testを実装 ・AI Response Parserの正常系 / 異常系Testを作成 ・Subscription状態ごとのTest Caseを作成 ・Widget TestでUI Stateを検証 ・外部Serviceを抽象化してMock可能なArchitectureを採用 ・新機能追加時に既存TestをRegression Testとして利用 ## 【成果】 Subscription、AI、Authenticationなど状態分岐の多いアプリでも、自動テストによって主要なケースを継続的に確認できる開発環境を構築しました。 また、このTestable Architecture自体を今後のアプリでも再利用できる形へ整理しました。 # ＃開発・実装内容G ## 【概要】 Claude Codeを活用した再利用可能なAI-Assisted Development基盤の構築 ## 【どのような機能の開発・実装か】 Dream Lucid Nowでは、アプリそのものだけでなく、**今後のFlutterアプリをより短期間で開発するためのTemplate Project**としてArchitectureを整理しました。 Claude Codeがプロジェクトの設計思想やルールを理解した状態で実装できるよう、Architecture Documentationや開発ルールを整備しました。 また、繰り返し利用する処理についてはReusable Component / Logicとして切り出しました。 例： ・Authentication ・Subscription ・Premium判定 ・Backend Communication ・Error Handling ・Loading State ・共通UI Component ・Testing Pattern ## 【課題・問題点】 個人アプリを複数開発していると、AuthenticationやSubscriptionなど同じ機能を毎回0から実装することになり、開発時間だけでなく同じ種類のBugを再び発生させる可能性があります。 また、AI Coding Agentへ毎回Architectureを説明すると、Projectごとに実装方針が変わる問題もありました。 ## 【打ち手・使用した技術】 ・Architecture Documentationを整備 ・Claude Codeが参照できる開発ルールを作成 ・Skills / Instructionsとして頻出作業を整理 ・Subscriptionなど共通LogicをReusable Module化 ・共通UI Componentを作成 ・Application Layer / Infrastructure Layerなどの責務を明確化 ・Test Patternも含めてTemplate化 ・新規Appでも同じ設計を再利用できる構成を目指した ## 【成果】 Dream Lucid Nowを一つのアプリとして完成させるだけでなく、**次のアプリをより速く・同じ品質基準で作るための開発基盤**として活用できるようにしました。 SubscriptionやAuthenticationなど、Bugが発生しやすく実装コストも高い機能を再利用することで、新しいアプリごとに同じ問題を解決し直す必要を減らしました。 また、ArchitectureやCoding RuleをClaude Codeへ明示的に与えることで、AIを単なるCode Generatorではなく、既存Architectureに沿って実装を進めるDevelopment Toolとして利用しています。 # ＃開発・実装内容H ## 【概要】 UI / UX・Visual Design・App Store Presentationの改善 ## 【どのような機能の開発・実装か】 過去の個人開発では機能実装や技術検証を優先することが多かったため、Dream Lucid Nowでは**機能だけでなく完成したプロダクトとしての品質**を意識しました。 夢・睡眠というテーマに合わせてVisual Designを作り込み、Animation、Spacing、Typography、画面遷移、Premium導線などを含めてUI / UXを設計しました。 また、App Storeでユーザーが最初に目にするScreenshotや商品ページについても、アプリの価値が伝わるように制作しました。 ## 【課題・問題点】 機能が優れていても、App Store上でユーザーが価値を理解できなければDownloadやSubscriptionにはつながりません。 また、PremiumアプリではPaywallもUser Experienceの一部であり、機能を制限するだけではなく、なぜPremiumにする価値があるかを分かりやすく伝える必要があります。 ## 【打ち手・使用した技術】 ・Dream / Sleepのテーマに合わせたVisual Design ・Animationを利用したInteraction改善 ・共通Design Componentを作成 ・画面ごとのSpacing / Typographyを統一 ・Premium機能が理解しやすいPaywallを設計 ・App Store Screenshotをプロダクトの一部として制作 ・Store Listingの説明・見せ方も含めて改善 ## 【成果】 機能だけを完成させるのではなく、UI / UX、Premium Flow、App Store Presentationまで含めて、一つのConsumer Productとして完成度を高めました。 また、ここで作成したDesign Componentについても、今後の個人アプリで再利用できる形へ整理しています。 # ＃主な成果まとめ ・夢の記録・管理・AI分析を行うConsumer Appを個人で0→1開発 ・RevenueCatを初導入し、**Subscription / Premium Architecture**を構築 ・ClientだけでなくCloud Functions側でもRevenueCat APIを利用してPremium状態を検証 ・Vertex AI / Geminiを利用したAI分析機能を開発 ・AI Responseを型付きData Modelとして扱えるParsing Layerを構築 ・Firebase Cloud Functionsを利用してAI APIをClientから分離 ・Firebase App CheckによるBackend保護を実装 ・Sign in with Apple / Firebase Authenticationを実装 ・Subscription / Authentication / AIを連携したBackend Architectureを構築 ・主要なBusiness Logic / UIに自動テストを導入 ・Claude Code向けArchitecture Documentation / Skillsを整備 ・Subscription、Authentication、Backend連携、UI Componentなどを再利用可能な形へTemplate化 ・AI-Assisted Developmentを利用して今後のアプリ開発速度を上げられる基盤を構築 ・過去の技術検証中心の個人開発から発展し、UI / UX・Visual Designにも重点を置いて制作 ・App Store Screenshot / Product Pageまで含めてプロダクトとしての完成度を意識してリリース **公開URL（App Store）** https://apps.apple.com/jp/app/dream-lucid-now-dreams-sleep/id6752128546

# ＃プロジェクト経験概要 個人開発として、日本語文法を効率よく学習するためのiOSアプリ「Japanana - Japanese Grammar」を企画・設計・開発し、App Storeへリリースしました。 自身が日本語を勉強する中で、教科書から学んだ文法をMarkdown形式のノートとして整理していましたが、復習や反復学習をより効率的に行いたいと考え、この既存ノートをそのままアプリの学習データとして活用できる仕組みを開発しました。 Markdownで書かれた文法ノートを独自Parserによって構造化データへ変換し、文法説明・例文・レベル・カテゴリなどをアプリ上で表示できる構成としました。 このプロジェクトでは、機能開発だけでなく新しいFlutter開発手法を実践することも目的としており、初めてRiverpodを状態管理に採用しました。さらにGoRouter、Patrolなど、それまで業務では十分に利用していなかったPackageを積極的に導入しました。 特に品質面ではTDDを意識し、Markdown Parserなどのロジックについて**Testを先に作成してから実装**する開発を行いました。Unit Test、Widget Test、E2E Testを組み合わせ、主要なアプリ機能を自動テストでカバーしています。 収益モデルについても実験的な取り組みとして、Subscriptionではなく**買い切り型の有料アプリ**として公開しました。一般的な語学学習アプリでSubscriptionが多い中、初回購入のみというモデルを試し、自分を除いて**7名のユーザーが実際に有料購入**しました。 現在も自身の日本語学習と並行して開発を継続しており、新しく学習した文法コンテンツの追加に加えて、当初は機能性を優先していたUIについて、より使いやすくモダンなUXへ改善しています。 App Storeでは現在、iPhone / iPad / Mac向けに公開されています。 :chatgpt-content-reference{index="0"} # ＃チーム情報 ・個人開発：1名 ・企画、設計、実装、テスト、App Storeリリースまで一人で担当 ・Flutterによるアプリ開発 ・Riverpodによる状態管理 ・GoRouterによるNavigation ・PatrolによるE2E Test ・Unit Test / Widget Test / E2E Test ・TDDによる開発 ・Markdown Parserの設計・実装 ・App Storeへの有料アプリ公開 ・継続的なコンテンツ追加・UI / UX改善 自身が実際に日本語学習者として感じていた課題を起点に、学習方法そのものをアプリとしてプロダクト化しました。 # ＃開発・実装内容A ## 【概要】 Markdown形式の学習ノートをアプリデータへ変換する独自Parserの開発 ## 【どのような機能の開発・実装か】 教科書で日本語を学習する際に作成していたMarkdown形式の文法ノートを、そのままJapananaの学習コンテンツとして利用できる仕組みを実装しました。 Markdown内に一定のルールで文法名、説明、例文、カテゴリ、レベルなどを記述し、それを独自Parserで読み取ってアプリ内のData Modelへ変換します。 これにより、新しく文法を学習した際にはMarkdownへノートを追加するだけで、その内容をアプリでも利用できる構成にしました。 ## 【課題・問題点】 手作業でアプリ内のデータへ文法を登録すると、 ・Markdownノートとアプリデータを二重管理する必要がある ・新しい文法を追加するたびにコードを編集する必要がある ・フォーマットミスによってデータが壊れる可能性がある ・学習コンテンツが増えるほど管理コストが高くなる という問題がありました。 また、Markdownには複数の構造や例外パターンが存在するため、単純な文字列分割だけでは安定して変換できませんでした。 ## 【打ち手・使用した技術】 ・Markdownノート用の独自フォーマットを定義 ・Markdownから文法情報を抽出するParserを実装 ・文法情報をアプリ内の統一Data Modelへ変換 ・異常な入力や不足項目を検出するValidationを実装 ・Parserの実装前にTest Caseを作成 ・正常系だけでなく異常系・Edge CaseもUnit Testで検証 ・新しい文法をMarkdownへ追加するだけでコンテンツを拡張できる構成を設計 ## 【成果】 自分の学習ノートとアプリコンテンツを別々に管理する必要をなくし、**日本語学習そのものがアプリのコンテンツ追加につながる仕組み**を構築しました。 現在も日本語学習を続けながら、新しく学んだ文法をMarkdownへ追加し、アプリの学習コンテンツとして継続的に拡張しています。 # ＃開発・実装内容B ## 【概要】 TDDを取り入れたMarkdown Parser開発 ## 【どのような機能の開発・実装か】 このプロジェクトでは、新しい開発手法を試す目的もあり、特にMarkdown ParserなどのロジックについてTDDを実践しました。 最初に期待する入力・出力をTestとして定義し、そのTestを通すためのParser実装を行う流れで開発しました。 ## 【課題・問題点】 Markdown ParserはInput Patternが増えるにつれて条件分岐が複雑になり、一つのパターンへの修正によって既存の別パターンが壊れる可能性がありました。 また、学習コンテンツは今後も増え続けるため、Parser変更時のRegressionを早期に検知できる仕組みが必要でした。 ## 【打ち手・使用した技術】 ・実装前にTest Caseを作成 ・Red → Green → Refactorを意識してParserを開発 ・正常なMarkdownだけでなく不正フォーマットもTest ・Edge Caseを発見するたびにRegression Testを追加 ・Parser LogicとUIを分離してTestしやすい構成に設計 ## 【成果】 Parserの仕様をTestとして明確化でき、新しいMarkdown Patternを追加する際にも既存のParsing Logicを壊していないことを自動で確認できるようになりました。 また、TDDを個人プロジェクトで実践することで、Testを後から追加するのではなく、**Testabilityを考慮して設計する開発スタイル**を習得しました。 # ＃開発・実装内容C ## 【概要】 Riverpodを利用した状態管理Architectureへの挑戦 ## 【どのような機能の開発・実装か】 このアプリでは、新しいFlutter Architectureを学ぶ目的で、状態管理にRiverpodを初めて本格導入しました。 学習コンテンツ、学習状態、ユーザー設定、Navigationなどの状態をUIから分離し、Providerを通して管理しました。 ## 【課題・問題点】 それまで利用していた状態管理方法とは異なる考え方を学ぶ必要がありました。 特に、状態をどの単位でProviderへ分割するか、Business LogicをUIからどこまで分離するか、Test可能な構造をどう作るかを試行錯誤しました。 ## 【打ち手・使用した技術】 ・Riverpodによる状態管理 ・UIとBusiness Logicの分離 ・Provider単位で依存関係を整理 ・Test時にProviderを差し替えられる構成を活用 ・状態管理ロジックをUnit Testから直接検証 ・GoRouterと組み合わせたNavigation設計 ## 【成果】 RiverpodのDependency InjectionやProvider Overrideを利用することで、外部状態に依存する機能でもTestしやすいArchitectureを構築できました。 このプロジェクトを通じて、単にRiverpodのAPIを使うだけではなく、**Testabilityを前提としたFlutter Architecture**について実践的に学びました。 # ＃開発・実装内容D ## 【概要】 Unit / Widget / E2Eによる自動テスト環境の構築 ## 【どのような機能の開発・実装か】 アプリ全体の品質を担保しながら、新しいPackageやArchitectureを試せる環境にするため、自動テストを積極的に導入しました。 Unit Test、Widget Test、Patrolを利用したE2E Testを組み合わせ、主要なUser FlowとBusiness Logicを自動的に検証できる構成にしました。 ## 【課題・問題点】 Unit TestだけではParserやBusiness Logicは確認できても、実際の画面操作やNavigationを含むユーザー体験までは検証できません。 一方ですべてをE2E TestにするとTest実行が重くなるため、Testの目的に応じた使い分けが必要でした。 ## 【打ち手・使用した技術】 ・Pure LogicにはUnit Testを実装 ・Riverpod Providerの状態変化をUnit Testで検証 ・UI ComponentにはWidget Testを実装 ・画面遷移や実際のUser FlowにはPatrolによるE2E Testを実装 ・Test対象に応じてUnit / Widget / E2Eを使い分け ・新しい機能追加時にも既存機能のRegressionを確認できる構成を構築 ## 【成果】 主要機能についてUnit Test、Widget Test、E2E Testを揃え、**アプリの主要なロジック・画面・ユーザーフローを自動テストでカバー**しました。 これにより、現在進めているUI / UXの大幅な改善でも、既存機能を壊していないことを確認しながら変更できる開発環境を構築しました。 # ＃開発・実装内容E ## 【概要】 GoRouterを利用したNavigation設計 ## 【どのような機能の開発・実装か】 FlutterのNavigationについても新しいアプローチを試すため、GoRouterを採用しました。 文法一覧、文法詳細、学習画面、設定などのRoutingを一元管理し、UIからNavigation Logicを分離しました。 ## 【課題・問題点】 画面数が増えるにつれて、各Widgetから直接Navigationを記述すると遷移関係が把握しにくくなり、Testもしづらくなります。 また、将来的なDeep Linkや機能追加にも対応しやすい構造にしておく必要がありました。 ## 【打ち手・使用した技術】 ・GoRouterを利用したDeclarative Routing ・Route定義の一元管理 ・Navigation LogicとUIの分離 ・Route Parameterを利用した文法詳細画面への遷移 ・Widget / E2E TestからNavigationを検証できる構成を設計 ## 【成果】 画面遷移を一元管理することで、機能追加時にもNavigation Structureを把握しやすく、Testしやすい構成にしました。 Riverpod、GoRouter、Patrolを組み合わせることで、新しいFlutter ArchitectureやPackageを実際のプロダクト上で検証できました。 # ＃開発・実装内容F ## 【概要】 買い切り型有料アプリとしての収益モデル検証 ## 【どのような機能の開発・実装か】 近年の語学学習サービスでは月額Subscriptionモデルが多い中、Japananaでは実験的に**初回購入のみの買い切り型アプリ**としてApp Storeへ公開しました。 現在もApp Storeでは有料アプリとして配信しています。 :chatgpt-content-reference{index="1"} ## 【課題・問題点】 Subscriptionではなく、ダウンロード前に料金を支払うモデルでは、ユーザーがアプリを試す前に購入判断をする必要があります。 個人開発のため大規模な広告やマーケティングも行っておらず、有料アプリとして実際に購入されるかは未知数でした。 ## 【打ち手・使用した技術】 ・Subscriptionを導入せず買い切りモデルを採用 ・App Store上で有料アプリとして公開 ・機能をSubscription Tierに分割せず、購入後はすべて利用可能な構成にした ・個人プロジェクトとして収益モデル自体もExperimentとして検証 ## 【成果】 開発者本人を除いて、**7名のユーザーが実際に有料でアプリを購入**しました。 大規模なユーザー数ではありませんが、Subscriptionに依存しない買い切り型の個人アプリでも、実際に料金を支払って利用するユーザーを獲得できました。 # ＃開発・実装内容G ## 【概要】 継続的なコンテンツ追加・UI / UX改善 ## 【どのような機能の開発・実装か】 Japananaはリリースして終了したプロジェクトではなく、自分自身の日本語学習と並行して現在も開発を続けています。 新しい日本語文法を学ぶたびにMarkdownノートへ追加し、その内容をアプリへ反映しています。 初期バージョンではまず学習機能やArchitectureの構築を優先しましたが、現在はより使いたくなるアプリを目指し、UI / UXやVisual Designの改善にも取り組んでいます。 ## 【課題・問題点】 初期開発では機能性と技術検証を優先したため、プロダクトとして見た場合にはUIや操作体験をさらに改善できる余地がありました。 また、自分自身が継続的に利用することで、開発時には気づかなかった使いづらさも見つかりました。 ## 【打ち手・使用した技術】 ・自身が実ユーザーとして継続的にアプリを利用 ・新しく学んだ文法を継続的に追加 ・実際の利用から発見したUX課題を改善 ・既存Test Suiteを活用し、機能を壊さずUIをRefactor ・AnimationやVisual Designを含めたUI改善を継続 ## 【成果】 一度リリースして終了するのではなく、**自身の日本語学習とプロダクト開発を連動させながら継続的に改善する個人プロダクト**として運用しています。 Test Coverageを整備していることで、現在行っているUI / UXの大規模な改善についても、既存機能のRegressionを確認しながら安全に進められています。 # ＃主な成果まとめ ・自身の日本語学習上の課題から0→1でプロダクトを企画・開発 ・Markdown学習ノートをアプリデータへ変換する独自Parserを開発 ・Parserを中心に**TDDで実装** ・Riverpodを初採用し、Testabilityを重視したArchitectureを構築 ・GoRouterによるNavigation設計 ・Patrolを利用したE2E Testを導入 ・Unit Test / Widget Test / E2E Testで主要機能・User Flowを自動検証 ・Subscriptionではなく買い切り型の有料アプリとしてリリース ・開発者本人を除き**7名が有料購入** ・iPhone / iPad / Mac向けにApp Storeで公開 :chatgpt-content-reference{index="2"} ・現在も日本語学習と並行してコンテンツ追加・UI / UX改善を継続中 **公開URL（App Store）** [Japanana - Japanese Grammar（App Store）](https://apps.apple.com/jp/app/japanana-japanese-grammar/id6476447175?utm_source=chatgpt.com) One small wording point: I would **not write 「100%テスト済み」** on 転職ドラフト unless you literally mean 100% code/branch coverage and can back it up with a coverage report. The stronger and safer wording is what I used above: **「主要なロジック・画面・ユーザーフローをUnit / Widget / E2E Testでカバー」**. That still sounds excellent and is much harder for an interviewer to challenge.

# プロジェクト名 **AirPodsを活用した腕立て伏せトラッキングアプリ「Pushup Bro」の個人開発** # ＃プロジェクト経験概要 個人開発として、AirPodsのモーション情報を活用して腕立て伏せの回数を自動計測するiOSアプリ「Pushup Bro」を企画・設計・開発し、App Storeへリリースしました。 対応するAirPodsを装着した状態で腕立て伏せを行うと、センサーから取得したモーション情報をもとに上下運動を判定し、ユーザーがスマートフォンを操作することなく回数を記録できるアプリです。 計測結果はアプリ内に保存され、カレンダーから過去のトレーニング履歴を確認できるようにしました。また、単純な回数カウンターではなく継続して利用したくなる体験を目指し、キャラクターを利用したUIや、ユーザーに合わせて調整できる設定機能も実装しました。 海外ユーザーにも利用してもらえるよう、日本語・英語・ドイツ語・スペイン語・ポルトガル語の5言語に対応しました。 企画、技術検証、UI / UX設計、実装、テスト、多言語対応、App Store申請・リリースまで一人で担当し、公開後は**累計約300ダウンロード**を獲得しました。 # ＃チーム情報 ・個人開発：1名 ・企画からApp Storeリリースまで一人で担当 ・iOSアプリの設計・実装 ・AirPodsのモーションセンサーを利用した動作検知 ・腕立て伏せ回数の判定ロジック ・トレーニング履歴管理 ・カレンダーUI ・キャラクターを利用したUI / UX設計 ・各種設定機能 ・5言語へのLocalization対応 ・App Store申請 / リリース / 継続アップデート プロダクトアイデアの検討から技術的な実現可能性の検証、実装、ストア公開まで、0→1のプロダクト開発をすべて一人で行いました。 # ＃開発・実装内容A ## 【概要】 AirPodsのモーション情報を利用した腕立て伏せ自動計測機能 ## 【どのような機能の開発・実装か】 対応するAirPodsを装着した状態でユーザーが腕立て伏せを行うと、AirPodsから取得したモーション情報をもとに上下運動を検知し、自動的に回数をカウントする機能を開発しました。 ユーザーがトレーニング中にスマートフォンへ触れる必要がなく、通常通り腕立て伏せを行うだけで回数を記録できる体験を目指しました。 ## 【課題・問題点】 AirPodsから取得できるセンサーデータには、「腕立て伏せをした」という直接的な情報は存在しないため、連続的に取得されるモーション値から実際の腕立て伏せ動作を判定する必要がありました。 また、ユーザーごとに動作速度や可動域が異なるため、単純に特定の値を超えた場合だけカウントすると、二重カウントやカウント漏れが発生する問題がありました。 ## 【打ち手・使用した技術】 ・AirPodsのモーションセンサーデータを取得 ・センサー値の変化から上下運動を判定 ・上下の一連の動作を1回として扱うCounting Logicを実装 ・連続入力による二重カウントを防止する状態管理を実装 ・実際に腕立て伏せを行いながら判定条件を繰り返し調整 ・異なる動作速度でもカウントできるよう判定ロジックを改善 ## 【成果】 AirPodsをセンサーデバイスとして利用することで、ユーザーがスマートフォンを手に持ったり画面を操作したりせずに、腕立て伏せの回数を自動記録できる体験を実現しました。 技術検証だけで終わらせず、実際のユーザーが利用できるプロダクトとしてApp Storeまでリリースしました。 # ＃開発・実装内容B ## 【概要】 トレーニング履歴・カレンダー機能の開発 ## 【どのような機能の開発・実装か】 自動計測した腕立て伏せの結果を保存し、過去のトレーニング履歴をカレンダー形式で確認できる機能を実装しました。 ユーザーが「いつ」「どの程度」トレーニングしたのかを後から振り返ることができるようにしました。 ## 【課題・問題点】 リアルタイムで回数を計測するだけでは、その場限りのカウンターとなってしまい、継続的なトレーニングをサポートすることができませんでした。 そのため、過去の運動状況を分かりやすく確認でき、ユーザー自身がトレーニングの継続状況を把握できる仕組みが必要でした。 ## 【打ち手・使用した技術】 ・トレーニング結果を端末内へ保存 ・日付と腕立て伏せ回数を紐付けて管理 ・カレンダー形式の履歴UIを実装 ・過去のトレーニング実績を日単位で確認できる構成を設計 ・計測結果と履歴画面の状態を連携 ## 【成果】 単発の腕立て伏せカウンターではなく、日々のトレーニング履歴を蓄積し、継続状況を振り返れるフィットネスアプリとして提供できるようにしました。 # ＃開発・実装内容C ## 【概要】 トレーニングを継続しやすくするUI / UX設計 ## 【どのような機能の開発・実装か】 単純に回数や数字だけを表示するアプリではなく、ユーザーが継続して利用したくなる体験を目指し、キャラクターを取り入れたUIを設計しました。 また、ユーザー自身のトレーニング方法に合わせて利用できるよう、各種設定機能も実装しました。 ## 【課題・問題点】 フィットネスアプリでは、計測精度だけでなく、運動中に操作が邪魔にならないことや、繰り返し使いたくなるUI / UXも重要でした。 個人開発のため、技術実装だけでなく、プロダクトのコンセプト、画面設計、キャラクター表現、操作導線まで自分で考える必要がありました。 ## 【打ち手・使用した技術】 ・キャラクターを利用したモチベーション設計 ・運動中に余計な操作を必要としないシンプルな計測フロー ・計測開始から結果確認までの操作ステップを簡略化 ・ユーザーごとに調整可能な設定機能を実装 ・機能性だけでなく「使い続けたくなること」を意識したUIを設計 ## 【成果】 単なるセンサー技術のデモではなく、実際のトレーニングで継続利用できる一つのプロダクトとして完成させました。 個人開発ながら、機能設計だけでなくプロダクトコンセプトやUI / UXまで一貫して作り込みました。 # ＃開発・実装内容D ## 【概要】 国際ユーザー向け5言語対応 ## 【どのような機能の開発・実装か】 日本だけでなく海外のユーザーにも利用してもらえるよう、アプリ全体を多言語化しました。 以下の5言語に対応しています。 ・日本語 ・英語 ・ドイツ語 ・スペイン語 ・ポルトガル語 ## 【課題・問題点】 言語ごとに文字列の長さや表現が異なるため、単純にテキストを翻訳するだけでは、ボタンや画面レイアウトが崩れる可能性がありました。 また、すべての画面でLocalization漏れが発生しないよう管理する必要がありました。 ## 【打ち手・使用した技術】 ・アプリ内文字列をLocalization対応 ・5言語分の翻訳データを管理 ・言語による文字列長の違いを考慮したレイアウト設計 ・各言語設定で実際に画面表示を確認 ・固定文字列をUIから分離し、多言語追加がしやすい構成に整理 ## 【成果】 日本国内だけに限定せず、5言語で利用できるアプリとしてApp Storeへ公開しました。 個人開発の段階から国際ユーザーを想定したプロダクト設計を行いました。 # ＃開発・実装内容E ## 【概要】 個人での0→1プロダクト開発・App Storeリリース ## 【どのような機能の開発・実装か】 「AirPodsのモーションセンサーを腕立て伏せの計測に利用できないか」というアイデアから、自分で技術検証を行い、一つのアプリとして設計・開発しました。 業務案件とは異なり、要件を与えられた状態から実装するのではなく、 ・どのような課題を解決するか ・どの機能を提供するか ・どのようなUXにするか ・どこまでを初期リリースに含めるか ・どのようにApp Storeへ公開するか まで自分で判断しました。 ## 【課題・問題点】 個人開発のため、エンジニアリングだけでなく企画、仕様決定、UI / UX、Localization、テスト、Store申請など、プロダクト公開に必要な作業を一人で行う必要がありました。 また、センサーを利用する特殊なアプリのため、実機で繰り返しテストしながら使いやすさや計測ロジックを改善する必要がありました。 ## 【打ち手・使用した技術】 ・プロダクト企画 ・AirPodsを利用した技術検証 ・アプリ全体のArchitecture設計 ・UI / UX設計 ・センサー処理・Counting Logicの実装 ・トレーニング履歴機能の実装 ・多言語化 ・実機テスト / デバッグ ・App Store Connectでの申請・公開 ・リリース後の改善・アップデート ## 【成果】 アイデア段階から一人で0→1のプロダクト開発を行い、一般ユーザーが実際に利用できるiOSアプリとしてApp Storeへ公開しました。 公開後は**累計約300ダウンロード**を獲得しました。 技術検証だけで終わらせず、企画・実装・UX・Localization・Storeリリースまで一連のプロダクト開発を経験しました。 # ＃主な成果まとめ ・AirPodsのモーションセンサーを利用した独自の腕立て伏せ自動計測機能を開発 ・企画、設計、UI / UX、実装、テスト、リリースまで**1人で担当** ・スマートフォンを操作せずに腕立て伏せを記録できる体験を実現 ・トレーニング履歴を確認できるカレンダー機能を実装 ・日本語 / 英語 / ドイツ語 / スペイン語 / ポルトガル語の**5言語に対応** ・一般ユーザー向けアプリとしてApp Storeへ公開 ・**累計約300ダウンロード**を獲得 ・個人でアイデアからリリースまで0→1のプロダクト開発を経験 公開URL（App Store） https://apps.apple.com/jp/app/pushup-bro/id1673181014

## ＃プロジェクト経験概要 ドイツの出版社が提供する、動画・音声・記事コンテンツを視聴・閲覧できるドキュメンタリーメディアアプリの保守・モダナイズを担当しました。 サービスとしてはNetflixのようにコンテンツを一覧・詳細画面から選択し、動画・音声・記事をアプリ内で閲覧できる構成でした。 僕はアプリのリリース後にプロジェクトへ参加しましたが、長期間アップデートされていなかったことから、依存ライブラリやOS対応が古くなっており、App Store / Google Playから最新API・OS要件への対応を求める警告も発生していました。 そのため、既存機能を維持しながら、古くなったライブラリの更新・置き換え、iOS / Android双方のビルド環境更新、最新OSへの対応、タブレットレイアウトの調整などを行い、今後も継続してアップデートできる状態へ改善しました。 iOSはUIKit + Storyboard、AndroidはXML View Systemを中心とした構成で、Android側は大部分がJavaで実装されていました。一部の既存コードについてはKotlinへ書き換えながら保守性を改善しました。 --- # ＃チーム情報 ・既存のiOS / Androidネイティブアプリの保守・アップデートを担当 ・iOS：UIKit / Storyboard ・Android：XML View System / Java / Kotlin ・動画 / 音声 / 記事など複数種類のメディアコンテンツを扱うアプリ ・スマートフォン / タブレット双方に対応 僕は主に以下の領域を担当しました。 ・古くなった依存ライブラリの調査・アップデート ・利用できなくなったライブラリの代替実装・置き換え ・最新iOS / AndroidおよびStore要件への対応 ・既存コードを壊さずに行う段階的なリファクタリング ・Javaコードの一部Kotlin化 ・スマートフォン / タブレット向けUIの調整 ・動画・音声などのメディア再生機能の保守 ・ビルドエラー、非推奨API、OSアップデートに起因する不具合への対応 --- # ＃開発・実装内容A ## 【概要】 App Store / Google Playの最新要件に対応するためのレガシーアプリのモダナイズ ## 【どのような機能の開発・実装か】 すでにリリース済みのiOS / Androidアプリに参加し、古くなったコードベース・依存ライブラリ・ビルド設定を更新しました。 アプリ自体は正常に運用されていましたが、長期間大きなアップデートが行われていなかったため、最新OSやStore要件との互換性に問題が出始めていました。 App Store / Google Playからも、新しいAPI LevelやOS要件に対応しない場合は今後アプリを公開し続けることが難しくなる旨の警告が出ていたため、既存機能を維持しながらアプリを最新環境へ移行しました。 ## 【課題・問題点】 単純に依存ライブラリのバージョンを上げるだけではなく、以下のような問題がありました。 ・すでにメンテナンスされていないライブラリが存在 ・新バージョンでAPI仕様が変更されたライブラリが存在 ・古いOS向けコードが最新SDKでは非推奨・利用不可になっている ・Storyboard / XML View Systemを中心とした大規模な既存UIを壊さずに更新する必要がある ・一度にすべてを書き直すことはできないため、既存仕様を維持しながら段階的に更新する必要がある ## 【打ち手・使用した技術】 ・既存依存ライブラリとビルド設定を調査 ・アップデート可能なライブラリについては最新版へ移行 ・メンテナンス終了・互換性のないライブラリは代替ライブラリや別実装へ置き換え ・最新iOS SDK / Android SDKへの対応 ・非推奨APIの置き換え ・既存機能を維持したまま段階的にコードを更新 ・iOSではUIKit / Storyboard環境を保守 ・AndroidではXML View System / Javaを中心とした既存コードを保守 ## 【成果】 App Store / Google Playの最新要件に対応し、公開停止リスクのあった既存アプリを継続してアップデート・配信できる状態へ改善しました。 また、一時的に最新OSへ対応するだけではなく、その後のアップデートも行いやすいよう、古い依存関係やコードを段階的に整理しました。 --- # ＃開発・実装内容B ## 【概要】 Androidレガシーコードの保守およびJavaからKotlinへの段階的移行 ## 【どのような機能の開発・実装か】 AndroidアプリはXML View Systemを利用しており、コードの大部分がJavaで実装されていました。 既存機能の修正・追加を行う際には、Javaコードをそのまま増やすのではなく、一部についてKotlinへ書き換えながら開発しました。 ## 【課題・問題点】 既存アプリのため、JavaとKotlinが混在する状態でも動作を壊さずに保守する必要がありました。 また、大規模な一括リライトはリスクが高いため、機能改修に合わせて少しずつモダナイズする必要がありました。 ## 【打ち手・使用した技術】 ・Javaベースの既存コードを調査 ・修正対象の一部コードをKotlinへ移行 ・Java / Kotlin間のInteropを利用して既存コードとの互換性を維持 ・既存XML View SystemのUIと連携 ・一括リライトではなく、機能改修に合わせた段階的な移行を実施 ## 【成果】 既存のJavaベースコードを維持しながら、変更頻度の高い部分からKotlinへ段階的に移行しました。 全面的なリライトによるリスクを避けながら、今後の開発・保守を行いやすいコードベースへ少しずつ改善しました。 --- # ＃開発・実装内容C ## 【概要】 動画・音声・記事を扱うメディアアプリの保守・互換性対応 ## 【どのような機能の開発・実装か】 アプリでは出版社が提供する動画・音声・記事コンテンツを扱っており、それぞれ異なる形式のコンテンツをアプリ内で閲覧・再生できるようになっていました。 僕は既存のメディア再生機能について、ライブラリ更新やOSアップデートによって発生した互換性問題の調査・修正を担当しました。 ## 【課題・問題点】 動画や音声再生はOSや利用ライブラリへの依存が強く、ライブラリ・SDKを更新すると、それまで正常に動いていた再生処理が動かなくなるケースがありました。 また、アプリ全体の更新が目的だったため、メディア再生部分だけを新しくして他の既存画面との挙動を壊さないようにする必要がありました。 ## 【打ち手・使用した技術】 ・動画 / 音声再生周辺の既存実装を調査 ・古くなったメディア関連ライブラリをアップデート・置き換え ・OSバージョン差異による不具合を修正 ・再生状態や画面遷移との整合性を確認 ・既存コンテンツ形式との互換性を維持しながらアップデート ## 【成果】 動画・音声・記事という複数種類のメディアコンテンツを扱う既存サービスについて、ユーザー体験を大きく変えることなく最新OS環境でも利用できる状態を維持しました。 --- # ＃開発・実装内容D ## 【概要】 スマートフォン / タブレット双方へのUI対応 ## 【どのような機能の開発・実装か】 本アプリはスマートフォンだけでなくタブレットでも利用されるため、iOS / Android双方で複数の画面サイズに対応する必要がありました。 既存のStoryboard / XML View Systemで構築されたUIについて、OSアップデートや新しい端末サイズでも表示が崩れないよう調整しました。 ## 【課題・問題点】 スマートフォンでは問題なく表示される画面でも、タブレットではコンテンツ幅・画像サイズ・レイアウト・余白などに問題が発生するケースがありました。 また、既存コードではスマートフォンを前提とした固定的なレイアウトも存在していたため、既存UIを大きく書き直さずに複数画面サイズへ対応する必要がありました。 ## 【打ち手・使用した技術】 ・iPhone / iPad双方でレイアウトを検証 ・Androidスマートフォン / タブレットで画面表示を検証 ・Storyboard / Auto Layoutの調整 ・Android XML Layoutの調整 ・固定サイズに依存したUIを修正 ・異なる画面サイズ・アスペクト比での表示崩れを改善 ## 【成果】 スマートフォンだけでなくタブレット環境でもコンテンツを快適に閲覧できるようにし、既存のiOS / Androidアプリを幅広い端末サイズで継続利用できる状態にしました。

### ＃プロジェクト経験概要 モダンなミュージアム向けに、Flutterを用いた館内ガイドアプリを0から開発しました。 2名のアプリエンジニア体制で、僕はBluetooth Beaconを利用した館内ナビゲーション、外部ベンダー製SDKのiOS / Androidネイティブ連携、音声ガイド、画像・動画・音声などのマルチメディア表示、多言語対応、Universal Links、アニメーション実装、テスト、リリース後の品質改善などを担当しました。 アプリは5言語・1,000件以上の展示物に対応し、約6か月という期間で新規開発からクライアントへのリリースまで実施しました。 リリース後も実際の来館者が利用する環境で継続して保守・改善を行い、Firebase Crashlyticsを利用したクラッシュ監視や警告の調査・修正にも取り組みました。 --- ### ＃チーム情報 ・アプリエンジニア：2名 ・FlutterによるiOS / Androidアプリ開発 僕は主に以下の領域を担当しました。 ・Bluetooth Beaconを利用した館内ナビゲーション ・外部ベンダー製の屋内測位SDKのiOS / Android統合 ・Flutterとネイティブ間のMethodChannel設計・実装 ・音声ガイド機能 ・画像 / 動画 / 音声などのマルチメディア機能 ・展示物のコレクション・館内ルート生成機能 ・5言語への多言語対応 ・Universal Links / Deep Links ・Flutterアプリ内のアニメーション・UX改善 ・Golden Test / Widget Test / Unit Test ・Firebase Crashlyticsを利用したリリース後の監視・改善 担当機能について、技術調査、設計、実装、テスト、不具合修正、リリース後の保守まで一貫して担当しました。 また、屋内測位SDKについては外部ベンダーとのミーティングにも参加し、SDKの仕様や実装方法を確認しながら、iOS / Android双方への組み込みを自分で行いました。 --- ## ＃開発・実装内容A ### 【概要】 Bluetooth Beaconと外部SDKを利用した館内ナビゲーション機能の開発 ### 【どのような機能の開発・実装か】 Bluetooth Beaconを利用して館内にいるユーザーの位置を取得し、アプリ内のマップ上に現在地を表示する屋内ナビゲーション機能を実装しました。 ユーザーは1,000件以上の展示物から目的の展示物をマップ上で確認でき、興味のある展示物をコレクションへ追加できます。 さらに、そのコレクションをもとに館内を巡るルートを生成し、マップ上で案内できる機能を実装しました。 ### 【課題・問題点】 GPSを利用できない屋内環境で高精度な位置情報を扱う必要があり、一般的な位置情報APIだけでは実現できませんでした。 屋内測位には外部ベンダーが提供するクローズドソースSDKを使用しましたが、Flutter向けSDKが存在せず、iOS / AndroidそれぞれでネイティブSDKを直接組み込む必要がありました。 SDKの仕様について不明点もあったため、ベンダーとの調整も必要でした。 ### 【打ち手・使用した技術】 ・SDK提供ベンダーとのミーティングを実施し、仕様・実装方法を確認 ・iOS側ではXcode上でFrameworkのLinkingや各種設定を実施 ・Android側でもネイティブSDKを直接導入 ・iOS / Android双方のネイティブ連携を自分で担当 ・MethodChannelを利用してSwift / KotlinとFlutterを接続 ・取得した位置情報をFlutter側のマップ・BLoCへ連携 ・展示物の位置情報と現在地を利用した館内ナビゲーションを実現 ### 【成果】 Flutter向けSDKが存在しない環境でも、iOS / Android両方のネイティブSDKをFlutterから統一的に扱える仕組みを構築しました。 これにより、GPSを利用できない館内でも現在地を表示し、1,000件以上の展示物を対象とした館内ナビゲーションを提供できるようになりました。 --- ## ＃開発・実装内容B ### 【概要】 音声ガイド・マルチメディア機能の開発 ### 【どのような機能の開発・実装か】 展示物ごとに、テキストだけでなく画像・動画・音声を利用したガイドコンテンツを閲覧できる機能を実装しました。 音声ガイドでは通常のスピーカー再生に加えて、イヤホン利用時の再生や、端末を耳元へ近づけた際にレシーバーから音声を再生する機能も実装しました。 ### 【課題・問題点】 画像・動画・音声など異なる形式のメディアを同一アプリ内で扱う必要がありました。 特に音声ガイドでは、イヤホン接続状態や端末の状態に応じて音声出力先を適切に変更する必要がありました。 ### 【打ち手・使用した技術】 ・Firebase Storageを利用したメディア管理 ・画像 / 動画 / 音声それぞれの表示・再生UIをFlutterで実装 ・Proximity Sensorを利用して端末を耳元へ近づけた状態を検知 ・スピーカー / イヤホン / レシーバーの音声出力切り替え ・BLoCを利用したメディア再生状態の管理 ### 【成果】 ユーザーがイヤホンを装着している場合、通常のスピーカーを利用する場合、端末を耳元に近づける場合など、利用シーンに応じて自然に音声ガイドを利用できるUXを実現しました。 また、展示物ごとに画像・動画・音声を組み合わせたリッチなガイドコンテンツを提供できる基盤を構築しました。 --- ## ＃開発・実装内容C ### 【概要】 1,000件以上の展示物を対象としたコレクション・ルート生成機能 ### 【どのような機能の開発・実装か】 ユーザーが興味のある展示物をコレクションへ追加し、選択した展示物を巡るためのルートを生成できる機能を実装しました。 生成されたルートは館内マップ上に表示され、現在地と組み合わせて利用できます。 ### 【課題・問題点】 1,000件以上の展示物データを扱いながら、ユーザーが選択した複数の展示物、現在地、館内マップの状態を組み合わせて管理する必要がありました。 ### 【打ち手・使用した技術】 ・展示物データと館内マップ上の位置情報を紐付け ・ユーザーごとのコレクション機能を実装 ・選択された展示物をもとにした館内ルート生成 ・BLoCによるコレクション・マップ・ルート状態の管理 ・Firebaseを利用した展示物データ管理 ### 【成果】 単に展示物一覧を閲覧するだけではなく、ユーザー自身が「見たい展示」を選択し、その内容に応じて館内を回れるパーソナライズされた鑑賞体験を実現しました。 --- ## ＃開発・実装内容D ### 【概要】 5言語に対応した国際ユーザー向け多言語対応 ### 【どのような機能の開発・実装か】 海外からの来館者も利用することを想定し、アプリ全体を5言語に対応しました。 UIテキストだけでなく、1,000件以上の展示物のタイトル・説明・音声・動画などのコンテンツについても、選択された言語に応じて切り替えられるようにしました。 ### 【課題・問題点】 静的なUIだけではなく、Firebaseから取得する展示物情報やFirebase Storage上のメディアコンテンツまで多言語化する必要がありました。 言語変更時には、テキストだけでなく表示中の展示情報・音声・動画なども同じ言語へ切り替える必要がありました。 ### 【打ち手・使用した技術】 ・FlutterのLocalization機構を利用したUIの多言語対応 ・5言語分の展示コンテンツを管理できるデータ構造を構築 ・Firebase / Firebase Storage上の言語別コンテンツとの連携 ・BLoCを利用した言語状態管理 ・言語変更に合わせた画面・コンテンツの動的更新 ### 【成果】 5言語・1,000件以上の展示物に対応し、国内利用者だけでなく海外からの来館者も同じアプリから展示情報や音声・動画ガイドを利用できる仕組みを実現しました。 --- ## ＃開発・実装内容E ### 【概要】 ミュージアムのブランド体験に合わせたUI / UX改善 ### 【どのような機能の開発・実装か】 施設自体がモダンなデザインを特徴としていたため、アプリについても単純な業務アプリのような見た目ではなく、施設の体験に合ったモダンなUIになるようアニメーションを追加しました。 画面遷移やコンテンツ表示などにアニメーションを取り入れ、操作時のフィードバックや視覚的な質感を改善しました。 ### 【課題・問題点】 館内体験の一部として利用されるアプリのため、機能的に利用できるだけではなく、実際の施設のデザイン・ブランドイメージと違和感のない体験を提供する必要がありました。 ### 【打ち手・使用した技術】 ・Flutter Animationを利用したUIアニメーション ・画面遷移や状態変化に合わせたアニメーションの追加 ・機能性を損なわない範囲でインタラクションを改善 ・施設のモダンな空間に合わせたアプリ体験を意識して実装 ### 【成果】 館内施設のモダンな雰囲気とアプリの体験を合わせ、単なる情報閲覧ツールではなく、施設体験の一部として自然に利用できるUIを目指しました。 --- ## ＃開発・実装内容F ### 【概要】 テスト・品質管理およびリリース後の継続改善 ### 【どのような機能の開発・実装か】 6か月という限られた期間で0からアプリを開発し、クライアントへリリースする必要があったため、開発と並行して自動テストやリリース後の監視環境も整備しました。 ### 【課題・問題点】 実際の来館者が利用するアプリのため、開発環境で正常に動くだけではなく、さまざまな端末・利用状況で安定して動作する必要がありました。 また、位置情報・センサー・動画・音声・ネイティブSDKなど端末依存性の高い機能が多く、不具合が発生した場合に原因を追跡できる仕組みも必要でした。 ### 【打ち手・使用した技術】 ・Unit Testを実装 ・Widget Testを実装 ・Golden TestによるUI差分の検知 ・Firebase Crashlyticsを導入 ・リリース後のクラッシュ・警告を継続的に監視 ・Crashlytics上で発生した問題を調査し、不具合や警告を改善 ・実ユーザー利用開始後も継続して保守・改善 ### 【成果】 2名のアプリエンジニア体制で、約6か月で0からクライアント向けアプリをリリースしました。 リリース後もCrashlyticsを用いて実際のユーザー環境で発生するクラッシュや警告を監視し、問題を発見・修正する運用を継続しました。 Golden Test / Widget Test / Unit Testも導入することで、機能追加や保守時の品質を担保しやすい開発環境を構築しました。

＃プロジェクト経験概要 友人と立ち上げたスタートアップにて、NFTの発行・売買・ギフトをモバイルアプリ上で完結できる「NFT Metro」を開発しました。 React Nativeを用いたモバイルアプリ開発から、Node.js / Expressによるバックエンド、Firebaseを利用したユーザー・データ管理、Polygon上のSolidityスマートコントラクト、IPFSへのNFTメタデータ保存まで、一人のエンジニアとして設計・実装・リリース・運用を一貫して担当しました。 サービスリリース後は約5,000ユーザーに利用され、ユーザー増加後も継続的な保守・改善を行いました。 主な機能として、アプリ内でのNFT Mint、ユーザー間でのNFTギフト、NFTの出品・購入、Stripeによる決済、アプリ内課金、NFTメタデータ・画像のIPFS保存などを実装しました。 ＃チーム情報 ・開発エンジニア：1名 ・共同創業者と2名でスタートアップとして立ち上げ ・技術選定、アーキテクチャ設計、モバイルアプリ、バックエンド、スマートコントラクト、インフラ、ストアリリース、リリース後の運用・保守を一人で担当 ＃開発・実装内容A 【概要】 モバイルアプリからNFTを発行し、ユーザー間で所有・送受信できるNFTプラットフォームの開発 【どのような機能の開発・実装か】 React NativeでiOS / Android向けアプリを開発し、ユーザーがアプリ上からNFTをMintできる機能を実装しました。 また、保有しているNFTを他ユーザーへギフトとして送信する機能や、他ユーザーからNFTを受け取る機能も開発しました。 NFTの画像およびメタデータについてはIPFSを利用し、Pinata経由で管理しました。 【課題・問題点】 一般ユーザー向けのモバイルアプリであるため、ユーザーにブロックチェーンやウォレット操作を強く意識させずにNFTを扱えるUXが必要でした。 また、モバイルアプリ、バックエンド、スマートコントラクト、IPFSと複数のシステムをまたぐ処理になるため、NFT発行時の状態管理やトランザクション失敗時のハンドリングも必要でした。 【打ち手・使用した技術】 ・React NativeによるiOS / Androidアプリ開発 ・SolidityによるNFTスマートコントラクト開発 ・Polygon Networkへのスマートコントラクトデプロイ ・Node.js / ExpressによるバックエンドAPI開発 ・Firebaseによるユーザー情報・アプリデータ管理 ・Pinata / IPFSによるNFT画像・メタデータ管理 ・ブロックチェーントランザクションとアプリ側の状態を連携する処理を実装 ・ユーザーがブロックチェーンを意識せず利用できるアプリUXを設計 ＃開発・実装内容B 【概要】 NFTマーケットプレイスおよび決済機能の開発 【どのような機能の開発・実装か】 ユーザーが保有しているNFTをプラットフォーム上に出品し、他のユーザーが購入できるマーケットプレイス機能を開発しました。 NFT購入手段としてStripeを導入し、通常の決済フローからNFTを購入できる仕組みを実装しました。 また、モバイルアプリ内ではIn-App Purchaseにも対応し、アプリストア経由の購入処理とサーバー側での購入状態管理を実装しました。 【課題・問題点】 NFTの所有権移転と決済処理は別々のシステム上で行われるため、「決済は成功したがNFTの移転に失敗する」といった不整合を防ぐ必要がありました。 また、Stripe決済、アプリ内課金、ブロックチェーン上のトランザクションという複数の決済・状態管理フローを扱う必要がありました。 【打ち手・使用した技術】 ・Stripeを利用したNFT購入フローの構築 ・iOS / AndroidのIn-App Purchaseを実装 ・Node.js / Express側で購入状態をサーバーサイド管理 ・決済状態とNFT所有権移転処理を連携 ・Polygon上のスマートコントラクトを利用したNFT Transfer処理を実装 ・Firebaseを利用した購入履歴・ユーザーデータの管理 ・異常系を考慮した決済およびNFT移転フローを設計 ＃開発・実装内容C 【概要】 約5,000ユーザー規模まで成長したサービスのリリース・運用・保守 【どのような機能の開発・実装か】 アプリの初期設計・開発だけでなく、App Store / Google Playへのリリース、その後の不具合修正、機能追加、バックエンド・Firebase・スマートコントラクトを含めたサービス全体の運用を担当しました。 【課題・問題点】 一人のエンジニアでサービス全体を担当していたため、開発速度だけでなく、障害時の影響範囲や保守性を考えながら設計する必要がありました。 また、ユーザー数が増えるにつれて、開発時には発生しなかったエッジケースや運用上の問題にも継続的に対応する必要がありました。 【打ち手・使用した技術】 ・モバイル、バックエンド、Firebase、スマートコントラクトを横断した問題調査・改善 ・約5,000ユーザーが利用するサービスを継続的に保守・運用 ・ユーザーからのフィードバックをもとに機能改善・不具合修正 ・React Native / Firebase / Node.js / Express / Solidity / Polygon / IPFS / Pinata / Stripeを含むサービス全体の技術領域を一人で担当