400万人が利用する会社訪問アプリ

田口慎

個人事業主 / エンジニア東京都

登録してプロフィールを閲覧

田口慎

個人事業主 / エンジニア

登録してプロフィールを閲覧

4年目のインフラ / バックエンドエンジニア # スキル・クラウドインフラとIaC（Terraform）, CI等に特に自信があります。・AWS/GCPインフラの設計構築運用フェーズでの経験（いずれも認定プロフェッショナル資格保持）

qiita.com

この先やってみたいこと

未来

特定の領域に閉じるのではなく、幅広くその場で求められる領域を担いたいタイプです。どちらかというとゼロイチに近いフェーズのサービス・システムを作ることに関心があります。

個人事業主7ヶ月

エンジニア現在

2024年4月 - 現在

バックエンド/SRE

ベンチャー企業BtoCサービスにおけるバックエンド開発
## プロジェクト概要電気自動車充電サービス開発におけるバックエンドエンジニア ## 期間・規模 - 2024/4 ~ 現在 - エンジニア：バックエンド5名、全体10名程度 - プロジェクト全体：50名程度 ## 担当 - バックエンド開発 - インフラ ## 使用技術 - GCP（GKE, CloudSQL, Redis, LB, CloudArmor, VPC, GCS, Pub/Sub等） - gRPC, Gitlab, Terraform, Datadog, Kubernetes, metabase - node.js, NestJS, PostgresSQL, TypeScript ## その他 - Slack, Jira, Confluence, ## 業務バックエンド開発 - API新規実装・既存機能の修正 - バグ修正 - 既存コードのリファクタ（DBパフォーマンス改善・メソッドの共通化等） - 企画・フロントエンド・外注の開発チーム等との連携インフラ - CI改善 - コスト最適化（GCP, CI, Datadog等） - 障害時の調査・対応
2024年4月

パーソルキャリア株式会社（キャリア採用）2年間

インフラ/バックエンドエンジニア

2022年9月 - 2024年3月

GCPインフラの構築運用。プロダクトの要求定義。時期によってはフルスタックに開発にも参画。

