JayGatsby

# 「トルー」の開発 ## プロダクト概要 採用CMSアプリ「[トルー](https://toroo.jp/)」の開発・運用をした。 一言で言うと、**企業の採用活動を効率化**するWebアプリケーション。 直接的な競合サービスは、採用係長やジョブカンATSなど。 具体的には、以下の機能が強み。 - 求人情報と応募者情報を一元管理 - 自社専用の採用サイトをノーコードで構築 - IndeedやGoogle For Jobs、Facebook Jobsなどの求人サイトとAPI連携 ## プロジェクトの規模 - **開発メンバー:** 2021年4月時点で4人（私とオフショア3人）。多い時で7人（私を含めた日本人4人、オフショア3人） - **開発期間:** 2018年8月〜2022年4月（3年9ヶ月） - **ARR:** 2020年度の売上は1.2億円 ## 技術スタック | | 技術スタック | |----------------------|-----------------------------| | フロントエンド | Slim, jQuery, Vue.js | | バックエンド | Rails, Python | | DB | MySQL, Redis | | インフラストラクチャ | AWS, Docker, CircleCI | | 開発支援ツール | GitHub, Slack, Chatwork | ## 担当役割 プレイングマネージャー（`PjM`、および`フルスタックエンジニア`）として**企画以外を全て担当**していた。 プロダクトロードマップや新規機能発案などの大きな"企画"と言われる部分は`PdM`が担当し、それ以降の要件定義・設計・コーディング・テスト・運用保守・データ分析を全て担当した。 # 出したバリュー ## パフォーマンス編 1. `N+1問題`を解消して、`DB`の`CPU使用率`を90%から60%に改善 - **課題 :** `N+1問題`が散見されていたが誰も修正せずに放置されていた。 様々な負債と相まって、`DB`の`CPU使用率`が90%に達してパフォーマンスが著しく低下していた。 - **工夫点 :** `bullet`というgemを提案・導入して、**N+1問題を解決・再発防止に成功**した。 <!-- また、データ肥大化に伴い上記解決方法ではメモリ効率が悪いケースもあったので、`pluck`も駆使してメモリ効率を考えながら解決した。 --> 2. 処理時間9時間 && メモリ使用率100%のバッチ処理を、処理時間20分 && メモリ使用率30%に改善 - **課題 :** 初期トルーでは求人データの登録手段は手作業のみだったが、CSVを用いた一括登録機能を実装したことにより、**従来の約100倍のペース**で登録される様になった。 具体的には、初年度は数千件程度だった求人データがが、1年で100万件を超えた。 また、トルーはXMLファイルを用いてIndeed, Facebook, 求人BOXに求人情報を連携しているが、掲載する求人データを1回のSQLで全て取得していた。一括登録機能の実装後は求人データ急増により、**メモリ使用率が100%に達しXMLファイルを作成できなくなった**。 - **解決方法 :** スロークエリログから根本原因がインデックスの貼り忘れであることを特定し、インデックスを貼ることで処理時間を20分に改善した。 データ取得処理・ファイル書き込み処理を小分けに処理することでメモリ使用率を30%に改善した。 - **工夫点 :** `lol_dba`というgemを提案・導入して、**DB全体のインデックス貼り忘れを修正・再発防止に成功**した。 `in_batches`メソッドを用いてSQLを小分けにするだけでなく、**ファイル書き込み処理も小分け**にすることでメモリパンクを半永久的に再発防止した。 `CloudWatch`を用いて**CPU・メモリ使用率の監視・通知を実装することで早期発見・再発防止に貢献した**。 3. ループ処理中にメモリ使用率が100%に達してサーバーが動かなくなった不具合の修正 - **課題 :** 上記2番とは別の課題。 大量のデータを一度にメモリ展開していた（100万レコードに対して`each`を使っていた）。 - **解決方法 :** データを1,000件ずつ取得することでメモリパンクを修正した。 - **工夫点 :** メモリパンクした箇所に留まらず、**プロダクト全体で同じ脆弱性のあるコードを全て修正した** （`each`を`find_each`や`in_batches`に置換）。 `pluck`を用いて、無駄なデータを取得しないようにデータ取得サイズを軽減させた。 4. `BULK INSERT`を実装して、処理時間を20分から7分に改善した。 - **課題 :** 従来のバッチ処理では大量のデータを1行ずつINSERTしていたので処理速度が遅かった。 - **解決方法 :** `activerecord-import`を用いて`BULK INSERT`を実装することで、処理速度を半分以下に改善した。 - **工夫点 :** `BULK INSERT`の際は`ActiveRecord`を経由せず直接`SQL`を実行するので、バリデーションやコールバックが発火されない。 なので、`BULK INSERT`のバッチ処理からも`ActiveRecord`からもバリデーションロジックを切り離し、独自のバリデーションクラスを実装することでデータの不整合が起こらないように一元管理した。 また、プルリクエストのテンプレートにチェックリスト作成を提案・導入することで、今後実装されるバッチ処理の再発防止に貢献した。 5. リードレプリカの導入でエンドユーザーへ返すレスポンスが12秒から3秒に改善 - **課題 :** 求人数の急増に伴い、上記課題1〜4を改善しても MasterDBの`CPU使用率`が80%を超えた。 - **工夫点 :** リードレプリカを導入することでエンドユーザーが閲覧する採用サイトのレスポンスを改善した。 パフォーマンスインサイトを導入し、ボトルネックの可視化・監視体制の構築をした。 6. 毎日のCSVインポート件数を20分の1に削減 && 論理削除された求人データを物理削除することでDB容量を80GBから70GBに削減 - **課題 :** Indeed SEOの仕様を活用し、CSVインポートを用いて求人情報を全部論理削除・新規作成を繰り返し行う企業が増え、求人データが1年で100倍になった。 - **工夫点 :** 全部論理削除・新規作成をしなくても済むようにIndeed専用のIDを導入することで、求人データ爆増を防いだ。 同時に、論理削除されたデータを物理削除することで、DBの容量を削減した。 ## セキュリティ編 1. `SQLインジェクション`や`XSS`、`CSRF`などの修正 - **課題 :** `SQLインジェクション`の脆弱性があるコードが散見されていたが、誰も修正せずに放置されていた。 - **工夫点 :** `brakeman`というGemを提案・導入して、**脆弱性のあるコードを全て修正・再発防止に成功** した。 2. BIツールを用いてDBの情報を社内に共有 - **課題 :** トルーの現状把握・データ分析のために、エンジニア以外の社員も`DB`を直接閲覧していた。 - **工夫点 :** Googleデータスタジオ（現 Looker Studio）を提案・導入することで、DBに直接接続することなく必要な情報のみ閲覧できる様にした。 3. `Trustred Advisor`を用いてセキュリティ強化 - **課題 :** AWSを使っているが、インフラセキュリティに知見がないメンバーしか居なかったので網羅的セキュリティを評価できない状態だった。 - **工夫点 :** Trusted Advisorの提案・導入することで、セキュリティ堅牢度の向上に貢献した。 具体的には、`WAF`の導入、`S3`のバージョニング、`ALB`のログ保存、`CloudWatch`で`CPU/Memory`の監視を設定した。 4. `WAF`の導入 - **課題 :** トルーの採用サイトに対して`DDoS攻撃`が発生していた。 - **工夫点 :** `WAF`を導入することで、`DDoS攻撃`を防ぐことに成功した。 ## コスト削減編 1. `ALB` と `ACM`の使い方を見直して、**年間50万円（層インフラ費用の5％）のコスト削減** に成功。 詳細は以下URLを参照。 [https://qiita.com/Gatsby/items/933c5a93e5900865b7d2](https://qiita.com/Gatsby/items/933c5a93e5900865b7d2) 2. 未使用ドメインを解約して、**年間20万前後のコスト削減** に成功。 - **課題 :** トルーでは企業毎に独自ドメインを発行しているが、解約済み企業のドメインを解約せずに毎年自動継続更新をしていた。誰もドメインの管理をしていない状態だった。 - **工夫点 :** 解約してもすぐ再契約する企業もチラホラ存在した為、トルー解約から1年経つ企業のドメインを解約するように実装した。 また、ドメインが悪用された場合のクレームや損害賠償に備えて、利用規約にドメインの解約に関する記述の提案・修正もした。 ## リファクタリング編 1. モデルに`schema`情報を記載 - **課題 :** Railsではモデルとテーブルが密結合にも関わらず、テーブルの`Schema`情報がモデルファイルに記載されていない。「モデルにどんなカラムあったっけ？」となった際はDBか`Schema`ファイルを確認するしかなく少し面倒な状態だった。 - **解決・工夫点 :** `annotate`というGemを提案・導入することで、漏れなく全てのモデルファイルに`Schema`情報を記述した。 2. 1000行あった`Fat Model`を400行に縮小 - **課題 :** トルーのコアドメインに当たる`Company`や`Recruitment`などの`Model`, `Controller`, `View`が`Fat`になっていたが、規模が大きすぎて誰も手を出さずにいた。更にコールバック関数やアソシエーション、メソッド、スコープの記述位置がバラバラでどこに何があるか把握しにくい状況になっていた。 - **解決方法 :** - `ActiveSupport::Concern`を用いて`Module`に切り出し - `View`でしか利用しないロジックを`ViewModel`に切り出し - `Controller`でしか利用しないロジックを`Form Object`に切り出し - `Model`に限らず`View`, `Controller`, `Model`, `Mailer`, `Presenter`など広範囲に使うメソッドは`Utility`として`Class`に切り出し - どのアーキテクチャにも属さない特定の処理は`サービスクラス`に切り出し - 変数・定数・`enum`を用いてハードコーディングの撲滅 - コールバック関数の利用 - **工夫点 :** - リファクタリング前に、テストを実装 - また、`before_action`などのコールバック関数は使いすぎると処理がブラックボックス化するので、意図的に使わない様に実装 - コールバック関数やアソシエーション、メソッドの記述位置を統一 3. `Trailblazer`のドキュメント化 - **課題 :** `Trailblazer`はカオスなRailsコードに秩序をもたらすので超優秀なGemだが、導入した人が辞めてドキュメントもなくキャッチアップが大変で属人化していた。 - **解決方法 :** `Trailblazer`の使い方をドキュメント化して、全メンバーが使い方を把握できる様にした。 4. `Rubocop`の導入 - **課題 :** コードの書き方がバラバラで、コードレビューが大変だった。 - **解決方法 :** 上司それぞれがこだわりを持っていたので、辞めた後に`Rubocop`を導入する事で穏便にコードの書き方を統一した。 ## マネジメント編 1. オフショア開発と密にコミュニケーションを取ることで、タスクの遅延率を80%から20%に削減。 - **課題 :** 以下のような地獄の状況だったので、「タスク完了日」が「納期」としての役割を果たしていなかった。 - **私が担当する以前は、オフショアメンバーとのMTGは週1回の15分だけだった。** - 依頼するタスクの仕様が雑で、**ほぼ全てのタスクで手戻り・闇の工数が多発**していた - オフショア側も一切質問してこない - **解決方法 :** 毎日30分MTGと毎週1時間MTGを行い、認識に齟齬がないか・仕様の理解度・進捗のチェックを行い徐々に改善していった。現在では20%に削減することができた。 - **工夫点 :** 以下の取り組みをすることで、オフショアメンバーに自発性・主体性を芽生えさせた。 - 依頼したタスクがそもそもなぜ必要なのか、背景と理由を説明 - 1度犯したミスを逐一チェックリストに追加し、再発防止をした（品質マネジメントの徹底） - タスクの進捗確認と技術的フォローをする事で納期の意識付けをした（スケジュールマネジメントの徹底） - 依頼するタスクのゴールを明記（スコープマネジメントの徹底） - 雑談をする、相手に敬意を払い、発言・質問・提案を褒め、感謝をする（コミュニケーションマネジメントの徹底） 2. エンジニア以外のステークホルダーから要望のヒアリング・要件定義を遂行 - **課題 :** 営業・CSが、クライアントの要望をそのまま企画に出すことが多く、企画に上がる要望と達成したいゴールが異なる問題が発生していた。 また、MTGや口頭でのやり取りをチャットやドキュメントに残さないので、認識の齟齬が発生していた。 - **工夫点 :** 以下の取り組みをすることで上記問題の再発防止を心がけていた。 - 「そもそもその機能は本当に必要なのか？」と前提を疑う ここをしっかり議論することで無駄な機能を作ったり、仕様変更をしたりといった手戻りを発生させない様にしていた。 - その機能が必要となった背景・目的を明確に理解 「目的を達成する為にはこの企画がベストなのか？」を常に意識・議論することで無駄な手戻りを防いでいた。 - 建設的議論ができる雰囲気・信頼の構築 相手を頭ごなしに否定・きつい口調で話すなどの愚行をしない様にした。幸い、社内では年下ということもあり、雰囲気・信頼の構築は容易にできていた。また、曖昧な表現は避けるなど、意思疎通には細心の注意を払っていた。 - ログ記録 「言った・言ってない」の水掛け論を防ぐために、チャットやドキュメントなどにログを残し、必ず確認を取り、認識の齟齬を最小限にしていた。 <!-- ## その他 --> <!-- 他にも頑張って実装したこと・結果を出したこと - 契約・請求周りの実装、運用保守 - 画像一括アップロードの実装 - ATS - Facebook API連携 - facebook, google, indeed, job boxをXML化 - ライン応募、Pythonサーバー、MessagingAPIで急にNgrokが使えなくなった。 - 営業日 - OEM - 価格改定、コアドメインの仕様変更 - MySQLをバージョンアップ - リードレプリカ、マルチAZ、 - RSpecでGETメソッド - 採用 - 教育 - タスクマネジメント - リスクマネジメント - スコープマネジメント - スケジュールマネジメント - 品質マネジメント - コミュニケーションマネジメント - チームマネジメント - リーダーシップ - プロジェクトマネジメント - プロダクトマネジメント - ビジネスマネジメント - マネジメントスキル - マネジメントスタイル - マネジメント手法 - マネジメント理論 - マネジメントツール - マネジメント思想 - マネジメント戦略 - -->

