チームラボでは、アート展示などを行う「アート」と、クライアントワークを行う「ソリューション」という、大きく2つの事業を運営しています。私はソリューション事業のUI/UXデザイナーとして、様々なプロジェクトに携わってきました。

チームラボが手がける2つの事業

その中で、ソリューション事業における案件を横断して活用可能なコンポーネントやモジュールを体系化したデザインシステム (= teamLab Design System )を作れないかとチャレンジしたことがあります。

teamLab Design Systemの構想について

結論として、チームラボが目指すクオリティを追求するためには、そのようなデザインシステムを作っても十分な効果が得られないと判断し、より根本的なデザインの思考プロセスを体系化していくことを目指しています。

チームラボが取り組んでいる思考プロセスの体系化の概要

このような判断をしている背景や、どのような狙いで思考の体系化に取り組んでいるのかについてまとめていきたいと思います。

チームラボといえば、チームラボプラネッツをはじめとした「アートを手がける集団」というイメージが強いかもしれませんが、実は事業規模や関わるメンバー数もソリューションのほうがアートを上回っています。

ソリューション事業におけるプロジェクト例
https://www.team-lab.com/works/

これまで金融や不動産、飲食からスポーツなど、多岐にわたる業界・業種のプロジェクトに携わっており、構想策定から企画、デザインから開発、リリース後の運用までワンストップで手がけることが、私たちの特徴です。

代表的な実績のひとつが、りそな銀行様のアプリです。銀行店舗やATMで行われていた諸手続き機能をアプリに移行するにあたり、「使っていて気持ちいいバンキングアプリとは何か」のUIUXを徹底的にこだわって開発。その結果、現在ではアプリの利用者がATM・店舗の利用者数の2倍にまで増える実績を生み出すことができています。 https://www.team-lab.com/resonasmartapp/

また、チームラボ全体の約1100名のメンバーの内、700名がソリューション事業に所属しており、今まで手がけたプロジェクト数は延べ100件以上。制作したアプリは合計1.5億ダウンロードを超えるほどまでに成長しています。

ソリューション事業の人員数や実績

その中で、実はソリューション事業に所属するデザイナーは少数です。全体から見ると3%に満たない人員数で数多くの案件を手がけ、クオリティも妥協しないとなると、どうしてもハードワークになりやすくなってしまいます。

さらに当時(2018年頃)は、案件が増えていく一方で、品質のばらつきや、レビューコストの増加などの問題も見られていました。

このような状況の中で、効率化や品質の標準化に対する必要性が高まり、社内でもデザインシステムの重要性が説かれるようになっていきました。

ソリューション事業において、デザインシステムの必要性が高まったきっかけ

当時はSketchやFigmaなどのUIデザインツールが台頭し、デザイン業務のシステム化という概念も浸透してきていました。

さらに、バックエンドのプログラムについては、例えばレコメンドエンジン・検索エンジン・自動画像圧縮機能などをパッケージ化し、案件をまたいだ共通化を実現しているケースも社内で生まれていました。

そのため、デザインも何かしらのシステムに落とし込めないか、これによって効率化を実現できないかといった仮説 (=teamLab Design System構想 )が生まれました。

このような背景をもとに、実際に作成・運用してみるという試みを始めることになるのですが、早い段階で「teamLab Design Systemは、できないし、やるべきではない」という結論に至りました。

案件を横断して活用できるデザインシステムを運用しようとすると、どうしてもチームラボとして目指したいクオリティを満たすことが難しいと考えたからです。

例えば、ワイン販売を行うエノテカ様の「エノテカ・オンライン」と、キューピー様の「キユーミー」の開発にはteamLabが携わっています。

どちらもECサイトですが、エノテカ・オンラインでは、ワインをこよなく愛する方や、これからワインの世界に踏み込みたい方への体験の配慮をUXに落とし込みたい。キユーミーでは、野菜をより美味しく手軽にいただける工夫を知ってもらいたい。

それぞれで異なる思想が根底にあるため、例えば商品詳細のレイアウトや購入フローの細かいオプションなど、似ている部分はあっても、全く同じものにはなりません

サービス構造が似ていても、思想が異なれば求められるUIの要件も異なる

Atomic Designを引き合いに出すと、パーツの共通化ができるのは「Lv.1 Atoms」ぐらいまでで、それ以上のレイヤーでは、エノテカ・オンラインとキユーミーでの例のように、プロジェクトの性質が色濃く反映され、異なるものになっていきます。

プロジェクトを横断して共通化できるパーツは、想像以上に少ない

デザインをパッケージ化することで、より早く・安くクライアントの皆様にUIを届けることができるかもしれません。しかし、パッケージ化してしまうことで「 デザインシステムの仕様だから対応できない」「とりあえずこのUIパーツを使っておくと良いか 」といった状況を招いてしまいかねません。

細かな違いに見えて、チームラボとして目指したいクオリティを断念せざるを得ない状況や、デザイナーとしてのクリエイティビティを発揮しづらい状況につながってしまうのではないかと考えました。

このような背景から、案件を横断して活用可能な汎用的なデザインシステムを構築するというアプローチは取らないという判断をしました。

案件ごとに、最適なデザインを0→1で作り続けるしかない。つまり、あえて車輪の再発明を続けていこうという意思決定をしました。もちろん、一つ一つのデザインシステムを作る工程自体は効率化を図っていますが、それらについては各社で工夫されていることと近しいものかと思います。

案件ごとに最適なデザインを0→1で作り続ける

