ID:78219さん

# プロジェクト経験概要 プロジェクト名: 不動産仲介プラットフォーム【不動産連合体】ホームページおよびインフラリニューアル 期間: 2024年10月〜現在 担当フェーズ: 基本設計、詳細設計、開発、単体テスト、インフラ構築 ## 背景と課題認識 既存の不動産仲介プラットフォームはモノリシックな構成で、以下の課題を抱えていました： - API管理の複雑化により、新機能追加・修正時の影響範囲が広大 - フロントエンドとバックエンド間の通信仕様が統一されておらず、個別開発が必要 - HTTPSへの未対応によるセキュリティリスク - 手動インフラ設定による環境間差異と運用コスト増大 - 過剰なIAM権限設定によるセキュリティリスク これらの課題を解決するため、BFFアーキテクチャの導入とAWS上でのTerraformによるインフラ管理を主軸とした改善策を計画しました。スケーラビリティと保守性の向上、開発・運用負担の軽減を目標としました。 # チーム情報 - チーム規模: 30名（PjM 2名、フロントエンド 5名、BFF 7名、バックエンド 10名、インフラ 6名） - 自分の役割: BFFリード（設計・実装）、AWS インフラ構築リード、CI/CD改善 - 開発方法: アジャイル（2週間スプリント）、デイリースクラム実施 # 開発・実装内容A：BFFアーキテクチャの設計・実装 ## 【概要】 フロントエンドとバックエンド間の通信を統一し、開発効率と保守性を向上させるためのBFF層を設計・実装しました。 ## 【課題・問題点】 - フロントエンドが複数のバックエンドAPIに個別に接続する構成で、API仕様の変更時に影響範囲が広大 - データ変換ロジックがフロントエンド側に散在し、コードの重複と保守性低下 - 型定義が不十分で、ランタイムエラーが頻発 - 依存関係の管理が不適切で、ビルド時のエラーが多発 ## 【思考プロセスと解決策】 課題分析の結果、APIゲートウェイパターンとレイヤードアーキテクチャの導入が最適と判断しました。以下の理由から： 1. APIゲートウェイ（BFF）導入 - フロントエンドのリクエストを一元管理できる - バックエンドAPIの変更が直接フロントエンドに影響しない - データ変換を集中管理できる 2. レイヤードアーキテクチャ採用 - 関心事の分離による可読性・保守性向上 - テスト容易性の確保 - 依存関係の明確化 ## 【実装内容と使用技術】（※個人で実装） - NestJS + Node.js によるBFF層の構築 - TypeScriptによる型安全性の確保（共通型定義の作成と共有） - Inversifyを用いたDI（依存性注入）コンテナの実装 - 以下のレイヤー構成による責務分離： - Domain層：ビジネスロジックとエンティティ定義 - UseCase層：ユースケース単位の処理フロー - Application層：HTTPリクエスト/レスポンス処理 - Infrastructure層：外部APIとの通信、キャッシュ処理 - pnpmによるモノレポ管理とモジュール依存関係の最適化 - OpenAPI仕様に基づくAPI自動ドキュメント生成 - Jestによる各レイヤーの単体テスト（カバレッジ85%以上確保） ## 【成果】 - フロントエンド開発工数：前比30%削減（APIの一元管理により） - バックエンドAPI変更時の影響範囲：50%縮小 - ビルドエラー発生頻度：80%減少 - リリース頻度：週1回→週3回に向上 - バグ修正コスト：40%削減（型安全性向上による） # 開発・実装内容B：AWSインフラのIaC化と最適化 ## 【概要】 Terraformを活用したAWSインフラのコード化、HTTPS対応、環境間設定の統一化を実施し、セキュリティ強化と運用コスト削減を実現しました。 ## 【課題・問題点】 - HTTP通信のみでセキュリティリスクが高い - 手動設定による環境間差異（開発/ステージング/本番）と構成管理の難しさ - IAM権限過剰付与によるセキュリティリスク - 手動デプロイによる人的ミスの発生 - インフラリソース増加に伴うコスト管理の困難さ ## 【思考プロセスと解決策】 クラウドインフラの課題を分析し、以下のアプローチが最適と判断しました： 1. Infrastructure as Code（IaC）による管理 - 環境間の一貫性確保 - バージョン管理によるロールバック容易性 - セルフドキュメント化 2. セキュリティファーストの設計 - 最小権限の原則適用 - 通信の暗号化 - セキュリティグループによるアクセス制限 ## 【実装内容と使用技術】（※個人で実装） - Terraformによるインフラ定義（モジュール化による再利用性向上） - HTTPS対応： - ALB + Route53 + ACM構成 - 証明書自動更新の仕組み実装 - 環境管理： - terraform workspaceによる環境分離（dev/staging/prod） - 環境変数の一元管理（AWS Systems Manager Parameter Store） - セキュリティ強化： - IAMポリシーの最小権限化（リソースごとに細分化） - セキュリティグループの最適化（必要最小限のポート公開） - WAFによるアプリケーション層防御の導入 - CI/CD構築： - GitLab CI/CDによるTerraform plan/applyの自動化 - インフラ変更のレビュープロセス導入 - コスト管理： - タグ付けポリシー策定と自動化 - AWS Cost Explorerによる可視化と定期レポート ## 【成果】 - HTTPS化によるセキュリティリスク：90%低減 - 環境間設定差異による障害：70%削減 - IAM権限の最適化：不要アクセス権限をゼロに - インフラ構築時間：3日間→30分に短縮 - 運用コスト：25%削減（自動化とリソース最適化により） # 開発・実装内容C：CI/CDパイプライン構築 ## 【概要】 Docker化と自動デプロイパイプラインの構築により、開発からリリースまでのプロセスを効率化しました。 ## 【課題・問題点】 - 環境依存の開発により「自分の環境では動くが他では動かない」問題 - 手動デプロイによるヒューマンエラーと工数増大 - テスト実行の非一貫性と品質担保の難しさ - 長時間のリリース作業（2〜3時間）によるダウンタイムの発生 ## 【思考プロセスと解決策】 継続的インテグレーション/デリバリーを実現するため、以下のアプローチを採用しました： 1. コンテナ化による環境統一 - 開発/テスト/本番環境の一貫性確保 - 依存関係の明確な管理 2. パイプライン自動化 - 手動操作の最小化 - 一貫したビルド/テスト/デプロイプロセス ## 【実装内容と使用技術】（※チームで設計し個人で実装） - Docker化： - マルチステージビルドによる最適化 - ベースイメージの脆弱性スキャン自動化 - CI/CDパイプライン（GitLab CI/CD）： - ブランチ戦略に連動した自動テスト/ビルド - 静的解析（ESLint, SonarQube）の自動実行 - テスト自動化（Jest, Cypress） - Blue/Greenデプロイ： - AWS ECSによるゼロダウンタイムデプロイ - 自動ロールバック機能 - モニタリング統合： - CloudWatch Logsとの連携 - アラート設定の自動化 ## 【開発環境構築時間短縮の具体的な実装内容】 開発環境構築時間を1日から30分に短縮するために、以下の具体的な施策を実施しました： 1. **Docker Composeによる環境統一** - 開発に必要な全サービス（アプリケーション、DB、キャッシュ等）をDocker Compose化 - ローカル環境差異に左右されない一貫した開発環境を実現 - 環境変数を.env.exampleとして管理し、初期設定を簡略化 2. **初期設定自動化スクリプトの作成** - シェルスクリプト（setup.sh）で以下を自動化： - 必要なツール（Docker, Git, Node.js等）のバージョン確認とインストール案内 - リポジトリのクローン - 環境変数ファイルの生成（.env） - Docker環境のビルドと起動 - 初期データのシード処理 - ローカル開発用SSL証明書の自動生成 3. **開発者向けドキュメントの整備** - README.mdに詳細な環境構築手順を図解付きで記載 - トラブルシューティングガイドの作成 - VSCodeの推奨設定・拡張機能リストの提供（.vscode/配下に設定ファイル配置） 4. **VSCode Dev Containersの導入** - エディタからコンテナ内開発を直接可能に - 拡張機能も含めた開発環境をコンテナ化し、環境差異を排除 5. **依存関係のキャッシュ最適化** - npmモジュールをボリュームマウントで永続化 - Docker層キャッシュの最適化による再ビルド時間の短縮 ## 【成果】 - リリース作業時間：2~3時間→15分に短縮 - リリース頻度：月2回→週3回に向上 - デプロイ失敗率：15%→2%に減少 - 開発環境構築時間：1日→30分に短縮（Docker Compose + 自動化スクリプトにより） - リリース品質：重大バグ発生率30%減少 # 技術スタック - 言語：TypeScript, Golang, HCL(Terraform) - フレームワーク：NestJS, Inversify - パッケージ管理：pnpm - DB：PostgreSQL, DynamoDB - AWS サービス：ECS, ALB, Route53, ACM, S3, CloudFront, API Gateway, WAF, Systems Manager - CI/CD：GitLab CI/CD, Docker - 監視/ロギング：CloudWatch, X-Ray - 開発ツール：ESLint, Prettier, Jest, Cypress, SonarQube

