yama

## プロジェクト概要（要約・チーム・目的） - 送客業務を自動化するための管理画面システムを新たに構築 - チームはPM1名、開発者3名（CTO・EM・私） - CTOやEMからのフィードバックを受けつつ、自分が実装・設計・運用の中心を担った - 目的は、案件数の増加に対応できるスケーラブルな仕組みを整えることで、ヒューマンエラーの防止や運用負荷の軽減・売上のさらなる拡大を実現すること ## 当時の背景/抱えていた課題等 既存の送客システムでは連携クライアント数の増加にともない、手動対応の限界が見え始めていた。処理件数の増加に比例してヒューマンエラーの頻度が高まり、運用工数や属人性の高さもボトルネックになっていた。さらなる短納期化やクオリティ担保を両立させるため、運用の自動化と管理機能の整備が求められていた。 ## プロジェクトにおける自身の役割 CTOやEMからのフィードバックを受けつつ、企画・要件定義・設計・実装・テスト・リリース・保守運用を一貫して担当。Miro上でアーキテクチャを図示し、FigmaでUIを確認しながら既存の同時登録システムと新卒向け就活支援Webサービスとの連携イメージを明確化。auto_registrationデータベースを新設し、管理画面からBigQueryを通じてクライアントの除外・抽出条件を設定可能にした。セキュリティや負荷を考慮し、連携方法は各プロダクト経由とした。また、技術選定ではRails Viewを採用し、社内利用に最適なシンプル構成でCORS問題も回避した。 ## 考慮した論点と設計上の工夫 ### 1. マスタデータをどこのデータベースに持たせるか 新卒向け就活支援Webサービス側にマスタデータを集約すれば、データの一貫性を保ちやすく管理もシンプルになる。一方で、各プロダクトが共通のデータを参照するため、個別にカスタマイズが必要なケースでは柔軟性が乏しくなり、新卒向け就活支援Webサービスが単一障害点になるリスクもある。 逆に、各プロダクト側でマスタデータを保持する構成にすれば、個別要件への対応がしやすくなるが、整合性の担保が難しくなり運用コストも増大する。 ### 2. auto_registrationデータベースとの連携先 ブラウザ側から直接連携する場合、ユーザーの操作に即したレスポンスが可能になる反面、クライアント側のコードが露出するためセキュリティリスクが高まる。また、複雑な処理がブラウザに移ることで開発や保守の難易度も上がる。 一方で、各プロダクトのバックエンドを経由して連携する方式であれば、データの安全性が高まり、管理もしやすくなるが、サーバー側の負荷が増える点には注意が必要。結論としては、よりセキュアな後者を選択。 ### 3. 管理画面の技術選定 管理画面は社内専用のため、UIの複雑さは求められていない。RailsのViewのみで構築すれば、既存リポジトリとの統合が容易で、CORSの問題も発生しにくい。また、デプロイやインフラ管理がシンプルになり、開発コストの削減にもつながる。一方で、今後インタラクションの多いUIが求められる場合には、FEとBEを分離して、FEにはReact Router を用いて開発する可能性もあり。（SEOは考慮しないため、Next.jsは構想外） ## 課題に対して自身が発揮したバリュー及び成果 - 月900万円規模の売上を創出 - インサイドセールスの人件費（月600万円相当）を実質的に削減 - 送客システムの自動化により、1案件あたりの運用工数を約4時間から10分に短縮。 - データ連携の高速化・属人性の排除・UI経由での柔軟な設定対応により、運用負荷を下げながら精度を向上。

