Webフロントエンドの秩序を維持する体制を作る

Webフロントエンドの  秩序を維持する体制を作る  Hatena Engineer Seminar #15  2020/12/23   

自己紹介  • id:mizdra  • はてな2020新卒  • マンガメディア開発チーム  • コードを書くのが趣味  ◦
Webフロントエンド 

GigaViewer  • 社内で開発しているマンガビューワ  ◦ ブラウザで漫画を読むための機能を提供  ◦ ビューワ / トップページ /
検索画面 / 管理画面 / …  • 出版社様向けに提供  ◦ 9社・11のサイトで採用 

少年ジャンプ＋ (集英社様) 

webアクション (双葉社様) 

まだまだ成長中 

id:mizdra のチームにおける普段の活動  • フロントエンド会  ◦ GigaViewer のフロントエンドを改善する会  • 5月に立ち上げてから約半年経った  •
色んなことがあったので色々良い話をします 

フロントエンド会  立ち上げの経緯 

立ち上げ当時のチームの状況  • いままで  ◦ 1人の職人が専属でフロントエンドを見ていた  • しかし id:mizdra の入社と共に異動に  ◦
フロントエンドの面倒を見る人が不在に 

立ち上げ当時のチームの状況  • 皆主にバックエンドを触っている  ◦ それほどフロントエンドに詳しい訳でもない  ◦ 片手間でちょっとしたことをするくらい  • 難しい問題がやってくると手に負えない状態  ◦
異動された方にお任せしていた  ◦ フロントエンドが属人化していた 

なんとかしよう  • 持ち回り制でやってみる?  ◦ 片手間でできないとなると非現実的  ◦ かといって1人にお任せすると異動や退職で困る  • 得意な人/興味のある人で集まって専門者集団を作るのはどうか  ◦
チームメンバー3人で「フロントエンド会」を結成 

フロントエンド会での  取り組み 

npmパッケージのアップデート  • npmパッケージのバージョンが古びていた  ◦ majorアップデートが30件  • Breaking Changeが積み重なり、アップデートが難しい状態  ◦ 上げようと思っても中々上げられない 
◦ とはいえ放置するとどんどん困難に  • セキュリティ上のリスクも  • まずはこれから取り組むことに 

とはいえ...  • メンバーのスキルセットはバラバラ  ◦ 何でもできます〜趣味でちょっとした物を作ったりできます  ◦ パッケージのアップデートをどうやれば良いか分からない人も  •
出来る人だけやっても仕方がない  ◦ 再び属人化してしまう  ◦ そもそも複数人で集まっている意味がない 

会の運営方針  • それぞれが知識を学び、自走できるように  • そのために...  ◦ 識者が積極的に知識を配っていく  ▪ やり方をレクチャーしたり、ドキュメントを書いたり  
◦ 簡単に進められるよう道を整備する  ▪ 便利なツールやサービスを導入する   ◦ 自走できるようになるまでフォローする  ▪ ペアプロやモブプロを積極的に活用   • => 属人化も解消され、より高速に進められるようになるはず 

npmパッケージのアップデートにおける工夫  • Renovateを活用  ◦ パッケージをアップデートするPRを自動で作ってくれる  ◦ PRにCHANGELOGへのリンクなどがあり、効率的に作業できる  • モブオペを活用  ◦
アップデート作業には知識が必要  ▪ ライブラリの機能や用途   ▪ CHANGELOGの眺め方   ▪ Breaking Changeがプロダクションに影響があるかを判断する方法   ◦ 識者と一緒に作業し、知識を共有する 

結果  • 1ヶ月後には自走し始めるように  • npm パッケージをアップデートしていく習慣ができた  • 半年後には major が
30 => 8 に  • あとは gulp とかアップデートするより脱出したいもの  ◦ ひとまず安心できる状態に 

パッケージのアップデートが落ち着いてきた  • 設立から2ヶ月経過  • 他のことをやる余裕が出てきた  • 識者が沢山居ることを生かして何かやりましょう  ◦ フロントエンド相談窓口  ◦
巨大な問題の解決 

フロントエンド相談窓口  • フロントエンドタスクの相談や見積もり、実装の依頼などを受け付ける活動  • 例  ◦ マンガが表示されない原因を調査してほしい  ◦ 格好良い機能を作りたいのだけど実現できそう?  ◦
自信無いので一緒にタスク分割や見積もりしてくれませんか  • こうしたタスクを会で引き受けていった 

難しいところ  • 色んな種類のタスクがやってくる  ◦ ビューワだったり広告だったりビルドパイプラインの話題だったり  ◦ 人によって詳しかったり詳しくなかったり  ◦ １人で全部やるのは難しい  •
結構タスクがやってくる  ◦ 専属ならまだしも1人で片手間で捌くのは難しい 

複数人であることを活かして進める  • まずはタスクを会の議題として取り上げる  ◦ 実装方針を決めたり、タスクを分解したり  ◦ 進め方のイメージがつくようになるまで議論する  • 興味のある人や余裕のある人にお渡しする  ◦
不安があるなら一緒にペアプロして倒す  • => 複数人で協力して短時間で片付ける 

巨大な問題の解決  • チームの力で巨大な問題を倒す活動  • 代表例: ビューワのメモリリーク問題  ◦ ページをめくっていくとモリモリメモリ使用量が増えていく  ◦ 開発初期から存在していた 
◦ ユーザからのお問い合わせもなかったため、優先度が低かった   