# プロジェクト経験概要 プロジェクト名: 自社ERP ソリューション(人材、関連会社、生産ラインの統合管理)プロジェクト 担当フェーズ: 基本設計、詳細設計、開発、単体テスト 期間: 2022.04 ~ 2023.12 ## 思考プロセス 本プロジェクトでは、以下の課題に直面していました： - **既存のERPシステムの老朽化**: 10年以上使用されていたシステムで、技術的負債が蓄積していた - **分断されたデータ管理**: 生産ライン、関連会社、人材管理が別々のシステムで運用されており、統合されたデータ分析やリアルタイムの情報共有が困難 - **手動プロセスによる非効率性**: 多くのデータ入力・更新が手動で行われ、業務負荷増大とヒューマンエラーの原因に - **パフォーマンスの問題**: APIの最適化不足によりページの読み込み速度が遅く、ユーザー体験を損なっていた これらの問題を分析した結果、単なる既存システムの改修ではなく、アーキテクチャから見直す必要があると判断しました。特に、ユーザー離脱率の高さ（30%）は業務効率に直接影響していたため、UX改善を最優先課題として設定。また、継続的な機能追加と保守を容易にするために、開発プロセス自体の改善も並行して進めることが重要だと考えました。 これらの課題を解決するため、以下のアプローチを採用しました： 1. SPA（Single Page Application）アーキテクチャの採用とSSR最適化によるパフォーマンス向上 2. マイクロサービス的なAPI設計による拡張性と保守性の確保 3. CI/CDパイプラインの構築による開発・デプロイプロセスの効率化 4. スクラム開発の導入によるイテレーティブな開発サイクルの確立 # チーム情報 ## チーム規模: 13名 - PM: 1名 - 開発: 8名（内訳：バックエンド4名、フロントエンド4名） - テスト: 3名 - デザイナー: 1名 ## 自分の担当領域 サブリーダーとして以下を担当： - 技術選定とアーキテクチャ設計（特にフロントエンド部分） - 開発チームのタスク管理とスケジュール調整 - コードレビュー体制の構築と実施 - APIインターフェース設計 - 主要な機能モジュールの開発 # 開発・実装内容A (SPA・API最適化によるUX改善) ## 【概要】 ERPシステムのWebアプリケーションをモノリシックなサーバーサイドレンダリングからSPA（Single Page Application）アーキテクチャに刷新。Vue.jsを採用し、SSR（Server-Side Rendering）の最適化によりページ読み込み時間の短縮とユーザー体験の向上を実現。 ## 【どのような機能の開発・実装か】 個人として以下を担当： - Vue.jsとNuxt.jsを用いたSPAアーキテクチャの設計と実装 - SSRの最適化（Nuxt.jsのasyncDataを活用したデータプリフェッチ） - REST APIとGraphQLを組み合わせたバックエンドインターフェースの設計 - コンポーネント設計とVuexによる状態管理パターンの確立 ## 【課題・問題点】 - 既存システムはサーバーサイドレンダリングが最適化されておらず、ページのリロード時間が15秒以上かかっていた - 複数のAPIを連続して呼び出す必要があり、画面表示までの時間が長く、ウォーターフォール問題が発生 - 頻繁にアクセスされるデータに対しても毎回DBクエリが実行され、バックエンドへの負荷が高かった - ブラウザキャッシュの活用が不十分で、同じデータを何度もロードしていた ## 【打ち手・使用した技術】 個人として以下の対策を実施： - **SSRの最適化**: Nuxt.jsの導入とasyncDataを活用し、初期レンダリング時にサーバーサイドでデータを取得することで、クライアント側の初期表示を高速化 - **APIの集約**: GraphQLを一部導入し、複数リソースの取得を1リクエストに集約（従来の7回のAPI呼び出しを1回に削減） - **キャッシング戦略の導入**: - バックエンドではRedisを導入し、頻繁にアクセスされるデータをキャッシュ化 - フロントエンドではVuexストアを活用し、セッション中のデータ再利用を促進 - HTTP ETagとConditional Requestsの実装によるネットワークトラフィックの削減 - **レスポンシブデザインの改善**: データ量の多い表示画面を分割表示に変更し、レンダリング負荷を分散 ## 【成果】 - ページのリロード時間を15秒→3秒に短縮（約80%削減） - APIの最適化とGraphQL導入により、ユーザーの離脱率を30%→8%に改善 - バックエンドの負荷を平均60%軽減し、サーバーリソースの効率的な利用を実現 - モバイルデバイスからのアクセス率が25%向上（レスポンシブデザイン改善による） # 開発・実装内容B (CI/CD & デプロイ自動化) ## 【概要】 Docker + Jenkins + GitLabを活用したCI/CDパイプラインの構築。開発からテスト、デプロイまでの全プロセスを自動化し、開発サイクルの短縮とリリース品質の向上を実現。 ## 【どのような機能の開発・実装か】 個人として以下を担当： - Jenkins + Docker + GitLab CIによるCI/CDパイプラインの設計と構築 - Spring BootアプリケーションのDockerコンテナ化とオーケストレーション - 環境ごとの設定を管理するための仕組み構築（Dev/Staging/Production） - 自動テスト（単体・結合・E2E）の導入とパイプラインへの組み込み ## 【課題・問題点】 - 従来は手動デプロイで、環境ごとの設定変更が必要で、設定ミスによるデプロイ失敗が月平均5回発生 - テスト環境と本番環境の構成差異により、環境依存のバグが頻発 - リリースごとにQAチームの手動テストが必要で、リリースサイクルが長期化（平均4週間） - ブランチ管理が標準化されておらず、マージ作業に時間がかかっていた ## 【打ち手・使用した技術】 個人として以下の対策を実施： - **CI/CDの自動化**: - JenkinsとGitLab CIを連携させ、コミットからデプロイまでの自動化パイプラインを構築 - Docker Composeを活用し、アプリケーション、DBなど全環境を一貫して管理できるよう設計 - **環境の統一化**: - 環境変数を.envファイルに集約し、Docker環境間での設定共有を実現 - Terraformを導入し、インフラ構成をコード化（IaC）して環境間の一貫性を確保 - **自動テストの拡充**: - JUnitによる単体テスト、RestAssuredによるAPI結合テスト、Seleniumを使用したE2Eテストを自動化 - テストカバレッジを計測し、80%以上を維持する仕組みを導入（JaCoCo活用） - **Git-FlowとGitLab Flow**: - ブランチ戦略を明確化し、feature/develop/master構成のワークフローを確立 - マージリクエストに対する自動テストと複数人によるレビュー必須化 ## 【成果】 - デプロイにかかる時間を30分→5分に短縮（約83%削減） - デプロイ失敗率を月平均5回→0.5回に削減（90%改善） - リリースサイクルを4週間→1週間に短縮（75%削減） - テスト工数を50%削減し、QAチームがより専門的なテストに集中できる環境を整備 - 環境差異に起因するバグの発生を95%削減 # 開発・実装内容C (データ統合・分析基盤の構築) ## 【概要】 複数システムに分散していた生産ライン、関連会社、人材データを統合的に管理・分析する基盤を構築。リアルタイムダッシュボードによる意思決定支援機能を実現。 ## 【どのような機能の開発・実装か】 個人として以下を担当： - データウェアハウス設計とETLプロセスの構築 - 分析用APIの設計と実装（集計・予測機能） - リアルタイムダッシュボード用のバックエンド処理 - バッチ処理の最適化と定期実行の仕組み構築 ## 【課題・問題点】 - データソースが5つのシステムに分散し、横断的な分析が困難 - レポート生成に平均3日を要し、意思決定の遅延を招いていた - 分析用クエリの実行がトランザクション処理に干渉し、システム全体の応答性が低下 - ユーザーごとに異なるデータアクセス権限の管理が複雑化 ## 【打ち手・使用した技術】 個人として以下の対策を実施： - **データ統合アーキテクチャ**: - PostgreSQLをメインDBとして採用し、読み取り処理と書き込み処理を分離（CQRS原則） - 夜間バッチ処理でデータを集約・前処理し、分析用のマテリアライズドビューを作成 - **パフォーマンス最適化**: - 頻出クエリのインデックス最適化（実行計画分析による） - 大量データ処理のためのPartitioningを実装 - **セキュリティとアクセス制御**: - Row-Level Securityを実装し、ユーザーロールに基づいたデータアクセス制御を強化 - 機密データを自動的にマスキングする仕組みを導入 - **リアルタイム連携**: - Websocketを活用したリアルタイム通知システム構築 - 重要指標の変化を検知し、関連部署に自動通知する仕組みを実装 ## 【成果】 - レポート生成時間を3日→10分に短縮（99%以上の時間削減） - データ分析基盤の導入により、在庫最適化で年間約2,000万円のコスト削減を実現 - システム全体のパフォーマンスを維持しながら、分析機能を提供（読み取り分離による） - 部署間のリアルタイム情報共有が可能になり、意思決定サイクルが大幅に短縮（平均70%） # 実績・取り組み ✅ **UX/パフォーマンス改善** - SPA + SSR最適化により、ページ読み込み時間を80%短縮 - API設計の改善でユーザー離脱率を30%→8%に低減 ✅ **CI/CD導入による開発効率化** - Docker + Jenkins + GitLab CIによるパイプライン構築 - リリースサイクルを4週間→1週間に短縮（75%削減） ✅ **データ統合・分析基盤の構築** - 複数システムのデータを統合し、リアルタイム分析基盤を実現 - レポート生成時間を3日→10分に短縮 ✅ **スクラム開発の導入・定着** - Jiraを活用したスプリント管理の導入 - 開発期間を当初計画より2ヶ月短縮 ✅ **ナレッジ共有基盤の構築** - Notionを活用したドキュメント整備とチーム内ナレッジ共有 - オンボーディング期間を2週間→3日に短縮 # 技術スタック ✅ **OS**: Windows Server 2019, Linux (Ubuntu) ✅ **言語**: Java 17, JavaScript/TypeScript, Kotlin, HTML5, CSS3/SCSS ✅ **フレームワーク**: Vue.js 3, Nuxt.js, Spring Boot 2.7 ✅ **DB**: PostgreSQL 14, MS-SQL 2019, Redis 6 ✅ **インフラ**: Docker, Kubernetes, Jenkins, GitLab CI/CD, AWS (EC2, S3, RDS) ✅ **ツール**: Swagger, Jira, Slack, Git, Figma, JUnit, Selenium, JaCoCo

