ID:73790さん

## プロジェクト概要（要約・チーム・目的） - 同時登録による送客システムの自動化の導入 - チームはPM1名、開発者3名（CTO・EM・私） - 実質的に私が中心に手を動かしCTOとEMにはフィードバックを頂く形で進行 - 目的は、管理画面からの同時登録による送客システムの自動化を実現し、クライアントとの連携までの運用時間を削減すること、ヒューマンエラーを防止すること、属人性をさらに低下させること、更なる売上増加に繋げること。 ## 当時の背景/抱えていた課題等 自身が携わった同時登録による送客システムの自動化の導入から半年以上が経過する中で、連携するクライアントが右肩上がりに増加。一方で、対応頻度が上がりヒューマンエラーが発生したことや、クライアントとの連携時間を約1日から3時間程度に短縮したものの、これ以上の短縮が品質担保のために望めないという課題がある。 ## プロジェクトにおける自身の役割 企画・要件定義・設計・実装・QA・リリース・保守運用を担当。Miroを用いて、これまでの同時登録による送客システムの自動化のアーキテクチャと新卒学生向け就活支援Webアプリのマイクロサービス化、共通認証基盤（Idp・リソースサーバー）のアーキテクチャを統合する図示を作成し、議論を行いやすい環境を整備した。また、auto_registrationデータベースを新規作成し、同時登録による送客システム元と連携して管理画面側からクライアントの要望（データの除外や抽出など）を反映できる仕組みを整備した。 ## 考慮するべきこと 1. マスタデータをどこのデータベースに持たせるか リソースサーバー側に持たせる場合、データの一貫性が保たれて管理が容易になる。しかし、全プロダクトで共通のマスタデータを利用するため、プロダクトごとのカスタマイズが難しくなり、リソースサーバーに依存するため単一障害点となるリスクがある。各プロダクト側に持たせる場合、プロダクトごとのカスタマイズが可能になるが、データの一貫性が保たれずに管理が煩雑になる。プロダクトごとに異なるデータベースを管理するコストが増加する。 2. auto_registrationデータベースとの連携先 ブラウザ側で連携する場合、ユーザーの操作に対するリアルタイムな反応が期待できるがセキュリティリスクが増大する。ブラウザ側のコードがエクスポーズされるため、データの不正アクセスや改ざんのリスクが高まる。一方、バックエンドの負荷が軽減される反面、ブラウザでの処理が複雑化しやすく開発・メンテナンスコストが増加する。各プロダクト側で連携する場合、セキュリティが強化されてデータの管理が容易になるが、バックエンドの負荷が増加する。 3. 管理画面の技術選定 社内の者だけが使用する管理画面を簡易的に作成する予定だが、その際の技術スタックを決めかねている。Ruby On RailsのViewで作成するか、ViewにReactを埋め込む形で作成するかで迷っている。RailsのViewで作成する場合、既存のリポジトリと統合しやすくCORSの問題が発生しない。社内向けの管理画面であり複雑なUIが不要であるため、RailsのViewを採用することでシンプルな構成で開発が可能となる。また、デプロイやインフラ管理が容易になり、開発コストが削減される。 ## 課題に対して自身が発揮したバリュー及び成果 現在進行中のため、以下に見込みインパクトを記載する 1. 売上の向上 - 同時登録による送客システムによる月あたりの合計売上額は約540万円。 - 送客データ1件あたりの売上は約300円、1日あたりの送客数は約100〜150件。 2. コスト削減 - 架電（インサイドセールスの人件費）を要しないことで、1日あたり約40万円、月あたり約1,200万円のコスト削減が見込まれる。 3. 業務効率化 - 連携日数は3〜5時間から1時間以内へと大幅に短縮（約3〜5倍の改善）。 - 属人性を低下させ、管理画面側からの設定でヒューマンエラーを防止。 4. スケーラビリティの確保 - 連携サービス数や案件数が増えてもクエリが軽くなり、システムのスケーラビリティが向上。 これらの改善により、全体売上の10%を占める重要な部分での効率化とコスト削減が実現され、さらにヒューマンエラーの防止やシステムのスケーラビリティ向上により、運用の安定性が高まることが期待される。

