JayGatsby

「トルー」の開発

プロダクト概要

採用CMSアプリ「トルー」の開発・運用をした。
一言で言うと、企業の採用活動を効率化するWebアプリケーション。
直接的な競合サービスは、採用係長やジョブカンATSなど。
具体的には、以下の機能が強み。

• 求人情報と応募者情報を一元管理
• 自社専用の採用サイトをノーコードで構築
• IndeedやGoogle For Jobs、Facebook Jobsなどの求人サイトとAPI連携

プロジェクトの規模

• 開発メンバー: 2021年4月時点で4人（私とオフショア3人）。多い時で7人（私を含めた日本人4人、オフショア3人）
• 開発期間: 2018年8月〜2022年4月（3年9ヶ月）
• プロダクトの売り上げ: 2020年度の売上は1.2億円

技術スタック

担当役割

プレイングマネージャー（PjM、およびフルスタックエンジニア）として企画以外を全て担当していた。
プロダクトフェーズとしては1→10を経験。
プロダクトロードマップや新規機能発案などの大きな"企画"と言われる部分はPdMが担当し、それ以降の要件定義・設計・コーディング・テスト・運用保守・データ分析を全て担当した。

• 要件定義
• アプリ・インフラの実装・運用保守
• オフショアメンバーの育成・マネジメント

アプリ・インフラの実装・保守運用

セキュリティ強化

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攻撃を防いだ
   • 課題 :
     トルーの採用サイトに対してDDoS攻撃が多発していた。
   • 解決策 :
     WAFを導入することで、DDoS攻撃を防ぐことに成功した。

コスト削減

1. ALB と ACMの使い方を見直して、年間50万円（層インフラ費用の5％）のコスト削減 に成功。
   詳細は以下URLを参照。
   https://qiita.com/Gatsby/items/933c5a93e5900865b7d2

2. 未使用ドメインを解約して、年間20万前後のコスト削減 に成功。

   • 課題 :
     企業毎に独自ドメインを発行しているが、解約済み企業のドメインを解約せずに毎年自動継続更新をしていた。誰もドメインの管理をしていない状態だった。
   • 工夫点 :
     • 解約してもすぐ再契約する企業もチラホラ存在した為、トルー解約から1年経つ企業のドメインを解約するようにBizサイドを合意を得てから実装した。
     • ドメインが悪用された場合のクレームや損害賠償に備えて、利用規約にドメインの解約に関する記述の提案・修正もした。

リファクタリング

1. コーディング規約の導入により、1000行あったFat Modelを400行に縮小
   • 課題 :
     コーディング規約が無かったため、コードの属人化、可読性・メンテナンス性の低下が顕在化していた。具体的には以下のような課題があった。
     • コアドメインに当たるCompanyやRecruitmentなどのMVC全てがFatだった。
     • before_actionの多用でコントローラのブラックボックス化
     • コールバック関数やアソシエーションなど記述位置がバラバラ
     • ハードコーディングの多用
     • メソッドレベル・クラスレベルでコードの書き方がバラバラで、コードレビュー・メンテナンス共にが大変だった。
   • 解決方法 :
     • Viewでしか利用しないロジックをViewModel（RailsでいうDecorator）に切り出し
     • Controllerでしか利用しないロジックをServiceクラスとForm Objectに切り出し
     • ModelやView, Controllerなど広範囲に使うメソッドはUtilityモジュールに切り出し
     • 変数・定数・enumを用いてハードコーディングの撲滅
     • コールバック関数の制限
   • 工夫点 :
     • 上司それぞれがこだわりを持っていたので、辞めた後に導入する事で穏便にコードの書き方を統一した。
     • リファクタリング前に、テストを実装
     • before_actionなどのコールバック関数は使いすぎると処理がブラックボックス化するので、意図的に使わない様にした。
     • Rubocopを導入して、書き方を統一した。
