ID:82196さん

# プロジェクト概要 電力データを活用し、ユーザーの節電意識向上を目的とした **Webサービス／スマホアプリ（iOS・Android）** の開発・運用。 React / React Native / Expo / Node.js / Firebase / Google Cloud を用いたフルスタック開発を担当。 参加期間 2021年8月 ~ 2026年3月 --- # 役割 - **開発リーダー** - 要件定義〜設計〜実装〜テスト〜リリース〜運用まで一貫して担当 - フロントエンド／バックエンド／モバイル横断で技術方針を策定 - 工数見積、技術選定、レビュー運用設計、開発プロセス改善を主導 **チーム構成：** PM1名、エンジニア3名（計4名） --- # 開発・保守 ① : EAS Buildへの移行作業 ## 【概要】 Expo Classic Build で運用していたアプリを、EAS Build / EAS Submit を用いた運用に移行。 属人化していたビルド・提出手順を標準化し、継続運用可能なリリース基盤を整備。 ## 【課題】 - Classic Build 環境下で、ビルドおよびアップデート作業の多くを手動で実施しており、手順の属人化が発生していた - EAS Build 移行後も、標準化された運用フローが整備されておらず、共有・引き継ぎコストが高い状態だった - 環境変数やビルドプロファイルの管理が不十分で、環境差異によるビルド失敗リスクがあった ## 【アプローチ】 - リリース工程を分解し、手動作業、判断作業、自動化可能な作業を切り分けた - ヒューマンエラーを排除できる工程は自動化する方針を採用した - 単一チーム最適ではなく、他チーム展開を前提とした再現性の高いフローを設計した ## 【実施内容】 - EAS Build / EAS Submit を含むリリース用スクリプトを整備し、コマンド一つでビルド〜提出まで実行可能な運用を構築した - Git Workflow を整理し、ブランチ運用およびリリーストリガーを明確化した - 環境変数およびビルドプロファイルを整理し、環境差異によるビルド失敗を抑制した - リリース手順を標準化し、他メンバーでも実行可能な状態へ改善した ## 【成果】 - リリース作業時間を 120分→50分まで削減 - 手動オペレーションによるミス発生リスクを低減 - 作業手順の標準化により、代理リリース可能な体制を構築 - 属人性を排除し、継続的に運用可能なビルド基盤へ移行 --- # 開発・保守 ② : LINE / iOS アカウント連携によるログイン機能開発 ## 【概要】 既存の Firebase Authentication アカウントをメインアカウントとして維持したまま、LINE / iOS アカウントでもログインできる仕組みを追加。 誤連携やアカウント衝突を防ぎつつ、安全性と運用性を両立した認証基盤を設計・実装。 ## 【課題】 - 既存 Firebase Authentication アカウントをメインとして維持したまま、同一ユーザーが LINE / iOS アカウントでもログインできるようにしたい要件があった - 事前に Firebase Authentication アカウント作成済みのユーザーのみを対象とする制約があり、認証導線の整理が必要だった - Firebase Authentication が LINE を標準サポートしていないため、Swift / Kotlin による LINE SDK 導入が必要だった ## 【アプローチ】 - 「Firebase Authentication アカウントをメインとする」前提を守るため、ログイン導線を「メールアドレスとパスワードを用いてメインアカウントでサインイン」「連携済みユーザーのみ LINE / iOS でサインイン」の2系統に整理した - Firebase Authentication の UID と各ソーシャルアカウントの UID を紐付け、ログインには Firebase Custom Token を利用する構成とした - 未作成ユーザー、連携済み衝突、認可キャンセルなどの失敗パターンを事前に整理し、UI / エラー設計へ反映した ## 【実施内容】 - LINE / iOS 連携およびログイン処理を設計・実装した - 連携 / 解除 / ログインの主要イベントをログ化し、問い合わせ時の追跡性を向上させた - 失敗時の戻り先や案内文言を整理し、ユーザーが復帰しやすい導線を設計した ## 【成果】 - 既存 Firebase Authentication アカウントをメインに維持したまま、LINE / iOS によるログイン手段を追加 - 連携済み / 未連携 / 衝突 / キャンセルなどの分岐整理により、トラブルシュート性を向上 - 問い合わせ対応時の調査容易性を高め、運用負荷を軽減 --- # 開発・保守 ③ : アカウント登録ページの改修 ## 【概要】 旧来の JavaScript / HTML / CSS による個別実装の登録ページを、Express / React / TypeScript 構成へ刷新。 他プロジェクトとの技術スタック統一と保守性向上を目的に、入力仕様・バリデーション・エラー処理を整理した。 ## 【課題】 - 旧アカウント作成ページは JavaScript / HTML / CSS で個別実装されており、他プロジェクトと技術スタック・開発規約が統一されていなかった - 仕様管理やバリデーション実装が分散しており、改修時の影響範囲が不明確で保守性が低かった ## 【アプローチ】 - 他プロジェクトに合わせて Express / React / TypeScript 構成へ移行した - 旧ページの入力仕様、バリデーション、エラー文言、画面遷移を棚卸しし、互換性担保を完了条件として定義した - フロントエンドとサーバーサイドの責務を分離し、改修しやすい構造へ整理した ## 【実施内容】 - フォーム入力、バリデーション、エラー表示をコンポーネント化した - 必須 / 任意、入力形式、重複チェック、エラー文言など差分が出やすい観点を洗い出し、重点的に検証した - サーバー側で最終バリデーションおよび登録処理を実施する構成へ再整理した ## 【成果】 - Express / React / TypeScript へ統一し、他プロジェクトと同一の技術スタック・開発規約で保守できる状態を実現 - UI / バリデーション実装の共通化により、以降の改修容易性を向上 - リリース後、本対応起因の不具合 0件 を実現 --- # 開発改善 ①：少人数体制における開発生産性の最適化 ## 【概要】 フロントエンド / モバイル / バックエンドにまたがる開発環境と運用ルールを標準化し、再現性の高い少人数開発体制を構築。 ## 【課題】 - フロントエンド / モバイル / バックエンドで開発環境が不統一 - 個人依存の設定や暗黙知が多く、再現性が低い - コード品質のばらつきにより保守コストが増大 ## 【アプローチ】 - 属人スキルに依存せず、構造的に品質を担保する仕組みを優先 - 少人数体制でも継続しやすい開発基盤づくりを重視 ## 【実施内容】 - Node.js / パッケージ管理 / Lint / Formatter を標準化 - ESLint / Prettier による自動整形を導入 - コーディングルールとレビュー観点を明文化 - PR テンプレートを整備し、設計意図の記載を必須化 ## 【成果】 - コード品質を平準化 - 保守性・拡張性を向上 - レビュー指摘の質向上および指摘件数の適正化 --- # 技術スタック - **Frontend / Mobile**：TypeScript, JavaScript, React, React Native, swift, kotlin - **Backend**：Node.js - **Infra**：Google Cloud, Firebase - **Tooling**：VSCode, ESLint, Prettier