ID:70169さん

# プロジェクト1: マッチングアプリ開発プロジェクト ## 概要 自社サービスで運営しているマッチングアプリの開発プロジェクト。 サービスの改修や新規機能追加が主な開発業務。 ## チーム情報 - エンジニア - エンジニアマネージャー: 1名 - メンバー: 4名(含む: 私) - デザイナー: 1名 - ビジネスサイド - プロダクトマネージャー: 1名 - ディレクター: 4名 - マーケター: 2名 その他、SREチームやカスタマーサポートなど。 # 開発内容1: デート中の男女のコミュニケーションサポート機能 ## 機能概要 男女にお互いのアプリ上のQRコードを読み取ってもらい、コンテンツやクーポンを表示するなどして、デート中のコミュニケーションサポート機能 ## 開発の流れ - 企画から仕様策定まで - 企画の草案はディレクターから起案された - 機能の検討は私を含めたエンジニア2名で調査から担当 - 仕様の擦り合わせは、ディレクターと私を含めたエンジニア2名で行う - 設計から実装まで - API設計, DB設計の草案は私が作成し、エンジニアマネージャーにレビューいただいた - 実装は2名で担当し、私がフロントを7割, バックエンド3割を担当 ## 苦労した点 ### 1. 機能自体の検討からエンジニアが担当 - QRコードを利用した機能についてディレクターサイドの知見が浅かったため、企画の詳細部分についてはエンジニアへ依頼された - QRコード自体の仕様から調査し、どのような機能にできるかを検討 - セキュリティ面に関しては、機能の実態を勘案して、どの程度まで許容できるかを検討 - なるべく早く実装したいという要望があったため、既存テーブルを利用して最小限の工数で済むような設計を行った ### 2. QRコードの読み取りが未実装であった - アプリ内にQRコードの読み取り機能が未実装であったため、ライブラリ等の調査・比較検討から行なった ## 使用した技術 バックエンド: Ruby on Rails, フロントエンド: Vue.js - QRコードの生成には、バックエンドにてRubyのGem(ライブラリ), 読み取りにはフロントエンドにてJavaScriptのライブラリ(jsQR)を使用した - どちらもGitHubでのスター数が多く、メンテナンスも活発であったため採用した - `Barcode_Detection_API`というWeb APIの利用も検討したが、Experimentalであり、対応ブラウザが限られていたため断念した - 対象ユーザーかどうか等のバリデーションについては、バックエンドにて実装済みであったキャンペーン機能などを流用した # 開発内容2: eKYCを利用した本人確認機能 ## 機能概要 外部のeKYCサービスを利用した本人確認機能。マッチングアプリは業者による悪質な利用が多いため、本人確認機能の実装が求められていた。 ## 開発の流れ - 企画から仕様策定まで - ディレクターから起案 - 複数のeKYCサービスを比較検討したため、その際の技術的な検討は私が行った - ネイティブアプリでの挙動に関しては、ネイティブ担当の委託エンジニアと調査・動作確認を行なった - 設計から実装まで - DB設計、API設計等を含め、私が担当 ## 苦労した点 ### 1. 外部APIを使う際の各種設定 - API利用には、APIキーの発行や、SSL証明書の設定が必要であった - 本番やステージング環境を含めた各環境サーバーに、APIキーの設定やSSL証明書の配置を行う - API利用に関わるロジックをサービスクラスに切り出し、このAPIをアプリ内で汎用的に利用できるようにした ### 2. どの程度の柔軟性を持ったDB設計にするか - 将来的に外部サービスを乗り換えた際の柔軟性まで考慮するか否かに悩み、いくつかのDB設計を比較検討した - 結果的には、柔軟性の低さを許容し、最もシンプルなDB設計で実装した - 各種eKYCサービスのAPIレスポンスのデファクトスタンダードがあるか怪しかったため、過度な柔軟性を持たせることは避けた - ビジネスチームの動きから、頻繁な外部サービスの乗り換えは想定しづらいと判断した ### 3. リーダー業務との兼務(やや番外) - リーダーを任されたタイミングでの開発であったため、リーダー業務との兼務が課題となった - タイムマネジメントに関しては現在も模索中であり、日々奮闘している ## 使用した技術 バックエンド: Ruby on Rails, フロントエンド: Vue.js + TypeScript ### 基本的な処理の流れ - フロントエンドにてeKYCを呼び出す - 本人確認書類や顔写真等を撮影した後、外部サービス側のDB保存される(なお、ここはiframe内にて動作する仕様であった) - この時、固有IDが発行される(注1) - バックエンドのAPIに対して、フロントで取得したeKYCの固有IDを送信 - バックエンドにて、eKYCの外部API呼び出し、固有IDに基づく本人確認結果のステータスを取得 - 結果をDBに保存し、ユーザー情報と紐付る - フロントにて、バックエンドからの本人確認結果を取得 - 本人確認結果に応じて、ユーザーに対しての画面表示を変更 フロントエンドについては、eKYCのドキュメントの内容を反映した型定義を行なったため、他エンジニアも改修がしやすい形となった。 注1: この時に本人確認の結果もレスポンスとして渡るが、セキュリティ面を考慮し、バックエンドにて再度外部APIを呼び出す設計にした