# プロジェクト経験概要 **プロジェクト名:** Safe2Go 仁川国際空港のコロナ検査予約サイト **期間:** 2021年10月~202年3月 **担当フェーズ:** 開発、Webパブリッシング --- # 背景と課題認識 COVID-19 の感染拡大に伴い、海外渡航時の健康管理や検査予約の需要が急増しました。 従来の予約システムでは、以下の課題が顕在化していました： - **予約プロセスの複雑性:** 複数の入力項目や手続きが煩雑で、利用者の離脱リスクが高い。 - **レスポンシブ対応の不十分さ:** 固定レイアウトのため、多様なデバイス（スマートフォン、タブレット等）での表示最適化が不十分。 - **開発プロセスの非効率性:** GitHub を用いたバージョン管理は行われていたが、CI/CD の自動化が不十分で品質とリリース頻度に課題。 - **ユーザー認証・セキュリティ:** ログイン・会員登録機能の実装が利用者にとって分かりにくく、セキュリティ面での強化が求められていた。 --- # 思考プロセス 本プロジェクトでは、利用者の使いやすさと安全性向上を最優先とする観点から、以下の点に着目しました： - **ユーザー視点の再設計:** 現行システムの複雑さとレスポンシブ対応不足を改善するため、Figma を用いたプロトタイピングで直感的なUI/UXを模索。 - **技術的最適化:** Vue.js を活用したシングルページアプリケーション（SPA）としての再構築により、ページ初期表示時間の短縮と操作性向上を実現。 - **自動化と品質向上:** GitHub、Git-CI を組み合わせた自動テスト・デプロイパイプラインの導入により、リリースサイクルの短縮と開発効率の向上を図りました。 --- # チーム情報 - **チーム規模:** 全3名 - **自分の担当領域:** - フロントエンド開発および Webパブリッシング - UI/UX 改善と予約機能の実装 - **開発手法:** アジャイル開発（定期ミーティング、GitHub によるバージョン管理、Git-CI の活用） --- # 開発・実装内容A：Webアプリケーションの開発 ## 【概要】 COVID-19 関連情報の提供とコロナ検査予約機能、さらに感染症対策ガイドラインの情報発信を目的とした多機能 Web アプリケーションを実装しました。 ## 【どのような機能の開発・実装か】 - **検査予約機能:** 出入国時の検査予約、旅行計画の登録・管理機能を実装。 - **ユーザー認証:** ログインおよび会員登録ページの開発により、セキュリティと利便性の両立を図る。 - **レスポンシブ対応:** HTML, CSS, JavaScript、及び Vue.js を用いて、各デバイスに最適化された反応型レイアウトを実現。 - **情報提供:** COVID-19 関連の最新旅行情報や感染症対策ガイドラインの表示と定期更新。 ## 【課題・問題点】 - 予約プロセスの多段階化による利用者の操作負荷が高く、離脱リスクが存在。 - 固定レイアウトによる各デバイスでの表示最適化不足。 - リアルタイムな情報更新とユーザー認証処理を両立させるため、パフォーマンス面での改善が必須。 ## 【思考プロセスと打ち手・使用した技術】 - **UI/UX の再設計:** Figma でのプロトタイピングを重ね、利用者にとって直感的な操作感を実現するデザインを策定。 - **SPA の導入:** Vue.js を使用したシングルページアプリケーションとして再構築し、ユーザー操作の一貫性と高速表示を達成。 - **自動化環境の整備:** GitHub によるバージョン管理と Git-CI を利用した自動テスト・デプロイパイプラインの構築で、開発効率と品質の向上を図る。 ## 【成果】 - 予約プロセスの簡素化により、利用者離脱率を大幅に低減。 - レスポンシブ対応の強化で、スマートフォンやタブレットでの利用体験を向上。 - 自動化体制の整備により、リリースサイクルが短縮され、品質管理が改善。 --- # 開発・実装内容B：プロトタイピングとデザイン連携 ## 【概要】 Figma を用いたプロトタイピング手法の導入と、デザイナーとの連携を強化。初期デザインのフィードバックを迅速に反映し、UI/UX の改善を実施しました。 ## 【どのような機能の開発・実装か】 - **インタラクティブなプロトタイプの作成:** ユーザーシナリオを具体化し、改善点の洗い出しと迅速なデザインフィードバックを実現。 - **デザインレビュー:** 定期的なミーティングを通じて、Figma 上でデザイン案を共有し、改善を重ねたUIコンポーネントの実装。 ## 【課題・問題点】 - 初期デザインと実装間の認識のズレにより、修正工数が増大する可能性があった。 - ユーザーテストによって細かな改善点が多数指摘された。 ## 【思考プロセスと打ち手・使用した技術】 - **迅速なフィードバックサイクル:** 初期プロトタイプの段階でユーザーテストを実施し、得られたフィードバックを即時に反映する体制を構築。 - **チーム間連携の強化:** Figma プロジェクトの共有により、デザイナーと開発者間の認識統一を実現し、効率的なUI改善を行った。 ## 【成果】 - 初期段階での問題点を多数解消し、実装後の修正工数を大幅に削減。 - デザインと実装の認識のズレが解消され、統一感のあるUI/UXが実現。 - 結果として、ユーザー満足度が向上し、利用率の改善に寄与。 --- # 技術スタック - **OS:** Windows - **言語:** JavaScript, HTML, CSS - **フレームワーク:** Vue.js - **ツール:** Figma, Git-CI, Slack - **その他:** GitHub によるバージョン管理

