Upgrade to Pro — share decks privately, control downloads, hide ads and more …

スケーラブル CI/CD with Nx モノレポ

okmttdhr
December 08, 2021

スケーラブル CI/CD with Nx モノレポ

okmttdhr

December 08, 2021
Tweet

More Decks by okmttdhr

Other Decks in Programming

Transcript

  1. スケーラブル CI/CD with Nx モノレポ okmttdhr

  2. 自己紹介 DMM プラットフォーム事業本部エンジニア YouTube アニメにハマっている

  3. 背景 プラットフォーム事業本部は、認証・決済など横断的に使われる機能を提供する その中でもフロントエンドは、多くのプロダクトに対して少数のエンジニアで開発をしていた 似たようなコードや仕組みを書く必要がある割に、なんのエコシステムも存在していなかった 結果として、開発効率の悪さや、プログラムでもUI でも、統一感のなさが問題になっていた

  4. => フロントエンド開発を支える スケーラブルなエコシステムが必要

  5. => モノレポを選択 ひとつのプラットフォームチームを中心として 多くのチームがFE 開発を進めていく組織体制にマッチする

  6. Nx

  7. 一般的なモノレポの利点 - 簡単にコードを共有できる - アトミックなバージョン管理 - 技術スタックの統一

  8. Nx とは 元々はモノレポによらないビルドツール distributed task execution, computation caching, smart rebuilds

    of affected projects…
  9. Nx によるモノレポ - 影響のあるアプリケーションだけをテスト、ビルド - Nx CLI による、複数のシステムでのコマンドラインの統一 - ローカルキャッシュによる高速なビルド

    - 依存関係のビジュアル化、etc
  10. => 従来のモノレポの欠点をカバー

  11. モノレポに含まれるもの 例

  12. [ 本題] スケーラブルな CI/CD とは? - 1. アプリケーションが増えても 実行時間が速い -

    2. アプリケーションが増えても 保守できる - 3. チームが増えても 疎結合に運用できる
  13. 1. アプリケーションが増えても 実行時間が速い

  14. 1. アプリケーションが増えても 実行時間が速い n = アプリケーション & ライブラリの数 モノレポでないアプリでは n

    = 1 だが、モノレポでは理論上無限にアプリが増える すべて直列だと、実行時間が n に比例して伸びるのでスケールしない ` ` ` ` ` `
  15. => アプリケーションが増えても、全体の CI/CD 実行 時間に影響しないことが大事

  16. 1. アプリケーションが増えても 実行時間が速い Nx で影響のあるアプリケーション & ライブラリを出力することができる nx affected:test --parallel

    などもあるが、それ以上のことをしたかったので不採用 ` ` $ nx affected:apps --base=origin/main --head=HEAD # 環境によって base, head は変更可能 > NX Affected apps: - app-foo - app-bar - app-buz $ nx affected:libs --base=origin/main --head=HEAD > NX Affected libs: - lib-foo - lib-bar - lib-buz
  17. 1. アプリケーションが増えても 実行時間が速い 出力したアプリケーション & ライブラリを Github Actions の matrix

    形式 に変換 composite action 化することで、使い回せるように 1. https://github.blog/changelog/2020-04-15-github-actions-new-workflow-features/ ↩︎ 2. https://docs.github.com/en/actions/creating-actions/creating-a-composite-action ↩︎ [1] ` `[2] name: output affected outputs: affected: description: 'affected apps and libs' value: ${{ steps.print.outputs.affected }} runs: using: composite steps: - name: print id: print run: | # affected-to-matrix.js で nx affected を実行し matrix 形式に変換 MATRIX=$(node ./scripts/affected-to-matrix.js) echo "::set-output name=affected::$MATRIX" shell: bash
  18. 1. アプリケーションが増えても 実行時間が速い 出力したアプリケーション & ライブラリを Github Actions の matrix

    形式 に変換 composite action 化することで、使い回せるように 1. https://github.blog/changelog/2020-04-15-github-actions-new-workflow-features/ ↩︎ 2. https://docs.github.com/en/actions/creating-actions/creating-a-composite-action ↩︎ [1] ` `[2] MATRIX=$(node ./scripts/affected-to-matrix.js) name: output affected outputs: affected: description: 'affected apps and libs' value: ${{ steps.print.outputs.affected }} runs: using: composite steps: - name: print id: print run: | # affected-to-matrix.js で nx affected を実行し matrix 形式に変換 echo "::set-output name=affected::$MATRIX" shell: bash
  19. 1. アプリケーションが増えても 実行時間が速い 出力したアプリケーション & ライブラリを Github Actions の matrix

    形式 に変換 composite action 化することで、使い回せるように 1. https://github.blog/changelog/2020-04-15-github-actions-new-workflow-features/ ↩︎ 2. https://docs.github.com/en/actions/creating-actions/creating-a-composite-action ↩︎ [1] ` `[2] using: composite name: output affected outputs: affected: description: 'affected apps and libs' value: ${{ steps.print.outputs.affected }} runs: steps: - name: print id: print run: | # affected-to-matrix.js で nx affected を実行し matrix 形式に変換 MATRIX=$(node ./scripts/affected-to-matrix.js) echo "::set-output name=affected::$MATRIX" shell: bash
  20. 1. アプリケーションが増えても 実行時間が速い 出力したアプリケーション & ライブラリを Github Actions の matrix

    形式 に変換 composite action 化することで、使い回せるように 1. https://github.blog/changelog/2020-04-15-github-actions-new-workflow-features/ ↩︎ 2. https://docs.github.com/en/actions/creating-actions/creating-a-composite-action ↩︎ [1] ` `[2] name: output affected outputs: affected: description: 'affected apps and libs' value: ${{ steps.print.outputs.affected }} runs: using: composite steps: - name: print id: print run: | # affected-to-matrix.js で nx affected を実行し matrix 形式に変換 MATRIX=$(node ./scripts/affected-to-matrix.js) echo "::set-output name=affected::$MATRIX" shell: bash
  21. 1. アプリケーションが増えても 実行時間が速い 作成した composite action を使って、影響のあるアプリケーション & ライブラリだけをテスト `

    ` name: test lint build # リントやビルドも合わせて行っているが、並列化の余地はある (swc 等も活用し、全部込みで5 分程度で終わるので今は問題に jobs: output-affected: runs-on: ubuntu-latest outputs: affected: ${{ steps.print.outputs.affected }} steps: - uses: ./.github/workflows/actions/output-affected id: print test-lint-build: runs-on: ubuntu-latest environment: test strategy: # 生成した matrix を設置 matrix: ${{needs.output-affected.outputs.affected}} steps: # 実際のテスト実行スクリプト ( 省略)
  22. 1. アプリケーションが増えても 実行時間が速い 作成した composite action を使って、影響のあるアプリケーション & ライブラリだけをテスト `

    ` steps: - uses: ./.github/workflows/actions/output-affected id: print name: test lint build # リントやビルドも合わせて行っているが、並列化の余地はある (swc 等も活用し、全部込みで5 分程度で終わるので今は問題にな jobs: output-affected: runs-on: ubuntu-latest outputs: affected: ${{ steps.print.outputs.affected }} test-lint-build: runs-on: ubuntu-latest environment: test strategy: # 生成した matrix を設置 matrix: ${{needs.output-affected.outputs.affected}} steps: # 実際のテスト実行スクリプト ( 省略)
  23. 1. アプリケーションが増えても 実行時間が速い 作成した composite action を使って、影響のあるアプリケーション & ライブラリだけをテスト `

    ` outputs: affected: ${{ steps.print.outputs.affected }} test-lint-build: strategy: # 生成した matrix を設置 matrix: ${{needs.output-affected.outputs.affected}} name: test lint build # リントやビルドも合わせて行っているが、並列化の余地はある (swc 等も活用し、全部込みで5 分程度で終わるので今は問題にな jobs: output-affected: runs-on: ubuntu-latest steps: - uses: ./.github/workflows/actions/output-affected id: print runs-on: ubuntu-latest environment: test steps: # 実際のテスト実行スクリプト ( 省略)
  24. 1. アプリケーションが増えても 実行時間が速い 作成した composite action を使って、影響のあるアプリケーション & ライブラリだけをテスト `

    ` name: test lint build # リントやビルドも合わせて行っているが、並列化の余地はある (swc 等も活用し、全部込みで5 分程度で終わるので今は問題に jobs: output-affected: runs-on: ubuntu-latest outputs: affected: ${{ steps.print.outputs.affected }} steps: - uses: ./.github/workflows/actions/output-affected id: print test-lint-build: runs-on: ubuntu-latest environment: test strategy: # 生成した matrix を設置 matrix: ${{needs.output-affected.outputs.affected}} steps: # 実際のテスト実行スクリプト ( 省略)
  25. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけをデプロイ name: deploy jobs: output-affected:

    # 省略 call-testing: # 省略 call-deploy: needs: [output-affected, call-testing] runs-on: ubuntu-latest environment: ${{matrix.app-name}}-prd # environment によりアプリごとの環境変数を読み込める strategy: # 生成した matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: actions/checkout@v2 - uses: ./.github/workflows/actions/ecr-deploy with: app-name: ${{matrix.app-name}} AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}
  26. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけをデプロイ output-affected: # 省略 name:

    deploy jobs: call-testing: # 省略 call-deploy: needs: [output-affected, call-testing] runs-on: ubuntu-latest environment: ${{matrix.app-name}}-prd # environment によりアプリごとの環境変数を読み込める strategy: # 生成した matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: actions/checkout@v2 - uses: ./.github/workflows/actions/ecr-deploy with: app-name: ${{matrix.app-name}} AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}
  27. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけをデプロイ call-deploy: strategy: # 生成した

    matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} app-name: ${{matrix.app-name}} name: deploy jobs: output-affected: # 省略 call-testing: # 省略 needs: [output-affected, call-testing] runs-on: ubuntu-latest environment: ${{matrix.app-name}}-prd # environment によりアプリごとの環境変数を読み込める steps: - uses: actions/checkout@v2 - uses: ./.github/workflows/actions/ecr-deploy with: AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}
  28. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけをデプロイ - uses: ./.github/workflows/actions/ecr-deploy name:

    deploy jobs: output-affected: # 省略 call-testing: # 省略 call-deploy: needs: [output-affected, call-testing] runs-on: ubuntu-latest environment: ${{matrix.app-name}}-prd # environment によりアプリごとの環境変数を読み込める strategy: # 生成した matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: actions/checkout@v2 with: app-name: ${{matrix.app-name}} AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}
  29. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけをデプロイ environment: ${{matrix.app-name}}-prd # environment

    によりアプリごとの環境変数を読み込める name: deploy jobs: output-affected: # 省略 call-testing: # 省略 call-deploy: needs: [output-affected, call-testing] runs-on: ubuntu-latest strategy: # 生成した matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: actions/checkout@v2 - uses: ./.github/workflows/actions/ecr-deploy with: app-name: ${{matrix.app-name}} AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}
  30. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけをデプロイ name: deploy jobs: output-affected:

    # 省略 call-testing: # 省略 call-deploy: needs: [output-affected, call-testing] runs-on: ubuntu-latest environment: ${{matrix.app-name}}-prd # environment によりアプリごとの環境変数を読み込める strategy: # 生成した matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: actions/checkout@v2 - uses: ./.github/workflows/actions/ecr-deploy with: app-name: ${{matrix.app-name}} AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}
  31. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけをデプロイ reusable workflow でテストを呼び出せる 1.

    https://docs.github.com/en/actions/learn-github-actions/reusing-workflows ↩︎ ` `[1] name: deploy jobs: output-affected: # 省略 call-testing: needs: [output-affected] uses: org/repo/.github/workflows/testing.yml@main with: app-name: ${{needs.output-affected.outputs.affected}} call-deploy: # 省略
  32. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけをデプロイ reusable workflow でテストを呼び出せる 1.

    https://docs.github.com/en/actions/learn-github-actions/reusing-workflows ↩︎ ` `[1] output-affected: # 省略 name: deploy jobs: call-testing: needs: [output-affected] uses: org/repo/.github/workflows/testing.yml@main with: app-name: ${{needs.output-affected.outputs.affected}} call-deploy: # 省略
  33. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけをデプロイ reusable workflow でテストを呼び出せる 1.

    https://docs.github.com/en/actions/learn-github-actions/reusing-workflows ↩︎ ` `[1] call-testing: uses: org/repo/.github/workflows/testing.yml@main app-name: ${{needs.output-affected.outputs.affected}} name: deploy jobs: output-affected: # 省略 needs: [output-affected] with: call-deploy: # 省略
  34. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけをデプロイ reusable workflow でテストを呼び出せる 1.

    https://docs.github.com/en/actions/learn-github-actions/reusing-workflows ↩︎ ` `[1] name: deploy jobs: output-affected: # 省略 call-testing: needs: [output-affected] uses: org/repo/.github/workflows/testing.yml@main with: app-name: ${{needs.output-affected.outputs.affected}} call-deploy: # 省略
  35. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけの Storybook をデプロイ name: storybook

    jobs: output-affected: # 省略 call-storybook-build: needs: [output-affected] strategy: matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: ./.github/workflows/actions/storybook-build with: app-name: ${{matrix.app-name}} call-storybook-comment: # 省略
  36. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけの Storybook をデプロイ output-affected: #

    省略 name: storybook jobs: call-storybook-build: needs: [output-affected] strategy: matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: ./.github/workflows/actions/storybook-build with: app-name: ${{matrix.app-name}} call-storybook-comment: # 省略
  37. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけの Storybook をデプロイ call-storybook-build: strategy:

    matrix: ${{fromJson(needs.output-affected.outputs.affected)}} app-name: ${{matrix.app-name}} name: storybook jobs: output-affected: # 省略 needs: [output-affected] steps: - uses: ./.github/workflows/actions/storybook-build with: call-storybook-comment: # 省略
  38. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけの Storybook をデプロイ name: storybook

    jobs: output-affected: # 省略 call-storybook-build: needs: [output-affected] strategy: matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: ./.github/workflows/actions/storybook-build with: app-name: ${{matrix.app-name}} call-storybook-comment: # 省略
  39. 1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけの Storybook をPR にコメント エンジニアやデザイナーが影響範囲を容易に把握できる

  40. 1. アプリケーションが増えても 実行時間が速い✅ ( 理論上) n = アプリケーション がどれだけふえても、実行時間に影響はない CI/CD

    実行時間は、最も実行時間の長いアプリとほぼ等しくなる 1. 仮にボトルネックとなるアプリが現れた場合もまだまだ並列化の余地がある ↩︎ ` ` [1]
  41. 2. アプリケーションが増えても 保守できる

  42. 2. アプリケーションが増えても 保守できる n = アプリケーション & ライブラリの数 モノレポでないアプリでは n

    = 1 だが、モノレポでは理論上無限にアプリが増える すべて個別に CI/CD のコードを書いていると複雑化するし、スケールしない ` ` ` `
  43. => アプリケーションが増えても、統一されたパイプ ラインを使えることが重要

  44. 2. アプリケーションが増えても 保守できる 2.1. 技術スタックの統一 Next.js を Docker image として

    ECS 環境へデプロイ ( 将来的にはインフラ側もこちらで用意した環境を提 供したい) テスト、リント、型チェックなどは統一
  45. 2. アプリケーションが増えても 保守できる 2.2. GitHub Actions を使いこなす reusable workflow ,

    composite actions で共通のフローを切り出し 適切にモジュール化し、低コストで複数のアプリケーションでの CI/CD パイプラインを運用 ` ` ` `
  46. 2. アプリケーションが増えても 保守できる✅ n = アプリケーション がどれだけふえても、統一されたパイプラインを同じ yaml のコードで管理すれば 良い

    ` `
  47. 3. チームが増えても 疎結合に運用できる

  48. 3. チームが増えても 疎結合に運用できる n = 関わるチームの数 モノレポ上で開発するチームが増えるたびコミュニケーションコストが上がるようだとスケールしない ` `

  49. => チームが増えても、互いに疎結合な開発ができる ことが重要

  50. 3. チームが増えても 疎結合に運用できる GitHub Flow でブランチ運用の統一 (rc = master, stg

    = tag, production = tag release)
  51. 3. チームが増えても 疎結合に運用できる Hotfix のユースケースも考慮 ( 複数のチームがそれぞれのアプリケーションを検証中の場合、単純な revert だと他のチームに影響がでてしまうため)

  52. 3. チームが増えても 疎結合に運用できる 各ロールごとに、だれがなににオーナーシップを持つのかを定義 実装者 レビュワー マージ アプリの新規作成 エコシステム開発者 エコシステム開発者

    エコシステム開発者 アプリの機能開発/ 運用 アプリの開発者 アプリの開発者 & ( 一部) エコシステム開発者 アプリの開発者 共通ライブラリの新規作成 エコシステム開発者 エコシステム開発者 エコシステム開発者 共通ライブラリの機能開発/ 運用 エコシステム開発者 エコシステム開発者 エコシステム開発者 障害時の切り戻し … … … renovate … … … etc … … …
  53. 3. チームが増えても 疎結合に運用できる CODEOWNERS の活用により自動化 # CODEOWNERS * @platform-team */app-foo/**

    @app-foo-team @platform-team */app-bar/** @app-bar-team @platform-team */lib-bar/** @platform-team */lib-bar/** @platform-team
  54. 3. チームが増えても 疎結合に運用できる 依存関係を Lint できるため、適切でないライブラリの使用を制限できる { "rules": { "@nrwl/nx/enforce-module-boundaries":

    [ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "sourceTag": "scope:app-foo", "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] } ] } }
  55. 3. チームが増えても 疎結合に運用できる 依存関係を Lint できるため、適切でないライブラリの使用を制限できる "depConstraints": [ { "sourceTag":

    "scope:app-foo", "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] { "rules": { "@nrwl/nx/enforce-module-boundaries": [ "error", { "enforceBuildableLibDependency": true, } ] } }
  56. 3. チームが増えても 疎結合に運用できる 依存関係を Lint できるため、適切でないライブラリの使用を制限できる "sourceTag": "scope:app-foo", { "rules":

    { "@nrwl/nx/enforce-module-boundaries": [ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] } ] } }
  57. 3. チームが増えても 疎結合に運用できる 依存関係を Lint できるため、適切でないライブラリの使用を制限できる "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger"

    ] { "rules": { "@nrwl/nx/enforce-module-boundaries": [ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "sourceTag": "scope:app-foo", }, ] } ] } }
  58. 3. チームが増えても 疎結合に運用できる 依存関係を Lint できるため、適切でないライブラリの使用を制限できる { "rules": { "@nrwl/nx/enforce-module-boundaries":

    [ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "sourceTag": "scope:app-foo", "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] } ] } }
  59. 3. チームが増えても 疎結合に運用できる [coming soon] 依存関係のビジュアライズ (Nx Project Graph)

  60. 3. チームが増えても 疎結合に運用できる✅ n = チーム がどれだけふえても、疎結合に開発ができる ` `

  61. まとめ

  62. スケーラブルな CI/CD - 1. アプリケーションが増えても 実行時間が速い - 2. アプリケーションが増えても 保守できる

    - 3. チームが増えても 疎結合に運用できる
  63. スケーラブルな CI/CD - 1. アプリケーションが増えても 実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD -

    2. アプリケーションが増えても 保守できる - 3. チームが増えても 疎結合に運用できる
  64. スケーラブルな CI/CD - 1. アプリケーションが増えても 実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD -

    2. アプリケーションが増えても 保守できる✅ 技術スタックの統一 reusable workflow , composite actions - 3. チームが増えても 疎結合に運用できる ` ` ` `
  65. スケーラブルな CI/CD - 1. アプリケーションが増えても 実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD -

    2. アプリケーションが増えても 保守できる✅ 技術スタックの統一 reusable workflow , composite actions - 3. チームが増えても 疎結合に運用できる✅ ブランチ運用の統一 CODEOWNERS の活用 依存関係の Lint ` ` ` `
  66. スケーラブルな CI/CD ✅ - 1. アプリケーションが増えても 実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD

    - 2. アプリケーションが増えても 保守できる✅ 技術スタックの統一 reusable workflow , composite actions - 3. チームが増えても 疎結合に運用できる✅ ブランチ運用の統一 CODEOWNERS の活用 依存関係の Lint ` ` ` `
  67. => まだまだフロントエンドエコシステムで 解決したい課題がたくさんあります https://dmm-corp.com/recruit/engineer/946/ https://dmm-corp.com/recruit/designer/970/

  68. ご清聴ありがとうございました