Hirotaka Miyagi
🔭

Resume

Hirotaka Miyagi | 宮城 広隆

  • スタートアップでの開発でぶつかる壁に対して、ジェネラリストのように振る舞うことが得意です。
  • Railsをコンテナで動かすことや、開発スピードを上げつつあまり手のかからないインフラの構築が得意です。
  • 開発とBizを巻き込んだプロジェクト進行など、不確実性を排除しながら前に進む動きが得意です。

Experience

株式会社リゾートワークス（2020/12〜現在)

ワーケーションを通じて働く人の“創造性“を刺激する福利厚生サブスクリプションサービス ResortWorx で、インフラ/バックエンドエンジニアを担当しました。

インフラ構築の0→1に伴う技術選定と構築

プロダクトローンチ初期に求められる最低限の構成で、ランニングコストの抑制とエンジニアがキャッチアップできるようなドキュメンテーションを心がけました。

  • Nuxt.js + Rails API の利用者向け Web アプリケーションと、Rails SSR による管理画面のホスティング
  • Route53 → ALB → ECS / RDS の一般的な Rails のホスティング
  • GitHub Actions による CD 環境、 SSM を利用した ssh(rails c 等）実行環境
  • CloudWatch によるロギングとアラート、AWS Chatbot による Slack 通知
  • S3 + CloudFront による SPA のホスティング、GitHub Actions による CD, workflow dispatch を利用したブランチ指定のデプロイ
    • のちに Nuxt の SSR も必要になったため Vercel へ移行
  • 上記の AWS リソースを terraform で IaC 化、draw.io + VSCodeによるアーキテクチャ図の記載、その他オペレーションをドキュメント化

チケットベースでのチーム開発

  • Rails, Nuxtでの機能追加
  • CloudWatch Logs Insights で可視化・検索ができるよう Rails のログの JSON 化

株式会社タイミー（2018/07〜2021/09）

サービスローンチの 1 ヶ月前にジョイン、初期は 1 人サーバーサイドとして保守運用を担当Rails をメインに、プロダクト/会社の成長とともに幅広い業務を担当させていただきました。

PjM/PdM/バックエンドエンジニア (2020/08〜2021/04)

当時の課題

会社の成長に伴いガバナンスを強めていく必要性があり、プロダクト「タイミー」における社内オペレーション改善や、コーポレートエンジニアリングの領域で開発を進行しました。

メンバー構成

プロジェクトの開発メンバーとしては 2 名で、関係部署にヒアリングしながら遊軍のように活動しました。

  • 自身： プロジェクトマネジメント/ 要件定義/ Rails や Go での実装
  • チームメンバー: 元 iOS エンジニア（Rails はビギナー)/ 要件定義/ Rails や Go での実装
  • 関わる部署： 経理財務、 CS

やったこと

ヒアリングや SaaS の選定、スケジューリングや開発着手、リリースまで一気通貫で担当しました。（NDAレベルの業務が多く少しぼかしています）

  • CRM ツール HubSpot の API 連携
  • 経理・財務業務 SaaS との API 連携
  • 内部統制に伴う各種機能開発の進行（職務権限規定に沿った権限管理・与信・反社チェックなど）
  • 社内業務のオペレーション改善
  • Mac にインストールし deamon で常駐起動するソフトウェアを Go で開発
    • 主に非機能要件であるリリースパイプラインの設計を担当 死活監視、バイナリのセルフアップデート機構、リトライ制御など
  • チームメンバーに Rails を教える コードレビューやキャッチアップのための順序立てたタスク振りなど

新規事業 PjM/バックエンドエンジニア/フロントエンドエンジニア (2021/04〜2021/08)

メンバー構成

  • 開発チーム： iOS 担当 1 名、 デザイナー1 名、 Web フロントエンド&バックエンド API2 名
  • 関わった部署： 経営, Sales, CS, 経理

役割

  • プロジェクトマネジメント・技術選定・設計・実装（Rails, Vue.js)を担当
  • チームのエンジニアは それぞれ iOS や Rails に強いメンバーとのプロジェクトだったため、それぞれの強みを活かしてもらいつつ取りこぼしがないよう拾う立ち回りに努めた
  • Biz サイドとの折衝、サポートや経理とのオペレーション構築など
  • エンジニアリングとしてはコアドメインのモデリングや Stripe を利用した決済周りの設計実装を主に担当した