## プロジェクト概要（要約・チーム・目的） - 新卒向け就活支援Webアプリにおいて、AWS ECSのスロットリング発生時にCloudWatchとAWS SNSを連携させてSlackに通知を行うアラートシステムを主にTerraformで構築 - PM1名、開発者2名（CTOと私）の計3名 - 目的は、ECSのスロットリング発生時に自動で通知を行い、システムのダウンタイムを最小限に抑えること ## 当時の背景/抱えていた課題等 新卒向け就活支援Webアプリにおいて、主にコードのバグが原因と思われるECSのスロットリングが発生しやすい状況が続いていた。 また、改修前の段階ではスロットリング発生時に気づく手段がなかったため、迅速な対応が難しかった。この問題により、年間約40万円のインフラコストが発生していた。 ## プロジェクトにおける自身の役割 Terraformを使用してAWS ECSのスロットリング対策を実装。システムの要件定義から設計、Miroへの図示を行い、プロジェクトのビジョンを明確化した。その後、CloudWatchアラームの設定を行い、ECSのスロットリング発生時に自動でアラートを発砲する仕組みを構築。 AWS SNSを介してSlackに通知を行うシステムを設計し、迅速な対応を可能にした。さらに、IAMで適切なポリシーの設定を行い、AWS Systems Manager（SSM）でSlackのworkspace IDを安全に格納した。 バックエンド側では動作確認目的で意図的にスロットリングを発生させるコードを実装し、メトリクスのパフォーマンスチューニングを行った。 ## ボトルネックに対して工夫した点 TerraformとCloudWatchアラームのメトリクス設定において、最初に設定したPendingTaskCountでは、通常のデプロイ時にもECSのタスクがPendingTask状態になるため、スロットリング時との区別が難しかったこと。 これに対し、メトリクスをRepositoryPullCountに変更し、ECRに対して評価を行うことにした。具体的には、60秒間隔でRepositoryPullCountが1回以上評価された値が10期間のうち4回発生するとSlackにアラートが通知されるように設定を変更した。 また、スロットリングを意図的に引き起こすためにDockerのapp_task_definitionsに変更を加え、exitと1を追加することで、タスクが強制的に終了するようにした。 ## 課題に対して自身が発揮したバリュー及び成果 ECSのスロットリング発生時の対応が迅速化され、システムの安定性が向上した。この改善によりスロットリング発生を即座に認識できるようになり、年間約40万円のインフラコストの節約に貢献した。 さらに、社内の学びを共有する場で図示とともに当該プロジェクトの内容を同僚などに発表したところ、ECSをはじめとするAWSや新卒向け就活支援Webアプリのインフラ構成の知見が高まったこと。

## プロジェクト概要（要約・チーム・目的） - MySQLをDockerコンテナに含めることで、開発環境の最適化と環境差分のエラー削減を目的としたプロジェクト - 開発者2名（うち1名はCTO） - 目的は、MySQLのDocker導入による開発環境の最適化と環境差分のエラー削減 ## 当時の背景/抱えていた課題等 現状、Docker内にRedisとSidekiqは含まれているが、MySQLは手動で起動する必要があり、Rails Serverのバージョン相違によるエラーが頻発していた。これにより、開発をスムーズに進められない状況が続いていた。環境構築に1日以上かかることがあり、新しくジョインした開発者がスムーズに作業できないという課題があった。 ## プロジェクトにおける自身の役割 開発、テスト、導入、保守運用を担当。MySQLをDockerコンテナに統合し、環境構築の自動化を実現するために、Dockerfileやdocker-compose.ymlの設定を行った。また、config/database.ymlの修正を行い、Docker上のMySQLを参照するように設定。環境差分によるエラーを削減するため、最新のREADME.mdを更新し、チーム内での環境構築に関する齟齬を解消。 ## ボトルネックに対して工夫した点 システム開発において、バージョン相違や環境差分によるエラーが頻発していた。これに対して、DockerコンテナにMySQLを統合し、全開発者が同一の環境で作業できるようにした。また、環境構築の手順をREADME.mdに詳細に記載することで、新しい開発者がスムーズに環境を構築できるようにした。 ## 課題に対して自身が発揮したバリュー及び成果 MySQLをDockerコンテナに統合することで、環境構築にかかる時間を約3〜5時間から1時間以内に短縮。環境差分によるエラーが体感で90%以上減少し、スムーズな開発体制を実現。また、README.mdを最新に保つことで、チーム内での環境構築に関する齟齬が解消され、効率的な開発が可能となった。このプロジェクトにより、開発者の生産性が向上し、プロジェクト全体の進行が円滑に進んだ。