プロダクトのインフラ領域統括及び要求定義
# プロジェクト概要プロダクトのインフラ領域統括及び要求定義 # 期間・規模 - 2023/10 ~ 現在 - エンジニア：内製10名（インフラチームは3名、その中のリード） - プロジェクト全体：企画・デザイナー含め100名程度 # 担当 - インフラチームのリード - プロダクトのフェーズ移行に伴う、サービスの要求定義と改善推進 # 使用技術 - GCP（GKE, CloudRun, GCE, CloudSQL, LB, CloudArmor, VPC, GCS, Pub/Sub, Cloud Build等） - BigQuery - Terraform, Datadog, Kubernetes, GitHub Actions, ArgoCD ## その他 - slack, Backlog, esa # 業務インフラチームのリード - ArgoCD導入による継続的デプロイの改善 - 技術負債解消（GCPコンテナレジストリ移行,GKEバージョンアップ等） - インフラメンバーの教育（スキルトランスファー・1on1） - アラート・障害対応、全体定例での進捗状況説明 - その他インフラ運用業務、開発チームとの連携サービスの要求定義と改善推進 - 非機能要求の定義 - 優先度の高いパフォーマンス改善の要求のロードマップ作成・提案・各所へのタスク割り振り - 定常運用業務の外部協力会社への委託に向けたサポート # ポイント - インフラ業務は、協力会社など内外にエンジニアが多数在籍する中でトラブルが起きないように各所と細かく調整し、ゼロダウンタイムで大きなトラブルなく影響範囲の大きい技術負債解消やデプロイ改善を達成した。 - 要求定義は、各開発チームに課題感や見積もりなどのヒアリングを行い、IPA非機能要求グレードを参照しながら100個近い項目を定義した。また実際の改善推進に向けて、PMやビジネスレイヤ・デザイナ向けに抽象化した説明やロードマップの提案を行った。ステークホルダーが多く技術領域も広い業務であったが、無事ロードマップの事業合意と各開発チームのスケジューリングまで完了した。
2023年9月
ローンチ後サービスのグロース
# プロジェクト概要 - ローンチ後サービスの新規機能実装・インフラ運用改善 # 期間・規模 - 2023/4 ~ 現在 - 所属セクションのエンジニア：7名（リード2名、メンバー5名） - プロジェクト全体：企画・デザイナー含め50名程度 # 担当 - フロント/バックエンド/インフラをフルスタックに担当 - 特に、インフラ（K8s, GCP, Datadog）の運用・改善をリード # 使用技術 ## 開発関連 - Next.js, React, NestJS, TypeScript, MySQL, Jest, Prisma - Docker, MySQL WorkBench, Swagger, Postman ## インフラ関連 - GCP（GKE, CloudRun, GCE, CloudSQL, LB, CloudArmor, VPC, GCS, Pub/Sub, Cloud Build, BigQuery等） - Terraform, Datadog, K8s, GitHub Actions ## その他 - Slack, Figma, zenhub, Backlog, esa, Bitwarden # 担当業務 - フロントエンド - React MUIコンポーネント作成 - バックエンド - 既存コードのリファクタリング・E2Eテストコード作成 - 新規機能の実装 - インフラ - Terraform, GKE運用 - 利用ユーザ増加に応じた対応（CDN実装, GKEオートスケーリング設定など） - インフラ構成図などドキュメントの作成・整備 - Datadog運用（アラート作成, 障害時の初期調査, 担当者への周知など） - K8s, Terraformのスキルトランスファー（勉強会等） # 工夫した点 - TerraformやK8s等のインフラはサービスローンチまでは利用するメンバーが限られていたが、ローンチ後はセクション内の全エンジニアが利用する方針となったため、それに耐える運用改善をした。具体的には、Secretは自動的にGC SecretManagerから取得するよう変更・terraform状態管理ファイルはGCSバケットに配置・K8s内部構成図を作成など。具体的な取り組みは投稿しています。 - https://qiita.com/MAKOTO1995/items/b5d50b19cd389131d37d - https://qiita.com/MAKOTO1995/items/01f5a3196663b95c1682 - インフラだけでなくフロント/バックエンドの機能開発も担当した。ローンチ前はサブプロジェクト（機能）ごとにチームが分かれていた関係でサービスの機能全体を把握していなかったため、自分が取り組むタスクの機能に詳しいメンバーとコミュニケーションを取り認識齟齬が出ないように注意することで、バグや手戻りの防止を特に意識した。
2023年4月 - 2023年9月
Webサービスのファーストリリースに向けた開発とインフラ整備
# プロジェクト概要 - 人材系サービスのファーストリリースに向けた開発とインフラ整備 # 期間・規模 - 2022/9 ~ 2023/3 - チーム内：9名（マネージャー1名、バックエンド/インフラ4名、フロントエンド4名） - 機能ごとにチーム分かれており、他チームのエンジニアとのやりとりもあり - プロジェクト全体：企画・デザイナー含め50名程度 # 担当 - バックエンドの開発 - GCPインフラの構築・運用改善 # 使用技術 ## 開発関連 - NestJS, TypeScript, MySQL, Jest, Prisma - Docker, MySQL WorkBench, Swagger, Postman ## インフラ関連 - GCP（GKE, CloudRun, GCE, CloudSQL, LB, CloudArmor, VPC, GCS, Pub/Sub, Cloud Build等） - Terraform, Datadog, Kubernetes, GitHub Actions # 担当業務 - バックエンド - API実装 - DB論理設計 - e2eテスト/ユニットテスト作成 - インフラ - GCPインフラの構築、改善（Terraform記述） - GKE運用（K8sマニフェスト作成等） - アーキテクチャ図の作成 - 深夜のファーストリリース作業 # 工夫した点 - インフラ領域では、AWSの設計構築経験があったこともあり、GCP初経験ながらも既存インフラのterraform化、セキュリティ強化（権限の最小化、通信の制限等）、コスト最適化、GKE/CloudSQLバージョンアップ等を提案し幅広く運用改善に貢献した。 - 開発領域では、業務外の学習を特に心がけ、いちはやキャッチアップし、API開発・テストコード作成だけでなくDBの設計やコードのリファクタリングにも貢献した。 - 拡張性を常に意識した。期日が短いながらもリファクタリングやより良いDBテーブル設計についてファーストリリース前の影響が少ない段階でできるだけ対応しておくべきと考え、前向きに対応した。 - できるだけ多くのメンバーが見てわかる文書の作成を自発的に行なった。例えば、 - DB論理設計はバックエンドエンジニアであればDDLで理解できるが、デザイナーや委託先も見る場合があったため、補足説明も記載したスプレッドシートのDB定義書を作成した。 - インフラ構成は、開発エンジニアが大半でインフラ領域に詳しいエンジニアが少なかったたこともあり、参画時の段階でアーキテクチャ図があまり整備されていなかった。そこで自発的に図を詳細化してミーティングで説明するなどして、インフラ担当者以外でも全体の構成や通信の流れを把握できるようにしてチーム全体の理解度を上げた。
2022年9月 - 2023年3月

