ID:84880さん

## プロジェクト概要 正社員求人機能の新規開発により、スポットワーク以外の収益基盤を拡充する自社プロダクトの構築を推進しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアとして、Ruby on Railsを用いた求人機能の設計および実装を担当しました。 - Terraformを活用し、インフラリソース構築と運用を行いました。 - メール受信サブドメインの MX レコードの策定と定義 - Private S3 バケットの追加 - など - メッセージ機能の詳細設計からステークホルダーとのレビュー調整、合意形成までを推進し、汎用性の高い設計を意識しました。 ### チーム規模と構成 - エンジニア5名、プロダクトマネージャー2名からなる約7名規模のチームでアジャイル開発を実施しました。 ## 背景・課題 - スポットワーク中心の収益構造から多角化を図るため、正社員求人機能を新規に開発し、収益の柱を強化する必要がありました。 - 企業とワーカーはメールで採用の連絡を行っていますが、それだとリードタイムがかかったり、返信がなかったりで採用ファネルにおける歩留まりが目立っており、メッセージ機能を通じてその歩留まりを改善する必要がありました。 - ただ、メッセージ機能は複数の利用ケースに対応可能な汎用的設計を求められ、設計の品質確保とステークホルダーへの説明責任が大きな課題でした。 - ステークホルダーのレビューや合意形成に時間を要し、設計から実装開始までのリードタイムが通常より長めとなっていました。 ## 実際の取り組み ### 開発環境 - 開発手法は週一スプリントのアジャイル開発を採用し、継続的に機能の設計・実装・レビューを行いました。 - バックエンドはRuby on Railsを中心に構築し、インフラにはTerraformでコード管理したAWSリソース（Amazon ECS、Amazon Aurora MySQL、Amazon S3）を利用しました。 - DockerおよびDocker Composeを用いてローカル環境の再現性を確保し、SendGridによるメール送信機能の設計・実装も担当しました。 ### 設計・改善内容 - メッセージ機能の汎用性を維持しつつ、仕様変更に柔軟に対応可能な設計を目指し、詳細設計書を丁寧に作成しました。 - 企業がメールを送るとメッセージとして作成されるような設計になっています。Webhook エンドポイントがメールを受け取り、メッセージとして変換されるようになることで、企業側は普段のコミュニケーションチャネルを使いつつ、意思疎通をできる口を設け、将来的には管理画面上でもメッセージを使えるような設計にしています。 - ステークホルダーへ設計内容を明確に伝えるため、ドキュメントの充実を図り、レビューを重ねて合意形成の迅速化に努めました。 - RFC の公式資料をもとに根拠をしっかり明示することを意識しました。 - 運用・保守フェーズを考慮し、モニタリングにはDatadogを利用し、パフォーマンスのモニタリングを行っていました。 ### その他アピールポイント - 新卒のカルチャー面接の担当官、中途の技術面接の担当官をしています。 ## 成果・価値 - プロジェクトは現在進行中であり、明確なビジネスインパクトは未計測ですが、安定した汎用メッセージ基盤を構築中で、広くインパクトがある内容になる想定です。

