Amebaブログの会員画面システム刷新の道程

Amebaブログの会員画面
システム刷新の道程

View Slide

2
自己紹介
菅原良太 (すがわらりょうた)
株式会社サイバーエージェント
● 子会社でメディアの立ち上げ
● Ameba事業本部でWebフロントエンドエンジニア
○ AmebaのSNSプラットフォームの運用開発
○ Amebaブログの運用開発
○ AmebaのWebフロントエンドエンジニア組織の開発
● 新米パパ
@ryo_suga

View Slide

3
Today
● Amebaブログのシステム刷新とは
● 開発の歩み
● 現状の評価と今後の展望

View Slide

Amebaブログのシステム刷新とは

View Slide

5
Amebaブログのシステム刷新とは
システムの複雑性を解消し
システム毎の責務を明確にし
運用負荷を低くし
生産性を向上させ、事業スピードを加速可能にする

View Slide

6
課題
● システムの複雑性
○ 多種多様な構成の乱立による認知負荷の拡大
● 責務の曖昧さ
○ BFFがフロントエンド／バックエンドで競合し開発イテレーションが回りづらい
● 運用負荷
○ リリースステップが分かれていて運用負荷が高い
● 高い属人性
○ 作ったっきり更新されずリリースできなくなる

View Slide

7
刷新を終えたときの理想を設定
● 画面に関する開発サイクルをWebフロントエンドで完結できる
○ 開発のリードタイムを短く、ハイパフォーマーを目指せる
● Webフロントエンド開発者がUI開発に集中できる
● 乱立したアプリケーションのカバレッジ（人／品質／運用面）が高い
○ 作ったきりにならない体制を実現するシステム構成になっている
● BFF・インフラ・開発環境の標準化と属人性解消
○ システム管理を担えるメンバーが育つ
→ 息を吸うようにすべてのシステムの品質を維持・向上し続けたい
ミッション

View Slide

8
難易度
● 仕様の考古学
● Webフロントエンド開発者が管理できる構成へのリアーキテクチャ
○ Webフロントエンドで管理しきるためのバックエンド依存の分離
● 新インフラ基盤への順応（責務領域の拡大
○ Webフロントエンド領域での "Do it the Ameba Platform way" の設計
● 限られた期間でどう刷新成果を最大化させるか
○ 数年放置されたUIをSpindle(Design System)に乗せる
○ UI開発に集中できるBFFの標準化

View Slide

開発の歩み

View Slide

10
対象システムの把握
要件定義仕様策定詳細設計実装

View Slide

11
1. 対象システムの把握
2. システム設計と技術選定
3. 新しい仕様を策定 4. Design Docs 5. アプリケーション開発

View Slide

12
コード = 仕様
・実装言語が変わる ⇒ 仕様をコードから日本語化
・機能の整理 ⇒ 仕様の適正化
仕様 (esa)

View Slide

13
AmebaのPlatformで利用するNode.js向けの共通実装をGitHub Packagesで提供
例)
● ログのフォーマット／レベルルールを統一
● メトリクス実装を統一
● トレーシング実装を統一
● 他共通クライアントの実装
システム設計と技術選定
Platform(アプリケーションが乗るインフラ環境)、アプリケーション基盤を統一

View Slide

14
要件が実現可能か、実例を想定したシーケンスの候補を比較検証
例)
● ログイン判定
● ブラウザからのAPI呼び出し
● ステート管理
など

View Slide

15
UI / APIアプリケーションの責務分離
APIエンドポイントの責務
FrontendがBackendへデータを参照・更新するI/F
Sessionなど共通実装の点在を防ぐ
画面(UI)のエンドポイントの責務
UIの構築・ブラウザの振る舞いに集中
アプリ数 ≒ ドメイン数

View Slide

16
システム運用の認知負荷を下げるためにモノレポ構成
● モノレポ管理ツールには nx を利用
● 各アプリケーションの構成の統一
○ 新規アプリ作成時にテンプレートから生成
○ 基盤のアップデート
● CI / CD のワークフローを統一

View Slide

17
新しい仕様を策定
要件を元に”作るもの”の仕様を策定
1. エンドポイント毎の仕様
○ 画面仕様
○ API仕様
2. デザイン作成
● Spindle利用でデザイン品質を統一
3. テストケース
● この時点でQCに向けたテストケースを作成
具体的なコードではなくフローの説明を記載
仕様通りに実装すれば誰でも同じ実装ができるレベルで
ドキュメンテーションを行う

View Slide

18
Design Docs
設計戻しを最小限に留める
● 仕様をコードにする事前設計・計画
● 具体的になにをどう実装するのかを共有できる
○ 例：
■ コンポーネントの粒度
■ 関数の実例
■ インターフェース
● システム構成から乖離がないかのレビューもこの時点で実施
○ 設計のコーチングとしても機能

View Slide

19
アプリケーション開発
Design Docsをもとに実装
● コーディング
● 自動テスト
○ 基本的にはUnitテスト
○ APIはエンドポイント単位でのスペックをテスト
○ UIはコンポーネント単位でVisualRegressionテスト
Design Docs通りにうまく行けば良い
うまく行かなくても学びが明確になる

View Slide

現状の評価と今後の展望

View Slide

21
現状の評価と今後の展望
Good
● UI責務をフロント責務のシステムに移すことで生産性・保守性が向上した
● UIの開発に集中できる環境が作れた
● モノレポにすることでコストは上がるが保守が容易になった
More
● まだ影響範囲が狭いので、より適用対象を広げたときシステムが運用に耐えうるか
● BFFの変更を先行して行っているので、バックエンド側の刷新を含めた際の最適の設計

View Slide

ご清聴ありがとうございました
Amebaブログの会員画面システム刷新の道程

View Slide

Amebaブログの会員画面システム刷新の道程

Amebaブログの会員画面システム刷新の道程

Ryota Sugawara

More Decks by Ryota Sugawara

Other Decks in Programming

Featured

Transcript