よいUIデザインを生み出すためのチームづくりをコンウェイの法則から考える

こんにちは。Design Journal編集部です。突然ですが、皆さんは「コンウェイの法則」をご存知でしょうか？

コンウェイの法則は、コンピューター科学者のメルヴィン・コンウェイが提唱した法則です。

システムの開発には組織・メンバー同士の密なコミュニケーションが不可欠なので、関係性の遠い組織間を密に統合するようなシステムを開発するのは非常に難しい。よってシステムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう、というわけです。

コンウェイの法則が提唱された1968年は、1963年に世界初のGUI（グラフィカルユーザーインターフェース）であるSAGEというアメリカ空軍の防空管制システムが発明された5年後にあたります。「UIデザイン」というデザイン領域が存在することすらほとんど認知されていなかった時代でしょう。

ですが、コンウェイの法則は当然システムの一部であるUIデザインにも大きな影響を与えます。この記事では、良いUIデザインをつくるためにどんなチームを目指すべきか、またその中でUIデザイナーはどう動くべきか、といった指針を示したいと思います。

特に日本では今年『オブジェクト指向UIデザイン──使いやすいソフトウェアの原理』が発売され、「オブジェクト指向UIデザイン（OOUI）」という概念に注目が集まっています。その中で対比的に語られるのが、目指すべき「オブジェクトベース」なUIと、避けるべき「タスクベース」なUIです。実はこのタスクベースなUIが生まれてしまう背景にも、コンウェイの法則を見出すことが非常に多いのです。

Point1：機能やタスクごとの組織構造：「組織図を出荷」しないように注意する

コンウェイの法則で指摘されているように、組織構造の分断こそがシステムの設計においてもUIデザインにおいても、最もわかりやすい障壁になります。組織の構造をそのまま機能に割り当てることで、使いづらいシステムが出来上がってしまうというわけです。ちなみにこの状況は英語で「Ship the org chart（組織図を出荷する）」と言うそうです。

これをUIデザインの目線で分析すると、会社における部署はほとんどの場合オブジェクトではなく、機能やタスクごとに分かれています。そのため、部署の構成をそのまま機能として切り出すことで、自然とタスクベースのUIが生まれやすくなるのです。

例えば「顧客管理」というシステムを、営業とカスタマーサポートという2つの部署から考えてみます。それぞれの部署は別々のタスクを担当していますが、いずれも「顧客」という共通したオブジェクトが中心にあります。「顧客」というオブジェクトをベースにしてUIを設計し、そこに「営業」「顧客管理」といったタスクに必要な機能を配置すれば、最小限のコストで使いやすいシステムを構築できるでしょう。ですが部署間の連携がうまくいっていないと、重複するオブジェクトをそれぞれ全く別のシステムとして開発することになり、無駄が生じてしまうというわけです。

UIデザイナーとしては、それぞれの部署からの要望を別々の機能として捉えるのではなく、積極的に橋渡しをしていくとよいでしょう。

Point2：開発工程ごとの組織構造：チームの分かれ目を橋渡しする

マーケティング部署からデザイン部署、UXデザイナーからUIデザイナー、UIデザイナーからフロントエンドエンジニア、など、開発チームが分断されるケースです。このチームが分かれる工程では特にコミュニケーションのロスや誤った意思決定がされやすくなります。

一番の理想は分断が生じないように少数精鋭で密にコミュニケーションの取れるチームにすることですが、現実問題として、一定規模以上の組織ではどこかでチームが分かれることは避けられません。ここでは、その中でも特によくあるケースをいくつか挙げてみます。

マーケティング→デザインの間に溝があるケース

マーケティング部署が市場調査やアナリティクス、ABテストなどから算出された数字やロジックを元にUIに改善要望を出し、デザイナーがその背景や意図を理解しないままUIに反映させてしまうケースです。局所最適を繰り返すことでUIに一貫性が失われ、長期的に見たとき、UXが損なわれることになりかねません。マーケターとデザイナーが共同でその数字やロジックの背景を深堀りしていく必要があるでしょう。

UXデザイナー→UIデザイナーの間に溝があるケース