2. Trailblazerのドキュメント化により、各メンバーのキャッチアップ時間を約2週間短縮
   • 課題 :
     TrailblazerはカオスなRailsコードに秩序をもたらすので超優秀なGemだが、DDDの様に学習コストが高すぎる。にも関わらず導入した人が辞めてドキュメントもなくキャッチアップが大変で属人化していた。
     また、オフショアメンバーも毎月コロコロ入れ替わりが激しく、Trailblazerがボトルネックで開発スピードが遅かった。
   • 解決方法 :
     Trailblazerの使い方をドキュメント化して、全メンバーが使い方を把握できる様にした。
     <!-- 1. モデルにschema情報を記載
   • 課題 :
     Railsではモデルとテーブルが密結合にも関わらず、テーブルのSchema情報がモデルファイルに記載されていない。「モデルにどんなカラムあったっけ？」となった際はDBかSchemaファイルを確認するしかなく少し面倒な状態だった。
   • 解決・工夫点 :
     annotateというGemを提案・導入することで、漏れなく全てのモデルファイルにSchema情報を記述した。 -->

パフォーマンス改善

1. DBのCPU使用率を90%から60%に改善
   • 課題 :
     N+1問題が散見されていたが誰も修正せずに放置されていた。
     様々な負債と相まって、DBのCPU使用率が90%に達してパフォーマンスが著しく低下していた。
   • 工夫点 :
     bulletというgemを提案・導入して、N+1問題を解決・再発防止に成功した。
2. 処理時間9時間 && メモリ使用率100%のバッチ処理を、処理時間20分 && メモリ使用率30%に改善
   • 課題 :
     • 初期トルーでは求人データの登録手段は手作業のみだったが、CSVを用いた一括登録機能を実装したことにより、従来の約100倍のペースで登録される様になった。具体的には、初年度数千件程度だった求人データが、1年で100万件を超えた。
     • トルーはIndeed, 求人BOXなど求人媒体に求人情報を連携しているが、求人データを1回のSQLで全て取得していたことにより、メモリ使用率が100%に達しXMLファイルを作成できなくなった。
   • 解決方法 :
     • スロークエリログから根本原因がインデックスの貼り忘れであることを特定し、インデックスを貼ることで処理時間を20分に改善した。
     • データ取得処理・ファイル書き込み処理を小分けに処理することでメモリ使用率を30%に改善した。
   • 工夫点 :
     • lol_dbaというgemを提案・導入して、DB全体のインデックス貼り忘れを修正・再発防止に成功した。
     • find_each, in_batchesメソッドを用いてループ処理・SQLを小分けにするだけでなく、ファイル書き込み処理も小分けにすることでメモリパンクを半永久的に再発防止した。
     • CloudWatchを用いてCPU・メモリ使用率の監視・通知を実装することで早期発見・再発防止に貢献した。
     • pluckを用いて、無駄なデータを取得しないようにデータ取得サイズを軽減させた。
3. BULK INSERTを実装して、処理時間を20分から7分に改善した。
   • 課題 :
     従来のバッチ処理では大量のデータを1行ずつINSERTしていたので処理速度が遅かった。
   • 解決方法 :
     activerecord-importを用いてBULK INSERTを実装することで、処理速度を半分以下に改善した。
   • 工夫点 :
     BULK INSERTの際はActiveRecordを経由せず直接SQLを実行するので、バリデーションやコールバックが発火されない。
     なので、BULK INSERTのバッチ処理からもActiveRecordからもバリデーションロジックを切り離し、独自のバリデーションクラスを実装することでデータの不整合が起こらないように一元管理した。
     また、プルリクエストのテンプレートにチェックリスト作成を提案・導入することで、今後実装されるバッチ処理の再発防止に貢献した。