技術選定・初期設計

  • Vue.js/vue-router を使った SPA の実装
  • 一般的な Rails の環境構築（annotate/rails-erd/bullet/rspec/rubocop)
  • 監視/ロギング/CI/CD の導入（Datadog, Sentry, lograge を利用したログの JSON 化、 CircleCI)
  • 商品情報登録・在庫管理・注文・決済履歴などのドメインの境界を意識したモデリング
  • Rails プロジェクトでの行動指針決め
    • 原則テストコードを書く、書けないなら書けるよう責務を分割する
    • トランザクションやロックなど SQL を適切に書く
    • シンプル・ミニマルに

決済機能の要件定義・技術選定・Stripe APIの実装/運用

スキーマ駆動開発の導入・運用

  • OpenAPI3 + Committee を利用したスキーマ駆動開発の導入・運用
  • ドキュメントの信頼性と保守性を高めた運用が可能に
Rails + RSpec + OpenAPI3 + Committeeでスキーマ駆動開発を運用するTips - Timee Product Team Blog

こんにちは、 タイミーデリバリー開発チームの宮城です。 今回は弊社のOpenAPI3ベースの スキーマ 駆動開発の運用方法を紹介します。 技術スタックは OpenAPI3, Swagger UI, Committee, ActiveModelSerializers Committeeを利用してOpenAPI準拠のRequest Specを行う OpenAPI3のrequiredキーワードに注意する タイミーデリバリーでは、 Railsによる APIサーバーと、Web管理画面としてVue.jsによるSPA、ユーザー向け iOSアプリとしてSwiftを採用しています。 1つの モノリスな Railsで利用者別にネームスペースを区切り、それぞれエンドポイントを提供しています。 サーバーサイドとクライアントサイドを分離し並行して開発を進めるために スキーマ駆動開発を導入しました。 スキーマ 駆動開発の詳しい説明やメリットについては既に多くの記事が存在するため、ここでは参考にさせていただいた記事の紹介までとさせていただきます。 RubyKaigi 2019でOpenAPI 3について登壇しました - おおたの物置 スキーマファースト開発のススメ - onk.ninja スキーマ駆動開発のススメ - Studyplus Engineering Blog この記事では、実際に スキーマ 駆動開発を開発フローに導入する際のTipsを記したいと思います。 Railsで APIサーバーを構築するにあたって、 jsonの生成には ActiveModelSerializersを採用しました。 スキーマ定義には OpenAPI3を採用し、 Swagger UIでドキュメントを閲覧できるようにしています。 この3つに関しては近年では割とよくある一般的な技術スタックかなと思っています。 スキーマ定義を記述する YAMLファイルは Railsの リポジトリ に配置しています。 .

tech.timee.co.jp

Rails + RSpec + OpenAPI3 + Committeeでスキーマ駆動開発を運用するTips - Timee Product Team Blog

SRE (2021/01〜2021/04)

当時の課題

プロダクトの成長は進みテレビ CM を打つことになり、現状のスケールしない EC2 によるインフラでは耐えられないだろう、という課題がありました。ただひたすらこなしていた開発業務についてもメンバーが増えスクラムを回せるようになり、組織化が進んで自身の属人性は剥がれてきていました。運よくシニアレベルの SRE の方が採用できたこともあり、その方と主に SRE チームを立ち上げ AWS のアーキテクチャから作り変えるプロジェクトを始め、キャッチアップさせてもらいつつインフラの移行を進めていきました。

メンバー構成

SRE: 2 人（シニアメンバー, 自身）

やったこと

Railsでリードレプリカへの接続機能

  • CM 放映の負荷分散対応の 1 つとして、Rails 6 のマルチ DB 機能を利用しリードレプリカへの接続機能を実装し本番運用した
  • 現在は負荷が下がっているため primary だけを見るように設定しており、環境変数を変えるだけでいつでもリードレプリカへの接続ができるように

ECRのライフサイクルツールの作成

  • ECS タスクで ECR イメージが使われている場合はそのイメージを削除しないようにライフサイクルポリシーを拡張したツールを作成
  • Fargate Scheduled Task で運用