## プロジェクト概要（要約・チーム・目的） - 新卒向け就活支援Webアプリにおける、ECSのスロットリング検知体制をTerraformで構築 - チーム構成はPM1名、CTOと自分を含む開発者2名の計3名 - スロットリングによる起動失敗を早期に検知し、ダウンタイム・損失を最小化することが目的 ## 当時の背景/抱えていた課題等 新卒向け就活支援Webアプリにおいて、コードのバグが原因と思われるECSのスロットリングが発生しやすい状況が続いていた。また、改修前の段階ではスロットリング発生時に気づく仕組みが存在しなかったため、迅速な対応が難しかった。この問題により、年間約40万円のインフラコストが発生していた。 ## プロジェクトにおける自身の役割 Terraformを用いてCloudWatch Alarm、SNS、AWS Chatbot、Slack通知の一連構成を設計・実装。アラート発砲時のメッセージルートや、Slack Workspace IDのSSM管理、IAMポリシーの制御まで対応。Slack通知の受信確認やアラート条件の調整も含め、監視体制をインフラコードで整備した。 また、誤検知を避けるためにメトリクスには PendingTaskCount ではなく RepositoryPullCount を採用。通常のタスク起動との区別がつくようにし、60秒間隔で10回中4回を超えた場合のみ通知されるよう閾値を調整。検証ではappのタスク定義に exit 1 を含め、スロットリング再現テストも実施。 ## ボトルネックに対して工夫した点 ECSタスクのスロットリング検知を目的にCloudWatchアラームを構築。初期は PendingTaskCount を用いたが、通常のデプロイ時にも発火するためスロットリングとの区別が困難だった。これを受けてメトリクスを RepositoryPullCount に変更し、60秒間隔のうち10期間中4回以上リクエストが発生した場合にSlack通知が発火するよう修正。動作確認として、app_task_definitions に exit 1 を追加して意図的に強制終了を再現し、ECSタスクの状態がPendingの続くスロットリング状態にさせることで、監視アラートの動作確認と閾値調整も実施した。 ## 課題に対して自身が発揮したバリュー及び成果 ECSのスロットリング発生時の対応が迅速化されてシステムの安定性が向上した。この改善によりスロットリング発生を即座に認識できるようになり、年間約40万円のインフラコストの節約に貢献した。 さらに、社内の学びを共有する場で図示とともに当該プロジェクトの内容を同僚などに発表したところ、ECSをはじめとするAWSや新卒向け就活支援Webアプリのインフラ構成の知見が高まったこと。

## プロジェクト概要（要約・チーム・目的） - MySQLをDockerコンテナに統合し、開発環境の最適化と環境差分によるエラー削減を図ることを主目的 - 加えて、海外メンバーのスムーズにオンボーディングできる環境を整備することも目的 - チームは開発者2名（うち1名はCTO）で構成 ## 当時の背景/抱えていた課題等 現状、Docker内にはRedisやSidekiqが含まれていたが、MySQLは手動起動が必要だったため、Railsのバージョン差分やDB接続ミスなどのエラーが頻発していた。特に、新規ジョインしたインド在住エンジニアの環境構築に1日以上かかるケースもあり、オンボーディングのボトルネックとなっていた。 ## プロジェクトにおける自身の役割 MySQLのDocker統合と環境構築の自動化を担当。Dockerfileやdocker-compose.yml、database.ymlの設定を行い、開発者全員が同じ状態のDB環境で作業できるようにした。また、点在していた環境構築手順をREADMEに統合し、KPIシートや社内ツールの技術情報を集約。英語圏のエンジニアに向けてAIを活用して英訳を行い、オンボーディングドキュメントを整備。新メンバーが3日以内に開発へ参加できる状態を実現した。 ## ボトルネックに対して工夫した点 開発環境の差分によるエラーを抑えるため、Dockerでの構築手順を全社標準化し、READMEに従えば誰でも同じ環境が再現できる状態を目指した。また、環境構築に不慣れな新規メンバーでも詰まらないよう、構成ファイルや手順の整備とあわせて必要なKPIや設定情報へのリンクも一元管理。適度なSync-upミーティングやペアプロを通じて技術理解もフォローし、言語や文化の壁を越えて開発に参加できるようにした。 ## 課題に対して自身が発揮したバリュー及び成果 MySQLをDockerに統合したことで、環境構築時間は3〜5時間から1時間以内へ短縮。環境差分によるバグも体感で90%以上減少し、プロダクトの開発効率が大幅に向上。READMEとオンボーディングドキュメントの整備により、インド在住エンジニアの開発参加を3日で実現した。環境構築の属人性が排除され、継続的な開発基盤としての再利用性も高まった。