4. リードレプリカの導入で閲覧ページのレスポンス速度が12秒から3秒に改善
   • 課題 :
     求人数の急増とCSVインポート機能により常にWrite処理が走っていたことにより、上記課題1〜3を改善してもMasterDBのCPU使用率が80%を超えていた。
   • 解決策 :
     リードレプリカを導入することで閲覧ページのレスポンスを12秒から3秒に改善した。
5. 毎日のCSVインポート件数を20分の1に削減 && 論理削除された求人データを物理削除することでDB容量を120GBから100GBに削減
   • 課題 :
     CSVインポート機能を実装したことで求人データが1年で100倍になった。1番の原因は、顧客が増加したことではなかった。本質的な原因は、Indeed SEOの仕様を逆手に取った人材紹介企業の増加にあった。
     Indeed SEOの仕様上、新規求人は上位に表示されやすい。新規求人かどうかの判定はIDを用いて行われる。なので、CSVインポートを用いて求人情報を全部論理削除・新規作成を繰り返し行う企業が増えていた。これが本質的原因だった。
   • 工夫点 :
     • 全部論理削除・新規作成をしなくても済むようにIndeed専用のIDを導入することで、求人データ爆増を防いだ。
     • 同時に、論理削除された全く使われていないデータを物理削除することで、DB容量の節約にも成功した。

オフショアメンバーの育成・マネジメント

1. オフショア開発と密にコミュニケーションを取ることで、タスクの遅延率を80%から20%に削減。

   • 課題 :
     以下のような地獄の状況だったので、「タスク完了日」が「納期」としての役割を果たしていなかった。
     • 私が担当する以前は、オフショアメンバーとのMTGは週1回の15分だけだった。
     • 依頼するタスクの仕様が雑で、ほぼ全てのタスクで手戻り・闇の工数が多発していた
     • オフショア側も一切質問してこない
   • 解決方法 :
     毎日30分MTGと毎週1時間MTGを行い、認識に齟齬がないか・仕様の理解度・進捗のチェックを行い徐々に改善していった。現在では20%に削減することができた。
   • 工夫点 :
     以下の取り組みをすることで、オフショアメンバーに自発性・主体性を芽生えさせた。
     • 依頼したタスクがそもそもなぜ必要なのか、背景と理由を説明
     • 1度犯したミスを逐一チェックリストに追加し、再発防止をした（品質マネジメントの徹底）
     • タスクの進捗確認と技術的フォローをする事で納期の意識付けをした（スケジュールマネジメントの徹底）
     • 依頼するタスクのゴールを明記（スコープマネジメントの徹底）
     • 雑談をする、相手に敬意を払い、発言・質問・提案を褒め、感謝をする（コミュニケーションマネジメントの徹底）

2. エンジニア以外のステークホルダーから要望のヒアリング・要件定義を遂行

   • 課題 :
     営業・CSが、クライアントの要望をそのまま企画に出すことが多く、企画に上がる要望と達成したいゴールが異なる問題が発生していた。
     また、MTGや口頭でのやり取りをチャットやドキュメントに残さないので、認識の齟齬が発生していた。
   • 工夫点 :
     以下の取り組みをすることで上記問題の再発防止を心がけていた。
     • 「そもそもその機能は本当に必要なのか？」と前提を疑う
       ここをしっかり議論することで無駄な機能を作ったり、仕様変更をしたりといった手戻りを発生させない様にしていた。
     • その機能が必要となった背景・目的を明確に理解
       「目的を達成する為にはこの企画がベストなのか？」を常に意識・議論することで無駄な手戻りを防いでいた。
     • 建設的議論ができる雰囲気・信頼の構築
       相手を頭ごなしに否定・きつい口調で話すなどの愚行をしない様にした（上司はこれしてた）。幸い、社内では年下ということもあり、雰囲気・信頼の構築は容易にできていた。また、曖昧な表現は避けるなど、意思疎通には細心の注意を払っていた。
     • ログ記録
       「言った・言ってない」の水掛け論を防ぐために、チャットやドキュメントなどにログを残し、必ず確認を取り、認識の齟齬を最小限にしていた。
   • 成果:
     具体的には以下機能は自信を持って、要件精査をできたと感じている。理由は、手戻りや認識齟齬なくユーザーから良いFBを頂けたから。
     • 画像一括アップロードの実装
     • OEM機能の実装