# 「Icey」の開発 ## プロダクト概要 会員制動画配信サービス「[Icey](https://icey.jp/)」の新規開発・運用をしていた。 一言で言うと、**自身の動画コンテンツを限定公開・売買する**Webアプリケーション。 イメージとしては以下の様な感じである。 - Udemyの様に、自身の動画コンテンツを販売できる。 - CMSの様に、自分専用のサイトを簡単に構築できる。 ## プロジェクトの規模 - **開発メンバー:** 4人（全員日本人） - **開発期間:** 2021年5月〜2021年11月（7ヶ月） ## 技術スタック | | 技術スタック | |--------------------|--------------------------| | フロントエンド | Haml, jQuery | | バックエンド | Rails | | DB | MySQL, Redis | | インフラ | AWS, Docker, CircleCI | | 開発支援ツール | GitHub, Slack | ## 担当役割 インフラ・バックエンドのPjM兼テックリードとして、以下の重要な役割を担当: - インフラの設計・実装・運用 - バックエンドの底上げ - CircleCIを利用したCI/CDパイプラインの構築 ## 担当業務 ### インフラの設計・実装・運用 #### 前提 - **私以外のメンバーがインフラ未経験だった**ので、全てのインフラ業務を一人で担当した。 #### 成果 <!-- 具体的には、以下のサービスを利用 - IAM - VPC, Route53, ACM - ALB, TargetGroup, Athena, AWS WAF, Kinesis FireHorse - CloudWatch, SNS, Chatbot - S3, CloudFront - RDS, Redis - EC2, ECS/ECR, CloudFormation, AutoScaling - Lambda, MediaConvert --> 1. ゼロから一人でインフラ構築 **私以外のメンバーがインフラ未経験だった**ので、全てのインフラ業務を一人で担当した。 2. `CloudWatch`, `Performance Insight`, `Athena`を用いたパフォーマンスの可視化とログ解析 - **課題** 新規開発サービスなのでリリース時のアクセス数に予測がつかない状態だった。 - **解決策と工夫点** そこで、`CloudWatch`を用いて`CPU/Memory使用率` や `ALBのレスポンスタイム`, `StatusCode`などが一定の閾値を超えると`Slack`に通知することで、**チーム全員が即座にパフォーマンス悪化を確認できる様にした**。 また、`Performance Insight`, `Athena`を導入し、ログ解析・原因の早期発見・改善を実現した。 3. `AutoScaling`と`マルチAZ`構成用いたスケーラビリティを実現し、高負荷時でもダウンタイムをゼロに成功 - **課題** サービスの特性上、アクセス数が急増することが予想された。 - **解決策と工夫点** `マルチAZ`, `AutoScaling`を用いてアクセス数に応じて`EC2`を自動で増減させることで、アクセスのダウンタイムをゼロにした。 4. コストとセキュリティを加味したAWSアーキテクチャの採用でコストを`50％削減`に成功 - **課題** 予算が限られていたので、コスト削減が求められた。 - **解決策と工夫点** - `ECS`を`Fargate`ではなく`EC2`を使い、コスト削減を実現 - `WAF`を用いて、`SQLインジェクション`や`DDoS攻撃`からプロダクトを保護（実際、めっちゃDDoS攻撃きててヤバかった）。<!-- （海外からのリクエストをブロックしたらStripe死んだ） --> - 敢えて`Public Subnet`のみを使うことでコスト削減を実現（`EC2`や`RDS`は`SG`を用いてリクエスト元を制限）。 `Private Subnet`では`NATゲートウェイ`が必要になり、使用時間とデータ転送量でお金がかかる。 動画配信サービスなのでデータ転送量が多いとコストに跳ねそうだったので、敢えてパブリックサブネットのみを使うことでコスト削減を実現した。 5. `Route53`の`CLI`を活用し、CSの業務時間を月30時間削減に成功 - **課題** サービスの仕様として、動画コンテンツを配信するユーザーは各々`test.icey.jp`のようにサブドメインを発行して専用サイトを作る。 初期仕様ではユーザーがサブドメインをリクエストし、CSが都度サブドメインを登録するフローになっていた。 しかしそれではスケールしない && ヒューマンエラーの温床になる状態だった。 - **解決策と工夫点** サブドメイン自動登録バッチを実装したことで、**ドメイン発行処理を自動化し月30時間削減に成功**した。 6. `Lambda`, `MediaConvert`, `CloudFront`を用いて動画再生のUX向上に成功 - **課題** ユーザーがアップロードした動画の解像度が大きいと再生が遅くなる懸念があった。 - **解決策と工夫点** 動画アップロードを契機に`MediaConvert`を起動し、`HLS`形式に変換・解像度変換処理を実装し、`CloudFront`を用いて動画のキャッシュすることでUX向上に貢献した。 ### バックエンドの底上げ #### 前提 - **私以外のメンバーがプログラミングスクール卒業したばかりの実務未経験エンジニアだったので、可読性やパフォーマンス、セキュリティ的に良くないコードが散見されていた**。 `Cost`は良いが、`Quality`, `Delivery`が最低だったので、以下取り組みを通じで、バックエンドの底上げを行った。 #### 成果 1. 技術力の底上げ・属人化の排除に貢献① - **課題** - そのコードを書いた人しか読めないコードが多発していた。 - 自分以外のメンバーは全員エンジニア歴が浅く、単純に実力不足だった。 - **何が分からないかを分からない**状態だったので、課題の吸い上げやエスカレーションが無い状態だった。 - **解決策と工夫点** ペアプロ・モブプロを通じてメンバーとのコミュニケーション・教育を徹底することで技術力の底上げ・属人化の排除に貢献した。 2. 技術力の底上げ・属人化の排除に貢献② - **課題** `PRレビュー`やペアプロ・モブプロでは時間的限界があった。 - **解決策と工夫点** `Brakeman`や`Bullet`, `lol_dba`, `Rubocop`を導入し、セキュリティ脆弱性やパフォーマンス問題、コードの可読性などをシステマティックに特定・修正させることで、漏れなくコードの品質向上に成功した。 3. 技術力の底上げ③ - **課題** メンバー全員やる気はあるものの、自分以外はエンジニア歴が浅く知識や経験が不足していた。 - **解決策と工夫点** 週1回1時間の社内勉強会を実施することで、技術力の底上げ・コミュニケーション促進化にも貢献した。 4. プロダクト品質の向上 - **課題** `Quality`より`Delivery`優先で、**テストが一切実装されておらず、プロダクトの品質を保証する根拠が全くない状態**だった。 - **解決策と工夫点** 全くテストを実装せずに開発を続けるのは危険ではあるものの`Delivery`最優先だったので、 プロダクトのコアドメイン（動画やユーザーのCRUD）に限定して、単体テスト（RSpec）を実装した。 これにより、**最低限の品質を担保しつつ開発スピードを維持できるように貢献**した。 5. スケジュール遅延の改善 - **課題** - **PjMがいなかった。** - 自分以外のメンバーのエンジニア歴が浅く、タスクやスケジュール、スコープマネジメントが全く出来ていなかった。 - **解決策** なんちゃってスクラム（スクラムの`型`のみ導入し、`思想`は導入しない）の導入。 - **工夫点** スクラムの`思想`までちゃんと導入するには自分もメンバーも知識不足で失敗する可能性が高かったので、プロジェクト管理の手段としてスクラムを導入した。 具体的にはプランニング・スプリントレビュー・レトロスペクティブのみ導入し、スプリントごとにタスクの細分化・割り振り・締切設定をすることで、スケジュール遅延を大幅に改善できた。 また、スプリントごとに簡易的なレトロスペクティブをを行い、メンバーの成長を促進した。 これらを通じてメンバーの技術力の底上げに成功し、コードの品質向上や属人化を排除に貢献した。 ### CircleCIを利用したCI/CDパイプラインの構築 私は副業として本プロジェクトに参画しているが、**私以外メンバーはインフラ・デプロイ周りの知見が無いので、デプロイの時間帯は私の作業時間に依存していた**。 このままでは開発スピードが属人化するので、**`CircleCI`を提案・導入し、開発スピードの向上に貢献**した。