## プロジェクト概要 新規事業として長期アルバイト採用 PJ の立ち上げから Join し、0 -> 1 で自社プロダクトの収益基盤の構築を行いました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアとして、求人入稿機能や長期アルバイト採用機能の設計・実装、サービス運用を担当しました。 - フロントエンドの一部実装とUX改善にも携わり、ユーザー体験の向上を支援しました。 - キャッシュ設計・実装を行い、大規模ユーザーのカウント処理の効率化を図りました。 - クライアントや社内から来る様々なお問い合わせの対応を行いました。 ### チーム規模と構成 - エンジニア5名、プロダクトマネージャー1名、デザイナー1名、データアナリスト1名の計8名のチーム体制で、週一回のスプリントを軸にスクラム開発を行いました。 ## 背景・課題 - 単発のスポットバイトに依存しがちだった収益モデルを拡張し、長期アルバイトという時間軸の広い採用機能の開発が求められました。 - 新規事業で顧客ニーズが明確でなかったため、要件の不確定性が高く、機能の取捨選択や優先順位付けが困難でした。 - 顧客の実態に即した機能設計ができていないリスクが高く、早期に検証とフィードバックを得る必要がありました。 ## 実際の取り組み ### 開発環境 - フロントエンドはTypeScriptとNext.jsを用い、バックエンドはRuby on RailsでAPI設計・構築を行いました。 - インフラ環境はTerraformで管理されており、Amazon ECS、S3、Aurora MySQL、Dockerコンテナを活用していました。 - チーム内のドキュメント管理や進捗共有にはNotionを利用しており、Notion AI を使って効率的な情報収集が可能でした。 ### 設計・改善内容 - 求人入稿機能の設計・実装においては、まず最小限で使われる状態を目指すために CSV での入稿に限定し、そこでフォーマットの策定とビジネスサイドへの周知・連携まで担当。 - 長期アルバイト採用機能の有効・無効の管理を実装（xxx月から有効などの期限も加味した設計に）し、サービスの運用負荷を軽減しつつ、柔軟な機能制御を実現しました。 - 大規模ユーザーのカウント処理に関しては、キャッシュ周りの設計を最適化し、レスポンス性能とスケーラビリティを向上させました。基本的には KVS を使ってキャッシュを行い、適切な TTL を設定しました。 - 開発初期段階からチーム内外でのプロトタイプ共有を活用し、Bizサイドや顧客からのフィードバックを迅速に取り込む体制を構築しました。 - 継続的なスプリントレビューにBizサイドに参加してもらうことで、顧客ニーズの理解を深め、機能の優先順位調整に反映しました。 ### その他アピールポイント - Claude CodeやCursorなどの最新ツールを活用し、効率的なコーディングやリファクタリングを推進しました。 - SwiftとSwiftUIを用いたモバイルアプリの一部機能開発にも携わり、クロスプラットフォームでのサービス拡張に貢献しました。 ## 成果・価値 - チーム全体で月間約1,500万円の売り上げを生み出す基盤機能を構築し、新規事業の安定収益化に寄与しました。 - [https://corp.timee.co.jp/news/detail-6979/](https://corp.timee.co.jp/news/detail-6979/) - 顧客ニーズを反映した機能設計と迅速なフィードバックループにより、リリース後の顧客満足度と利用率が向上しました。 - 運用・保守体制の整備により、サービスの高可用性とパフォーマンス維持を実現しました。

## プロジェクト概要 インシデント対応を迅速化し、復旧と学びを支援する自社プロダクトのインシデントマネジメントサービス開発を担当しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドおよびフロントエンドエンジニアとして、Ruby on RailsとNext.jsを用いた機能設計と実装を担当しました。 - Webhook通知機能の設計から実装までを一貫して担当し、顧客要件の理解と最適な設計方針の策定に注力しました。 - "業務委託での参画"において、顧客との信頼関係構築と合意形成に注力し、円滑なプロジェクト推進に貢献しました。 ### チーム規模と構成 - 開発チームはエンジニア4名で構成され、アジャイル開発手法に基づく協働体制でプロジェクトを推進しました。 ## 背景・課題 - インシデントマネジメントサービスで発生したイベントをWebhookとして通知する機能は任意のイベント発生時に外部システムへ情報を送る重要な機能であり、一から要件定義や設計を行う必要がありました。 - ビジネス要件と技術的制約のバランスを取りながら最適解を模索することが最大の課題であり、設計に多くの時間を費やしました。 ## 実際の取り組み ### 開発環境 - バックエンドはRuby on Rails、フロントエンドはTypeScriptとNext.jsを使用しており、GraphQLを介した効率的なデータ通信を行っています。 ### 設計・改善内容 - Webhook通知機能についてビジネス価値を顧客目線で言語化し、設計の根拠を明確に示すことで、関係者との合意形成を促進しました。 - 顧客や社内双方にとって運用コストが抑えられ、かつ拡張性の高い設計を意識し、スケーラブルかつ柔軟なWebhook通知システムを構築しました。 - フロントエンド側も含めて通知設定のUI/UXを設計し、ユーザーが直感的に操作できる環境を提供しました。 ### その他アピールポイント - 業務委託という立場ながら、積極的なコミュニケーションと顧客視点の提案により、信頼獲得とプロジェクトの円滑な進行に貢献しました。 ## 成果・価値 - リリース直後のため正確な成果は未確定ですが、Webhook通知機能の導入意向を示す企業が存在し、将来的なビジネス貢献が期待されています。

