S

# 概要 イベントチケット販売用ECサイト開発プロジェクト。 - 既存サイトのリプレース - 販売商品の多様化のための追加開発 - イベント向けインタラクション機能、イベント用ポータルサイトの開発 - ユーザー向けReactによるフロントエンド開発とバックエンドAPI化リプレース - 管理者向けReactによるフロントエンド開発とバックエンドAPI化リプレース - パフォーマンス改善 など継続的な開発と運用に従事。 ## プロジェクト詳細 プロジェクト管理ではカンバン 方式の手法を採用しており、イテレーション毎に振り返りを行うなど、積極的に改善を目指していく環境。 先方のエンジニア2人、自社内のエンジニア3 ~ 4人の計5 ~ 6人チームで開発。 プロジェクト内での役割としましては自社内のテックリードを担当しているエンジニアのサポートとして - 設計時の課題発見・解決 - 先方との仕様調整や工数相談 - 大きめのタスクを巻き取る - コードレビュー - 後続のエンジニア2名の育成 等を行った。 ### 販売商品の多様化のための追加開発 購入制限機能、枚数割引機能を開発。 購入制限では、特定のユーザーのみ購入可能な場合や、特定の商品を購入している場合購入可、または不可といった複数の種類が想定されていました。 そのため、購入制限テーブルでは上記の購入制限の種類を表すtypeカラムとそのtypeのenum別で専用のclassを用意することで、enum別の処理を別classへ逃しました。enum別の条件ではJSONを格納できるカラムを用意することで設定値を柔軟に持たせられるようにしました。購入制限テーブルの小テーブルとして三種類の購入制限機能を用意する案もありましたが、当時はそこまでする必要はないという結論に至りました。 枚数割引も所持枚数によって割引額が変わる仕様上、柔軟性のあるデータ構造の方が都合が良かったため、JSONを格納できるカラムへの保存にしました。 ### イベント用ポータルサイト開発 イベントに来場された方がスマホで整理券を発行したり、決済できるようにするために開発。 整理券を発行したり、決済の情報をタイムラインで見れる機能を作成。 タイムラインでは最新情報をトピックとして画面上部に目立つように表示し、タップするとその情報のページへ遷移しトピックからは消える（既読）機能が要望としてあったためタイムラインテーブルとは別にトピックのみRedisを使用し、既読機能を実装しました。 ### 管理者向けReactによるフロントエンド開発とバックエンドAPI化リプレース #### プレビュー機能を開発 プレビュー機能を設計から担当。 一般ユーザー用のViewとバックエンド、管理画面はそれぞれ別のサーバーという前提で非公開のイベント情報を管理者だけ見れるようにしたい。 管理画面上から一般ユーザー用のViewをみたいという要望。 プレビュー対象のViewからコードをコピペだと修正時に作業が2倍になるデメリット、HTMLを取得しdangerouslySetInnerHTML等で描画も動作が保証できない、今後の機能追加の要望次第ではネックになるため実装方法に悩みました。 結果としては、一般ユーザー用フロントエンドにプレビュー用のパスを用意し、対象Viewを再利用、管理画面から一般ユーザー用のViewを開く際、Web Messaging APIを使用し、ブラウザ間でtokenを渡すことで一般ユーザー用のViewから管理者用の認証を通すことで課題を解決しました。 #### Lint設定 今回のイテレーションではエンジニアが4~5人のチームだったのですが、 仕様の把握と実力から先方のエンジニア1名がほぼ全てのPRをレビューすることになりました。 レビューの負荷を減らすため、Slaskで流れてくるレビューを見ながらLintで対応できるところは設定を次々に足して行きました。 eslint-plugin-importを使用したimport順や改行の指定、厳密等価演算子の指定、if文での波括弧指定等。 ### パフォーマンス改善 主にSlow Queryの改善を行いました。 bulletというN+1問題を検知するGemを使用した問題箇所の抽出やnewRelicを確認し、重そうなところから一アクションずつEXPLAINを確認、以下のような改善を実施。 - N + 1対応 - indexの追加 - Using filesort, Using temporaryを出ないようQueryの調整 - Redisへcache - ページング機能提案

案件終了から次の案件まで１週間ほど空き時間ができたため自社内の自社でのビデオシステム開発に従事。 いくつかの課題が見えたため、改善を行った。 ## 環境構築方法の改善 つまづきポイントが多く、ドキュメント通りに構築しても半日 ~ 1日程度かかる状態だった。 - Railsプロジェクト内のViewにReactが使われている状態だったのだが、パッケージ管理でnpmとyarnが使われていた - RailsはLocal上で起動、Postgre SQLはDocke Compose上で立ち上げる そのため、Docker Compose上に構築。 現在の方法でも起動できるようにしたいという要望もあったため、それにも対応。 ## コードの読みやすさと保守性を改善 - コードの書き方が統一されていない - デグレがよく起こる バックエンド側はRubocopとRspecが導入されていましたが、フロントエンドは何もなかったためESLint, Jestを導入。 そしてCIを使った自動テストを導入。 導入コストの低さからGithub Actionsを採用し、Push時にBuild, Lint, Rubocop, Jest, Rspecをチェック。 工夫したこととして、Github ActionsではCIの実行速度を早くするため、node_modulesやgemをキャッシュするよう対応。 ## その他 他にも、 - Github上のissueが管理されておらず誰が何をやっているのか、どれが終わっているのかがわからなかったため、タスクの整理 （自社のビデオチャットシステムでは、案件が空いている人が入るという運用上、経験が浅い方が多い背景があります） - アサインやタグを使用し、誰が何をやっているのか可視化 - コミュニケーションミスが多発していたため、毎朝朝会を開催 - 昨日やったこと、今日やること、困っていることを共有 - 意思決定時にissueやPRに残すよう共有 - issueやPRにテンプレートを導入 ちなみに私もビデオチャットプロジェクト開発にアサインしたからにはwebRTC周りの技術に着手したかったですが、期間（1週間）とプロジェクトの運用自体の改善を期待されていたため、断念しました。。 個人で粛々と学習しております。 https://codesandbox.io/s/web-video-2n3ix

大手出版社にも使用されている漫画配信サービスのプロジェクトにアサイン。 出版社とその読者を対象としたB to B to Cサービス。 出版社がこのサービスを利用しコンテンツを管理、読者が利用するアプリへコンテンツ配信を行う。 - ログやレコードの肥大化対応 - Slow Query改善 - コンテンツの一括非表示機能追加 - APNs http/2化、ノンブロッキング処理追加 - ランキング機能追加 初の10年近く稼働しているサービスへのアサイン、これまでみてきた中でもコード量が最も多く、複雑なシステムでした。 仕様書はなく、アプリのUIも確認できないところからのスタートで仕様の理解を深めるのに苦労しましたが、分からないところはコードリーディング、GithubやRedmineのログ、先方に質問するなどして徐々に理解を深めました。 現在自社エンジニア2名でのアサインですが、今後1名になる予定で、もう一人のエンジニアは2年近くこのプロジェクトに参加してしますが、お客様としては11月末以降は私を継続したい要望をいただき、3ヶ月と短い期間ですが一定の信頼を獲得することができました。

既存で開発チームがあったがそのチームとは別に二つ目の開発チームの開発リーダーとして参画。 ## Googleソーシャルログイン開発 ## Apple, MicroSoftソーシャルログイン開発 ## ログイン画面の機能改善