Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Amebaブログの会員画面システム刷新の道程
Search
Ryota Sugawara
January 19, 2023
Programming
3
1.1k
Amebaブログの会員画面システム刷新の道程
Amebaブログ会員が利用するWebアプリケーションの構成を変更し、Webフロントエンドエンジニアが管理しきれるようにシステムを刷新している過程を紹介します。
Ryota Sugawara
January 19, 2023
Tweet
Share
More Decks by Ryota Sugawara
See All by Ryota Sugawara
Google I/O 2017 - Accessibility / Mobile Web
ryotasugawara
0
29
Other Decks in Programming
See All in Programming
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
260
PicoRuby on Rails
makicamel
2
140
RailsGirls IZUMO スポンサーLT
16bitidol
0
190
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
3
790
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
5
1.4k
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
97
34k
CDK引数設計道場100本ノック
badmintoncryer
2
360
型で語るカタ
irof
0
530
The Niche of CDK Grant オブジェクトって何者?/the-niche-of-cdk-what-isgrant-object
hassaku63
1
500
VS Code Update for GitHub Copilot
74th
2
670
チームのテスト力を総合的に鍛えて品質、スピード、レジリエンスを共立させる/Testing approach that improves quality, speed, and resilience
goyoki
5
1k
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
2
20k
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
The World Runs on Bad Software
bkeepers
PRO
69
11k
The Language of Interfaces
destraynor
158
25k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
7
330
Music & Morning Musume
bryan
46
6.7k
Docker and Python
trallard
45
3.5k
Building Applications with DynamoDB
mza
95
6.5k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Bash Introduction
62gerente
613
210k
A Tale of Four Properties
chriscoyier
160
23k
Transcript
Amebaブログの会員画面 システム刷新の道程
2 自己紹介 菅原 良太 (すがわら りょうた) 株式会社サイバーエージェント • 子会社でメディアの立ち上げ •
Ameba事業本部でWebフロントエンドエンジニア ◦ AmebaのSNSプラットフォームの運用開発 ◦ Amebaブログの運用開発 ◦ AmebaのWebフロントエンドエンジニア組織の開発 • 新米パパ @ryo_suga
3 Today • Amebaブログのシステム刷新とは • 開発の歩み • 現状の評価と今後の展望
Amebaブログのシステム刷新とは
5 Amebaブログのシステム刷新とは システムの複雑性を解消し システム毎の責務を明確にし 運用負荷を低くし 生産性を向上させ、事業スピードを加速可能にする
6 課題 • システムの複雑性 ◦ 多種多様な構成の乱立による認知負荷の拡大 • 責務の曖昧さ ◦ BFFがフロントエンド/バックエンドで競合し開発イテレーションが回りづらい
• 運用負荷 ◦ リリースステップが分かれていて運用負荷が高い • 高い属人性 ◦ 作ったっきり更新されずリリースできなくなる
7 刷新を終えたときの理想を設定 • 画面に関する開発サイクルをWebフロントエンドで完結できる ◦ 開発のリードタイムを短く、ハイパフォーマーを目指せる • Webフロントエンド開発者がUI開発に集中できる • 乱立したアプリケーションのカバレッジ(人/品質/運用面)が高い
◦ 作ったきりにならない体制を実現するシステム構成になっている • BFF・インフラ・開発環境の標準化と属人性解消 ◦ システム管理を担えるメンバーが育つ → 息を吸うようにすべてのシステムの品質を維持・向上し続けたい ミッション
8 難易度 • 仕様の考古学 • Webフロントエンド開発者が管理できる構成へのリアーキテクチャ ◦ Webフロントエンドで管理しきるためのバックエンド依存の分離 • 新インフラ基盤への順応(責務領域の拡大
◦ Webフロントエンド領域での "Do it the Ameba Platform way" の設計 • 限られた期間でどう刷新成果を最大化させるか ◦ 数年放置されたUIをSpindle(Design System)に乗せる ◦ UI開発に集中できるBFFの標準化
開発の歩み
10 対象システムの把握 要件定義 仕様策定 詳細設計 実装
11 対象システムの把握 要件定義 仕様策定 詳細設計 実装 1. 対象システムの把握 2. システム設計と技術選定
3. 新しい仕様を策定 4. Design Docs 5. アプリケーション開発
12 対象システムの把握 要件定義 仕様策定 詳細設計 実装 1. 対象システムの把握 2. システム設計と技術選定
3. 新しい仕様を策定 4. Design Docs 5. アプリケーション開発 コード = 仕様 ・実装言語が変わる ⇒ 仕様をコードから日本語化 ・機能の整理 ⇒ 仕様の適正化 仕様 (esa)
13 AmebaのPlatformで利用するNode.js向けの共通実装をGitHub Packagesで提供 例) • ログのフォーマット/レベルルールを統一 • メトリクス実装を統一 • トレーシング実装を統一
• 他共通クライアントの実装 システム設計と技術選定 要件定義 仕様策定 詳細設計 実装 1. 対象システムの把握 2. システム設計と技術選定 3. 新しい仕様を策定 4. Design Docs 5. アプリケーション開発 Platform(アプリケーションが乗るインフラ環境)、アプリケーション基盤を統一
14 システム設計と技術選定 要件定義 仕様策定 詳細設計 実装 1. 対象システムの把握 2. システム設計と技術選定
3. 新しい仕様を策定 4. Design Docs 5. アプリケーション開発 要件が実現可能か、実例を想定したシーケンスの候補を比較検証 例) • ログイン判定 • ブラウザからのAPI呼び出し • ステート管理 など
15 システム設計と技術選定 要件定義 仕様策定 詳細設計 実装 1. 対象システムの把握 2. システム設計と技術選定
3. 新しい仕様を策定 4. Design Docs 5. アプリケーション開発 UI / APIアプリケーションの責務分離 APIエンドポイントの責務 FrontendがBackendへデータを参照・更新するI/F Sessionなど共通実装の点在を防ぐ 画面(UI)のエンドポイントの責務 UIの構築・ブラウザの振る舞いに集中 アプリ数 ≒ ドメイン数
16 システム設計と技術選定 要件定義 仕様策定 詳細設計 実装 1. 対象システムの把握 2. システム設計と技術選定
3. 新しい仕様を策定 4. Design Docs 5. アプリケーション開発 システム運用の認知負荷を下げるためにモノレポ構成 • モノレポ管理ツールには nx を利用 • 各アプリケーションの構成の統一 ◦ 新規アプリ作成時にテンプレートから生成 ◦ 基盤のアップデート • CI / CD のワークフローを統一
17 新しい仕様を策定 要件定義 仕様策定 詳細設計 実装 1. 対象システムの把握 2. システム設計と技術選定
3. 新しい仕様を策定 4. Design Docs 5. アプリケーション開発 要件を元に”作るもの”の仕様を策定 1. エンドポイント毎の仕様 ◦ 画面仕様 ◦ API仕様 2. デザイン作成 • Spindle利用でデザイン品質を統一 3. テストケース • この時点でQCに向けたテストケースを作成 具体的なコードではなくフローの説明を記載 仕様通りに実装すれば誰でも同じ実装ができるレベルで ドキュメンテーションを行う
18 Design Docs 要件定義 仕様策定 詳細設計 実装 1. 対象システムの把握 2.
システム設計と技術選定 3. 新しい仕様を策定 4. Design Docs 5. アプリケーション開発 設計戻しを最小限に留める • 仕様をコードにする事前設計・計画 • 具体的になにをどう実装するのかを共有できる ◦ 例: ▪ コンポーネントの粒度 ▪ 関数の実例 ▪ インターフェース • システム構成から乖離がないかのレビューもこの時点で実施 ◦ 設計のコーチングとしても機能
19 アプリケーション開発 要件定義 仕様策定 詳細設計 実装 1. 対象システムの把握 2. システム設計と技術選定
3. 新しい仕様を策定 4. Design Docs 5. アプリケーション開発 Design Docsをもとに実装 • コーディング • 自動テスト ◦ 基本的にはUnitテスト ◦ APIはエンドポイント単位でのスペックをテスト ◦ UIはコンポーネント単位でVisualRegressionテスト Design Docs通りにうまく行けば良い うまく行かなくても学びが明確になる
現状の評価と今後の展望
21 現状の評価と今後の展望 Good • UI責務をフロント責務のシステムに移すことで生産性・保守性が向上した • UIの開発に集中できる環境が作れた • モノレポにすることでコストは上がるが保守が容易になった More
• まだ影響範囲が狭いので、より適用対象を広げたときシステムが運用に耐えうるか • BFFの変更を先行して行っているので、バックエンド側の刷新を含めた際の最適の設計
ご清聴ありがとうございました Amebaブログの会員画面システム刷新の道程