# プロジェクト経験概要 プロジェクト名: 韓国LG社冷蔵庫ディスプレイ用Androidアプリケーション開発 担当フェーズ: 要件定義、UI/UX設計、実装、テスト 期間: 6ヶ月 ## 思考プロセス 本プロジェクトでは、スマート家電の普及に伴い、冷蔵庫に組み込まれるAndroidベースのディスプレイシステムを開発する必要がありました。従来の冷蔵庫管理システムでは、単純な温度設定や基本的な機能しか提供されておらず、ユーザーエクスペリエンスが限定的でした。また、IoT技術の進化により、家電製品とスマートフォンやその他のスマートホームデバイスとの連携が求められる状況でした。 特に以下の課題を解決する必要がありました： - 非タッチ操作が一般的だった冷蔵庫インターフェースを、タッチスクリーンに最適化する必要性 - 限られたディスプレイサイズと計算リソースの中で、複雑な機能を提供する技術的課題 - 冷蔵庫という特殊環境（明るさ変化、結露可能性、手が濡れた状態での操作）に対応したUIの必要性 - 多言語対応と国際展開を想定した設計の必要性 これらの課題を解決するため、シンプルさと機能性を両立させるUIデザインを目指し、Kotlin言語を活用した効率的な開発アプローチを採用しました。また、IoT機器としての特性を活かした独自の機能開発に重点を置きました。 # チーム情報 ## チーム規模: 8名 - プロジェクトマネージャー: 1名 - UI/UXデザイナー: 2名 - Androidエンジニア: 4名（日本側2名、韓国側2名） - QAエンジニア: 1名 ## 自分の担当領域 - Androidアプリケーションの主要UIコンポーネント設計・実装 - パフォーマンス最適化 - 日韓チーム間の技術的な橋渡し役 - コードレビューとテスト設計 # 開発・実装内容A (冷蔵庫特化型UIコンポーネントの開発) ## 【概要】 冷蔵庫という特殊環境で使用される組み込みAndroidシステム向けに、カスタムUIコンポーネントを設計・実装。通常のモバイルアプリとは異なる操作性や視認性を考慮した、使いやすく直感的なインターフェースを構築。 ## 【どのような機能の開発・実装か】 個人として以下を担当： - 冷蔵庫の温度設定や運転モード切替のためのカスタムダイアルコントロールの開発 - 食品在庫管理システム用のカスタムリスト・グリッドビューの実装 - レシピ提案機能のためのインタラクティブなカード形式UIの設計と実装 - ジェスチャー認識機能（手が濡れた状態での操作を考慮）の導入 ## 【課題・問題点】 - 標準的なAndroidコンポーネントでは冷蔵庫ディスプレイの使用シナリオに最適化されておらず、使い勝手が悪かった - 冷蔵庫前面という特殊な使用環境（照明条件の変化、視野角の問題）によるUI視認性の課題 - 限られた処理能力と省エネ要件の中で、アニメーションやトランジションを実現する必要があった - 手が濡れている可能性や手袋着用時など、一般的なタッチ操作が困難な状況への対応 ## 【打ち手・使用した技術】 個人として以下の対策を実施： - **カスタムUIコンポーネント**: - Kotlin DSLを活用した宣言的UIの構築 - Custom Viewとカスタムアニメーションを実装し、限られたリソース内で滑らかな操作感を実現 - CanvasとOpenGLを組み合わせた効率的な描画処理 - **アクセシビリティ対応**: - 大きなタッチターゲット設計（標準の1.5倍のサイズ） - 高コントラストモードの実装 - 音声フィードバックの強化 - **パフォーマンス最適化**: - ViewModelとLiveDataを活用した状態管理 - リソースキャッシュと再利用の仕組み導入 - 描画パフォーマンス計測と最適化（60fpsの維持） ## 【成果】 - ユーザーテストでタスク完了率が従来システムと比較して40%向上 - 操作時間が平均30%短縮 - バッテリー消費を20%削減（省エネ設計） - 韓国国内ユーザー満足度調査で90%以上の高評価を獲得 # 開発・実装内容B (多言語対応と国際展開対応) ## 【概要】 北米、欧州、アジア各国への展開を視野に入れた多言語対応とローカライゼーションフレームワークの構築。単なる言語切替だけでなく、文化や使用習慣に合わせたUI/UXの最適化も実施。 ## 【どのような機能の開発・実装か】 個人として以下を担当： - 10言語に対応する効率的なローカライゼーションシステムの設計 - 言語ごとのレイアウト自動調整メカニズムの実装 - 地域ごとの食品データベースとレシピ推薦ロジックの構築 - 測定単位（摂氏/華氏、メートル法/ヤード・ポンド法）の自動切替機能 ## 【課題・問題点】 - 言語によるテキスト長の違いがレイアウトを崩す問題 - フォントの違いによる視認性と統一感の損失 - 各国の食習慣や食材名称の違いによるデータベース設計の複雑化 - リソースの肥大化による起動時間とメモリ使用量の増加 ## 【打ち手・使用した技術】 個人として以下の対策を実施： - **動的レイアウトシステム**: - ConstraintLayoutを最大限活用し、テキスト長に応じて自動調整するレイアウト設計 - 言語ごとのフォントスケーリングを実装し、統一した視覚的印象を維持 - **リソース最適化**: - オンデマンドリソースロードの仕組みを実装し、必要な言語リソースのみをメモリに読み込む - 共通アイコンと言語固有アイコンを分離し、重複を削減 - **データモデルの設計**: - NoSQLベースの柔軟なデータモデルを設計し、各国の食品カテゴリとマッピング - ユーザー使用履歴に基づく自動最適化システムの導入 ## 【成果】 - アプリの初回起動時間を25%短縮（リソース最適化の結果） - メモリ使用量を30%削減 - 翻訳作業の効率が50%向上（翻訳チームからのフィードバック） - 地域ごとのカスタマイズ対応時間を従来の1/3に短縮 # 開発・実装内容C (開発プロセスとCI/CD改善) ## 【概要】 日韓共同開発という環境で、効率的な開発プロセスを構築。Git-CIとSlackを連携させ、継続的インテグレーション/デリバリーパイプラインを整備し、品質向上と開発速度の改善を実現。 ## 【どのような機能の開発・実装か】 個人として以下を担当： - Git-CIパイプラインの設計と導入 - 自動テストフレームワークの構築（UI自動テスト含む） - Slackとの連携による通知システムの実装 - コードレビュープロセスの確立と文書化 ## 【課題・問題点】 - 日韓チーム間の時差と言語の壁によるコミュニケーションロス - コードの統一性維持と品質担保の難しさ - ビルド時間の長さによる開発効率の低下 - テスト環境と実機環境の差異によるバグ発見の遅れ ## 【打ち手・使用した技術】 個人として以下の対策を実施： - **CI/CDパイプライン**: - Git-CIを活用した自動ビルドとテスト実行の仕組み構築 - コミットメッセージのテンプレート化と自動チェック導入 - プルリクエスト時の自動レビュー割り当てシステム実装 - **コミュニケーション改善**: - SlackのAPIを活用した自動通知システム（ビルド結果、テスト結果、コードレビュー依頼など） - 日韓両言語でのコメント自動翻訳プラグインの導入 - **テスト効率化**: - Espressoを用いたUI自動テストフレームワーク構築 - スクリーンショットテストの導入（視覚的変更の自動検出） ## 【成果】 - コードレビュー時間を40%短縮 - バグの早期発見率が60%向上 - リリースサイクルを2週間から1週間に短縮 - チーム間のコミュニケーションミスを70%削減 # 実績・取り組み ✅ **UIパフォーマンス最適化** - 操作応答時間を平均100ms以内に最適化（業界標準200ms） - メモリ使用量を30%削減し、安定動作を実現 ✅ **国際展開対応** - 10言語対応のローカライゼーションフレームワーク構築 - 地域別カスタマイズ時間を従来比1/3に短縮 ✅ **開発プロセス改善** - Git-CIとSlackを連携させた自動化パイプライン構築 - リリースサイクルを50%短縮（2週間→1週間） ✅ **技術移転と知識共有** - 韓国側チームへの技術移転を主導 - 開発ドキュメントとベストプラクティスの整備 ✅ **ユーザビリティ向上** - ユーザーテストでのタスク完了率40%向上 - アクセシビリティ機能強化による多様なユーザー対応 # 技術スタック ✅ **OS**: Android (組み込み版) ✅ **言語**: Kotlin, Java ✅ **フレームワーク**: Android Jetpack (ViewModel, LiveData, Room) ✅ **ツール**: Android Studio, Git-CI, Slack, Espresso (UIテスト), Figma (デザイン連携) ✅ **その他**: OpenGL ES (カスタムアニメーション), SQLite, NoSQL (食品データベース)

