本セッションの登壇者
セッション動画
本日はだいぶ実験的なトークなので、話の作りが荒いところが目につきましたら何卒ご容赦いただくようお願いします。
@ahomuというハンドルネームと鳥のアイコンでインターネットで活動しております、佐藤と申します。よろしくお願いします。最近転職してKINTOテクノロジーズというところにいます。
今回は、抽象的な話をしていくことになるのですけれども、テーマが「フロントエンドのアーキテクチャ」ということなので、設計についてのお話をします。ただ、設計という言葉自体は結構広い定義で受け取ることができてしまうので、今回はあまり風呂敷を広げすぎず、Webアプリケーション周りの主にコードベースの構造設計というようなイメージで聞いてもらえればと思います。
Web開発は長距離走、作り続け設計し続ける
皆さんご存知のとおり、Web開発というのは作りきりの納品スタイルでもない限り、基本は作り続けて、自分たちで作ったものを自分たちで長期的に運用するというような前提が多いと思います。
スタートアップの場合で、初期段階のビジネスや、それに付随するソフトウェアの構造のままで成長していくということはほとんどないでしょう。ビジネスが軌道に乗って、コードベースとしても、チームとしても長距離に耐え得るフォーメーションが求められるようになったときのために、少なくとも大事なところが後腐れしないようにとか、後からパーツを交換できるようにとか、長距離走をいくらかは想定されると思います。
今回は、開発や設計など長距離走と見て取れるものとWebの持続可能性みたいなキーワードを結んで話をしてみようというのが趣旨です。
まずは設計や開発の長距離走的な話として、自分なりにちょっと振り返ってみました。
まず設計の前提として、どういう形で長距離走ができればいいんだっけ、みたいなところですが、あくまで理想論なので、全部乗せみたいな感じになっているのはご容赦ください。
要は安心して快適に使える堅牢なUIがあって、それによって価値が提供され、コードベースも健全性が高く、タスクもちゃんと滞りなく回っていて、関わる人間が生き生きと活躍できていて、なるべく事業がうまくいっている状態を実現するための土台として設計をしたいということかなと思います。
謎かけではないのですが、皆さんが普段関わっているプロジェクトやプロダクト、サービスが、実際、長距離走に耐えられそうかどうかというのを思い浮かべてみてください。長距離走に耐えられない要因がコードベースではない可能性も全然あると思うので、いろいろかなと思います。
長距離走に耐えられなさそうな状態の具体例をいくつか挙げています。たとえばCSSを見ても、ある箇所のスタイルを変更したら、意図しない箇所の見た目が変わってしまうといった、副作用が起きやすくて変更容易性が損なわれている状態です。
またコンポーネントの設計や実装において、UIの一貫性がないとか、見た目や操作性、情報構造等がバラバラだったりすると、開発効率がそのうち落ちていくことは明白で、良くない状態であろうと考えられます。
なるべくそういうことが起きないように設計したいですね。実際、作り続けることが設計し続けることにつながってくるかなと思います。
開発者、設計者が取るべき長距離走戦略
長く走り続けるための設計を含むアプローチとしては、一般的にはリファクタリング、要素技術のアップデート、ライブラリーの交換のようなごく一般的なアプローチがあります。条件が良ければ、これだけで走りきるプロダクトもあると思います。
一方、Webアプリケーションは外的要因による変化に迫られることが多いので、戦略的な作り直しみたいなものを常にオプションとして検討する余地があるんじゃないかなとも思います。
実際、これらの2択のアプローチを普段からコツコツやれる範囲で解決するか、ガツッとリソースを投入してどうにかするかみたいなところがあると思いますが、そういう形で長距離を走り抜けるわけです。
そういういろいろなアプローチを取っていく中で、設計時に技術以外の影響要因としてこういうことが考えられるよねというのを挙げてみました。切り取り方によって他にもいろいろあると思うんですけど、一旦これで話したいと思います。
最初に、Googleがリリースしている「State of DevOps Report」というDevOps系のレポート文書の中で、サステナブルなデリバリーに関する言及があるんですけれども、2023年のレポートに燃え尽き症候群みたいな項目がありました。
SPACEフレームワークという開発生産性文脈のキーワードを思い浮かべる人もいると思いますが、関わる人間のウェルビーイングというのもインパクトを持っていると思います。ものすごく端的に言えば、燃え尽きてしまえば作業も何もなくて、仕事ができなくなる、もしくはすごいパフォーマンスが落ちます。維持するのに非常にエネルギーが必要な仕組みや、万全すぎるドキュメンテーション、いいコード品質を保つための良い習慣みたいなところも、高い目標を持ちすぎると開発文化の強要になって、本人の力量によっては燃え尽きを助長してしまいます。Googleのレポートの中でも、ドキュメンテーションの取り組みが行きすぎると、逆に燃え尽きのシグナルが上がるという関係性が示されています。人を見て妥協が生じるというのは、皆さんも経験上あるかと思います。
予算についてはこのスライドのとおりで、限られた時間で最大の成果を出すためには、普段から己を鍛えるしかないというところが正直あって、レベルを上げて物理で殴ろうみたいな話になってしまいます。ただ、時間的制約によって何かしらの調整があったとして、ベースラインにある実力次第で、結果がただの稚拙なアウトプットで終わってしまうのか、少なくともある程度コントローラブルな意図的な拙速という形で進められるのかが分かれるのではとも思います。
あとは環境変化です。Webアプリケーションでは外的な要因による変化を強いられる可能性が高いと考えています。ユーザーのニーズや、変化が早いと揶揄される技術環境、ビジネス的な提供価値、場合によってはデザインのトレンドとか、外部要因による変更が結構多く、特にUIに直結します。ビジネスのステージが進むにつれて、もともとモノリスなアプリケーションが普遍性の高いビジネスロジックを含むバックエンドと、運用で小刻みに変化するWebのフロントエンドアプリケーションに切り分けられるというのはよくある流れです。何にせよ、経年劣化の速さというのが、特にtoC領域では死活問題につながる課題の1つになると思います。
最後に、身も蓋もない話ではありますが社内政治です。目の前のアプリケーションには作り直しがいつかはあるだろうという前提で取り組む方が現実的ですが、実際にやるためには投資判断が必要なので、組織の意思決定にどのようにアクセスできるかで、制約がかかってくるイメージがあります。開発・設計のアプローチにおいては、先ほどのような経年劣化しやすいWebアプリケーション部分の責務をなるべく限定して小規模にとどめるとか、何かしら大規模な作り変えを行う時にも、うまく切断面を作って部分的な置き換えをしやすくするなど、あらかじめ作り直しの意思決定を軽量化するような開発者、設計者が取れる戦略というのもあるかなと思います。
選択肢を絞り込む指針としての「WSG」
それでもなお、設計する時に選び得る選択肢は非常に多いです。技術的な合理性以外で取捨選択の精度や説得力を高められる理由があれば知りたいと思っていました。
そこで1つヒントになりそうなものとして、「WSG」というWebの持続可能性について書かれたドキュメントを紹介します。
今年の4月にアップデートが入ったコミュニティグループドラフトみたいな感じなので、正式文書というステージではありませんが、持続可能性のための推奨事項のガイドラインです。内容が実装だけではなくて、配信上のプラクティスとかユーザー体験ビジネス設計セットなど多くを内包しすぎていて、どうやって収拾を付けるんだろうという感じなんですけれども、そんな文書がございます。関連する参考文書も人権とか倫理みたいな感じなので、そういうドキュメントだと思ってください。
このドキュメントと設計を結びつけて考えたのは、持続可能であるということは、本質的に効率的で長期的なサイクルを作るということなので、開発とか設計にも役立つ観点が得られるのではないかということです。ここから、設計に関わりそうな項目を抜粋して紹介していきます。開発における効率性、合理性とかなりシンクロするので、自信を持って、効率的な技術活用を設計しましょうということです。
この3.21は技術要件と持続可能性の目標を一致させましょうという項目です。要件に合わせて必要十分なソリューションを選びましょう、選ぶ上でより効率的で環境負荷が低いと思われるオプションを検討しましょうという話です。
達成することによるメリットは、テクノロジーを効率的に利用できれば、環境負荷を長期的に削減できる、無駄な複雑性を持ち込まないことで開発者の効率も性能も上がって排出量の削減にもなるなどです。変なテクノロジーを持ち込まない方がメンテコストが下がると書かれている一方で、効率的であることと、省エネであることの価値がしっかり示されているのかなと思います。内容の根拠となるドキュメントにもひたすらリンクが貼ってあるので、ある程度の裏付けを持ったドキュメントだと思います。
時間の関係で流しますけれども、2.17はデザインシステムに関する項目、
3.17は私が大好きな「依存環境を適切に管理しましょう」系の項目です。必要最小限の依存ツリーにとどめましょうと言っても、実際は大きめのフレームワークを1つ入れるだけで依存ツリーが絶望的に膨れ上がるので、コントロールできる気はあんまりしないんですけれども。
CDNも結局、全体に効率的な仕組みというのは当たり前ですが、エッジにコンテンツが配備されると、配信経路が十分に発達していない環境の人にもコンテンツが到達しやすくなるので、社会的に公平性が高まるという話も含まれています。
Edgeの高速化事例
最後に関連する話題として紹介します。EdgeのUIでJavaScriptフレームワークを利用している箇所があって、それがクライアントサイドレンダリングでJSに依存したHTML生成をしていたのを見直したら性能が向上したよという話です。正直、話だけ聞くと「そもそもの設計がミスマッチだったんじゃないの？」という感じはします。
ただ、ブラウザという特に多くのユーザーが利用するアプリケーションで、ローエンド系のスペックがそんなに高くないデバイスは76%の高速化、パフォーマンスに優れた改修を行えたということは、きっとエネルギーや社会的公平性に影響があるんじゃないかなと思った事例でした。
そのEdgeの記事では、チーム的な意見として、マークアップファースト、小さなバンドル、UIをレンダリングするようなJavaScriptコードの削減という方向に、世の中が進んでいくといいよねみたいなことが書いてあります。
実際、できる範囲で、複雑性とかコストがかかるアプローチを避けて通る方がエネルギー効率も表示のパフォーマンスも高いのは明らかなので、そのようにしていけるといいですねというところで、今日の話を終わろうと思います。
長距離走をし続けることと、持続可能性みたいなキーワードがWebに持ち込まれつつあるので、本質的な合理性とか効率性を評価する観点で見てみてもいいんじゃないかなというご紹介でした。以上です。