「Icey」の開発

プロダクト概要

会員制動画配信サービス「Icey」の新規開発・運用をしていた。
一言で言うと、自身の動画コンテンツを限定公開・売買するWebアプリケーション。
イメージとしては以下の様な感じである。

• Udemyの様に、自身の動画コンテンツを販売できる。
• CMSの様に、自分専用のサイトを簡単に構築できる。

プロジェクトの規模

• 開発メンバー: 4人（全員日本人、全員業務委託）
• 開発期間: 2021年5月〜2021年11月（7ヶ月）

技術スタック

担当役割

フェーズとしては、0→1と1→10を経験。
フルスタックエンジニア 兼 Tech Lead 兼 EM 兼 PjM（PdM未経験）として、以下の重要な役割を担当:

• インフラの設計・実装・運用
• バックエンドの底上げとチームビルディング
• CircleCIを利用したCI/CDパイプラインの構築
• メンバーのタスクマネジメント

インフラの設計・実装・運用

前提

• 私以外のメンバーがインフラ未経験だったので、全てのインフラ業務を一人で担当した。

成果

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攻撃きててヤバかった）。
     • 敢えて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）を実装した。
     これにより、最低限の品質を担保しつつ開発スピードを維持できるように貢献した。

これらを通じてメンバーの技術力の底上げに成功し、コードの品質向上や属人化を排除に貢献した。

CircleCIを利用したCI/CDパイプラインの構築

前提・課題

• 私以外メンバーはインフラ・デプロイ周りの知見が全く無いので、デプロイの時間帯は私の作業時間に依存していた。
• デプロイスクリプトを実装したが、他メンバーがM1 Mac(Apple Silicon)を使っていてCPUアーキテクチャが異なり、結局Dockerイメージが動かないという問題が発生した。
  (EC2のCPUがIntel製のx86アーキテクチャにも関わらず、M1 Macでビルドされたイメージはarmアーキテクチャだから。)

成果

• 開発スピードが属人化しないように、CircleCIを提案・導入し、開発スピードの向上に貢献した。

メンバーのタスクマネジメント

前提

私以外のメンバーがプログラミングスクール卒業したばかりの実務未経験エンジニアだったので、シンプルにタスクマネジメントができていなかった。

成果

1. スケジュール遅延の改善
   • 課題
     • PjMがいなかった。
     • スケジュール遅延が常態化していた。
     • 自分以外のメンバーはエンジニア歴が浅く、タスク・スケジュール・スコープマネジメントが全く出来ていなかった。
   • 解決策
     なんちゃってスクラム（スクラムの型のみ導入し、思想は導入しない）の導入。
   • 工夫点
     スクラムの思想までちゃんと導入するには自分もメンバーも知識不足で失敗する可能性が高かったので、プロジェクト管理の手段としてスクラムを導入した。
     具体的にはプランニング・スプリントレビュー・レトロスペクティブのみ導入し、スプリントごとにタスクの細分化・割り振り・締切設定をすることで、スケジュール遅延を大幅に改善できた。
     また、スプリントごとに簡易的なレトロスペクティブをを行い、メンバーの成長・自主性の向上に貢献した。

「HAKU」の開発

プロダクト概要

無人のセルフ医療ホワイトニングサービス「HAKU」の開発・運用をしている。
一言で言うと、HotPepperのホワイトニング版のような予約管理Webアプリケーション。
直接的な競合サービスは、hacomonoやSTORESなど。
具体的には、以下の機能が強み。

• ホワイトニングに特化した無人店舗の予約管理
• フランチャイズ展開による『HAKU』のSEO優位性

