ID:68263さん

## プロジェクト概要 自社製品の[MPcloud](https://zuu.co.jp/service/mp-cloud/)のバックエンドとフロントエンドを分離するリプレイス開発にフルスタックエンジニアとして従事 ## チーム構成 チームリーダー：1名 フルスタックエンジニア：3名 ## チームでの自分の役割 フルスタックエンジニア ## 担当フェーズ - 設計 - 開発 - テスト - 保守 ## 業務内容 自社プロダクトのバックエンドとフロントエンドの分離により、ログイン機能やセキュリティなどのリプレイス開発を担当。 ## 実績・取り組み - Csrf Token Securityの新規開発 - 技術選定、設計、実装、テストコードによる自動テストを担当 - ログイン機能のリプレイス - Twitter, Facebook認証によるログイン機能のリプレイス - 脆弱性診断と対策 - OWASP ZAPによる脆弱性診断 - リリース作業とドキュメント化 - Google CloudやKubernetesの知見がないエンジニアがリリースを行うため、ドキュメント化をした - マネージド証明書の実装 - KubernetesのManegedCertificateの適用 ## 課題 自分を含めチームの半分が新卒一年目のエンジニアで構成されており、チーム全体としての技術力に課題があった。 ## 課題の経緯 チーム全体として見た時に、Google CloudやKubernetesなどのインフラの知見が少なく、チームリーダ不在時の障害発生時に円滑に対応できないなどの課題があった。 ## 課題の原因 チームメンバーの担当タスクによる技術のキャッチアップが依存していた。 ## 対処 - タスクから学んだことを共有するmtgを設ける - ペアプロをしやすい環境の整備 - 障害訓練など定期的にGoogle Cloudを触る機会を設ける ## 成果 - 社内外を含め学んだことを積極的に共有する文化の確立 - ペアプロを通して、知識の拡充やレビューなどのリードタイムの削減 - 突如発生する障害に対して、適切に対処するチームワークの向上

## プロジェクト概要 運用サイドが意思決定に活用するためのデータレイクの構築と業務改善をデータエンジニアとして従事 ## 担当フェーズ - 要求定義 - 要件定義 - 設計 - 開発 - テスト - 保守 ## チーム人数 チームリーダ：1名 インフラエンジニア：1名 インフラ兼データエンジニア：2名 ## チームでの自分の役割 インフラ兼データエンジニア ## 業務内容 ユーザーインタビュー、要求定義、要件定義、技術選定、実装、リリースまでを担当 ## 実績・取り組み - データの自動収集バッチの自動化 - 運用サイドへユーザーインタビューを行い、データ活用促進を行なった。 - dbt基盤の構築 - 既存のバッチ処理のフローをdbtに以降 - データカタログの開発 - 社内のデータ活用促進のため、データカタログの要件定義・技術選定・開発 ## 課題 メディアを約20メディアほど運用しており、月次でデータの集計を手動で行なっており、工数と正確性に課題があった。 ## 課題の経緯 組織としてまだまだ歴史的に浅く、業務改善を行う基盤が整っていなかった。 ## 課題の原因 メディア数が多いことや、広告のプラットフォームが多数あり共通化して自動するのにエンジニアと運用サイドが深く連携を取る必要があった。 ## 対処 - 広告のプラットフォームごとのデータ収集バッチの実装 - それぞれの運用サイドのチームにインタビューを行い、データ活用のインタフェースを共通化 ## 成果 - データ活用の推進 - 月次のデータ収集自動化により、月30hの工数削減

## プロジェクト概要 自社プロダクトのマニュアルサイトの構築をメインで担当 ## 担当フェーズ - ユーザーインタビュー - 要求定義 - 要件定義 - 設計 - 開発 - テスト - 保守 主担当 ## 業務内容 機能利用方法に関するお問い合わせの工数削減のため、自社プロダクトの公式のマニュアルを構築 ## 実績・取り組み - 運用サイド30名ほどユーザーインタビューを行い、要求・要件定義 - 技術選定・実装 - コンテンツの作成 ## 課題 自社プロダクトにはユーザー向けのマニュアルが用意あれていないため、利用方法のお問い合わせの工数が削減し、生産性を向上したい課題があった。 ## 課題の経緯 運用者が自社プロダクト利用方法を知るためには、エンジニアとディレクターにお問い合わせを行う必要があり、完結するまでのリードタイムや課題があった。 ## 課題の原因 自社プロダクト利用方法のナレッジがエンジニア・ディレクターに属人化しており、運用者・エンジニア・ディレクターそれぞれに発生するコミュニケーションボリュームが課題となっていた。 ## 対処 - 運用者に運用上での困っていることやどのような機能が欲しいかユーザーインタビューを実施。 - マニュアルサイトを0から開発 - 要件定義、実装、リリースまでを担当 - コンテンツの作成 - ユーザーインタビューにより発覚したニーズが高いコンテンツから作成 ## 成果 - エンジニアによるドキュメント整備の促進 - 一月あたり15時間のコミュニケーションコストの削減

# 障害一覧 運用保守として自分が対応した障害をまとめました。 ## Redis高負荷 ### 事象 運営している一部メディアにて、レスポンスに10秒以上かかってしまう障害が発生 ### 原因 特定のユーザーから特定のページに大量のアクセスが行われたことにより、RedisのCPU利用率が上がってしまったこと。 ### 解決策 15分に一度Redisのkey数を確認し、一定数超えたらFlushDBするバッチ処理(CronJob)を作成した。 ## スロークエリによるDB高負荷 ### 事象 運営している一部メディアにて、レスポンスに10秒以上かかってしまう障害が発生 ### 原因 無限スクロールを行うページにて、実行されるスロークエリによりDBに高負荷がかかったこと ### 解決策 実行するスロークエリは記事の総数を取得するクエリであり、インデックスを張ってもシーケンス インデックスにより実行されるため効果がなかった。 そのため既存コードのリファクタを行い、スロークエリの実行頻度を少なくすることで対応をした。 ## 掲載先メディアにサムネイルが表示されない事象が発生 ### 事象 掲載先メディアの記事一覧にて、自社メディアの記事のサムネイルが表示されない事象が発生 ### 原因 自社メディアの画像形式をWebpで配信しており、掲載先メディアでは対応していなかったこと。 ### 解決策 NginxにてJpeg形式の画像ファイルをWebp形式に変換するロジックを、掲載先メディアから画像のリクエスト時のみ画像変換せずJpeg形式にてレスポンスするように変更 ## デプロイエラー ### 事象 AWSのCode Buildによる自動デプロイが失敗する事象が発生 ### 原因 ログ収集によるnode内のディスクがスペックを超えてしまったこと。 ### 解決策 ログはAWSのS3に保存されているので、ディスクに保持しているログを削除するバッチを実装した。

## 詳細 スタートアップの会社にお手伝いする形で参画したプロジェクト。 芸能人によるライブ配信アプリの新規プロダクトの開発で、自分はユーザー系の機能の開発を行いました。 ### 実装した機能 主に会員機能を担当 - [JWTトークン](https://jwt.io/introduction)によるログイン、ログアウト機能 - プロフィール登録、編集機能 - フォロー機能