Web 開発の長距離走と持続可能性 - TechFeed Experts Night#31 〜 フロントエンドアーキテクチャの現状と未来

TechFeed Experts Night#31 〜 フロントエンドアーキテクチャの現状と未来 (2024.06.19) https://techfeed.io/events/techfeed-experts-night-31 で使用のスライドです。本編 15 分。

Transcript

1. Web 開発の 長 距離 走 と持続可能性 2024.06.19 @ahomu TechFeed Experts Night#31 〜 フロントエンドアーキテクチャの現状と未来
2. @ahomu - Ayumu Sato KINTOテクノロジーズ株式会社 前の職場：HR Tech スタートアップで経営ボード + Web Dev 前々の職場：メガベンチャーで Web フロントエンド、EM、 人 事 最初の職場：Web システム受託 / 自 社CMS開発で LAMP スタック
3. 本題
4. 本論の ｢設計｣ = Webアプリケーション周りの構造 拡げてもシステムの構造くらいまでの意味合いとします
5. Web 開発は作ったあとも、作り続ける仕事 近年は特に DevOps を念頭に 長 距離 走 を意識せざるをえないことが少なくない
6. 長 距離 走 　 Wikipedia調べ 陸上競技としては5000メートル以上が 長 距離扱いらしいです 長 距離 走 （ちょうきょりそう）とは、陸上競技のうち 長 距離を 走 る競技。 絶対的なスピードや瞬発 力 などよりも持久 力 、戦略などが要求される。同様に 高 い有酸素持久 力 を要求される中距離 走 と 比 べると展開は緩やかであるのが特 徴。短距離 走 などは常に 自己 の最 大 パフォーマンスを発揮することを狙い同 走 者の動向によってレース展開を変えることはないが、 長 距離 走 は時には同 走 者と 駆け引きを 行 い、勝負どころを掴み勝機を掴むための 高 い技術 力 も必要とされ る。 via. https://ja.wikipedia.org/wiki/ 長 距離 走
7. 開発･設計という 長 距離 走 × Web の持続可能性 そんな話を試みてみよう、というのが本論の主旨（ほぼオチ）
8. ௕ڑ཭૸ͳઃܭ
   ΞϓϩʔνͱӨڹ