# 「HAKU」の開発 ## プロダクト概要 無人のセルフ医療ホワイトニングサービス「[HAKU](https://whitening-haku.com/)」の開発・運用をしている。 一言で言うと、`HotPepper`のホワイトニング版のような予約管理Webアプリケーション。 直接的な競合サービスは、`hacomono`や`STORES`など。 具体的には、以下の機能が強み。 - ホワイトニングに特化した無人店舗の予約管理 - フランチャイズ展開による『HAKU』のSEO優位性 ## プロジェクトの規模 - **開発メンバー:** 2024年3月時点で6人（全員日本人） - **開発期間:** 2022年10月〜2024年3月（1年6ヶ月） ## 技術スタック | | 技術スタック | |----------------------|-----------------------------------------------------------| | フロントエンド | Haml, jQuery, React, TypeScript | | バックエンド | Rails, Go | | DB | MySQL, Redis | | インフラストラクチャ | AWS, Docker, Github Actions, Terraform | | 開発支援ツール | GitHub, Slack, Notion, CodeRabbit, GitHub Copilot | ## 担当役割 テックリードとして以下の業務を担当 - PjM - エンジニア採用・教育・文化育成 - 開発効率化 - コスト削減 - アルゴリズム実装 ## 担当業務 1. エンジニア2名の離職防止と2名の新規採用に成功 - **課題:** 以下が原因でエンジニア採用が苦戦 && 離職者が出そうになっていた。 - 技術レベルの低さ - 給与の低さ - 会社の知名度 - 求人の見栄えの悪さ - エンジニア採用戦略の無さ - **解決策:** 技術のモダン化（`TypeScript`, `React`, `Go`, `Terraform`を導入）することで、2名の離職防止と2名の新規採用に成功した。 - **工夫点:** 全ての課題は解決できない。選択と集中が必要。既存メンバー離職が一番影響が大きいので、何が解決すれば残るかヒアリングを行い、それに向けて改善を行った。結論、『`Rails`, `jQuery`, `AWS`だけやっていてもエンジニアの成長を感じない』という技術的な成長・長期的なキャリア形成が課題ということが分かった。また、リファラル採用できそうな2名も同じ理由で内定承諾を渋っていた。よって、`TypeScript`, `React`, `Go`, `Terraform`を導入し、技術レベルを向上させたことで2名の離職防止と2名の新規採用にも成功した。（もちろん開発スピードが低下しないように、ドキュメント化とオンボーディングを徹底し、新規採用者がすぐに開発に参加できる環境を整えている）。 経営層へは、技術力向上には短期的にはコストがかかるが、それ以上に長期的なリターン（プロダクトのQuality向上・Delivery改善・採用改善を通じたCost改善が目に見えていた）があると説明し、理解を得た。 2. なんちゃってスクラム導入によるマネジメント不在の解消 - **課題:** **マネージャー不在**だったので、まともな進捗管理ができていなかった。 - **解決策:** スクラムの`型`を導入することにより、マネジメント属人化を解消し、チーム全体での進捗管理を行った。 - **工夫点:** スクラムの思想まで持ち込むとオーバーヘッドで且つキャッチアップが大変（メンバー全員未経験）なので、進捗管理の手段としてスクラムを導入することで、スケジュール・スコープマネジメントに成功した。 3. AWSコストを30％削減 - **課題:** 前任者が雑に作ったAWS環境が原因で、無駄なコストが発生していた。 - **解決策:** 作りかけの中途半端な`staging`環境や未使用のAWSリソースを削除・作り直しを行い、約30％のコスト削減に成功した。 - **工夫点:** `Billing and Cost Management`を用いてリソース利用料金を分析することで網羅的なコスト削減とリソース整備を行った。また、`production`と`staging`でAWSアカウントを分けることでコスト管理・セキュリティ・インフラ運用の向上を行った。 4. `staging`環境構築とデプロイの安定化 - **課題:** - メンテナンスモードにせずに、アクティブユーザーお構い無しで、各の独断でデプロイしていた。 - `staging`環境がないのでぶっつけ本番での動作確認になっていた。 - サーバーが2個しかないのに`Rolling Deployment`だったのでデプロイが不安定だった。 - **解決策:** - ビジネスサイドに了承を得てメンテナンス時間にデプロイするフローを作ることで、デプロイの安定化を図った。 - `staging`環境を構築することでバグ軽減とデプロイ動作の改善を行なった。 - `Rolling Deployment`でも耐えうるコードを設計し、サーバー数も増やすことで一時的な高負荷にも耐えられる設計を実装した。 5. `CodeRabbit`を導入し、プルリクレビューからマージまでのリードタイムを50％軽減に成功 - **課題:** 技術レベルの低さ、プルリクレビューの大変さ - **解決策:** `CodeRabbit`を導入することで、プルリクレビューの大変さを解消し、技術レベルの向上に貢献した。 6. マッチングアルゴリズムを実装し、CSの手作業を月間100時間削減 - **課題:** CSがExcel表を用いて手動でマッチングをしていた（もちろんヒューマンエラーも多発していた）。 また、自分以外のメンバーがマッチングアルゴリズムの実装に自信がなかったことも原因で実装されない状態が続いていた。 - **解決策:** CSと密に連携することで既存マッチング要件を擦り合わせながらアルゴリズムを構築した。 - **工夫点:** CSだけでなくPO・社長とも密に連携し、今後のプロダクトロードマップを加味してマッチングアルゴリズムを実装した。 <!-- 例えば現在は1時間区切りだが、15分区切りにしたり、 --> 7. `DDD`を用いたコーディング規約の導入 - **課題:** コードの属人化によるバグの多発や、新機能の追加が困難だった。 - **解決策:** コーディング規約として`DDD`の概念を導入し、疎結合や責任の分割、モジュール性の高いコーディングにすることで柔軟性と拡張性に優れたコードを書けるようにした。 - **工夫点:** `DDD`に関する勉強会の実施とドキュメント化を行い、全メンバーが理解できるようにしている。