案件ごとに0→1でデザインシステムを構築するアプローチを選択しつつも、高いクオリティで、メンバー全員が本質的なソリューションを提供するための仕組みづくりへのチャレンジを続けています。

その一つが、デザインにおける思考の体系化です。

思考の体系化とは、UIやUXを設計する際に、何をどういう観点で、どの順番で思考し、どうレビューしていくのかを整理し、メンバー間でズレがないようにするというものです。ツールのように形に落とし込めるものではなく、システムというよりカルチャーに近いものかもしれません。

チームラボでは、「原則・パターン・設計・ナレッジ化」という4つのプロセスで体系化しています。

チームラボが取り組んでいる思考プロセスの体系化の概要

原則とはデザインを行う上での思考の出発点です。つまり「ユーザーのための体験を考える」ことです。クライアントと共につくるサービスがどのようにユーザーに価値ある体験を提供できるかを考えます。

そして、原則から考えた価値を、「ユーザーの欲求」「を満たす手段」「を使う時に考えること」といった思考パターンを通して具体的に分解していきます。

その後、体験・機能・情報・レイアウト・UIなど、より具体的なサービス設計に落とし込んでいきます。体験からUIのレイヤーまで、ユーザーの価値を提供するためのロジックが通っているかどうかを常に考えていきます。

このような思考の流れは、UIUXデザインに携わる方にとって、当たり前の話のように感じられるかもしれません。

しかし、常に高い水準でこのような思考を辿ってデザインすることや、多くのメンバーが多様なステークホルダーと協力する中で、同じ思考を共有することはなかなか難しいことだと思います。

だからこそ、当たり前のように感じられる話を体系化し、根付かせ、例えばレビューの場で常にこの思考の流れに沿って会話できるようにすることで、基礎の水準を高めていくことが大切だと考えています。

そして、その中で得た知見をナレッジとして組織に還元し、ナレッジを積極的に活用することまでをひとつのプロセスとして体系化しています。

例えば以前に、2023年4月に開校した安平町 早来学園様でのICT空間設計に携わらせていただきました。

建物もコンセプトも新しく作られるこの学校では「みんなの学校」「自分が世界と出会う場所」が大きなテーマとなっていました。それに対し、「学校を、地域住民にも開かれた場所にし、地域と学校が一体となる空間」を、ICTを活用して実現しました。

その中で、アウトプットの一つとして、施設を検索・予約できるWebサイトとその管理画面、そして施設に設置して利用できるタブレットを開発しています。

このアウトプットに至る背景には、それ以前にチームラボが携わった施設利用におけるUXソリューションの経験があります。具体的には、エイベックス様での入館申請の支援と会議室予約の管理システムです。

実はこの2つのプロジェクトは全く別の担当者によって推進されていましたが、過去にエイベックス様でのナレッジがあることが早来学園メンバーに伝達され、体験からUIまでの思考に役立てられました。

クライアントの思いや課題が異なっても、本質的なソリューションは普遍的で、似てくることもあります。こういったナレッジを蓄積し、活かすことで、より早く、より大きな価値を届けることに集中しやすくなっていくと考えています。

このような思考プロセスは、ただ単にフレームワークとして共有し、中身を埋めていくように使えば良いというものではありません。個人の思考特性もありますし、ドキュメントにまとめれば定着するというものでもありません。

つまり、一朝一夕で実現できるものではなく、日々のコミュニケーションやレビュー、インプットなど、当たり前のように行っている業務の中で、鍛錬し続けるしかないと考えています。

その中でも、チームラボの中で重視していることが2つあります。

1つがレビュー文化です。チームラボでは、高頻度でレビューの場を持ちます。そこでは、前述の思考プロセスに沿ってレビューをするとともに、提供したい品質に達しているかジャッジを繰り返します。こうしたメンバー同士のレビューとジャッジを重ねることで、個々の認識がすり合い、チームでより良い品質を追求できるようになると考えています。

もう1つがナレッジ共有文化です。チームラボはこれまでに100以上のプロジェクトを手がけており、前述の通り、各プロジェクトでのナレッジを蓄積・共有することで、本質的なソリューションを提供する手がかりにしています。高品質な実績は、基準値をつくります。1つ1つのプロジェクトで高い品質を追求し、それらを参照することでより良いプロセスが浸透していく。こうしたサイクルを大切にしています。

ここまで、チームラボのソリューション事業におけるデザインシステムへの考え方と、これまで取り組んできたことについてまとめてきました。

案件を横断して汎用的に活用できるコンポーネントやモジュールを体系化すること以上に、チームラボが目指すクオリティを実現するためには、デザインの思考そのものを体系化することが重要 だと考えています。(もちろん、今後状況が変われば、そのアプローチが変わる可能性もあります)

そこで、チームラボで挑戦しているのが、今回まとめたような思考の体系化です。

一般的に想起されるデザインシステムのイメージと異なるかもしれませんが、「ユーザーのための体験を考えて実装する」という基本的な思考プロセスを、チームラボらしい水準で、メンバー全員が実践できるように体系化しようという試みであると考えると、これもデザインシステムだと考えています。

また、一見すると地味な試みに見えるかと思いますが、表面的なツールにこだわらず、トレンドやデバイスが今後変わっても、「恒久的に活用できるデザインプロセスを育てる」ための試みであると捉えれば、非常に有益だと思っています。

一朝一夕で身につくものではなく、組織全体で高い基準を目指すには相応の難しさがありますが、それでも私たちにとって必要な取り組みであり、チームラボとして高いクオリティのデザインを提供し続けるためにも重要で、チャレンジし続ける価値があると考えています。

このデザイン組織をもっと知る