# プロジェクト経験概要 **プロジェクト名:** ImpetBB - ペット専用ソーシャルネットワーキングサービス **期間:** 2020年11月~2021年6月 **担当フェーズ:** 基本設計、詳細設計、開発、テスト、保守・サポート --- # 背景と課題認識 ペット業界の成長と飼い主同士のコミュニケーション需要の高まりを背景に、専用のSNSが求められていました。 従来のサービスでは、以下の課題が顕在化していました： - ユーザー間のコミュニケーションが断絶し、情報共有が十分に行われていなかった。 - クロスプラットフォーム対応が不十分で、iOS と Android 両方の利用者へ一貫したUXを提供できなかった。 - リアルタイムな通知機能の不足により、ユーザーエンゲージメントが低迷していた。 - サービス運用・保守において、効率的な管理体制が求められていた。 --- # チーム情報 - チーム規模: 全7名 - 自分の担当領域: - 全体の基本設計から開発、テスト、保守・サポートまでを担当 - クロスプラットフォームモバイルアプリケーションの開発およびフルスタックの運営管理 - Firebase を用いたリアルタイム通知サービスの構築と「ペットインターンイベント」の企画・運営 - 開発手法: アジャイル開発（定期ミーティング、バージョン管理、CI/CDツールの活用） --- # 開発・実装内容 ## 【概要】 ImpetBB は、ペット専用SNSとして、クロスプラットフォームモバイルアプリケーションおよびフルスタックのシステムを開発しました。 Firebase を活用してユーザーへのリアルタイム通知サービスを実現し、日々のユーザー数を 100 人から 1 万人に増加させることを目標としました。 また、「ペットインターンイベント」の開発・運営を通じ、ユーザーエンゲージメントの向上も図りました。 ## 【どのような機能の開発・実装か】 - クロスプラットフォームモバイルアプリケーションの設計・実装: Flutter を利用して、iOS と Android 両方でシームレスに動作するアプリを構築。 - サーバーサイドの開発およびデータ管理: Spring Boot を用いたサーバーサイドシステムと、MySQL による安定したバックエンドデータ管理を実現。 - リアルタイム通知システム: Firebase を活用し、ユーザーへのリアルタイムな通知配信システムを構築。 - イベント機能の開発と運営: 「ペットインターンイベント」を企画・実施し、サービスの認知度と利用率向上に貢献。 ## 【課題・問題点】 - 複数プラットフォームで一貫したユーザーインターフェースの提供が必要。 - リアルタイム通知により、ユーザーエンゲージメント向上を実現するためのシステム設計が課題。 - サービスの利用者数拡大に伴う運用および保守の効率化が求められた。 ## 【思考プロセスと打ち手・使用した技術】 - UI/UX の再設計: ユーザーが直感的に操作できるインターフェースを目指し、Flutter によるクロスプラットフォーム対応を実現。 - バックエンドの堅牢性確保: Spring Boot と MySQL を用い、安定したサーバーサイドシステムを構築することで、サービスの信頼性を向上。 - リアルタイム通知システム: Firebase を採用し、リアルタイムでユーザーに通知を送る機能を開発。これにより、ユーザーエンゲージメントが向上。 - イベント運営の強化: 「ペットインターンイベント」を企画・運営し、ユーザー参加型のコンテンツで利用者数の増加を図る。 - プロジェクト管理ツールの活用: Swagger、Jira、Slack、Git-CI などを使用して、開発プロセスの透明性とチーム内コミュニケーションを強化。 ## 【成果】 - Flutter を用いたアプリ開発により、iOS および Android 両方での利用者アクセスが実現。 - Firebase によるリアルタイム通知システムで、日々のユーザー数を 100 人から 1 万人に増加。 - Spring Boot と MySQL を組み合わせた堅牢なバックエンドシステムにより、サービスの安定運用を確保。 - イベント機能を通じ、ユーザーエンゲージメントの向上とサービス認知度を大幅に改善。 - Git-CI や Slack を活用したチーム内の連携・コード管理体制の強化により、効率的なプロジェクト進行を実現。 --- # 技術スタック - OS: MacOS, Linux, Windows, iOS, Android - 言語: Dart, Java, JavaScript, HTML, CSS - フレームワーク: Flutter, Spring Boot - DB & Cloud: RDB (MySQL), Firebase, AWS (EC2) - Tools: Swagger, Jira, Slack, Git-CI, Docker, Jenkins, Figma, Postman