# 「Resily」の開発 ## プロダクト概要 OKR管理ツール「[Resily](https://resily.com/)」の開発・運用をしていた。 ## プロジェクトの規模 - **開発メンバー:** 8人（全員日本人） - **開発期間:** 2022年4月〜現在 ## 技術スタック | | 技術スタック | |----------------------|-----------------------------------------------------------| | フロントエンド(SPA) | React, TypeScript | | バックエンド | Go | | DB | PostgresQL, Redis | | インフラストラクチャ | GCP, Docker, Github Actions, Terraform, Kubernetes | | 開発支援ツール | GitHub, Slack, Notion, CodeRabbit, GitHub Copilot | | API | REST, GraphQL, gRPC | ## 担当役割 開発メンバーとして、フロントエンド、バックエンド、インフラ全ての分野で幅広く開発に携わっていた。 また、Resilyがアドバンテッジリスクマネジメント（ARM）に買収された後は、『[アドバンテッジタフネスカウンセリング](https://www.armg.jp/mhlw/toughness-counseling/)』の開発リーダーとして上流工程を行なっている。 ## 担当業務 1. CS部門と密に連携しながら`SRE`を導入することで効率的な監視体制を構築した - **課題:** 文字コードが`SJIS`のCSVインポートができない不具合が発生し、ユーザーの一括登録ができず、新規契約顧客がサービスを使えなくなっていた。 - **解決策:** `SJIS`のCSVインポートができるように修正を行うと同時に、`SRE`の設定も行った。 - **工夫点:** 開発リソース不足だったので、`SRE`を導入することで効率良くプロダクトの品質向上に注力できるようにした。 セッションリプレイやヒートマップ等のユーザー行動分析ツールを駆使し、CS部門と密に連携しながら以下を定義した。 - **CUJ:** CSVファイルのアップロード、バリデーション、データベースへの登録、招待メールの送信ができること。 <!-- 新規契約したユーザーの約9割が1日以内にCSVインポートを行っていたが、文字コードが`SJIS`のCSVインポートができなくなっていた。 CSVインポートでユーザーを一括登録できなければサービスが使えないと同義なので、`CUJ`を『CSVインポートができること』と定義した。 --> - **SLI:** - CSVファイルアップロードからユーザー登録完了までの平均時間 - CSVファイルアップロードから招待メール送付までの平均時間 - サービスの月間アップタイム率 - **SLO:** - CSVアップロード後、95%のケースで5分以内にユーザー登録と招待メール送信が完了する。 - 月間アップタイム99.9%を保証する。 - **SLA:** SLOを割った場合は、最優先でバグ対応を行い、顧客に対して謝罪を行う。 2. 500番エラーの画面実装 - **課題:** 500番エラーの画面が存在せず、エラー時に画面がただ真白になる状態だった。 問題は、**自分以外のエンジニアメンバーがそのことに何の違和感も感じていない**事であった。 - **解決策:** 500番ページを実装した。 - **工夫点:** 自分は違和感があったので、顧客とのMTGに参加させてもらい、`VoC`を聞き続けることで、エンジニア視点ではなく**ユーザー視点を身につけることに尽力**した。 他のエンジニアメンバー全員が気づかなかったUIUX改善を行なった。 3. `Ruby`用の`gRPC`のOSSのバグを修正して `Mailer`サービスを実装した。 - **課題:** Resilyはマイクロサービスアーキテクチャで構築されていて、`Mailer`が独立している。 `gRPC`経由で`Mailer`サービスを呼び出しているが、`Ruby`用の`gRPC`のOSSのバグが原因で実装が滞っていた。 - **解決策:** `Ruby`用の`gRPC`のOSSのバグを修正して、メーラーを実装した。 <https://github.com/grpc/grpc/pull/31783> - **工夫点:** `Issue`が無かったので、自分で`Issue`を立てて、PRを出した。 4. `CloudSQL`から`AlloyDB`へ移行し、DBの読み書き速度を30％改善 - **課題:** 本来`View`はデータ分析など単純な用途でしか使うべきではないが、複雑な`View`に更に複雑なクエリをかけていた。 もちろんインデックスが貼れないので、読み込み時間が10秒以上かかっていた。 - **解決策:** `AlloyDB`への移行を行い、DBの読み込み速度を30％改善した。 - **工夫点:** 本来であれば`Materialized View`やテーブル化で対応すべきだが、テーブル化するには開発リソースが足りず、また、リアルタイム性を求められるデータなので`Materialized View`も適していなかった。 一筋縄では行かない状況だったので、暫定的処置として`AlloyDB`への移行を行い、DBのRead速度改善によりUX改善に成功した。 5. `Go`のデバッグ環境を整備し、開発スピードを向上させた（計測はできていないが体感2倍以上） - **課題:** `REPL`系のデバッグ環境が無く、デバッグが大変だった。 - **解決策:** `Delve`を導入して、デバッグ環境を整備した。 - **工夫点:** 素の`Delve`は使いにくいので、UIが分かりやすい`VSCODE`経由で`Delve`を使えるようにした。 また、`Docker`コンテナ内外両方からでもデバッグできるようにした。 6. `DDD`でバックエンドの実装を行い、ドキュメント整備を行いメンバーのキャッチアップをサポートした。 - **課題:** バックエンドが`DDD`で記述されていたがメンバー全員`DDD`未経験で、コードが属人化していた。 - **解決策:** 自分自身も`DDD`未経験だった為、キャッチアップを行いながらでバックエンドの実装を行い、`DDD`についてドキュメント整備を行うことでメンバーのキャッチアップをサポートした。 7. `React`のコンポーネントレンダリングに20秒弱かかっていた処理を3秒に改善 - **課題:** レンダリングに20秒弱かかっていた処理があり、ユーザーが待ちきれずに離脱していた。 - **解決策:** `React.memo`, `useCallback`, `useMemo`を用いて、コンポーネント・関数・変数のメモ化を行い、パフォーマンスを改善した。 - **工夫点:** `why-did-you-render`を導入して、レンダリングの原因を特定し、パフォーマンスを改善・再発防止した。 8. リッチテキストエディタのレンダリング速度を10分の1に改善 && 文字記入数を20倍に改善 - **課題:** リッチテキストエディタの記入内容を自動保存する仕様だったが、`onChange`で`POST`していてパフォーマンスが最悪だったので、ユーザーの文字記入数が激減していた。 - **解決策:** `debounce`で実装することにより、レンダリング速度を10分の1に改善 && 文字記入数を20倍に改善に成功 9. PRの粒度を細分化することで、PRレビューのコメント数を約3倍に増やした。 - **課題:** PRの差分が数千行になることが頻発し、まともにPRレビューできていない && レビューコストが嵩む状況だった。 - **解決策:** PRの差分を`400行`以下にすることで、PRレビューの効率化を行った。 - **工夫点:** スプリントレトロスペクティブでPRの細分化を提案し、スクラムチーム全員で『差分は400行以下にする』という合意をとった。 10. 社内スクリプトの修正を行い、テスト実行時間を15分から1分に改善 - **課題:** - 社内スクリプトで使用するライブラリのバージョンが古く - マイグレーションを実行せずにテスト実行していて - テスト失敗時のログ出力が不十分で - 特定箇所のみのテストが実行できず、全テストが実行されるようになっていた - **解決策:** - 使用ライブラリのバージョンアップ - テスト実行前にマイグレーションを実行するように修正 - テスト失敗時のログにユーザーID・企業IDを出力するように修正 - 特定箇所のみテストを実行できるように修正 - **工夫点:** 社内スクリプトは滅多にメンテされないので、丁寧にコメントを記述した。 11. セルフサーブ機能の実装 - **課題:** 営業活動だけでは売り上げが伸び悩んでいたので、セルフサービス機能を実装することで、売り上げを伸ばすことが求められていた。 - **解決策:** セルフサービス機能を一人で実装。CSにヒアリングを行いながら、ユーザーのリテラシーに合わせたデザインや機能を実装した。 - **工夫点:** セルフサーブのターゲットとなる顧客や既存顧客のニーズをCSやマーケからヒアリングを行いながらUIUXの実装を行なった。セルフサービス機能を一人で実装。CSにヒアリングを行いながら、ユーザーのリテラシーに合わせたデザインや機能を実装した。