プロジェクトの規模

• 開発メンバー: 2024年3月時点で6人（全員日本人）
• 開発期間: 2022年10月〜2024年3月（1年6ヶ月）

技術スタック

担当役割

フェーズとしては、0→1と1→10を経験。
フルスタックエンジニア 兼 Tech Lead 兼 EM 兼 PjM（PdM未経験）として、以下を担当:

• エンジニア採用・育成・開発効率化
• PjM
• インフラの実装・コスト削減
• マッチングアルゴリズム実装

エンジニア採用・育成・開発効率化

1. エンジニア2名の離職防止と2名の新規採用に成功
   • 課題:
     以下が原因でエンジニア採用が苦戦 && 離職者が出そうになっていた。
     • 技術レベルの低さ
     • 給与の低さ
     • 会社の知名度
     • 求人の見栄えの悪さ
     • エンジニア採用戦略の無さ
   • 解決策:
     技術のモダン化（TypeScript, React, Go, Terraformを導入）することで、2名の離職防止と2名の新規採用に成功した。
   • 工夫点:
     全ての課題は解決できない。選択と集中が必要。既存メンバー離職が一番影響が大きいので、何が解決すれば残るかヒアリングを行い、それに向けて改善を行った。結論、『Rails, jQuery, AWSだけやっていてもエンジニアの成長を感じない』という技術的な成長・長期的なキャリア形成が課題ということが分かった。また、リファラル採用できそうな2名も同じ理由で内定承諾を渋っていた。よって、TypeScript, React, Go, Terraformを導入し、技術レベルを向上させたことで2名の離職防止と2名の新規採用にも成功した。（もちろん開発スピードが低下しないように、ドキュメント化とオンボーディングを徹底し、新規採用者がすぐに開発に参加できる環境を整えている）。
     経営層へは、技術力向上には短期的にはコストがかかるが、それ以上に長期的なリターン（プロダクトのQuality向上・Delivery改善・採用改善を通じたCost改善が目に見えていた）があると説明し、理解を得た。
2. CodeRabbitを導入し、プルリクレビューからマージまでのリードタイムを50％軽減に成功
   • 課題:
     技術レベルの低さ、プルリクレビューの大変さ
   • 解決策:
     CodeRabbitを導入することで、プルリクレビューの大変さを解消し、技術レベルの向上に貢献した。
3. コーディング規約の導入
   • 課題:
     • コードの属人化によるバグの多発、可読性の低下が顕在化していた。
     • 既存機能のメンテや他機能との連携が困難になり、著しくDelivery速度が低下していた。
   • 解決策:
     • レイヤー分けに関してはDDDの概念を導入し、MVCより適切にレイヤー分けできるようにした。
       具体的には、Value Object、Repository、Service層とRailsのForm Object層を導入し、それぞれの責務を明確にすることで、コードの可読性を向上させた。
   • 工夫点:
     • 個人的には、未熟なエンジニア組織にDDDを導入することはアンチパターンだと考えている。よって、DDDの中でも比較的簡単で且つ、現状のカオスなコードにコスパ良く導入でき且つ、DDD以外の文脈でも登場するレイヤーのみを導入した。
     • コーディング規約に関する勉強会の実施とドキュメント化を行い、全メンバーが理解できるようにしている。
     • Rubocopによる記法の強制統一
     • よくあるアンチパターンやPRレビューで指摘された内容をドキュメント化することで、再発防止を図っている。

PjM

1. なんちゃってスクラム導入によるマネジメント不在の解消
   • 課題:
     マネージャー不在だったので、まともな進捗管理ができていなかった。
   • 解決策:
     スクラムの型を導入することにより、マネジメント属人化を解消し、チーム全体での進捗管理を行った。
   • 工夫点:
     スクラムの思想まで持ち込むとオーバーヘッドで且つキャッチアップが大変（メンバー全員未経験）なので、進捗管理の手段としてスクラムを導入することで、スケジュール・スコープマネジメントに成功した。
