オープンソースで提供されているWebデザインシステムとCMS構築の相性について考える

デザインシステムとは、企業やブランド・プロダクトなど、とある対象のアイデンティティやタグラインを基にロゴタイプ、シンボルマークに関する利用規定を中心に、カラー、フォントなどの基本デザイン要素を体系化することです。語弊を恐れず言えば、上位概念としてのルールブックとも言えるかもしれません。

Webやアプリ開発においては、今までのデザインシステムの概念にない”動きに対する反応”(インタラクションデザイン)の定義が必要だったり、ボタンのように必ずと言っていいほど使用するエレメント(部品)があったりと、従来のデザインシステムで体系化された基本デザインだけではカバー出来ない実態があります。そこを補うために開発されたのがWebデザインシステムです。

Webデザインシステム構築の流れはここ数年で増加傾向にあり、特に海外での動向は顕著です。民間企業だけでなくアメリカでは政府が2015年にUnited States Web Design System(USWDS)を公開するなど早くからその動きが見られていました。近年、Webガバナンス構築におけるデザイン領域のアプローチとしてもオープンソースのWebデザインシステムを活用するケースが増えてきています。

例を挙げると、日本でもすっかり定着したMaterial Design(マテリアルデザイン)を利用すればガバナンスを保ちつつ、ユーザーが慣れ親しんだUX/UIを提供できます。また、周辺システムにSharePointなどのMicrosoft製プラットフォームが存在するWebサイトを構築、運用する場合にはOffice UI Fabric(オフィス UI ファブリック)を利用することでデザインとして調和が取れたシステム構成が実現できたりと非常に有用性が高いです。    

グローバルにおけるWebデザインシステムのトレンドは?

グローバル目線のトレンドは、積極的にデザインシステムを取り入れている傾向にあります。この点は日本よりもかなり先を行っていると言えそうです。

先日、海外のデザインエージェンシーのお話しを伺う機会がありましたが、IBMのCarbon Design System(カーボン デザイン システム)ベースでの考えでした。Carbon Design Systemを利用する目的にガバナンス構築も当然含まれますが、アジャイル開発のイテレーションで利用するプロトタイプもCarbon Design Systemで対応するという内容には正直驚きました。

日本では、実際のインタラクションを再現できないプロトタイプツールでイテレーションを行うケースが多いです。一方、海外では、プロダクトのビジュアル・インタラクション両面のデザイン表現を重視しています。この違いは、海外ではデザインシステムを重要だと認識し、相応のコストをかけているからだということが読み取れます。受け取る側としては、海外の方がより優れていると感じることでしょう。    

IBMのCarbon Design System(カーボン デザイン システムより

Webデザインシステムが時に仇になるケースも

ここから「オープンソースWebデザインシステムとCMS構築の相性について考える」ことの本題に入ります。Webサイト構築を進める上では、時としてWebデザインシステムが邪魔をする場合があるのです。それはインタラクションデザインの不具合です。

これは主に動的CMSを導入するケースに起こりやすい事象であり、その理由は、動的CMSが多機能ゆえフロントエンド上の動作に影響を及ぼすことがあるのです。 不具合と思しき事象が発生する理由は以下の2点です。  

  1. CMSが保有するJavascript、jQueryとのコンフリクト
  2. 多機能起因によるパフォーマンス低下(読み込み遅延)

Webデザインシステムには多くのインタラクションが定義されており、優れた機能を提供してくれます。その一方で、全てWebデザインシステム通りに再現しようとした場合に前述の問題に当たってしまうケースが多いのです。

これは、特にSIerとだけプロジェクトを進行してしまうとよく起こります。なぜならSIerの得意領域がこの範囲になく、結果として原因に気付かず、簡単に修復ができないようなタイミングである開発完了後にようやく問題が発覚するというケースがあるからです。

その為、プロジェクトを完遂するために必要なことは、プロジェクト初期からSIer側にCMSのフロントエンドに関する有識者を巻き込むことです。その有識者がプロジェクト全体を通じ、結果としてフロントエンド領域を依頼する制作会社にCMSの仕様(制約)を共有することができれば、こういったケースを予防することができるといえるでしょう。

但し、、、中々SIer側にこういった人材がいることは稀なため、ある意味外部の協力を仰ぐ必要が出てくるかもしれません。   

編集画面側への配慮も必要  

インタラクションの影響は編集画面側にも起こり得るケースがあります。

エンタープライズ向けCMSには、公開されているWebサイトの見た目のままで画像やテキストの変更ができる便利な編集機能があります。しかし、この見たままで編集できる機能が『動的』であるために注意が必要です。

一例を挙げるとメインビジュアルに利用するカルーセルです。公開画面側ではスライドするはずのカルーセルが編集画面ではスライドせず1枚しか編集ができないなどの不具合に手こずるケースがあります。エンタープライズCMSを導入することで、Webサイト更新を簡単に運用できる未来をイメージしていたのに、出来上がってみたら全然簡単運用できなかった、という失意を残したままプロジェクトを終えてしまうケースもあります。  

お互いの”多機能さ”という落とし穴

スクラッチによる開発・構築であれば要件の実現に向かってプロジェクトを進行するだけですが、CMS導入という形で開発・構築する場合は、良いWebデザインシステムを届けるために念頭に置かなければいけないことがあります。

それは「マニュアルには存在しない、目に見えないCMSの制約があること」です。CMSは日々進化し、どんどん他機能になっていきます。その過程で入念なテストは行われますが、世の中に存在する無数のコーディングの癖に合わせたテストは現実的に不可能です。CMSとデザインシステムの機能と機能のぶつかり合いは実際の構築段階で検証するしかないのです。

デザインシステムとCMSの相性を確かめるフロントエンドディレクションの重要性

思い描いていた通りのデザインシステムを実現するためのポイントはいくつかあります。

「制約(ソフト)面」

  1. 『デザインシステムの完全準拠にこだわり過ぎない』=『例外ルールを設けた独自のデザインシステム』を定義する
  2. (ある種諦めて)インタラクションデザインの要件を満たせる(静的)CMSを選定する

「体制面」

  1. 構築するCMSの有識者アサインを前提とすること
  2. フロントエンドディレクション可能なメンバーが在籍しているSIerをパートナーとすること

デザイン要件にインタラクションの”滑らかさ”を完全に求める場合は静的なCMSがマッチします。要件を叶える上でCMSが動的になる場合は、デザインシステムの一部の適用を避けるかCMSの一部機能を諦めることで解消することになります。この課題解決策を提示できるパートナー、すなわち機能と機能のぶつかり合いを経験し、ナレッジを保有しているパートナー選定が非常に重要になります。

デザインシステムを利用してガバナンス構築をおこなう場合はフロントエンドディレクションが重要です。パートナー(SIer)のケイパビリティとしてフロントエンド領域を切り離してスコーピングするケースが多いため、この領域まで一貫して対応できると手を挙げてくれるパートナーであれば安心でしょう。逆に、パートナーを選択する時点では、この領域をもカバーできるパートナーか、を入念に確認する必要があるでしょう。

あわせて読みたい記事