こあら

# 概要 婚活相談所と提携をして、婚活ユーザー向けの洋服レンタルサービスの新規開発を行った。 ユーザー管理、予約システムとコーディネート作成システムを開発した。 # チーム規模 9人(婚活アドバイザー3人、営業1人、スタイリスト2人、エンジニア3人) # 役割 テックリード # 使用技術 Ruby Ruby on Rails TypeScript Next.js Vercel MariaDB Bubble # 担当業務 ## 提携先会社とのコミュニケーション 提携先である婚活相談所と現状どのような課題があり、どんなユーザー体験を作るかの部分からコミュニケーションをとった。 提携先の事情も加味しつつ、技術的にどのような解決策があるのかを一緒に考えながら進めていくような立ち位置。 ## 要件定義、基本設計 要件定義から、どのような技術構成で行うかまで担当した。一部システムはノーコードツールの採用を行うことでスピード感とメンテナンス性を意識した。 サーバはEC2をAuto Scaling設定を行い2つのインスタンスで動かすように採用した。 DBはRDBをマスタースレーブ構成で採用した。 ## 担当した開発・実装1 ### 概要 ユーザー管理画面の実装 ### どのような機能の開発・実装か 提携会社と自分たちの会社で使うユーザーのを管理する画面を設計、実装する。予約、コーディネート作成、出荷、返却を一元で管理できるシステムを実装した。 ### 課題・問題点 提携先会社の運用フローを変更せずにシステムを作成しなければいけなかった。また、提携先会社の意見をある程度参考にしつつも、将来的に保守する自分たちの保守工数を考えながら最低限の実装にすることを意識した。 ### 使用した技術 【フロントエンド】 TypeScript, Next.js 【バックエンド】 Ruby, Ruby on Rails 【インフラ】 Vercel ## 担当した開発・実装2 ### 概要 コーディネート作成画面の実装 ### どのような機能の開発・実装か ユーザーへ提供するコーディネートを選択し、QRコードでピックできるシステムの実装をした。 ### 課題・問題点 1からコーディネートを選んでいると、1ユーザーあたりにかけられるコーディネートを選んでいる時間が膨れ上がってしまい、スタイリストの時間がなくなってしまう。 そこで、コーディネートをパターン化してユーザーサイズを加味したコーディネートを自動で作成するロジックを実装した。自動で作成されておかしかった部分は学習をさせることでより精度の高いコーディネートを作成するようにした。 * 1ユーザーあたり手動ならば20分かかる作業を5分に短縮することに成功した。 * 学習させることで今後より短くなっていくと思われる。 ### 使用した技術 【フロントエンド】 TypeScript, CreateReactApp 【バックエンド】 Ruby on Rails 【インフラ】 Firebase

# 概要 既存のRuby on Rails ActionViewをReact(LINE Frontend Framework, LIFF)にリプレイスするプロジェクトに参画した。 # チーム規模(構成) 4人(PdM1人、エンジニア3人) # 期間 2022/6~2022/8 # 担当 テックリード # 使用技術 Ruby Ruby on Rails React TypeScript LIFF Firebase Bitbucket Bitbucket Pipeline ## 課題 古くなったユーザーマイページがメンテナンス性が悪く、少しの修正でも時間がかかっていた。原因として対象箇所のコードが古かったこととテストコードが書かれていないことが大きな原因だった。 ## 解決策 1. 現存のマイページのサーバ部分のテストコードを記述する 2. Rails API をテストが通るように実装する 3. React(LINE Frontend Framework, LIFF)にリプレイスする ## 成果 * 開発スピードが2.2倍早くなった * 大きな不具合なくリプレイスすることに成功した