2. ステークホルダーとのコミュニケーション強化による業務理解の向上
   • 課題:
     エンジニア全員業務委託だったので、Bizサイドとのコミュニケーションが一切無かった。
   • 解決策:
     スプリントレビュー・プランニングにBizサイドを呼び、他部署が何をやっているか、エンジニアが何をやっているかをお互いに共有することで、コミュニケーションの活性化と業務理解を向上させた。

インフラの実装・コスト削減

1. AWSコストを30％削減
   • 課題:
     前任者が雑に作ったAWS環境が原因で、無駄なコストが発生していた。
   • 解決策:
     作りかけの中途半端なstaging環境や未使用のAWSリソースを削除・作り直しを行い、約30％のコスト削減に成功した。
   • 工夫点:
     Billing and Cost Managementを用いてリソース利用料金を分析することで網羅的なコスト削減とリソース整備を行った。また、productionとstagingでAWSアカウントを分けることでコスト管理・セキュリティ・インフラ運用の向上を行った。
2. staging環境構築とデプロイの安定化
   • 課題:
     • メンテナンスモードが無く、アクティブユーザーお構い無しで各々の独断でデプロイしていた。
     • staging環境がないのでぶっつけ本番での動作確認になっていた。
     • サーバーが2個しかないのにRolling Deploymentだったのでデプロイが不安定だった。
   • 解決策:
     • これまでメンテナンス時間がなかったので、Bizサイドに了承を得てメンテナンス時間を作ることで、デプロイの安定化を図った。
     • staging環境を構築
     • Rolling Deploymentでも耐えうるコードを設計し、サーバー数も増やすことで一時的な高負荷にも耐えられる設計を実装した。

マッチングアルゴリズム実装

1. マッチングアルゴリズムを実装し、CSの手作業を月100時間削減
   • 課題:
     • 空き枠とカウンセラーと歯科医師と顧客のスケジュールマッチングを、CSがExcel表を用いて手動でマッチングをしていた。
       この作業にCSの工数が月100時間も発生していて、もちろんヒューマンエラーも多発していた。
     • にも関わらず、自分以外のメンバーがマッチングアルゴリズムの実装に自信がなかったことも原因で実装されない状態が続いていた。
   • 解決策:
     CSと密に連携することで既存マッチング要件を擦り合わせながらアルゴリズムを構築した。
     これにより、ヒューマンエラーはゼロになり、CSの手作業を月100時間削減に成功した。
   • 工夫点:
     CSだけでなくPO・社長とも密に連携し、今後のプロダクトロードマップを加味してマッチングアルゴリズムを実装した。

「Resily」の開発

プロダクト概要

OKR管理ツール「Resily」の開発・運用をしていた。

プロジェクトの規模

• 開発メンバー: 8人（全員日本人）
• 開発期間: 2022年4月〜現在

技術スタック

担当役割

開発メンバーとして、フロントエンド、バックエンド、インフラ全ての分野で幅広く開発に携わっていた。
また、Resilyがアドバンテッジリスクマネジメント（ARM）に買収された後は、『アドバンテッジタフネスカウンセリング』の開発リーダーとして上流工程を行なっている。

担当業務

1. CS部門と密に連携しながらSREを導入することで効率的な監視体制を構築した
   • 課題:
     文字コードがSJISのCSVインポートができない不具合が発生し、ユーザーの一括登録ができず、新規契約顧客がサービスを使えなくなっていた。
   • 解決策:
     SJISのCSVインポートができるように修正を行うと同時に、SREの設定も行った。
   • 工夫点:
     開発リソース不足だったので、SREを導入することで効率良くプロダクトの品質向上に注力できるようにした。
     セッションリプレイやヒートマップ等のユーザー行動分析ツールを駆使し、CS部門と密に連携しながら以下を定義した。
     • 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にヒアリングを行いながら、ユーザーのリテラシーに合わせたデザインや機能を実装した。