## プロジェクト概要 働き手と雇い手のマッチング領域における品質向上を目的とした自社プロダクトの機能設計・開発・運用を担当し、売上向上に寄与しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアとしてRuby on Railsを用いたAPI設計・実装、およびパフォーマンスチューニングを主導しました。 - フロントエンドエンジニアとして、TypeScript、React、Next.jsを活用したユーザーインターフェースの実装と保守を担当しました。 - 運用・保守フェーズにも携わり、Datadogを用いた監視と障害対応に従事しました。 ### チーム規模と構成 - エンジニア6名、プロダクトマネージャー1名、マーケティング1名、デザイナー1名、スクラムマスター1名の計10名のチームでスクラム開発を実践しました。 - スクラムマスターのリードのもと、週1回のスプリントレビューやデイリースクラムを通じて密なコミュニケーションを行い、継続的な改善を推進しました。 ## 背景・課題 - 働き手と雇い手のマッチング率が売上に直結するため、マッチング領域の品質向上が急務でした。 - 作成した機能をいかに実際のユーザーに使ってもらうかが課題であり、次に取り組むべき機能の選定や優先順位付けが困難でした。 - 機能追加による効果の計測が不十分だと、リソースの無駄遣いにつながるリスクがあったため、継続的な評価と改善が必要でした。 ## 実際の取り組み ### 開発環境 - スクラム開発手法を採用し、1週間1スプリントで計画的に開発を進めました。 - バックエンドはRuby on RailsとAmazon Aurora MySQLを用い、Amazon ECS上でコンテナ運用を行いながら、パフォーマンスの最適化に注力しました。 - フロントエンドはTypeScript、React、Next.jsを活用し、ユーザー体験の向上と保守性の高いコードベースを実現しました。 - Datadogを利用し、システムパフォーマンスの監視とログ分析を行い、運用の安定化に貢献しました。 - システムとしては Rails を使ったモジュラモノリスなアプリケーションサーバーでコードベースが巨大です。 ### 設計・改善内容 - 新機能のAPI設計に際しては、ユーザー数が多いためパフォーマンス劣化を防ぐため、クエリの最適化やキャッシュ設計に重点を置きました。 - 機能追加は必ず削除可能な設計とし、リリース後に利用状況の観測やA/Bテストを実施して機能の有用性を検証しました。 - チーム全体でスクラムイベントを通じて対話を重ね、機能の優先順位を明確化し、不要な機能の早期削除と必要な機能の追加を繰り返すことで、開発のフォーカスを維持しました。 ### その他アピールポイント - 継続的なモニタリングと分析に基づき、機能の改善サイクルを高速化し、顧客のニーズに迅速に対応できる体制を確立しました。 ## 成果・価値 - 追加した機能の利用促進により、マッチング率が月間で約0.1〜2%向上し、これが売上に寄与しました。 - マッチング率向上により、月間約200万〜300万円の売上増加効果をもたらし、プロダクトの競争力強化に貢献しました。 - 継続的なA/Bテストと利用観測を通じて、機能改善の効率化が進み、チーム全体の開発生産性向上にも寄与しました。