Ragate株式会社(業務委託)1年間

バックエンドエンジニア（副業）

2021年7月 - 2022年10月

GraphQLバックエンド開発

AWSサーバーレスバックエンド開発
# プロジェクト概要 - AWSサーバーレスサービスを用いた受託開発及び自社開発 # 使用技術 - AWS：AppSync, Lambda, DynamoDB, Cognito - 使用言語：TypeScript, Node.js - 構成管理：CloudFormation, ServerlessFramework - その他：GraphQL, Git, BitBucket, Postman, Docker, Sequelize, Jest # 取り組み - DynamoDBテーブル/ファセット設計 - AWSアーキテクチャ図、通信シーケンス図作成 - Lambda関数（CRUD処理）実装、単体テストコード作成 - GraphQLスキーマ、リゾルバ作成 - Appsync疎通試験 # 工夫した点 - ただ与えられたタスクをこなすだけでなく、設計書や仕様書へのコメントなど（DB設計へのコメント、他社製API仕様書に対するQA対応）も積極的に行った。元々はLambda実装のみが担当であったが、このような他工程にも積極的に関与する姿勢を評価いただき、DynamoDB設計、GraphQLスキーマの実装やAppsync上での疎通試験など幅広く担当させて頂けることとなった。
2021年8月

株式会社GIBJapan1年間

インフラエンジニア

2021年9月 - 2022年8月

AWSインフラ設計構築

CIパイプラインの導入（IaCテンプレートの品質管理）
# プロジェクト詳細 ## 課題 - インフラ設計構築チームでは、CloudFormationでのテンプレート管理を行っていた。 - テンプレート数や、チームの人数が増えてきたため、従来のPMによるプルリクのレビューだけでは品質維持が難しくなってきている背景があった。 - そこで、今後のチーム規模拡大に向けテンプレートの品質を維持すべくCIパイプラインによる自動テストを導入することとなった。 ## CIパイプラインの内容 - GitHubリポジトリ（汎用テンプレート管理用）devブランチへの、プルリクエストのマージをトリガーに、自動テスト - テスト内容 - 静的解析（cfn-lint） - CFnルートスタックの検証環境へのデプロイ確認 - Teamsチャネルへのテスト結果通知 # 担当 - CIパイプラインの検証・構築・実運用への導入 # 使用技術 - AWS（CloudFormation, CodePipeline, CodeBuild, CodeStar, Lambda, S3, IAM, SNS） - Github Enterprise Server, cfn-lint - VSCode, AWS Cloud9 # 担当業務 - GitHubフローによるブランチ運用方法の調査 - AWS Codeシリーズ利用事例の調査 - AWSアーキテクチャ設計 - AWS利用料の見積り（ビルドにかかる料金等） - CIシステムの構築（CloudFormation） - 実運用への導入 - 運用方法についてチームメンバーとの議論 # 工夫した点 -運用でなるべく手間がかからないよう意識し、下記の機能を持ったLambda関数を作成した。 - Teamsへのテスト結果通知時に、失敗時のみメンション（成功時はメンションしない）するようにし、被通知者の確認工数を減らす。 - ルートスタックの作成後、作成したS3バケット中のオブジェクトを全削除した上でルートスタック削除する構成とし、スタック削除エラーを回避。 - 既存のブランチ運用のままでは、CIシステムのアーキテクチャが複雑となり、システム全体の理解や修正が煩雑になる恐れがあったため、一般的なGit運用方法を調査しGitHubフローに則った運用を提案した。結果自分の提案が採用され、CIシステムもシンプルなものとなり後々負債となる可能性を回避できた。 # アピールポイント - DevOps系のスキル AWS上でのCIパイプラインの構築スキル、Gitリポジトリの運用方法（フロー）の理解や、チームメンバーとの議論による最適なCI構成の検討など、従来のクラウドインフラ設計構築だけでは経験できないことができ、DevOpsの理解が深まった。
2022年5月 - 2022年6月
EKSを含むAWSインフラの設計構築
# プロジェクト概要 - EKSを含むAWSインフラの設計構築（EKS on EC2） # 使用技術 - AWS（EKS, CloudFormation, IAM, VPC, VPC Endpoint, ALB, EC2, S3, ECR, RDS Lambda, KMS, SecretsManager, Route53, ACM, WAFv2, Inspector v2） - VSCode, Docker, AWS CloudShell, FluentBit # 工夫した点 - 現場でも初めての試みであるEKSの設計構築を担当させていただいた。ログの永続化やオートスケーリング・EKSの操作権限管理・構成管理の分離など、本番運用に向け考慮すべき事項が多数ある中、利用者とQA表によるやりとりで要件を明確化し、実現に向けてつまづく箇所はAWSサポートへの問い合わせ等で解決策して無事インフラ構築と引き渡しを完了した。 - 取り組み詳細の一例は以下Qiitaに投稿しています。 - EKS on EC2の本番運用に向けて考えたこと https://qiita.com/MAKOTO1995/items/6ef1d55850a3511147a5 - CFnとK8sマニフェストの構成管理の区分け https://qiita.com/MAKOTO1995/items/caa951c45ee119e70a60
2021年12月 - 2022年4月
セキュリティを考慮したAWSインフラ設計構築
# プロジェクト概要 - 複数プロジェクトでのAWSインフラ設計構築 # 使用技術 - AWS（CloudFormation, IAM, VPC, EC2, S3, CloudFront, ECS, ECR, RDS, RDSProxy, Lambda, KMS, SecretsManager, Codeシリーズ, Route53, ACM, API Gateway, NLB, WAFv2, Inspector v2） # 取り組み - 利用者や開発チームの提示する機能要件・非機能要件に基づいたAWSインフラのアーキテクチャ設計 - AWS利用料の見積り - 基本設計書、パラメータシートの作成 - 構築（主にCloudFormationを記述してデプロイ） - AWSサービス間の結合テスト、機能テスト - AWSサポートへの不明点問い合わせ # 工夫した点 - それまで手動管設定していた構成をCFnテンプレート化してチームに導入し、別案件でも汎用的に使いまわせるようにしてインフラ構築省力化に貢献した。（Route53のエンドポイントヘルスチェック、ECR脆弱性スキャン結果のメール通知など） - 引き合いから構築完了・引き渡しの期限が短いイレギュラー案件もあったが（開発・プロダクション環境2面を1ヶ月弱）、自らマイルストーンを作成し日次で上長に進捗報告/不明点の相談など行い主体的に業務を進めたことで、無事引き渡し完了できた。　これにより現場でも一定の信頼をいただき、別のEKS案件を担当させていただけることとなった。
2021年9月 - 2021年12月