「ARM」の開発

プロダクト概要

メンタルカウンセリング・コーチングのWebアプリケーション「アドバンテッジタフネスカウンセリング」の刷新をしている。

プロジェクトの規模

• プロジェクトメンバー: 20人（全員日本人）
• 開発期間: 2023年8月〜現在
• 開発規模: 3億円
• 開発スタイル: ウォーターフォール

担当役割

開発リーダーとして、RFPや要件定義書の作成、カウンセラーのマネジメントなど、上流工程を担当している。
具体的には以下を担当:

• スコープマネジメント
• コミュニケーションマネジメント
• ステークホルダーマネジメント
• スケジュールマネジメント
• リソースマネジメント
• 品質マネジメント

前提

このプロジェクトは私がアサインされる前からかなり炎上していた。
具体的には以下。

• 3年がかりの大プロジェクトにも関わらず、1年半経ってようやくRFPを作成し始めた段階。理由は、前任者が何も決めなかったから（これにより前任者は取締役を降格になった）。
• 要件定義やRFPの作成は本来エンジニアが行うべきだが、自分がアサインされた当時は上司（PjM）がそれら全てをカウンセラーに任せていた。理由は、この炎上案件の責任を取らされたくないから。

現在もその影響を強く受け、プロジェクトの進行が遅れに遅れているがリリース日は絶対にズラせないので、試行錯誤しながらなんとか前に進む様に奮闘している状況である。

コミュニケーション・ステークホルダーマネジメント

1. 社内用語ドキュメントを作成し、開発受託会社との認識齟齬を減らした。
   • 課題:
     一般的な言葉を使わず社内用語を多用していて、誤解を生みやすい && ハイコンテキストな状態だった。
     例えば『メール』と言う言葉が『チャット』の意味で使われていたり、『クロスセル』のことをARM社内では『アップセル』と呼んだり、『カウンセリング』を人によって『CNG』『CLG』と略したりとカオスな状態だった。
     自分だけならまだしも、今後アサインされるメンバーや外部ステークホルダー（開発受託会社やOEM売りを考慮した際の顧客など）との意思疎通に支障が出る状態だった。
   • 解決策:
     社内用語をドキュメントにまとめることで、認識齟齬を減らすことに成功した。
   • 工夫点:
     カウンセラー達に用語の説明文を書いてもらい自分がレビューすることで、チームで社内用語ドキュメントを運用できる仕組みを作った。
2. 無駄な仲介役の廃止
   • 課題:
     • 協業T社とのコミュニケーションを仲介するARM社内メンバーが無駄に二人も居た。これにより、伝書鳩のようなコミュニケーション構造になり、認識齟齬や単純なコミュニケーションコストが爆増していた。
     • 協業T社とのコミュニケーションを、チャットではなくExcelファイルを用いて行なっていた。しかもそのExcelを個人フォルダに置くなど情報管理が属人化していた。
   • 解決策:
     仲介役とExcelを廃止し、Backlogを用いて協業T社と直接コミュニケーションできるようにした。
   • 工夫点:
     仲介役は自分より年齢も役職も上だったので権限のない自分では廃止できなかった。
     よって、コミュニケーションを阻害している客観的証拠をPMに提示・説得することで廃止してもらった。

リソース・品質・スケジュールマネジメント

1. 上流工程の巻取り
   • 課題:
     RFP・要件定義書の作成は本来エンジニアが担当するべきタスクであるにもかかわらず、上司（PjM）はそれをカウンセラーにやらせていた。理由は上司が炎上案件の責任から逃れるためだった。
     なので、当たり前だが成果物の質・量ともに最低だった。実際、開発ベンダーから『何を言いたいのかよく分からない』『そもそも日本語として体を成していない』と言われた。。
   • 解決策と工夫点:
     • 一人で全ては巻き取れないのでシステムのコアドメイン機能に当たる部分は自分が担当し、それ以外の部分はカウンセラー達に任せることで少しはマシになった（もちろんリソース不足の中やっているので、まだまだ質は低い）。
     • 要望を要件として記述するための簡易的な文章テンプレートを用意したり、考え方の指針を示したり、内容レビューをしたりすることで属人化の排除を徹底させた。