RailsをFargateでデプロイするチュートリアルの作成

  • rails new -> generate scaffold -> docker build -> Fargate へのデプロイまでを、Terraform で AWS リソースを作って 30 分程度でデプロイできるようなチュートリアルを作成

RailsアプリをEC2->Fargateに移行

  • 全社的に移行を進めていた Fargate 対応の一部を担当

タスク定義を更新するローリングデプロイ

  • ALB のリスナールールの priority を変更することによるメンテナンス画面表示
  • それらを全て chatops だけで完結できるように

Go製のマイクロサービスの保守、機能追加

  • echo/gorm を利用したマイクロサービスの保守運用を担当

RedashをFargate, Datadog, Terraformで構築/運用

  • Redash を Fargate でオートスケールできるように
  • Datadog による監視
  • それら全てを Terraform で管理
RedashをFargate, Datadog, Terraformで構築/運用する - Timee Product Team Blog

こんにちは、タイミーSREチームの宮城です。 今回は弊社が Redash をFargateで構築/運用している話を紹介します。 タイミーでは、CSやセールスのKPI策定から毎月の事業数値に至るまで、Redashが様々な用途で活用されています。 Fargateで構築する以前はEC2上のdocker-composeで運用されていましたが、以下の課題がありました。 オートスケールできないため、クエリが詰まってCPUが100%になってサービスが停止する。 セットアップしたエンジニアが退社しており、インフラ構成図やノウハウの共有、IaCによる管理ができていない。 クエリやダッシュボードなどのデータの定期的なバックアップができていない。 v7系からv8系へのアップデートがしたいが、アップデートによる影響範囲がわからず恐怖感がある。 事業に大きく関わるサービスなのにも関わらず、モニタリングやアラートができていない。 上記をFargateに移行することで解決することができました。 Redashで利用する ミドルウェアに関しては下記 コンポーネントを使い、全てをterraformで管理しています。 - PostgreSQL -> RDS - Redis -> ElastiCache ここからは、それぞれの構成をTerraformの ソースコードやタスク定義の JSON などを交えつつ説明していきます。 ダッシュボードなどのデータが定期的なバックアップが行われていない問題は、RDSでsnapshotを取得することで解決しました。 それぞれ一番小さい インスタンスタイプのシングルAZ構成で構築しています。 実際に運用してみて負荷が大きければスペックを上げるつもりでしたが、現状問題なく捌けています。 将来、可用性を高めるためマルチAZにすることも容易であり、こういった柔軟なサーバーリソースの活用も クラウド の利点といえるでしょう。 privateサブネットに置いたシンプルな構成です。 applyが完了したらrootユーザーのパスワードを AWS コンソール上から変更し、接続情報をSecretsManagerに保管しています。 resource "aws_db_subnet_group" "redash" { name = "redash" subnet_ids = [ data.aws_subnet.private-subnet-1a.id, data.aws_subnet.private-subnet-1c.id,

tech.timee.co.jp

RedashをFargate, Datadog, Terraformで構築/運用する - Timee Product Team Blog

バックエンドエンジニア (2018/07〜2020/01)

サービスローンチの 1 ヶ月前にジョイン、初期は 1 人サーバーサイドとして保守運用を担当Rails をメインに、プロダクト/会社の成長とともに幅広い業務を担当させていただきました。

メンバー構成

  • リリース前： iOS…5 人、 サーバーサイド 4 人
  • リリース後〜半年程度： iOS…2 人、 サーバーサイド 1 人、 技術顧問数人
    • 徐々にメンバーは増えていきました

役割

スタートアップのシード期なので、通常の機能開発や運用はもちろん、経営・CS・経理・営業チームからの要望対応も全てバックログに載せただひたすらにこなしていました。

やったこと

  • 0→1 の開発・0→1 後のサービスの保守運用・負債解消
  • RSpec, Rubocop, OpenAPI3 の導入
  • Ruby/Rails のバージョンアップ業
  • API のバージョニング、Serializer のスキーマ分割
  • テーブルへの index 追加、スロークエリのチューニング等
  • サービス固有の強いドメインを持つ機能の設計、実装