BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Paypalは企業レベルでのUIコンポーネント共有をいかに実現したのか

Paypalは企業レベルでのUIコンポーネント共有をいかに実現したのか

ブックマーク

原文(投稿日:2020/06/08)へのリンク

PaypalのエンジニアであるDong Chen氏は先頃、企業レベルのコンポーネント共有における課題と、その課題に対処するためにPaypalが講じたソリューションについて講演した。

氏は問題を次のように要約している。

[コンポーネントベースの] Webフレームワークはコンポーネント共有を簡単にしてくれますが、何もせずに共有できる訳ではなく、課題は依然としてあります。特に企業レベルでは、企業内のさまざまなプロダクトに関わっているチーム間の調整という、難しい問題が残っているのです。現実には、他のチームが開発したコンポーネントを見つけることでさえ大変なのです。

コンポーネントの再利用には大きなメリットがある。よく設計された高品質のコンポーネントの再利用は、その時点において、そのチームのスキルや時間、リソースでは再現できない可能性のある機能や動作、パフォーマンスに関するベースラインを提供してくれる。ローカライゼーションや国際化、アクセシビリティなどは、チームがまだ習得できていない可能性のある、特別な知識を活用した設計のメリットを享受できる、重要な機能である。

さらに、コンポーネントを再利用すれば、開発するアプリケーションのより大きな動作に集中することが可能になる。Chen氏の参照した調査報告書によると、40~81パーセントのエンジニアリング時間を節約できるという。

その一方で、再利用可能なコンポーネントの設計と実装にはコストが必要だ。Butler W.Lampson氏は、書籍"Computer Systems: Theory, Technology, and Applications"の1章を、設計コストに関する見解に割いている。

設計には費用が必要です。再利用可能な設計は特に高価です。システムに対して十分に設計されたクリーンなインターフェースを持つモジュールの構築には、運を天に任せてコードを書く場合に比べて、1/2~2倍のコストが必要になります。しかし、再利用可能なコンポーネントには、そのような優れたモジュールのさらに3~5倍のコストを要するのです。増加したコストは汎用化 […]、単純化 […]、カスタマイズ […]、テスト […]、資料の作成 […]、安定性 […]といった部分で使用されます。

Lampson氏はさらに、再利用可能コンポーネントのプロジェクトが失敗する理由にも言及し、主要なものを3つ挙げている。それは、ビジネスモデルの欠如であり、コンポーネントの理解と利用に関わるコストであり、コンポーネントが干渉するインターフェースを持つという事実である。

Chen氏はさらに、発見、共有、品質基準、コミュニティのコラボレーションという、4つの側面を付け加えている。氏の説明によると、PaypalのSlackチャネルで最も多い質問は、既存のコンポーネントがどこにあるのか、そのコンポーネントがニーズに合うかどうかをどうやって判断できるのか、ドキュメントは最新か、といったものだという。

次にChen氏は、Paypalが採用しているソリューションについて説明した。

コンポーネント共有に関するPaypalのソリューション
(出典: Chen氏のブログ記事)

Paypalでは、使いやすさやカスタマイズ機能、コンポーネント開発者に提供するコントロールの面から、コンポーネントの構築と提供にコンポーネントプレイグラウンド(Storybookなどのような)を使用することにした。

Paypalでは、Component Explorer(自社開発ソリューション)を使用して、利用可能なコンポーネントをドキュメント付きでインタラクティブに表示すると同時に、バージョン管理と品質の担保を行っている。品質の指標としてコンポーネントの利用数を計測したり、コンポーネント作者に評価を返送することも可能である。注目すべきなのは、Component Explorerが、タグ(チェックアウト、通貨など)によって問い合わせ可能な集中型のホスティングプラットフォームを適用することによって、コンポーネントの検索を容易にしている点だ。

PaypalのCX Component Explorer
(出典: Chen氏のブログ記事)

誰でもコンポーネントを掲載可能なように、コンポーネントの共有は分散アプローチに従っている。一部の企業で採用しているような、システム設計と再利用可能なコンポーネントの提供を担当する専門チームによる集中型アプローチとは対照的だ。ある開発者は、自身の会社が集中型の共有システムを採用している理由について、次のようにTwitterで説明している

当社の設計システムであるIRISが、私たちのコンポーネントライブラリです。当社では、新たに発足したチームがIRISを使って、あるプロダクトのPoCを3週間で構築しました。他の方法ならば、少なくとも3か月はかかっていたでしょう。
それに加えて、マイクロフロントエンドに重点を置いたアーキテクチャ ... UIの一貫性においては重要な課題です。[…]
最後に。[...] アクセシビリティには一貫性のある、熟考されたHTMLマークアップと、思慮のあるARIA(Accessible Rich Internet Applications)拡張が必要です。専門チームにはこの知見がありますが、一般的にアプリケーションチームにはありません。[...] 検索に関しては、フロントエンドに関するミートアップを隔週で実施して、開発中や完成したコンポーネントについて話し合っています。

別の開発者は、自分たちの会社の事情として、使用しているスタックが多様であるために共有が妨げられている、と嘆いている。

残念なことに、私の会社ではコンポーネントはあまり共有されていません[...] これまで話題に上がっていませんでしたが、私たちの課題は技術スタックの違い(React、Angularなど)にあります。同じような問題はないのでしょうか — 全員がReactを使っているのですか?

これに対してChen氏は、さまざまなUIフレームワークを扱うためにStorybook機能を活用して、技術スタック間でのコンポーネント使用に役立てている、と回答した上で、Webpack 5にあるModule Federationのペンディングリリースも有効ではないか、と主張した。

Paypalが発表したソリューションは、現時点ではオープンソースにはなっていない。これについてChen氏は、コンポーネント共有のベストプラクティスを確立する上で、まだ調査段階であるからだ、と説明している。コンポーネント共有におけるChen氏のチームのプラクティスに関しては、Twitter上で意見交換することが可能だ。Mediumにあるブログ記事には、より詳細な技術的説明とイラストレーションが掲載されている。

この記事に星をつける

おすすめ度
スタイル

BT