## プロジェクト概要 LINE連携のチャットbotサービス開発において、API連携強化と運用効率向上を実現しました。 ## 役割・体制 ### 自身のポジションと役割 - 当初はメンバーとしてバックエンド、フロントエンド、インフラの構築および運用を担当し、途中からチームリーダー兼エンジニアリングマネージャーとして組織運営と開発チームの技術的推進を担いました。 - LINE APIおよび複数のEC系ツールとのAPI連携設計・開発、DBチューニング、マイクロサービス間トレーサビリティの向上などを実施しました。 - インフラの運用も向上的に行なっており、IAM の管理や Amazon Aurora MySQL のアップグレード、不具合調査（StepFunctions が途中でコケている原因調査など）、S3 バケットの管理、EC2 インスタンスサイズの調整などを行なっていたりしました。 - 新卒エンジニアの教育や開発タスクの優先順位調整、社内外のステークホルダーとの調整ミーティングを継続的にリードしました。 ### チーム規模と構成 - 途中まで業務委託含む5～6名のエンジニアチームで、後に4名体制に縮小されたチーム構成で開発を推進しました。 ## 背景・課題 - 多数のAPI連携先が存在する中で、データ連携に不整合や遅延が生じるケースが発生し、顧客からの問い合わせが増加して業務負荷が高まっていました。 - 開発リソースが限られる中、問い合わせ対応に割く時間が増大し、他プロダクトの開発時間が圧迫されるという課題がありました。 - チャットbotサービスの利用拡大に伴い、システムの安定稼働と迅速な問題検知が求められていました。 ## 実際の取り組み ### 開発環境 - アジャイル開発を採用し、2週間1スプリントのリリースサイクルで機能開発と運用改善を継続的に実施しました。 - 開発環境のDocker化を推進し、環境構築の標準化と迅速化により新規メンバーのオンボーディング時間を短縮しました。 - マイクロサービス構成になっており、Rails のアプリケーションサーバーがありつつ、各 EC プラットフォームとデータ連携をする AWS Lambda があり、データストアは Amazon Aurora MySQL と DynamoDB、データの ETL として AWS StepFunctions で AWS Glue の ETL ジョブを動かして S3 に分析用のデータを保持する仕組みで行っていました。 ### 設計・改善内容 - API連携のトレーサビリティ向上を目的に、ログ出力の追加と不要ログの削減をバランスよく実施し、問題検知の精度を高めました。 - Slack連携によるエラーログ自動通知体制を構築し、障害発生時の初動対応を迅速化しました。 - APIのレートリミットを考慮したリクエスト設計と、結果整合性を前提とした非同期処理の導入により、データ連携の安定性と処理速度を改善しました。 - Amazon Aurora MySQLのパフォーマンスチューニングを行い、DB負荷の軽減と応答速度向上を実現しました。 ### その他アピールポイント - チームリーダー兼エンジニアリングマネージャーとして、多様な技術課題の解決とチームの生産性向上を両立させ、新卒エンジニアの育成にも注力しました。 ## 成果・価値 - データ連携に関する顧客問い合わせを約3割削減し、開発リソースを確保することで他プロダクトの開発時間を増加させました。 - 新たにSMSを活用したカゴ落ちリマインド機能を追加し、年間約120万～150万円の売上貢献を達成しました。 - Docker化による開発環境の標準化で環境構築工数を削減し、社内全体の開発生産性向上に寄与しました。 - 上記の成果を挙げた結果、2023年1月に社内で表彰されました。

## プロジェクト概要 社内エンゲージメント向上を目的に、GASアプリケーションの内製化とインフラ構築による運用負荷低減を実現しました。 ## 役割・体制 ### 自身のポジションと役割 - インフラ構築をメインに担当し、AWS環境の設計・コード化を推進しました。 - バックエンドのGASアプリケーション開発にも従事し、システム全体の安定稼働に寄与しました。 - コード化されたインフラを用いた継続的な運用改善とトラブルシューティングを担当しました。 ### チーム規模と構成 - エンジニア3名の少人数チームで、各メンバーが複数の役割を兼務しながらアジャイルに開発を進めました。 - インフラに関する知見が限られていたため、インフラ設計・構築のノウハウは私が中心となって蓄積しました。 ## 背景・課題 - 社内向けのエンゲージメントを高めるため、他者の頑張りを称える社内アプリケーションをGASで内製化し、運用負荷の低減を目指しました。 - 社内アプリケーションの優先度が低く、腰を据えて作業できる時間が限られていたため、開発・設計に割ける時間が不足していました。 - AWSのManagement Consoleからの手動リソース作成による運用困難が課題であり、インフラ構成のコード化に初めて挑戦したことから、デプロイや環境構築に多くの時間を要しました。 - 今のようにCoding Agentがなかったので、仮説を立ててトライアンドエラーをひたすら繰り返すということをしていました。 ## 実際の取り組み ### 開発環境 - 開発手法はアジャイルで、スプリントを回す形式ではなく、メンバーの空き時間を活用しつつ段階的に設計・開発を進めました。 - AWSを利用し、インフラリソースをコード化することで、手動操作の削減と再現性の高い環境構築を実現しました。 - GASを用いたバックエンド機能開発により、社内アプリケーションの業務ロジックを効率的に実装しました。 ### 設計・改善内容 - インフラ構成のコード化を行い、従来のManagement Consoleによる手動操作から脱却し、運用の自動化と品質向上を図りました。 - 日報形式で進捗を可視化し、プロジェクトの現状把握とメンバー間の情報共有を強化して、作業の属人化を抑制しました。 - デプロイにおける課題を都度解決しながら、コード化の完成まで粘り強く対応しました。 ### その他アピールポイント - 限られた工数の中でインフラコード化を完遂し、社内の今後のクラウド運用の基盤となる資産を構築しました。 ## 成果・価値 - 社員の頑張りを定量評価する業務時間を週1〜1.5時間から約5分に短縮し、大幅な業務効率化を実現しました。 - AWSインフラのコード化により、リソース作成・管理の属人化を解消し、運用の再現性と安定性を向上、社内の資産として継続的に活用可能な基盤を構築しました。