UXデザイナーがリサーチに基づいて課題を起票し、UIデザイナーがそれをUIに落とし込む場合にも落とし穴があります。UXデザイナーはユーザーの「行動」や「体験」といった要素に注目するため、どうしてもオブジェクトよりタスクに関心が集まりやすくなります。たとえばカスタマージャーニーマップのようなフレームワークは「タスク」で整理されています。UIデザイナーがリサーチ結果の真意を理解せずにUIに落とし込むことで、タスクベースのUIが生まれる可能性があるのです。本来はUXデザイナーとUIデザイナーが相談しながらリサーチ結果におけるタスクをオブジェクトに変換する作業が必要なのですが、作業を渡すタイミングで必要な情報が抜け落ちてしまうパターンです。

UIデザイナー→エンジニアの間に溝があるケース

非常によく聞く話ですが、デザインが実装を考慮できていない、逆に実装がデザインの意図を汲み取れていないなどのケースです。デザイナーが実装を考慮していないUIをつくることでエンジニアが実装に苦労したり、逆にデザイナーがエンジニアに伝わるようにデザインカンプや資料を作り込むため必要以上に時間がかかるようなことが起こります。

UIデザイナーは自分の所属する開発チームの構成をよく理解して、どこでこういった分断が起こりやすいか注意する必要があります。またその分断を埋められるよう、積極的に情報を取りに行ったり、他の職種のメンバーを巻き込んだ議論を投げかけるとよいでしょう。

Point3：プロジェクトメンバーの心理的安全性を確保する

あなたの所属するチームは、メンバー全員がUIについて安心して意見できる環境になっているでしょうか？ UIデザインは間違った意思決定をしやすい領域でもあります。会議で思いついたアイデアを勢いで決定してしまったり、チーム外のステークホルダーからの要望を深く考えずにそのまま取り入れてしまったり、などなど。そうして生まれた間違いを「やっぱりこれやめませんか？」「こっちのほうが良くないですか？」と言えるチームづくりが重要です。

こういった環境を作り出すために、UIデザイナーはデザインのプロセスを開示したり、各場面で非デザイナーから意見を聞いたり、といったコミュニケーションを積極的にとっていくことが重要です。特に非デザイナーのメンバーがデザインに対する苦手意識があったり、「デザインはデザイナーが考えるもの」と距離を置かれているように感じたら、UIデザインはチーム全員でつくっていくものだということを理解してもらうような努力が必要になるでしょう。

FigmaやMiroのようなオンラインのコラボレーションツールを使い、チームメンバーがいつでもデザインの過程を見られるようにしておくことも非常に効果的です。

Point4：使いやすいUIを作ったメンバーを正しく評価する

UIデザインは地味で目立たない存在です。その上、使い慣れたUIほど使いやすいため、よいUIには大抵の場合既視感があります。それを作ったデザイナーが適切な評価を受けられないような組織では、奇抜で斬新なUIを生み出さなければならないという歪な圧力が発生しかねません。結果として開発コストが高くて使いづらい、誰も幸せにならないUIが生まれてしまうかもしれません。こういったことを避けるためにも、たとえ見た目が地味でもよいUIを作ったデザイナーが適切に評価されるような組織文化と評価制度を整備していくことが重要です。

UIデザイナーにとっては、まずはユーザーにとって使いやすいUIをつくることが全ての基本になります。その上で、必要以上に斬新なUIを求められる場合は、本当に使いやすいUIは使い慣れたものであることを理解してもらうよう、丁寧に説明していきましょう。

特に企業やサービスの世界観、ブランドイメージといったものをUIデザインで表現しようとすると、不自然なUIになりやすくなります。こういったイメージはUIだけでなく、コンテンツ、Webサイト、広告などを使って総合的に表現すべきものだということを理解する必要があります。

また、残念ながらチームメンバーの誰かが組織で評価を得るために斬新なUIデザインを発明してアピールしようとすることがあります。特に開発に関わるメンバーが多かったり、複数の外部組織が参加して力関係が怪しかったりすると、残念な動きが生まれてしまいやすくなります。こういった政治にUIデザインを利用されないよう、ユーザーの立場から使いやすいUIを守っていくことも時には必要になるでしょう。

Point5：UIを適切に評価できるような承認プロセスをとる

どのようにUIデザインが承認されていくかも組織によって異なります。前述の「使いやすいUIを作ったメンバーを正しく評価する」と重複するところも多いですが、よいUIを適切に評価できるような承認プロセスを意識する必要があります。

