ID:6480さん

## プロジェクトの概要 アーリー〜グロース期のベンチャーのBtoBtoCシステムのプロジェクト。 エンジニア4名程度のチームにメンバーとして関わった。 技術選定 / 実装 / 運用すべてのフェーズに携わり、フルスタックエンジニアとして活動した。 ## 私が主に担当したこと - react-native製モバイルアプリの保守 - 複数のモバイルアプリの共通認証基盤作成（nodejs / express） ☆ Amazon Chime sdk を用いたモバイルアプリ/ブラウザ間のユーザとカウンセラー間のビデオ通話機能 ☆ 面談予約機能(アプリ/管理画面連携) ☆ アプリ外の決済/在庫管理システム(決済SaaS仕様) ☆ レガシーrailsアプリの実行インフラの移行(AWS ElasticBeanstalk → AWS ECS + Docker) 注) ☆は技術選定から担当したものです ## ハイライト ### Amazon Chime SDK を用いたモバイルアプリ/ブラウザ間のカスタマーサポート用ビデオ通話機能の実装 【概要】 エンドユーザーがカウンセラーとビデオ通話できる機能を、React Native 製の既存アプリに追加。 面談予約機能と連携し、予約当日にそのままアプリ上からシームレスに通話へ遷移できる導線を設計。 【どのような機能の開発・実装か】 - ビデオ通話SaaSの選定〜実装・リリースまでを一人で担当 - Amazon Chime SDK の採用を主導し、通話UIや接続状態のハンドリングを含めた実装 - React Native 非対応部分をカバーするため、ネイティブ層の実装や修正も対応 【課題・問題点】 - Chime SDK の React Native 対応はライブラリの安定性が低かった - 公式の実装サンプルにもバグが存在する状態だった - それでも他のライブラリよりは安定していた - 可用性の低さにより、サービスとしてはミッションクリティカルにしづらい懸念があった 【打ち手・使用した技術】 - AWSサポートエンジニアとのコミュニケーションを増やし、ドキュメントに記載されていない内部仕様や運用事例も調査した - 通話が不安定な場合には、外部ミーティングツールへ切り替えるフォールバック導線を設計 - 安定性とユーザー体験の両立を意識したビデオ通話機能を実現 ### レガシーRailsアプリの保守・AWS Elastic Beanstalk から ECS + Docker への移行 【概要】 決済機能および医薬品販売管理を担う自社サービスのレガシーRailsアプリにおいて、保守運用と継続的なデプロイの確保を目的としたインフラ移行を実施。 未経験ながらRailsをキャッチアップし、日常的な保守と機能開発を行いながら、中長期的なリスクに備えた環境移行を主導。 【どのような機能の開発・実装か】 - Elastic Beanstalk での継続的デプロイが将来的に困難になることを2年前から予見 - Docker + ECS によるホスティング環境への移行を提案・設計・実装 - PdM・EMと連携しつつも、実装・設計・要件整理などはすべて自身で担当 - e2eテスト環境（Cypress + CircleCI）を構築し、最低限のユーザー導線を担保 【課題・問題点】 - Typescript製サーバへのリプレイスと保守の両天秤でプロジェクトが進まなくなっていた - ミッションクリティカルなサービスのため止めることはできないが、積極的な回収が行われるサービスではなかった - 創業期に作られたRuby on Rails製で、社内の主流な技術スタックから外れていたため、保守の知識を持った人員がいなかった - 技術的負債が多く、メンバーのスキルセット的にもRubyや各種ライブラリのアップデートが困難だった - Elastic Beanstalk に依存したデプロイが継続不能になるリスクが現実化しつつあった 【打ち手・使用した技術】 - Ruby / Railのバージョン追従をあきらめ、リプレイスまで凌ぐ決断をした - Docker化とAWS ECSへの移行により、インフラ更新を最小の工数で実現 - CircleCI + Cypress を用いたe2eテストにより最低限の品質を担保 - 移行期間は約3ヶ月、インフラ移行による業務インパクトを最小限に抑制 - 事前にリスクを察知し、継続的デプロイが不可能になる事態を未然に回避