2. カウンセラーをマネジメント
   • 課題:
     カウンセラー達がそもそもタスク・スケジュールマネジメントが一切できていなかった。
     理由は2つ。1つ目は人手不足。
     2つ目はカウンセラーの中で役職（部長や副部長、課長など）が、カウンセリング業務の成績だけで決まっているので、マネジメントスキルがない人が役職に就いていた。
     よって、マネジメントが破綻していて上流工程が進まない状況だった。
   • 解決策:
     • カウンセラーがスケジュールを全く意識してなかったので、Backlogを使い進捗管理を徹底させた。
     • 業務フロー図やER図などもExcelで管理していたが、重すぎて開かなくなったりメンテが大変だったので、Miroを導入したことで劇的に業務効率が上がった。
   • 工夫点:
     カウンセラー達とは15歳以上歳が離れているので、年齢差によるハレーションを防ぐ為に、信頼関係の構築に細心の注意を払った。
     具体的には、以下のような工夫をした。
     • 雑談を交えたり
     • お土産を送ったり
     • 年齢は若くても技術力は一人前であることを示す為に、自分のITに関する知見を披露したり
     • 三現主義に基づいてカウンセラー業務を理解したり
     • 一緒に飲みに行ったりなどした。
3. カウンセラーのリソース配分の調整
   • 課題:
     カウンセラー達は通常業務の合間にシステム開発の作業を行っていた為、コンテキストのキャッチアップやスイッチングコストが高く、作業効率が悪化していた。具体的には、リソースの1、2割を割くカウンセラーが5名もいたが、そんなちょっとの時間ではMTGにも参加できず、全体の決定事項などをキャッチアップすることが困難だった。そのため、タスクを振られても何をやって良いのか・何の為にやるのかを把握できず言われた事すらできない状況に陥り、ハレーションが発生していた。
   • 解決策:
     各カウンセラーにリソース配分を最低でも5割以上割く様に強く要請した。クオーターごとにリソース配分が決まっているので、次のクオーターからは5割以上のカウンセラーのみ残るようになり、作業効率が劇的に上がった。

調達マネジメント

1. 協業T社との契約漏れによる要件爆発。
   • 課題:
     ARMと協業T社の認識齟齬が大きく、要件爆発が起きていた。ARM側は『カウンセリングシステムをSaaS売りする為に汎用的に作る。協業T社はあくまで1顧客』という方針でこれまで検討してきた。しかし、協業T社から『ARMはT社専用にカスタマイズされたシステムを作ってもらうための請負会社だと認識しています』とストレートに言われた。本来であれば前任PMが、認識を合致させて契約を結ぶはずが、それをしていなかった。これにより、汎用的ではないT社専用のシステム要件が大量発生し、要件爆発が起きている。
     ではなぜ協業T社と関係を立たないかというと、『投資委員会（社内稟議）でシステム開発費をT社が半分出す』という前提で今回のプロジェクトの承認が降りているので、引くに引けない状況にあるから。
   • 解決策:
     正直、うまく解決できたとは微塵も思っていないし、まだ解決できていない。
     自分一人でエスカレーションしても解決しないと判断し、上司（PjM）とカウンセラー全員でPMにエスカレーションすることを依頼した。
     これにより、T社の要望をできるだけ断る嫌われ役を別の部署からPMが連れてきた。その人がT社との交渉を行い、ARM側の要望を概ね通すことができた。しかし結局いまだに契約は結んでいないので、後々手のひら返しされるか不安だが、とりあえず要件爆発は一件落着？した。