例えば意思決定にプレゼンが重要視される組織では、短時間のプレゼンにおけるわかりやすさが重視されやすくなります。ですがUIは広告のようにひと目でインパクトを伝えるデザインとは異なるため、短時間のプレゼンで使いやすさを伝えることは難しいでしょう。特にプレゼンは基本的にシングルラインの物語（ナラティブ）の形をとるため、オブジェクトベースのUIよりタスクベースのUIのほうが伝わりやすいという課題があります。OOUIはユーザーが予め決められた手続きではなく自由な順序で物事を考え、行動の決定を遅延することができるため、プレゼンでは冗長に感じられやすいのです。

また、本当の意味でUIを評価するには実際に動くシステムとして開発するしかありません。開発する前に動きのない「絵」の状態でUIを評価しようとすると、判断を誤る可能性が高まります。「絵」としては魅力的だが実際のUIとして操作すると派手すぎるとか、前後の画面との整合性が取れていないといった事態が起こりかねません。そのため、開発前でもプロトタイプツールを使ってなるべく実際の挙動に近い体験ができるようにする、リアリティの高いコンテンツやデータを用意して1画面でも複数のパターンを検証するなどの工夫が必要になってきます。

このようにして、承認プロセスのなかには実際の使いやすさとは無関係な「映え」が優先されやすくなる罠が各所に潜んでいます。

UIデザイナーは自分の作るUIデザインがどのような承認プロセスを経てリリースされるのかを把握し、誰よりも詳しくなりましょう。誰が、何を見て、どのような順番で承認するのか、承認者はこのサービスのことをどれくらい知っていて、どんな人なのか。その上で、望ましくないプロセスがあれば、それを変えられないかチームに働きかけてみましょう。とはいえ、大きなチームでは各企業の文化や制度から避けられないことも多いでしょう。そのような場合は、その承認プロセスにはどんな問題があり、どんな間違いを犯しやすいのか、といった懸念をチーム全体で共有するとよいでしょう。

Point6: ユーザーと開発チーム、アプリケーションの三角関係を意識する

ここまで主にシステムをつくるチーム内の話をしてきましたが、忘れてはいけないのが「ユーザー」と開発チーム、アプリケーションの関係性です。アプリケーションは開発チームが作りユーザーに提供する商品であり、我が子のように大切にしている人もいるでしょう。それ自体は良いことですが、それと同じくらい重要なのが、アプリケーションとそのUIはユーザーの身体と脳の延長である、という見方です。

ここで、アプリのプロフィール画面でユーザー名に「さん付け」する、というアイデアを考えてみましょう。このアイデアは一見丁寧なユーザー体験を作り出そうとしているように見えます。ですが、あなたは自分の手帳の名前欄に「さん付け」をするでしょうか？ この背景には、開発チームの中に「アプリはそれを開発している自分たちのものだ」という意識が潜んでいる可能性があります。アプリをユーザーのものだと考えていたら出てこないアイデアなのです。

こういったすれ違いは、特にtoCのサービス業で起こりやすいものです。ユーザーを大切にする意識自体は大切ですが、過剰な「お客様」扱いはアプリケーションの所有権をユーザーから奪うことに繋がります。またユーザーを「消費者」として位置づけることで、ユーザー自身が創造的な行動を生み出す可能性を奪っている可能性はないでしょうか？

UIデザイナーとしては、特にチーム内でユーザーを「お客様」扱いする考え方が強い場合にタスクベースのUIを作り出していないか注意すると良いでしょう。ユーザーは大抵の場合、いちいち次にやることをシステムに指示されたくありません。また過度に説明のポップアップやダイアログ使うことでかえって使いづらくなるというのもよくある話です。

まとめ　組織が抱える課題を分析し、チーム全体に共有して取り組んでいく

完璧に理想的な夢のチームでない限り、組織は上記のような課題をなにかしら抱えています。

UIデザイナーとして重要なのはこういった組織構造を分析することで問題の発生しやすい箇所を見極め、それをチームメンバーと共有することです。その上で対策を整え、よいUIを作ることのできる組織をつくっていきましょう。ほとんどの問題はUIデザイナーだけで解決できるものではありません。あまり一人で抱え込みすぎないも大切です。自分にできることから始めてみましょう。

• #サービスデザイン
• #新規事業
• #デザイン
• #ディレクション
• #プロジェクト・マネジメント
• #リサーチ
• #R&D
• #Tips
• #デザイナー