## プロジェクト概要（要約・チーム・目的） - AWS WAFとCloudFrontを連携させたDDoS攻撃対策とダウンタイム削減 - チームはPM1名と開発者2名（CTOと私）の計3名 - 目的は、DDoS攻撃によるシステムダウンタイムを削減し、年間の損失見込み額を90%以上減少させること ## 当時の背景/抱えていた課題等 当初、US-regionからのDDoS攻撃により、新卒向け就活支援Webアプリの約70%以上が約30分間ダウンしていた。CloudWatchのログより、DDoS攻撃を受けた具体的な部分は、CloudFrontからLambda@Edgeへのリクエストは成功していたものの、Lambda@Edgeからバックエンド（例：Creativeコントローラー）へのリクエストで問題が発生し、タイムアウトが繰り返される状況だった。これにより、ユーザーの信頼性が低下し、1時間あたり数十万円の損失が発生していた。 ## プロジェクトにおける自身の役割 CTOにフィードバックを頂きながら、AWS WAFのCloudFrontへの導入を主導。DDoS攻撃に対する防御策として、WAFルールの設定、監視体制の構築、アラートシステムの設定を担当。さらに、CloudFrontのED（Edge Distribution）設定を手動で調整し、WAFと正しく連携させる作業を実施。 ## 課題に対して自身が発揮したバリュー及び成果 具体的には以下のKPIや問題解決に貢献した。 - CloudFrontからLambda@Edgeへのリクエスト成功率の維持：DDoS攻撃時にもCloudFrontからLambda@Edgeへのリクエストが正常に処理されるようにし、システムの稼働率を確保 - Lambda@Edgeからバックエンドへのリクエストタイムアウト問題の解決：Lambda@Edgeからバックエンドへのリクエストで発生していたタイムアウト問題を解決 AWS WAFをCloudFrontに連携して導入した結果、DDoS攻撃一回あたりのダウンタイムを以前の30分から1分未満に削減。これにより、年間数百万円であった損失見込み額を90%以上削減。

## プロジェクト概要（要約・チーム・目的） - Rubyが中心の既存プロダクトからRedash・GASを用いて同時登録による送客システムを構築し、新たな売上軸を創出。その後、保守運用の中で標準化を行い、非エンジニアでも作業可能な環境を整備し、クライアントの要望反映時間を短縮。 - PM1名、営業チーム数名、役員数名、開発者3名（うち1名はCTO） - 目的は、同時登録による送客システムの導入・保守運用・標準化を行い、クライアントの要望を迅速に反映し、売上を向上させること。 ## 当時の背景/抱えていた課題等 弊社では新卒学生向けの就活支援サービスを提供している。以前はクライアントへの送客が完了した時点で、プロダクトへの新規登録で得たデータが使い切り状態になっていた。 このため、獲得したデータのLTVを伸ばす手段を模索し、弊社で獲得したデータをニーズのある企業に安全に送客することで、弊社とクライアント企業が双方に利益をもたらすシステムを構築することを課題とした。 ## プロジェクトにおける自身の役割 要件定義、営業チームからのヒアリング、設計、開発、テスト、導入、保守運用を担当。Redashの構築はチームのエンジニアが担当したが、SQLの修正やトリガーの設定などを担当した。Rubyが中心の既存プロダクトから取得したデータをRDSに保存し、Redashで加工したデータをスプレッドシートに反映。 その後、GASを使ってCSV形式でクライアントにデータを連携する流れを構築。システム構成図の作成、エンティティの抽出、テーブル設計、ER図の作成をMiroを用いて行い、営業チームや役員にも説明・議論しやすいように整えた。 ## ボトルネックに対して工夫した点 主に2点 1. システム開発において、多くの利害関係者との調整が必要だったこと 上記1に対して、例えばスプレッドシートのimport関数を用いたリアルタイムでの連携を試みたが、クライアントの営業時間がそれぞれ異なるため公平性が欠けるという指摘があった。そのため、営業チームと何度もミーティングを重ね、納期を考慮しながら優先順位を決め、要件漏れや認識の齟齬がないように進行した。 2. データの除外項目などクライアントから詳細な要望があったこと 上記2に対して、クライアントによっては「〇〇のデータは不要」「〇〇のデータだけほしい」など、取引数が増えることで様々な要求を頂くことになった。それらの要望をデータベース、Redash、スプレッドシートの関数のどこに修正を加えることで、より簡潔に要件に合ったデータを提供することができるのかをPMなどとも協議をしながらNotionやGitHubに変更履歴を残すことで、開発者だけが知っている状態に陥らないように対応した。 ## 課題に対して自身が発揮したバリュー及び成果 同時登録による送客システムの導入により、1案件あたり月間約50万円の売上を創出することに成功。現在では10案件以上にスケールアップ。 また、マニュアル作成により属人性を低下させ、NotionやGitHubに変更履歴を残すことで、開発側とビジネス側のコミュニケーション時間を削減し、クライアントの要望反映時間を約1日から3時間に短縮。これにより、データ連携の正確性が高まり、弊社全体売上の10〜15%を担う重要な収益源に成長させた。