## プロジェクト概要（要約・チーム・目的） - AWS WAFとCloudFrontを連携させたDDoS攻撃対策とダウンタイム削減 - チームはPM1名と開発者2名（CTOと私）の計3名 - 目的はサービス全体の可用性を担保し、DDoS攻撃によるビジネスインパクトを最小限に抑えること。 ## 当時の背景/抱えていた課題等 USリージョンからの大規模DDoS攻撃を受け、全体のLPのうち50%以上が約30分間ダウン。CloudWatchログを確認すると、CloudFrontからLambda@Edgeへのリクエストは成功していたが、その先のRailsバックエンド（コントローラー）へのリクエストでFetchErrorが発生してタイムアウトを繰り返していた。これにより、ユーザー離脱と信頼性低下を招き、1時間あたり30万円の損失が見込まれる状態だった。 ## プロジェクトにおける自身の役割 CTOの技術的レビューを受けながら、自ら主導してAWS WAFとCloudFrontの連携をServerless Frameworkを使って構築。具体的には、レート制限・地理制限を含むWAFルールを設計・設定し、CloudWatchログと連携させたアラート通知を整備。WAFの有効化にあたっては、手動でCloudFrontディストリビューションの設定も更新し、意図したルールが正しく適用されているかを含め動作確認を行った。 ## 課題に対して自身が発揮したバリュー及び成果 - DDoS攻撃を受けてもCloudFrontからLambda@Edgeへのリクエスト成功率を維持。 - Lambda@EdgeからバックエンドへのFetchError（レスポンスタイムアウト）を調査し、トラフィック過多時の処理安定性を改善。 - Serverless FrameworkによるWAF構成のTerraformにより、IaC化を実施することで今後のメンテナンス性を向上。 - 結果として、1回あたりのダウンタイムを約30分から1分未満に削減し、年間で想定されていた損失額の90%以上を抑制。サービスの安定稼働と信頼性向上に貢献した。

## プロジェクト概要（要約・チーム・目的） - Rubyを中心とした既存プロダクトに対し、Redash・GASを用いた同時登録による送客システム構築のサポートを行い、新たな売上軸を創出。企画提案から一部実装、保守運用までを担当 - チーム構成はPM1名、営業チーム数名、役員数名、開発者3名（うちCTO1名） - 目的は同時登録による送客システムを導入・運用・標準化し、クライアントの要望を迅速に反映して売上を向上させること ## 当時の背景/抱えていた課題等 新卒向け就活支援Webサービスでは、クライアントへの送客が完了した時点で新規登録ユーザーのデータが使い捨てられていた。獲得したデータのLTVを高めるため、ニーズのある企業へ送客できる仕組みを検討。ユーザー・クライアント双方にとって価値ある形でデータを活用し、継続的な売上につなげることが課題だった。 ## プロジェクトにおける自身の役割 上記の課題に対して営業チームと連携しながら企画・提案を自ら行い、一部Redash実装、スプレッドシート関数の整備、GASでのCSV出力、保守運用を担当。Redashの構築やインフラ設計などは他メンバーが主導しており、SQLの軽微な修正や出力トリガーの調整、関数最適化、納品フロー改善を軸に業務を推進。マニュアルや運用ドキュメントも整備し、属人化を防いだ。 ## ボトルネックに対して工夫した点 主に2点 ### 1. 多くの利害関係者との調整が必要だったこと。 スプレッドシートの IMPORT 関数を用いたリアルタイム連携を試みたが、セキュリティ上の懸念やクライアントごとに営業時間が異なるという事情から、公平性に欠けるという指摘があった。この課題に対しては、営業チームと何度もミーティングを重ね、納期や優先順位をすり合わせながら、要件漏れや認識の齟齬が起きないよう丁寧に調整を行った。 ### 2. クライアントごとの細かいデータ要望への対応。 「〇〇のデータは不要」「〇〇だけ欲しい」といった個別のリクエストが増えたことで、対応の複雑さが増していった。これに対しては、データベース・Redash・スプレッドシート関数のどこにロジックを実装すべきかをPMと協議しながら判断。実装内容と変更履歴はNotionやGitHubに残すことで、属人化を防ぎ、誰でも追える状態を保った。 ## 課題に対して自身が発揮したバリュー及び成果 - システム導入後は1案件あたり月90万円の売上を実現 - 営業チームの功績により、現在は10案件以上へ拡大 - 属人性の排除により、クライアントの要件反映までの対応時間を1日→3時間に短縮 - 会社売上全体の約10%を担う収益源に成長させた