# プロジェクト2: 1対1相席サービスアプリ開発プロジェクト ## 概要 新規事業である、実店舗で1対1でお相手とマッチングできるサービスにおいて使用されるアプリの開発プロジェクト。 主要機能は、プロジェクト1の機能の一部として実装されており、マッチングアプリとのシームレスな連携が求められた。 ## チーム情報 前述のプロジェクト1のチームの中から、メンバーを抽出して構成されたチーム。 - エンジニア - メンバー: 2名(含む: 私) - デザイナー: 1名 - ビジネスサイド - ディレクター: 1名 その他、SREチームやカスタマーサポートなど。 ## 全体的な開発の流れ - 新規事業の始動 - 経営陣からの要望により、新規事業の立ち上げが決定 - コンセプトやサービス内容の大枠はこの時点で決定 - 物件確保や工事と並行して、開発依頼がスタート - 企画から仕様策定まで - コンセプトに基づき、ディレクターがフレームワークを作成 - ユーザーの利用導線 - スタッフ側のオペレーション - フレームワークをもとに、デザイナーがUI/UX面から、エンジニアが技術面からそれぞれFB - 設計から実装まで - DB設計やAPI設計は、エンジニア2名で担当。草案はもう1名のエンジニアが担当し、私がレビュー・壁打ちとして設計に参加。 - 私がフロントエンド、もう1人がバックエンドを担当 ### 主な担当範囲 - 私が担当したもの - ユーザー操作画面 - LP（WordPressで構築） - 登録導線のフロント・バックエンドの処理、社内製の共通IDサービスとの連携 - もう1人が担当したもの - 予約等の処理 - スタッフ操作画面 各部署とのやり取りや、アプリ機能のレクチャーなどは私が主導して進めた。 # 開発内容1: ユーザー利用画面 ## 機能概要 ユーザーが、予約段階から、店舗を来店しサービス利用、退店までに利用する画面。 - 来店予約画面 - 自身のプロフィールや、マッチ相手からの評価スコア - 店舗でマッチ中の画面 - お相手のプロフィールや残り時間 - 評価機能 ## 苦労した点 ### 時間的制約から、仕様の細部や、デザインがない状態で開発をスタートせざるを得なかった - コードの骨格となるであろう部分から先に実装を進めた - 細かいUIを省いた主要機能や、画面遷移 - ワイヤーフレームやデザインが完成してからも、細部については都度調整が入った - 仕様の不確実性をコミュニケーションでカバーしながらの開発のなった ## 使用した技術 バックエンド: Ruby on Rails, フロントエンド: Vue.js + TypeScript ### トピック1: TypeScriptの本格導入 - それまでも実験的にTypeScriptの使用はされていたが、今回の開発が本格的な導入となった - それまでの開発では、多機能に影響のない箇所のみで利用する程度であった - 今回の開発では、フロントエンドの全てのファイルをTypeScriptで記述することとなった - 導入の可否やメリットデメリットを含めて私が検討した - コードの安全性や開発効率向上、また今後のチームの技術力向上を見据え、導入を提案した - 「不慣れであることから通常のJavaScriptに比べて、開発スピードが落ちるのでは」という懸念もあったが、1週間ほどの猶予をもらい、実際に開発を進めてみたところ、予想以上にスムーズに進んだため、導入を決定した - TypeScriptの導入に伴い、各種パッケージの導入や更新も行った ### トピック2: Store Design Patternの導入 - これまでVuexに全てのデータを集約していたが、今回の機能ではStore Design Patternを導入した - Vuexのように、全てのデータを集約することなく、新規事業の機能に必要なデータのみをStoreに保持することができるようになり、データの管理が容易になった - APIレスポンスへの型付けも行なったため、データの取り回しがしやすくなった - Store Design Patternのアイデア自体はマネージャーからの提案がきっかけであったが、私が設計から実装を担当した - これ以降、新規事業の機能以外での開発でも、Store Design Patternを導入することが多くなり、プロジェクトの全体の開発効率向上につながった # 開発内容2: 各導線からの登録機能と、それに付随するトラッキングへの対応 ## 機能概要 今回のサービスは、様々な導線からの登録を想定されていた。 - LP - マッチングアプリ内 - 街コンイベントページ それらの導線からスムーズに登録できるようにし、かつトラッキングによる分析を行う仕組みを構築した。 ## 苦労した点 ### 1. 他部署との連携 - 新規事業のユーザー登録には、弊社サービス間で共通のIDサービスを使用する必要があった - このサービスと連携するにあたり、共通ID開発チームと仕様の擦り合わせや、テスト・修正のやり取りを行った - 部署をまたがる開発は通常よりも工数の増加が見込まれるため、先に開発できる箇所は先に開発を進め、他部署との連携が必要な箇所は、開発の最後に回すようにした ### 2. トラッキングのテスト - トラッキングのテストには、本番環境でのGTMやGAの設定が必要であった - テストのタイミングが限られていたため、クロスドメインにまたがる箇所などは、リリース後もテストを継続する必要があった - 問題が発生した際には、それが実装側によるものなのか、あるいはGA等の設定によるものなのかを切り分ける必要があった - 公式のドキュメントの確認 - 実際にGAの設定を行なった経験のあるエンジニアに相談 ## 使用した技術 バックエンド: Ruby on Rails, フロントエンド: Vue.js + TypeScript ### トピック: Railsのセッション機能を利用したトラッキングの設定 - 共通IDが別ドメインである（別アプリである）ことや、認証のために登録時にバックエンドに遷移する必要性などから、単にクッキーやクエリパラメータを利用したトラッキングでは対応できなかった - 解決策として、Railsのセッションにトラッキングの各種IDを保存した - フロント側に遷移する際に、セッションから取得したIDをパラメータ等に付与することで、トラッキングを行うことができた - ローカル、ステージング、本番で使用しているSesstion Storeが異なっていたため、認証周りのコードまで読み込む必要があった