## プロジェクト概要（要約・チーム・目的） - Rubyを用いて学歴グループのバリデーションを追加し、架電経由エントリーの誤登録を防ぐ機能を実装。 - エンジニア2名（うちCTO1名）。 - 目的は、学歴グループ外の学生が誤ってエントリーされるのを防ぐこと ## 当時の背景/抱えていた課題等 管理画面で学歴グループを設定しているにもかかわらず、学歴グループ外の学生が登録される問題が発生していた。これにより、クライアントからのクレームが週に1〜2件発生し、やり取りを含めると1件あたり1時間ほどかかっていたため、営業側のチームが対応に追われる課題があった。 ## プロジェクトにおける自身の役割 管理画面において、学歴グループのバリデーションを追加する実装を担当。学歴グループの設定が正しく機能するように、既存のバリデーションロジックを見直し、必要なテストケースをRspecで追加。エントリー時に学歴グループ外の学生が登録されないようにするためのエラーメッセージ表示機能も実装。また、システムの動作確認として、学歴グループ内外のユーザーのエントリーシナリオを検証し、正常に機能することを確認。 ## ボトルネックに対して工夫した点 障害対応と同様の温度感・速度感を持って迅速に対応しました。自分から積極的に営業チームや役員陣にヒアリングを行い、学歴グループのバリデーションロジックについて詳しく話し合いを重ねました。これにより、クライアントの要求を正確に反映するためのバリデーション強化を実現しました。 ## 課題に対して自身が発揮したバリュー及び成果 学歴グループのバリデーション強化により、学歴グループ外の学生が誤ってエントリーされる問題を解消。この改善により、クライアントからのクレームが週に1〜2件から0件に減少し、誤登録による月間約15万円の損失も防ぐことに成功。最新のREADME.mdを更新し、チーム内での環境構築に関する齟齬を解消することで、開発体制のスムーズ化を実現。

## プロジェクト概要（要約・チーム・目的） - 新卒向け就活支援Webアプリにおいて、Salesforceの管理画面での検索効率を改善するため、管理者テーブルにステータスカラムを追加し、使用していない管理者を非アクティブに設定する仕組みを導入。 - PM1名、営業チーム数名、開発者3名（うち1名はCTO）。 - 目的は、管理画面の検索効率化を通じてSalesforceの運用を改善し、業務効率を向上させること。 ## 当時の背景/抱えていた課題等 管理画面で1000人以上の管理者が表示されており、管理者の検索に平均7秒かかっていた。これにより業務効率が低下していた。また、Salesforceのoperatorテーブルにstatusカラムがなく、管理者のステータス管理ができていなかった。 ## プロジェクトにおける自身の役割 フルスタックエンジニアとして、タイムズのadminsテーブルにstatusカラムを追加し、statusカラムをSalesforceのoperatorカスタムオブジェクトに連携する作業を担当。バックエンドはRubyを使用し、管理画面はReact, TypeScript, Nextjsで構築。バリデーションロジックを実装し、Salesforceフローを修正して、statusがactiveなユーザーのみが架電ログで表示されるようにした。 ## 今後実装していきたい部分 現状の改善点に加えて、(他のタスクとの優先度との兼ね合いもあるが)さらにユーザー検索の速度を向上させるために、データベースにインデックスを付与することを検討している。特に、statusカラムにインデックスを付与することで、activeなユーザーのみを効率的に検索できるようにし、システム全体のパフォーマンス向上を図りたい。 ## 課題に対して自身が発揮したバリュー及び成果 タイムズのadminsテーブルにstatusカラムを追加し、使用していない管理者を非アクティブに設定することで、1000人以上いた管理者の表示数を200人以下に減少させた。この結果、管理者の検索時間が平均7秒から2秒に短縮された。

## プロジェクト概要（要約・チーム・目的） - AIを活用したWeb履歴書自動作成アプリのトップページ改修。 - チームはPM1名、開発者2名（1名はCTO）、デザイナー1名の計4名。 - 目的はトップページのUI/UXを改善することにより、ユーザーの離脱率を減らして売上を向上させること。 ## 当時の背景/抱えていた課題等 当初、トップページからのユーザー離脱率が高く、新規ユーザー登録も低迷していた。トップページのUI/UXが直感的でなく、ユーザーが必要な情報に迅速にアクセスできないことが課題だった。また、既存のデザインが古く、ユーザーにとって魅力的なデザインとはいえないことも離脱率の高さの一因と考えられた。 ## プロジェクトにおける自身の役割 トップページ改修において、フロントエンド開発を主に担当。Tableauでユーザーファネルデータを分析し、離脱率の高さについてPMやCTOに提案してプロジェクトチームを結成。その後、デザイナーとFigmaを用いてUIを協議し、Next.js・React・TypeScriptを使用してPCとSPのトップページを改修。 ## 課題に対して自身が発揮したバリュー及び成果 リリース後3ヶ月でユーザー離脱率を約70%から20%に削減。さらにその半年後には、PCユーザーのプロフィールページ到達率が約540人から約4120人へ（約8倍）、SPユーザーでは約1010人から約4770人へ（約5倍）に増加。アクションページ（売上）への到達数も、PCユーザーで約30人から約1660人へ（約60倍）、SPユーザーで約60人から約1660人へ（約30倍）に大幅増加を実現。