## プロジェクト概要（要約・チーム・目的） - 新卒学生向け就活支援サービスの管理画面において、学歴グループに基づくエントリー制限機能の改修を担当 - エンジニア2名（うちCTO1名） - 学歴グループ外の学生が誤って企業にエントリーされる問題を防ぎ、クライアントからの信頼を維持・向上させること ## 当時の背景/抱えていた課題等 管理画面で学歴グループを設定しているにもかかわらず、システム側でバリデーションが機能しておらず、対象外の学生が企業にエントリーできてしまう状態だった。その結果、クライアントからのクレームが週1〜2件ペースで発生しており、営業チームがその対応に追われていた。1件あたりの対応工数は平均1時間程度で、事業側にも無視できない業務負荷と損失が生じていた。 ## プロジェクトにおける自身の役割 管理画面のバリデーション処理を見直し、学歴グループ外の学生がエントリーできないようにユニーク制約を付与した中間テーブルとバリデーションを用いたロジックを実装した。Rspecを用いて正常系・異常系のテストケースを設計し、既存処理との整合性を担保しながら機能改修を行った。営業チームと連携し、過去のクレーム内容を確認しながら想定される誤操作や例外パターンも考慮してエラー表示の内容を調整。検証段階では、学歴グループの設定パターンごとに実際のユーザー登録シナリオを再現し、挙動確認まで一貫して行った。 ## ボトルネックに対して工夫した点 障害レベルのインシデントとしてスピード重視で対応。実装前の段階で営業チームや役員と直接ヒアリングを行い、現場での実態や求められている動作を正確に把握した。実装後はREADMEを更新し、学歴グループバリデーションの仕様を明文化。ドキュメントによる共有を行うことで、開発チーム内の再発防止と機能保守性の向上にもつなげた。 ## 課題に対して自身が発揮したバリュー及び成果 学歴グループのバリデーション機能強化によって、誤登録の問題は完全に解消。週1〜2件発生していたクレームはゼロになり、月15万円程度の損失を防止できた。営業チームの対応工数も削減され、クライアントとの信頼関係の再構築にも寄与した。プロダクト品質の改善を通じて、全体のユーザー体験と事業運営効率の向上に貢献した。

## プロジェクト概要（要約・チーム・目的） - 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人から約4,120人へと約8倍に増加。SPユーザーでは約1,010人から約4,770人へと約5倍に伸びた。 さらに、サービスの売上導線であるアクションページ到達数は、PCユーザーで約30人から約1,060人へと約35倍、SPユーザーでも約60人から約2,660人へと約45倍に増加。こうした成果を通じて半年後には、会員登録数も約2,000人から約20,000人へと約10倍に成長し、サービスのスケールに貢献した。 離脱率 - リリース後3ヶ月でトップページのユーザー離脱率を - 約70% → 約20%（約50pt改善） プロフィールページ到達率 - PCユーザー: 約540人 → 約4,120人（約8倍） - SPユーザー: 約1,010人 → 約4,770人（約5倍） アクションページ（売上導線）到達数 - PCユーザー: 約30人 → 約1,060人（約35倍） - SPユーザー: 約60人 → 約2,660人（約45倍） 会員登録数（半年後） - 約2,000人 → 約20,000人（約10倍）