ID:62831さん

## プロジェクトの概要 カナダ・トロントのスタートアップにて、証券口座を連携し AI がポートフォリオ分析・株式分析を行う iOS アプリを 0→1 で開発。iOS チーム（3名）のリードとして技術選定のすべてを担い、CTO・CEO と英語で仕様・UI/UX・技術設計を議論しながら、要件定義からリリース、その後の App Store リリースサイクル運用まで一貫して主導しています。 ## 担当領域について - iOS アプリ全域の実装: 認証（Apple/Google サインイン・Face ID）、ポートフォリオ分析、WebSocket によるリアルタイム株価チャート、株式スクリーナー、プッシュ通知 - アーキテクチャ設計: SPM マルチモジュール化（RealtimeClient/APIClient/Domain/Store/Service/UILogic/UIComponents 分離）、DI コンテナ設計、Swift 6 Strict Concurrency 対応、Observation 移行 - チームビルディング: ジュニアエンジニアへのコードレビュー・技術指導。iOS 未経験メンバーが機能開発を担当できる状態まで育成 - リリース運用: GitHub Actions の CI 整備、Firebase App Distribution による Dev/Prd 共存配信、審査リジェクト時の機能退避・再提出判断を含むリリースマネジメント ## 技術的なアピール点 一つ目は、プロダクトのフェーズに合わせたアーキテクチャ選定です。これまでのプロジェクトでクリーンアーキテクチャや TCA など複数のアーキテクチャを実務で経験してきた上で、本プロダクトではあえて MVVM というシンプルな構成を選択しました。0→1 のフェーズで最優先すべきは早くプロダクトを Ship して学習サイクルを回すことであり、メンバーの習熟度を踏まえると、学習コストの高いアーキテクチャは立ち上がりの速度を損なうと判断したためです。一方でシンプルさが将来の負債にならないよう、SPM によるマルチモジュール分割と DI で責務の境界だけは最初から固め、「規律はモジュール境界で、画面実装は簡単に」というバランスに落としました。アーキテクチャを流行や好みではなく、チームとフェーズに対するトレードオフとして意思決定できるのが自分の強みだと考えています。 二つ目は、Sentry を活用した SRE 体制の構築と、それを起点にした起動時間最適化です。主要機能単位でパフォーマンス・可用性の SLI を計測し、SLO の閾値を下回ると Slack へ自動通知される監視体制を整備しました。キャンセルされた処理を「失敗」と区別することで、ユーザー起因のキャンセルが失敗率を汚染しない計測設計にしています。この計測から起動時間がボトルネックだと特定し、二つの改善を実施しました。一つは生体認証（Face ID）とデータプリフェッチの並列実行です。単純に並列化すると「Face ID 完了前にプリフェッチ完了で画面遷移してしまう」競合が生まれるため、画面遷移の発火点を一箇所に集約する構造にして設計レベルで排除しました。もう一つはサーバー側で計算コストの高い全期間ポートフォリオ集計を起動時の API から外し（バックエンドと連携して v2 化）、チャート表示時の遅延ロードに変更したことです。「計測の仕組みを作る → ボトルネックを特定する → 設計で解決する」まで一人で完結できます。

## プロジェクトの概要 アプリの中核データソースである証券口座連携基盤（Plaid → SnapTrade）の全面移行と、API 連携基盤の型安全化を、iOS・バックエンド双方の設計・実装を担当して完遂したプロジェクトです。移行により固定費（月額 10,000 ドル）を従量課金モデルへ変更し、現在の利用規模で最大75%のコスト削減と、ユーザー数に応じてコストが最適化されるスケーラブルな料金体系を実現しました。 ## 担当領域について - SnapTrade 連携のサービス層設計（連携 URL 発行 → OAuth → 再連携 → 過去データバックフィルという連携ライフサイクル全体の抽象化）から UI・リリースまで - Supabase Edge Functions ベースの API を OpenAPI / oRPC の型安全なクライアントへ移行（数十エンドポイント、サービス無停止） - バックエンド開発: 銘柄スコア計算ロジック、主要エンドポイントへの JWT 検証導入（リクエストの user_id を信用せず認証セッションから導出するセキュリティ強化）、金融計算のバグ修正 - バックエンド側 SnapTrade 実装（initial-sync ステートマシン、突合 cron 等）のコードレビューによる API 契約の整合性担保 ## 技術的なアピール点 この移行は、そもそも自分の課題提起から始まったプロジェクトです。当初導入されていた Plaid は、バックエンド側の要件を満たせるか十分に検証されないまま採用されており、証券トランザクションの種別（Buy / Sell / Dividend など）が証券会社ごとに正規化されずバラバラの形式で返ってくるという問題を抱えていました。ポートフォリオのリターン率は過去のトランザクション履歴を組み立てて計算するため、この不整合はユーザーのポートフォリオチャートが正しく表示されないという、投資アプリとして致命的な品質問題に直結していました。そこで「そもそも連携プロバイダー自体を替えるべきではないか」と自発的に代替サービスの調査を開始。候補となった SnapTrade と直接連絡を取り、API がバックエンドの要件（トランザクションの正規化、履歴の取得範囲など）を満たすかを自ら検証した上で移行を提案し、iOS・バックエンド双方の実装からリリースまで主導しました。課題の発見からプロバイダー選定・検証・移行完遂までを自分起点で動かし、結果としてデータ品質の問題を解消するとともに、月額 10,000 ドルの固定費を従量課金へ切り替えるコスト構造の改善にもつなげています。 API 基盤の型安全化では、いきなり置き換えるのではなく「文字列指定の Edge Function 呼び出しを enum 化 → swift-openapi-generator による生成クライアントへ移行」と段階を設計。認証ヘッダー注入と指数バックオフリトライをミドルウェアに分離し、生成型→ドメインモデル変換を Mapper 層に隔離、エラー型が依存の向きを壊さないようパッケージ境界まで設計しました。さらにバックエンドの OpenAPI spec 変更を iOS リポジトリへ自動 PR する GitHub Actions を構築し、バックエンドの破壊的変更を開発段階で検知できる体制にしています。フロントとバックの「API 契約」を仕組みで守るという思想で取り組みました。