9. 設計の前提にある 長 距離 走 の理想 もちろん、アプリケーションの設計だけで成し遂げられるわけがない話です • 安 心 して快適に使える堅牢な UI、サービスによって価値が提供されていて • コードベースの健全性が 高 い 水 準を保ち続けていて • 事業価値にヒットする (かもしれない) タスクを滞りなく回せていて • 関わるメンバーの成 長 やウェルビーイングが両 立 されていて • あわよくば事業がうまくいっている状態 • ...を実現するための 土 台として「設計」をしたい（ですよね？）
10. 関わっているコードベースは 長 距離に耐えられそう？ ちょっと思い浮かべてみてください
11. 長 距離 走 に耐えられなさそうな状態 よくある「技術的負債」に丸めず、きっと皆さんが出会ってきたであろう具体ケースを想定してみたい • CSS の変更が予期できず壊れやすいため、変更容易性が損なわれている • limit なしの全件取得箇所で、データ増加に伴う性能低下や表 示 崩れが 生 じる • 非 標準のWeb APIに依存していて、 非 合理なブラウザ環境の制約を抱えている • キャッシュレイヤーがなく、アクセス量と 比 例して通信費が 高 騰する • UIの 見 た 目 や操作性、情報構造などに 一 貫性がなく利 用 体験が損なわれる
12. なるべく 長 距離 走 を阻害されないように設計したい 作り続けることは設計し続けるということ、既存の不都合は解消するしかない
13. 長 く 走 り続けるための設計的アプローチ 技術投資が継続されながら 長 期間存続しているWebプロダクト 自 体が全体に対して稀な存在ではある 漸進的改修（延命） 作り直し（転 生 ）
14. 設計において考慮される技術以外の影響要因 ビジネス要求、技術要件に叶うように設計すべきという話は前提条件として割愛 人 的資源 予算/期限 環境変化 社内政治
15. 人 的資源 今のところはまだ開発のほとんどを 人 間がコーディングしているので、 人 的資源のウェイトが重い • 人 は燃え尽きる • 正しい開発習慣の強要も相 手 次第で燃え尽きを助 長 する • メンバーを鑑みて複雑性や強度を調整する必要がある • 生 成 AI が進歩したら計算資源の問題になるかもしれない
16. 予算/期限 まさに時は 金 なり • 開発費 = ほぼ 人 件費であり、時間に 比 例して予算が溶ける • アジャイルだろうと滝 行 だろうと時間的制約はある • そのために時間を理由とした妥協も常に 生 じる • 妥協の産物がただの稚拙か、意図的な拙速かの区別はある
17. 環境変化 ユーザーの利 用 環境の多くはコントロールできず、相対的な劣化に晒されます • デバイスの性能や通信環境は今も進歩し続けている • ユーザーニーズ、ビジネス要求、デザインも変わり続ける • 特に toC 領域では定性的にイケてることが死活問題 • 最善を尽くしても表層の経年劣化は避けがたい
18. 社内政治 正しくは、組織の意思決定に対するアクセス可能性というべきかもしれません • 消極的な改修か、積極的な作り直しか • 作り直しの要否判断、要とした場合の投資判断 • 健全に設計し続けるための環境整備をできるか？ • 好調な事業ですら/であればこそ難しいこともある
19. 各種条件で絞り込んでなお、設計上の選択肢は多い 取捨選択の精度や説得 力 が 高 めるためのプラスアルファの観点
20. 84(
    
    8FCͷ࣋ଓՄೳੑ
21. IUUQTXDHJUIVCJPTVTUZXFC
    %SBGU
    $PNNVOJUZ
    (SPVQ
    3FQPSU
    
    "QSJM
    
22. Web Sustainability Guidelines (WSG) 1.0 うぇっぶさすてなぼー... Draft Community Group Report ですし、標準仕様とかではありません • Web をより持続可能にするため、ESG に基づいた推奨事項のガイドライン • 具体的な実装や配信上のプラクティス、ユーザー体験、ビジネス設計 etc など 多岐にわたる関 心 事を内包したドキュメント • 関連する参考 文 書に Design Principles、Ethical Web Principles、Human Rights Spec、Privacy Principles など....
23. 持続可能性 ≒ 効率的で 長 期的なシステムであること 長 距離 走 を 走 り抜くヒントとして役に 立 つ考え 方 のひとつではないか？
24. 3.21 Align Technical Requirements With Sustainability Goals 技術要件と持続可能性の 目 標を 一 致させるための達成基準（抜粋） • Identify Requirements • 要件に合わせ最 小 限の実装 (構築負荷が 高 い) か既製品的な実装 (運 用 負荷が 高 い) か慎重に選択する • Optimized Methodology • 重いライブラリ、フレームワークよりもネイティブな機能を優先する • Static VS Dynamic • サーバーで動的 生 成するよりも、配信時の負荷が低い静的 生 成の採 用 を優先して検討する • Expandability Considerations • プラグインや拡張機能の類は相互運 用 性、アクセシビリティ、性能が最 大 限 高 まるよう選択する
25. 3.21 Align Technical Requirements With Sustainability Goals 技術要件と持続可能性の 目 標を 一 致させることによる利点（抜粋） • Environmental • 長 期的なテクノロジーの影響を慎重に検討し、時間をかけて最適化して効率的に活 用 すること で、環境への影響を 長 期的に削減できる • Performance • インフラストラクチャの無 用 な複雑さを回避すると、開発者の作業速度が向上するだけでなく、 パフォーマンス 面 のオーバーヘッドも軽減され、排出量削減に関連するメリットも 高 まる • Economic • ユーザー体験に過度の負担をかける可能性のあるテクノロジーを避けることで、結果的にメンテ ナンスなどの 面 で経済的な節約につながる可能性がある
26. 2.13 Use a Design System To Prioritize Interface Consistency ウェブ標準とわかりやすいパターンに基づいたインターフェースによって体験の 一 貫性を提供しましょう • Environmental, Economic • 一 貫性と最適化が成されたパーツに倣い、無 用 な再 生 産や冗 長 性を排することで結果的に利 用 者、開発者、企業など全体のエネルギー使 用 量を削減し、経済効率を 高 める • Performance, Accessibility • よく作り込まれて標準化されたコンポーネントによって構築されることは各種のパフォーマンス やアクセシビリティにポジティブな影響がある • Conversion • 一 貫性のある体験によって訪問者が効果的に利 用 できるようになると、リテンション率やコン バージョン率の向上が期待される
27. 3.17 Manage Dependencies Appropriately "only using libraries where necessary" 本当に必要なものだけを管理しましょう • Environmental • 開発者のマシンは、必要のないパッケージのインストールやレンダリングにエネルギーを浪費す る必要がない • Security • サードパーティのコードには、バグやセキュリティ上の問題が含まれている可能性がある。パッ ケージを常に最新の状態に保ち、サードパーティ・ライブラリの使 用 数を減らすことで、セキュ リティ上の 欠 陥が発 生 する可能性を減らすことができる • Performance • クライアントサイドのJavaScriptを減らすと、通常ウェブサイトが速くなる
28. 4.10 Consider CDNs and Edge Caching CDNで効率的な配信を 行 うことのシンプルな価値を前提として、CDN事業者 自 体の持続可能性への投資も考慮しましょう • Environmental • アセットの配信が速くなり (サーバーがデバイスに近づくため)、デバイスの前で過ごす時間が短 縮され、その結果、消費者のデバイスのバッテリーが消耗しなくなる • Social Equity • コンテンツが 自 分の所在地に近い地域で利 用 できる可能性があるため、通常はサービスが 行 き届 いていない地域や経済、または恵まれない環境の訪問者にメリットをもたらす • Economic • コンテンツ配信ネットワークは規模の経済性に基づいて機能し、そのデータ転送料 金 は多くのホ スティングプロバイダーよりも安価であることが多い
29. "O
    FWFO
    GBTUFS
    .JDSPTPGU
    &EHF
    IUUQTCMPHTXJOEPXTDPNNTFEHFEFWBOFWFOGBTUFSNJDSPTPGUFEHF
    JavaScript による UI レンダリングを 見 直して Browser Essentials の応答性を 42 % 高 速化 SSD でないデバイスや RAM が 8GB 未満のデバイスでは 76 % の 高 速化
30. ” "We hope that more websites start moving in this direction of markup-first, small bundles, and less UI- rendering JavaScript code." via. An even faster Microsoft Edge
31. 太平洋フェリー船内の壁 面 にあった 鳥 の絵 • 開発は 長 距離 走 • 設計はし続けるもの • 長 距離 走 と持続可能性の親和性 • 持続可能なアプローチにおける 本質的な合理性・効率性を評価 してみても良いのではないか まとめ
32. ご視聴ありがとうございました :)