株式会社ラクスパートナーズ1年間

インフラエンジニア

2020年7月 - 2021年7月

CI構築

JenkinsによるCIパイプライン構築
# プロジェクト概要 - 物流業界大手の社内倉庫管理システムにおいて、開発環境へのCIシステムの導入。 # 期間・規模 - 2021/3 ~ 2021/7 - 開発メンバー20名 # 担当 - 開発チームへCIシステム構築専任で参画。CI導入による既存の開発環境の省力化に貢献。 # 使用技術 - Jenkins, Windows7/10, GitBucket, Git, Java, Tomcat, MySQL, バッチファイル # 取り組み - Jenkinsパイプライン構築＜課題＞ - 開発運用中の倉庫管理アプリケーションについて、最新バージョンの動作確認をテストするために既存のE2Eテストツールが用意されていたが、作業者が手動でテスト開始し、テスト結果もテキスト形式のレポートファイルから確認するという非効率的なものとなっていた。＜解決策＞ - JenkinsによりCIパイプラインを構築し、GitBucketの任意のブランチへのコミットをトリガーに以下の一連を自動実行できるようにした。 - パイプラインの内容『スレーブノードでのGitチェックアウト→War差し替え展開→スレーブノードへのミドルウェア構築・DB初期化（テスト用の環境構築）→E2Eテスト→GUI上へのレポート出力』 - 上記により最新バージョンや特定ブランチのアプリケーションに対するテスト実行の自動化とテストレポートの視覚化に成功した。 # 工夫した点 - CI構築を自分1人が担当したため、自分が抜けた後に技術的負債にならないよう、できるだけ複雑な処理は避けるよう意識した。例えば、プラグインを使ってGroovyスクリプトによりJenkinsパイプライン全体を実装する選択肢があったが、Groovyの経験があるエンジニアが少なかったことからスクリプト改修には時間を要すると考え、あえてスクリプトではなくGUIでパイプラインを実装した。 # アピールポイント - リモートワークでのコミュニケーション MTGで、リモートでも上長にわかりやすく（ハンズオンの画面を見せる、パワポで図を作成する等）説明するように心がけ、的確なフィードバックをもらいやすい環境作りを意識し、また自分と周囲との間で認識の齟齬をなるべく無くした。
2021年3月 - 2021年7月