ID:76300さん

# ポイ活アプリ（iOS/Android）のバックエンドapi・管理画面の作成・新機能開発 アジャイル・スクラム PdM 1名・デザイナー 1名・バックエンド 2〜4名・アプリ 4〜6名 ## 使用技術 - Ruby （2.0から3.2までアップデート)・Ruby on Rails (3.2から4系までアップデート) - Rspec, Sidekiq, graphql-ruby 他gem多数, MySQL, Redis, Fastly,AWS Athena - さくらのクラウド上に構築したインスタンス群 (+手製オートスケールcron) -> Docker + AWS ECS Fargate + ALB + Aurora にマイグレート - NewRelic -> DataDog, CircleCI, GitHub - 管理用データ閲覧画面 TypeScript/Next.js/React ## 概要 プロトタイプがそのまま本番化された状態のアプリに安定化施策を施しながら続々新機能を投入、増え続けるアクセスを捌きながらMAU30万人を捌くアプリに育つまでを経験。 サービスが拡大する中、AWSへの移行やGraphQLを導入。 ### 開発例: データ登録APIのレスポンスタイムを半減させた アプリで一番クリティカルなデータ登録APIが重く、ピークタイムにインフラを圧迫していました。 データ登録の結果としてポイント獲得の詳細はレスポンスで返却する必要があったので、ポイント付与**以外**の全ての処理をSidekiqに避難させました。 結果レスポンスタイムを半減させ、サーバーにだけでなくユーザー体験的にも優しい改修となった。 ### 開発例: GraphQLの導入 それまでのjson apiでの開発では、新規開発のたびにアプリ開発チームとの調整が大変でした。apiの内容を決めきらないとアプリ側の開発が始められず、バックエンド開発者にはプレッシャーとなっていました。 そこでGraphQLの導入を決意。graphql-rubyとgraphql-batch gemを導入し、一発目のapiの実装を担当しました。 クライアント側で汎用ライブラリが使えるようになり、型定義の手間が一気に減りました。

創業メンバーだったCTOの退職により、開発部の実質的なリーダーとして稼働 - 進捗管理・プロダクトマネージメント - ビジネス層との折衝・経営会議への参加 - 部の技術力・モチベーションアップ施策 週一での勉強会やバグバッシュの開催等 - 採用活動 各種媒体への出稿から面接対応・部レベルの合否判定まで ### 事例: FAQサイトの作成 ヘルプページがアプリ内に静的ページとして埋め込まれており、更新の度にリリースが必要でQAチームの希望するスピード感が出せていませんでした。 リッチCMSの構築が要望として上がりましたが、工数が多く車輪の再開発になると反対しWordPressによるヘルプサイトの構築を提案しました。 結果ほぼインフラ作業のみでスピーディに構築完了。迅速なヘルプ更新環境を実現しただけでなく、別システムにしたことで障害時のお知らせ表示にも使用可能になりました。 実際の作業は、ちょうど良い小ささだったので評価も兼ねGKE上に構築・Terraformの使用もこのタイミングで始めました。 ### 事例: 経験者を採用しFargate+Aurora環境へ移行 さくらのクラウドでの運用に限界を感じていたのですが、コンテナ環境への移行にはチーム内に経験者がおらず二の足を踏を踏んでいました。 そこで「新しいインフラ構築のチャンスがあります」をキーワードに採用活動を積極的に展開。経験者を採用することに成功しました。 稼働後は徹底的にサポート、Fargate+Auroraのモダンな環境へのマイグレートを成功させました。

アジャイル・スクラム PdM 1名・デザイナー 1名・開発 2〜4名 ## 使用技術 Ruby on Rails, Rspec, Capybara, Sidekiq, devise, AASM, CanCan 他gem多数 さくらのクラウド / MySQL / Redis / Jenkins / NewRelic / GitHub ## 概要 クライアント依頼の店舗覆面調査等の案件をユーザーに実施してもらい、結果をアンケート形式で提出してもらい集計の上納品するwebサイトのリニューアル。リリース後は運営・障害対応等。 ### 開発例: 楽観ロックを使用した競合回避 ユーザーに記入してもらうアンケートは長大で、早い段階から一時保存の機能を提供していました。 その後機能を流用し自動一時保存の機能をリリースしたところ、「入力内容が途中で消えた」とのクレームが届くようになり、調査したところ `写真添付のため一度スマートフォンに移動し、添付後PCに戻る` 操作でPC側の入力内容がなくなるケースがあることが分かりました。デバイス間での編集の競合が原因でした。 そこでrailsの楽観ロックを参考に（機能そのままは一時保存が実際にはレコードの新規登録だったため使えなかった）最新バージョンを編集元にしない一時保存リクエストをリジェクトする仕組みを開発、クレームの根絶に成功しました。 ### 開発例: AASM gemの採用 アンケート回答には 運営側のレビュー・差し戻しの機能もあり `回答が今どの状態にあるか、該当の状態の場合ユーザー・運営のそれぞれがどの操作ができるか` が非常にややこしい要件でした。 そこでAASM gem を導入。ステートマシンの考えを導入し、controllerにはステートの遷移のみを記述・model内で遷移ごとのコールバックとバリデーションにビジネスロジックをまとめました。 結果コードの見通しがよくなり、運営側も把握しきれなくなっていた仕様の再整理にも繋がりました。