問題発生  • 今年の7月になってページ画像が表示されないとの報告が  ◦ ページ数が多い作品だと上限に達してページ画像が表示されなくなる  ◦ 報告件数も徐々に増えてきた  ◦ 怪しい雰囲気  •
11月に人気のある雑誌の定期購読サービスが始まる  ◦ 500Pくらいある  ◦ なんだか嫌な予感  • なんとかしよう   

めちゃめちゃ難しい  • メモリリークが発生している理由(ページめくり)に見当は付いていた  ◦ 一方どう修正すれば良いかは不明  • GCの仕組み / メモリリークが発生する仕組み /
メモリリークを引き起こすコードパターンに関する知識  • そもそもビューワはGigaViewerで特に難しいとされる部分  ◦ 複雑なコードを読み解き、的確な修正をしなければならない   

どう進めたか  • GCの仕組みやメモリリークの仕組みについて勉強することに  ◦ 偶然 id:mizdra が趣味でメモリリークに取り組んでいた  ◦ その知見を元に会向けの学習資料を用意 

どう進めたか  • 資料を元に修正箇所や修正方法について議論  ◦ 古いページ (Nページ前) のDOMは捨てるよう改良することに  • その後方針通りに実装  ◦
ピタリとメモリリークが収まる   

Before     

After     

良かったこと  • メモリリーク識者が居た  ◦ 取っ掛かりができた  • ビューワのアーキテクチャの識者が居た  ◦ 修正箇所の特定や修正方法がすんなり決まった  
• 学習資料で知識が底上げされた結果、メンバー全員で実装イメージが共有できるように  ◦ 実装もレビューも全員自信を持ってできるように    => 複数人で協力して安定して進めることができた 

これにて一段落 

順調に課題を解決して来たが…  • ある日Dから相談が  ◦ 「会の目標や存在意義を明確にしてほしい」  • よくよく話を聞いていくと  ◦ フロントエンド会に対してどういう期待をしてよいのかよく分からない  ◦
タスクを任せづらい 

振り返ってみると  • フロントエンドの秩序を維持する、みたいな目標で行動してきた  ◦ ふわっとしている  ◦ 「秩序とは? 保守運用のこと?」  ◦ 「実装の相談に乗って欲しいのだけど保守しかやってくれないの?」 
• 本当は相談なども引き受けたい  ◦ しかし目標が不透明なせいで混乱が生じていた 

目標を整理する  • これを機に一度目標を整理してみることに  • 今までの活動実績や会のメンバーの意見を元に、会に期待されていること /会でやりたいことを書き出していく  • まとめて「フロントエンド会で担いたい仕事」としてチームに告知 

フロントエンド会で担いたい仕事  1. フロントエンドの開発支援  ◦ タスクの見積もりや壁打ちやります  ◦ レビュー引き受けます  ◦ 企画やデザインでやりたいこと・導入したいツールがあれば支援します  2.
フロントエンドの課題解決  ◦ メモリリークのような難しい問題倒します  ◦ パフォーマンス改善やります  ◦ 新技術導入やります 

結果として  • 「この話題はフロントエンド会に相談しよう」と判断しやすく  • Dからも気持ちよくGOと言えるように  • 会の指針があることで互いに信頼し、連携しやすく 

その後 

その後、最近の取り組み  • 保守や相談窓口の活動 (いわゆる守りの活動) が会で回せるように  ◦ 秩序を維持する体制が整った  • しかし守りだけでは出せる価値に限界がある  ◦
秩序を維持する以上のことができない  • 守りだけでなく攻めもできるようになろう  ◦ 最新技術の導入 / パフォーマンス改善 

パフォーマンス改善  • ユーザにより快適に、ストレスなく使ってもらえるように  • パフォーマンスの指標の検討に始まり、パフォーマンス測定基盤の構築、測定結果の分析...という流れで進む  ◦ 今ようやく実際にパフォーマンスの改善施策を導入していこう、という段階 

現在の課題  • 具体的な実装イメージを会で共有できていない  • dev-toolsを使い、当たりを付けていく...ことまではできている  ◦ コードのどこをどういじれば良いか、が共有できていない  • 原因: Frontend-Ops
の深い知識が要求されるため  ◦ Frontend-Ops: アプリケーションコード以外のこと  ◦ 実はパフォーマンス改善テクの殆どは Frontend-Ops に関連  ▪ Web Speed Hackathon Online 出題のねらいと解説   ◦ アプリケーションコードよりは基盤をいじるのが主  ◦ Frontend-Ops に詳しい人が id:mizdra 以外にいない 

検討中の案  1. id:mizdra が会に割く時間を増やす  ◦ 属人化時代に逆戻りになってしまいそう  2. 会の皆でFrontend-Opsを学ぶ  ◦ id:mizdra
がレクチャー  ◦ パフォーマンスチューニングの力を付ける  => パッと見た感じでは2が良さそう 

しかし...  • 会がどんどん高度化して、人の入れ替えが困難になる可能性  ◦ 新規メンバーの受け入れや異動・退職で困りそう  ◦ 会を持続可能な形でどう発展していくかが課題 

まとめ 

まとめ  • 秩序を維持する体制を作る話をした  • フロントエンド会の立ち上げ  • 自走する力をつけて、属人化を解消する  • 会の指針を出し、チームやDとの連携を図る  •
価値を高めるため守りだけでなく攻めもやる  • フロントエンドの属人化から会の持続性に話題がシフトしつつある 

Webフロントエンドの秩序を維持する体制を作る

Webフロントエンドの秩序を維持する体制を作る

More Decks by mizdra

Other Decks in Programming

Featured

Transcript