ID:66423さん

# 概要 Google Kubernetes Engineでホスティングしたコンテンツ管理システムの保守運用を担当するチームリーダーとして勤務している。 社内・社外からの問い合わせ対応、必要に応じて開発をしている。 チームリーダーとしてタスクや進捗管理をした上で、自分も一人のエンジニアとして、以下のような開発フローを定義し、チームで分担する等している。 - 開発要求の整理 - Google DocumentやFigJam等で文書化 - 要件定義, 設計 - 文書化したものをチーム内レビュー - 実装 - Goによるバックエンド開発 - Kubernetes, Terraformで定義されたインフラの開発 - Vue.js, Nuxtによるフロントエンド開発 - CIによる自動テスト - Goによる単体テスト - 手動テスト - エンドユーザーの視点から見た結合、総合、E2Eテスト - デプロイ - ArgoCD, Spinnaker - 課題管理 - backlog チーム内外からのPull requestのレビューもしている。 また、保守運用の一環としてアプリケーションのログ監視、エラーログやGCP上のリソース状態調査、問題解決なども行なう。

# 概要 自社と顧客が協業して運営するメディアにおけるコンバージョン増のため、ビジネスインテリジェンス（BI）の設計、開発、保守をおこなっている。マーケティング担当者や管理職に対する聞き取り、ビジネス上の課題の設定、課題解決の方針をチームで共同して実施し、ビジネス上のKPIの進捗を確認するためのダッシュボードを作成し、担当者に提供、継続的に保守している。 - ビジネス上の課題設定 - FigJam, Google Documents - データウェアハウス構築 - Big Query, dbt - ダッシュボード設計 - FigJam - ダッシュボード構築 - Looker Studio

# 概要 プロダクトの保守運用業務においてバグや障害対応の経験を豊富に有する。具体的には以下のような作業を随時実施していた。 - 障害の発見、または障害のお問い合わせ受理 - 障害の内容や影響範囲の調査、文書化 - 障害対応の指揮 - 障害の原因の特定 - インフラやアプリケーションのコード、外部サービスなどを調査 - 障害の復旧 - インフラのリソース補強、アプリケーションのコード修正 - 障害の復旧連絡 - 障害対応の振り返り

## 目的・背景 弊社では、自社CMSで構築したWebメディアを顧客に提供しています。インフラはマルチテナントです。 私はエンジニアチームのメンバーとして顧客のテナントを構築したり、顧客の特別な要件に基づいた新規実装を行なっていました。 ## 規模 顧客向けにはステージング環境、本番環境の2つのテナントを構築していました。 テナントごとの構築工数は1週間程度です。 ## 私の役割 インフラエンジニアとしてはGCPのリソース作成（Terraform）や、GKE上で稼働するKubernetesのリソース作成をおこなっていました。 アプリケーションエンジニアとしても兼務していたので、要件に基づいたfrontendのスタイル実装や、GoでのAPI実装も担当していました。 ## 使用した技術 - Kubernetes - GKE - GCP - Terraform - Go - Nuxt

# 背景 自社では、Webメディアを展開しており、私は主にメディアのコンテンツ管理システム（CMS）の改善を担当しています。 当該CMSでは、複数人がコンテンツの編集を行うことができるのですが、コンテンツの編集履歴を管理していないため、以下のような問題が発生していました。 - CMSのユーザーはコンテンツの編集履歴を参照できないため、編集前の状態に戻せない。そのため、記事を編集することで記事のSEO評価等が下がった場合等に備え、記事の編集者は記事の編集履歴を手書きの紙で管理していたが、そのやり方も破綻しかけていた。 - コンテンツに対し、誰が、いつ、どのような編集を行なったのかわからないため、複数人によるコンテンツの管理自体が難しくなっていた。 # 目的 コンテンツの編集履歴を参照する機能をCMSユーザーに提供すること。 # 開発の規模感 90人日から120人日程度 # チームの構成 私、プロダクトマネージャー、テックリードの3人でチームを構成した。 開発の目的の策定、設計、実装、テストは私一人で全て行った。 プロダクトマネージャーとテックリードはアドバイス役。 # 技術的に工夫したこと ## アーキテクチャ CMSでは、リリース時、DBのマイグレーションを適応した際の障害が多発していたため、CMSのDBに対して変更しないようにするべく、編集履歴を管理する仕組みをマイクロサービス（REST API, 編集履歴の保存・参照のインターフェース）をCMSの画面から呼ぶ形で実装した。このことで、マイクロサービスが障害を起こしても、CMSでは編集履歴機能を利用できなくなるだけで、他の主要な機能には影響がないようにした。 ## DBの選定 マイクロサービスが管理する編集履歴は、時間の経過とともに膨大になり、パフォーマンスが悪化することが予想された。このため、データの正規化は行わず、編集履歴に付随する編集者のデータなども含め、編集履歴を1つのテーブルで管理することにした。従って、DBとしてはRDBを用いず、ドキュメント指向DBを中心に調査した。その結果、1ヶ月の利用料が定額であったMongo Atlasを用いることにした。 # 結果 CMSのユーザーは、コンテンツに対して、いつ・誰が・どのような内容の編集を行なったのか参照できるようになった。 （GithubのdiffのようなUIで編集履歴を参照できる） 開発を行なった編集履歴機能は、毎日利用され、コンテンツの管理に役立てられている。