Hirotaka Miyagi | 宮城 広隆
- 開発チームがぶつかる壁に対して自分ごととして捉え、フルサイクルに向き合うことを大事にしています。
- 開発とBizを巻き込んだプロジェクト進行など、不確実性を排除しながら前に進む動きが得意です。
- 開発者体験の向上 / レガシーコードからの脱却 / 4 keys / 変化圧の強いフロントエンドの動向 などに興味があります。
- 「人が本質(価値・幸せ)に向き合う時間を増やすために、それ以外を技術で解決する」を人生で取り組みたいと思っています。
Experience
株式会社ビットジャーニー(2021/9〜現在)
ProseMirrorを利用したリッチテキストエディタの開発
- ProseMirrorの木構造⇄DOM⇄markdown textの相互変換により、リッチテキストエディタで記入したテキストを即座にmarkdownに変換させる
- ユーザーフレンドリーなテーブル記法の入力UIの実装
- 列・行・セルの選択や追加、削除などを直感的に行えるように
- ProseMirrorコミュニティでの活動
- 開発中必要になった機能をupstream側に提案・実装し、無事リリースされた: https://github.com/ProseMirror/prosemirror-markdown/pull/68
- フォーラムでのバグ報告や知見共有
- ガイドを和訳し公開: https://zenn.dev/mh4gf/articles/d25ef1ff30b5a6
ProseMirrorはユーザーのイベント(keydown, mousemove)ごとにDOMを再構築します。Reactのように差分更新するアルゴリズムはあるものの、テーブル操作中は各種ボタン等含めテーブルの全てのDOMが再構築されることとなり、キーリピート等がチラつくほどにパフォーマンスが劣化する問題がありました。
そのため簡易的なReact.memoのようなアルゴリズムを実装し、特定の条件下のみ特定のDOMを更新することで全体の再構築を防ぐ仕組みを作りました。
フルサイクルな機能開発
- DB設計・RailsのMVC設計・GraphQLインターフェース・Reactコンポーネント・Redash/GA4での分析までを一貫して担当
- GitHub Actionsの導入と開発プロセス中のトイルの自動化
リリース7年が経過するRails + Reactアプリケーションのモダン化
- Sassの@import非推奨によるsassc-railsからcss-bundling-railsへの移行
- webpack.config.jsの最適化
- Sass →CSS in JSへの移行のための技術選定
- jQueryからの安全な脱却ロードマップの策定・進行(進行中)、ES5を上げていくためのリスク評価、古いpolyfillの削除等
株式会社リゾートワークス(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 化
企画LPサイトの構築
- Nuxt.js(composition API), Tailwind CSS, Vercelによる0→1を一人で担当
- デザイナーとFigma上で会話しながら背中合わせで進行
- Lighthouseの点数をほぼ100点に
株式会社タイミー(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の実装/運用
- CS/経理/法務とのコミュニケーション、要件定義
- PMF していないプロダクトでの最小工数になるような技術選定
- Stripe API を利用した複数サービスを跨ぐ決済トランザクションの実装
- 外部 API を ActiveModel オブジェクトとして扱う際のリトライ戦略やエラーハンドリングなど
スキーマ駆動開発の導入・運用
- OpenAPI3 + Committee を利用したスキーマ駆動開発の導入・運用
- ドキュメントの信頼性と保守性を高めた運用が可能に
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 で管理
バックエンドエンジニア (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 のスキーマ分割
- サービス固有の強いドメインを持つ機能の設計、実装