## プロジェクト概要 EC企業向けに在庫管理と発送管理をクラウド上で効率化するWMSサービスの設計・開発・運用を担当しました。 ## 役割・体制 ### 自身のポジションと役割 - フロントエンドとバックエンドの両面で機能設計および実装を担当し、ユーザーインターフェースの改善と在庫管理ロジックの修正を行いました。 - 顧客からの問い合わせ対応や障害対応を担当し、サービスの安定稼働と品質向上に寄与しました。 - 開発チーム内での課題共有や優先順位付けに積極的に参加し、改善活動を推進しました。 ### チーム規模と構成 - エンジニア4名のチームで、フロントエンド・バックエンドの開発と運用保守を分担しながら協働しました。 - エンジニアリーダーやビジネスサイドとの密な連携により、顧客ニーズを反映した開発を行いました。 ## 背景・課題 - EC事業者の商品の在庫管理と発送管理を効率化するため、クラウド上で一元管理可能なWMSサービスの構築が求められました。 - 論理在庫と実在庫の整合性不良による障害が頻発し、問い合わせ対応が増加しながら開発リソースを圧迫していました。 - 問い合わせ対応に割く時間が多く、開発に十分な時間を確保できない課題がありました。 ## 実際の取り組み ### 開発環境 - フロントエンドはVue.js、バックエンドはRuby on Railsを用い、Amazon Aurora MySQLをデータベースに採用し、AWS EC2上でサービスを稼働させました。 - Amazon CloudFrontやAmazon S3を活用して、コンテンツ配信と静的ファイル管理の効率化を図りました。 - Gitなどのバージョン管理ツールやCI/CD環境を活用し、2週間スプリントのアジャイル開発を実践しました。 ### 設計・改善内容 - 論理在庫と実在庫の不整合問題に対し、障害発生箇所を特定し優先的に改修すべきポイントをMTGで論点整理し、段階的に修正を進めました。 - 顧客からの問い合わせ内容を分析し、緊急度の低いものについてはビジネス側と調整して対応を削減し、開発リソースを確保しました。 - 在庫情報を分かりやすく表示する機能を設計・実装し、ユーザビリティの向上を図りました。 - 障害対応のフロー見直しや自動化も検討し、運用効率の改善に取り組みました。 ### その他アピールポイント - 顧客対応の効率化と開発時間の最大化を両立させるため、コミュニケーションや調整の仕組み作りに注力しました。 - サービス品質向上のため、障害発生率のモニタリング体制構築にも貢献しました。 ## 成果・価値 - 問い合わせ件数を約30%削減し、開発に割ける時間が増加したことで、障害対応の負荷も低減しました。 - 在庫管理システムの品質向上により、サービスの安定稼働と顧客満足度の向上に寄与しました。 - 継続的な改善活動により、WMSサービスの運用効率と信頼性を向上させ、顧客からの信頼獲得に貢献しました。