# 概要 Ruby on Railsで作成されたアプリケーションのGemアップグレードプロジェクトを発足して、1年半ほどで4.0から7.0に上げることに成功した。Railsのアップグレードが全く行われていないことから新しい機能の恩恵が受けられていない状況にあり、またメンテナンス性の低いコードになっている箇所が多かったため、Railsのアップグレードをプロジェクトとして実施した。 # チーム規模(構成) 4人(エンジニア4人) # 担当 テックリード # 期間 2021/9 ~ 2022/12 # 技術 Ruby on Rails attr_encrypted MariaDB EC2 RDS # 困難だったこと Rails6.1からRails7.0にアップグレードする際に、Rails6.1まで使っていた暗号化ライブラリがRails7.0から使うことができず、約100万行のデータを利用できるようにデータ移行しなければいけなかったことだった。 # 解決策 絶対に避けなければいけないのはデータ不整合、紛失なので、2つのことを特に意識しながら実装をした。 1. データ移行環境の構築 2. クエリ発行数を最小化 1に関しては、まず本番環境で使っていたEC2インスタンスとRDSインスタンスのレプリケーションをして本番と同じ環境を新たに用意し入念にテストを行った。テストを行った後にロードバランサーを変更してリリースを行い、また、リリース時にスナップショットを作成してデータ紛失が起きないように徹底した。 2では、クエリ発行数を検知できるライブラリを用いることで、クエリの発行数を最小に抑え、コスト削減とメモリ逼迫によるサーバーエラーが起きないよう心がけた。 # 成果 * バージョンアップ前にはなかった機能(ActiveRecordの新メソッドなど)を使えるように * Railsに依存関係にあるGemのバージョンを上げられるように * 問題なくRails7.0に移行することに成功した

# 概要 大手銀行向けの文書管理システムに要件定義と顧客折衝を従事した。 主に大手銀行の社内向けに作られた文書管理システムを海外の支社でも使えるようにするプロジェクトに従事した。要件定義から設計まで担当。 # チーム規模 30人 要員数10人 # 役割 メンバ # 技術 Java Spring Framework Oracle Database # 担当フェーズ 要件定義 設計 テスト # 成果実績 ## 要件定義 要件定義フェーズでは、海外のどこの国からリリースするか、最初のリリースに必要な要件を実際に海外で働いているクライアントにヒアリングをしながら行った。 ## 設計時間の短縮 設計フェーズでは現存しているシステムのコードから必要な箇所のクラス図とIPO、画面を設計した。Javaで書かれているコードを1から手動でクラス図を作成するのではなく、自動化ツールを用いて、修正が必要な箇所のみを手直しすることで時間の削減を行うことができた。 ## 動作確認時間の削減 テストフェーズでは、スナップショットを撮った後にExcelに挿入する作業をVBAで自動化して時間を短縮しながら実行することに成功した。 社会人になって初めてのプロジェクトでドメイン知識も浅かったため、先輩SEとコミュニケーションを積極的にシステムの目的から教えてもらいながらリリースを完遂することができた。

# 概要 新サービス立ち上げに伴った検証環境の構築を行った。 # チーム規模 3人(CEO 1人、マーケティング1人、エンジニア1人) # 使用技術 Google Analytics 4 BigQuery Looker Studio Ruby on Rails # 担当業務 * 仮説と検証内容のすり合わせ サービスで大事にしたいこと、仮説と検証をCEOとマーケティングとすり合わせを行った。 * 検証環境の構築 どのデータが必要なのかを洗い出し、別データを紐づけるための設計をした。 検証環境に最適で、かつアプリケーションと疎結合な環境を作ることを意識した。 # 成果実績 ## 課題 * Redashを自らデプロイ管理して運用していた * RedashはアプリケーションのDBに直接クエリを問い合わせていた * アプリケーションデータとユーザー行動データの紐付けができていなかった * マイクロサービス毎のデータの検証をすることができなかった * データ分析分野は専門外であり、かつ社内にナレッジがなかった ## 解決策 * デプロイ管理が必要なく、かつGoogle Analytics 4やGoogle Firestoreとの相性も良いBigQueryを採用した * アプリケーションのデータを直接触る構成ではなく、BigQueryに検証用スキーマを用意してそこに問い合わせるようにした * Looker Studioで必要に応じてグラフィカルな情報のダッシュボードを作成した * 社外からスポットコンサルをしてもらい、アドバイスをもらいながら実施した ## 成果 * Redash管理をする必要がなくなり、アプリケーションDBを検証用に問い合わせることのリスクを回避できるようになった * Google Analytics 4上の情報とアプリケーション上の情報を検証できるようになった * マイクロサービスごとの検証を行えるようになった * 社内で検証の重要性を文化的に浸透させた