OOUI のトレーニングができるまで

より良いデザインを生むために

私はこれまでデザインコンサルティングを行う中で「一度出来上がったものを変えるには多大な労力がかかる」と感じてきました。

同じような状況に何度か遭遇するうちに徐々に「トレーニングプログラムが必要かもしれない」と思うようになりました。

トレーニングというのは少し遠回りなものに感じましたが、より良いデザインを生むための土台を作ってみるチャレンジを始めることにしました。

出来上がったのはミニマムなトレーニング、「OOUI トレーニング」ですが今回はその裏側をご紹介します。

背景

世の中は新規のプロダクトよりも既存のプロダクトが多く、私もいくつかの既存アプリケーションの改善の支援に関わることがありました。その中で様々な理由で新しく作る方が負荷が少ないと感じることがありました。

デザインチームのマインドや知識が既存アプリケーションを前提としているとゼロから OOUI のデザインをする場合に比べて、変化を伴う分コストが大きくなります。これは OOUI に限った話ではなくデザイン全般に言えることだと思いますが、OOUI は土台となるストラクチャーを大きく変更するケースが多いため変化が大きくなります。

進行中のプロジェクトであれば既存のデザインプロセスを踏襲する力学が働くのは自然なことです。

そのため変化の下準備としてのエクスパートレビューやユーザービリティテスト、デザインガイドラインの作成を行う形で推進者を支援することもありました。

デザインをオブジェクトベースにするには、既存プロダクトであれば長期的に理想像へ近づけるようにするか、新しくオブジェクトベースで作るかのどちらかしかありません。

前者が堅実な取り組みに聞こえますが、実際のところは後者のようにタスクベースUIの混乱が極まって行き詰まりを感じ、それをきっかけに大胆にオブジェクトベースに考えなおすというケースも多いです。

そういったタスクベースUIの行き詰まりも最初からオブジェクトベースUIを目指していれば避けられたことかも知れないと感じていました。

このような経験から、できるだけコストをかけずにやるためにスタート以前に共通したマインドを持つことの必要性を感じるようになりました。（これは多様性を低下させるということではなくポケットの中にやり方の１つとして、皆が持っておくと良いものがあると考えたのでした。）

それも長期的な視点に立てば、1プロジェクトのメンバーだけでなくデザインチームで基礎知識をつけておくことが大事であると考えました。

本来は走りながら吸収できるチームが理想ではありますが、スコープ設定からしてずれてしまっている場合はどうにもならないこともあります。

既存のアプリケーションのプロジェクトの中だけで行う場合、エバンジェリスト的な立ち位置から始めたり、ボトムアップ的なアプローチで徐々に理解を得たりする方法は効果はありますがプロジェクトのスコープとずれていれば常に負荷ががかかります。

共通認識として存在しない話をプロジェクトの最中にし始めても耳を貸してくれる人がいるとは限りません。

一方トップダウンでやれるかというと組織というのはそう単純でもなく、現場は現場で実行を伴う決断をしなければならないので、すぐに変わるものではありません。そうこうしているうちに逆にトップが変わるなんてこともあります。

（ただしこういった現象はプロジェクト単位ではネガティブなことかもしれませんが、社会全体からするとフットワークの軽い小さなチームが変化に対応できることを示唆しているので、経済活動のゲームとしてはある種健全な側面ともいえるかもしれません。とはいえ変化のできない大きなチームが独占的に公共的なサービスを提供してる場合は頭の痛い問題です。）

さて、こういったコストは組織的には顕在化しないものの、それを進めようとする推進者個人に大きく負荷としてのしかかってくるのを度々目にしてきました。長期的には組織視点においてもタスクベースUIの量産という形で負債となって数年後に現れるでしょう。

困ったことにこういった問題に特効薬はありません。

マインドの違いから人材の流出も起こるため、推進できるところは推進できて、推進できないところは推進できないという二極化も起こります。

他の観点においても問題があります。何らかの方法で得られたオブジェクトベースUIに関しての共通認識がプロジェクト内で閉じてしまうことです。複数人によるデザインの難しさは皆で１つのものを持ち上げる難しさに似ています。

プロジェクトに関わったメンバーが分割され、新しいプロジェクトで少数派になれば、それまで持ち上げられていたものも持ち上げることはできなくなります。

プロジェクトのメンバーが変われば、最初はオブジェクトベースUIだったものが徐々にタスクベースUIになるということも十分起こり得ることです。

いずれにしても、山を登りながら山登りの準備をするような進め方は非常に負荷がかかります。

登山に喩えるならば登る前に皆でできるトレーニングが必要であると考えました。それもできるだけ普遍的な準備というものがあると良いのではないかと考えました。

もちろんこれまで挙げてきた事象と簡単に対になるものではなく、むしろ真っ当に進める方法の逆算として必要性を感じたのでした。

トレーニングのコンセプト

トレーニングのコアコンセプトは自分達用のトレーニングです。トレーニングは様々な方に向けたものですが、これは我々 Sociomedia のデザイナーが身につけている基礎知識と同等でなければならないと考えました。

実際クライアントワークでは毎回同じようなデザインの基礎知識をインハウスのデザイナーにレクチャーするような構図になることも多く、そういった現状を鑑みての判断でもあります。

最終的にはデザイナーやそれに準ずる立場の人は Sociomedia のようなアドバイザーから自立し、自分でデザインを考え続ける必要があります。そのためには簡単な説明では足りないと考えました。

その結果、必然的にお楽しみや受け売りのトレーニングではなく、日々行なっているデザインの進め方、デザイナーの考え方など実態に即した手堅いメニューを目指すことにしました。

派手さは求めず本物の自分達用のトレーニングの水準に足るものにしたかったのです。

原型

通常、デザイナーはオブジェクト指向UIデザインを実際のプロジェクトを通じて学んでいきます。まずはこれをさらに手堅くするために基礎知識としての言語化をはかりました。

当時はデザインやリサーチ方面からペルソナやジャーニーマップなどのユーザーのモデリングが論じられ、一方で実装方面にはすでに様々なモデリング手法があるものの、最終的な形としてのデザインとは分断されているように感じていた時期でした。

実装とデザインは分断していましたが、共に同じ課題があるようにも見えました。実装方面ではユーザー要求という形を手掛かりに、デザイン方面のユーザーリサーチにおいてはストーリーという形を、ユーザービリティテストにおいてはタスクという形を手掛かりにしていていずれも「すること」ベースにアイデアを練って行き詰まってしまう点です。

ユーザー中心、人間中心のデザインといっても、形の段階ではデザイナーにおまかせになることも多く、リサーチやユーザービリティテストをしたもののデザインの段階で行き詰まり依頼を受けることもありました。つまりデザイナーがタスクを適度に無視できなければタスクベースUIが作られ、それでいてタスクを基準に行うユーザービリティテストでは評価が高いというような状況でした。

やがて iPhone の隆盛に伴って iOS アプリケーションのデザインが発展しました。その影響でユーザー・エクスペリエンスという言葉も広く使われるようにもなりました。こちらは Apple のアプリを参照することでオブジェクトベースになっていることが多いですが、やがてリサーチ系の手法が持ち込まれるとともにタスクに最適化することがデザインである、といったデザイン観も目にするようになりました。

ユーザーの方を向いている向いていない、といった意味では目指す方向は近いのですが、タスクかオブジェクトかという意味では、ユーザーの方を向いているデザイナーほどタスクに関心を寄せていたので真逆の指向であった印象があります。

オブジェクトの重要性を語ろうとすると意図せず味方の後頭部にボールが当たるような、そんな気がする時期だったのです。

昨今デザイン方面でUIコンポーネントやデザインガイドラインについて意識が向いてきているように感じます（グラフィックデザインがソフトウェアデザインにようやく気がついたと言えるかもしれません）。一方で相変わらずこのトピックは手付かずでした。パーツが統一されるのは一貫性を保つために素晴らしいことです。一方でそれらを組み合わせて、つまり標準パーツで見た目にも美しいタスクベースUIを作ることはいくらでもできてしまうのです。

元々日常的にクライアントワークを汎用的な知識として抽象化するようにしていましたが、ブラックボックスを開けるべく、オブジェクト指向UIの領域に狙いを定めました。幸い我々 Sociomedia のデザインチームはもう何年も前からデザイン原則の１つとして当然のように名詞→動詞シンタックスを心得て実行していましたので、事例には事欠きませんでした。そして時には Textwell という自社プロダクトを大胆な理想像の実現例として大いに参照しながら試行錯誤、言語化を試みました。

デザイナーの具体的なプロセスと直結させながら言語化を進めるうちに、抽象と具体が混ざったトレーニングの原型が見えてきました。

この言語化の取り組みは最終的に、オブジェクト指向UIという概念が広まる１つのきっかけになったブログ記事「OOUI – オブジェクトベースのUIモデリング」としても結実しました。この記事は今なお OOUI に取り組もうとする多くのデザインチームに参照され続けています。

構成

基礎知識の言語化と並行してトレーニングとしての有り様を考えていました。

デザイナー向けのトレーニングですのでハンズオンのワーク（実際に手を動かした作業）がなければ成り立ちません。抽象的なモデルと具体的な形を同時に考えることが重要であるためです。そもそも我々デザイナーはプロジェクトを通じて何かを作る過程で段階的に学んでいくのでその通りにしようと思いました。もちろんプロジェクトは OOUI に関わる話だけではありません。単体のプロジェクトでは俯瞰できない汎用的なポイントをまとめることを考えました。

すでに言語化の時点で実態と照らし合わせて進めていましたので大きな方向の変更はありません。むしろ大きな変更がないようにすることが重要でした。ポイントを掴むためのモデル化はしつつも、遊びとしてのワークショップではないものを目指しました。

魚を海から運ぶ水族館ではなく海を見ることができる水族館のようにできるだけ自然に近いものにしたいと思いました。

トレーニングの設計ではメタファとしてスポーツのような様々なフィジカルなアクティビティから以下のようなインスピレーションを得ながら進めました。

• レクチャーはアクティビティとセット
• レベルに応じたアイテムや箱庭的環境を用意
• 山に登ってない人が山登りを教えることはない

重要視したのはキッザニア的な体験ではなく「トレーニング」です。迷った時の基準は常に自分達のトレーニングになるかどうかでした。

この結果、使ってもないツールをフレームワーク感やワークショップ感の演出のために組み込まない、曖昧な箇所は曖昧なものとしてそのまま残す、などの判断につながりました。

またハンズオンは推進者視点でも意味があると考えました。

前述のように組織によっては OOUI に取り組むという行為に至るまでに多大なコストを払うこともあります。

明確な考えを持たないデザインチームの場合、デザインのアイデアは当人の知るデザインパターンに影響を受けます。パターンが乏しければ単に社内で使っているアプリケーションを真似たアイデアが基準になってしまうこともあります。

こういったケースでは何よりも発案者の中に OOUI という１つのパターンを作ることが重要になります。

しかし卵が先か鶏が先か、のように OOUI を理解してからでないと、OOUI に取り組むことはありません。やらなければ理解できないけれど、理解するまではできない、というジレンマです。このジレンマを脱する意味で些細なレベルでも実際にやってみることが重要だと考えハンズオンを必須としています。

発展

トレーニング向けにさらなる言語化を進めるうちにいくつかのエアポケットにも遭遇しました。デザインは判断を伴う創造的な作業ですので、言語化した仕組みとデザイナーの職人的な判断の間には隔たりがあります。

その際は言語化の仕方をみなおし、セオリーの適用と発展的なチューニングを分けて段階的に示したり、職人的な判断を内包できるように、形から発想する方向を取り入れることで、できるだけ現実に即した仕組みになるようにしました。

またハンズオンは社内のデザイナーやインターンのデザイナーに実際に行ってもらいその様子を観察し、インスピレーションを得るたびに形を変えていきました。この過程で様々なツールも試しその特徴を把握していきました。アナログ、デジタルに関わらず、一見合理的に見えるツールもある閾値を超えると役に立たなくなることもありました。そしてツールは制約を設けずデザイナーが実際に作業するのにまかせれば自然とふるい落とされていくこともわかりました。

デザインプロセスによくある大いなるアイデアのジャンプを言語化しつつも、過度のプロセス化を避けました。汎用性の高い普遍的なポイントをシンプルにプロセス化し、個別最適に相当するのはハンズオンとしてまとめようと考えました。

やはりデザインというのは複雑な行為です。そのような複雑なものを、材料を入れればデザインがコロンと出てくるミキサーのようなプロセスに見せることはできません。（実際ミキサー的探究も行いましたが結局戻ってきました）

実態と異なるミキサーを装うと派手にはなるもののミスリードを生むファンタジーになってしまいます。商売っ気はないかもしれませんがそれで良いと考えました。

我々 Sociomedia のデザイナーは普段のデザインにおいては「モードレス」ということを意識しています。デザインのプロセス化は下手をするとモーダルなプロセスに人を押し込めてしまう危険性があります。

デザインはモードレスな行為の最たるものなのでこれは良くありません。そこで、説明に順序は設けるものの、ハンズオンはできるだけやり方、使用するツールに制限を設けないようにし、アイデアの発展を前提としたデザインを行えるようにしました。

またグループワークでは人によっては手を動かす機会が減ってしまいハンズオンの意味がなくなってしまいます。学習効率を最大にするために個人ワークにしています。まずは個人ワークを行った上で自然に互いを参照し始めるようなチームプレイを想定して設計しました。

現在、これらのコンテンツは企業向けであるものの、ハンズオンに社会性を持たせるべく漫画的表現の取り入れというささやかなチャレンジを行いました。OOUI という専門領域を囲む壁に覗き込みたくなる小さな穴を空けておこうと考えたのでした。

これは私が子供の頃読んでいた「たくさんのふしぎ」という絵本の影響があります。このシリーズは絵本として楽しむこともできますが、その一方で科学の本としても楽しめるようになっていたのです。

こどもでも大人のサポートのもと頑張ればほんの一部であっても取り組める可能性をいれておきたいと考えました。

OOUI のトレーニングがチームに根付くには伝達が必要です。このささやかなチャレンジはトレーニングを受けたデザイナーが内容を端的に説明する際に役立つミームとしての役割も果たします。

この先

こうしてトレーニングメニューが出来上がりました。

参加者は何らかのUIデザインの経験者が多いようです。短期間での習得を目指すことから、最終的に負荷を少しだけ高めにチューニングしましたので、経験の浅いデザイナーにとっては少々難しいかもしれませんが、今後のデザインにおいて土台となる基礎知識を習得できると思います。

一方、OOUI デザインの基礎知識の共有という意味で様々な部署からの参加が多いのも特徴です。

デザイナーといってもハードウェアやグラフィック、コーポレートサイトなどのデザインをしていてソフトウェアのデザインに携わってこなかったデザイナーの方もいて、普段と異なる思考に苦戦しますが形にする段階でこれまでの経験が発揮されることもあります。プログラマーやリサーチャーの方はむしろモデリングの方で力を発揮することもありますし、業務ドメイン理解に関しては類似業務の経験が役に立ったという人もいますので様々です。

これまでのところ幸い「難しいけれどおもしろい」という頼もしい反応を得ることが多いです。

以上、トレーニングの裏側をご紹介しました。

果たして10年後はどうなっているでしょう。トレーニングの後のアクションもまた名詞→動詞のシンタックスです。それぞれの自由なアクションによってその結果もまた変化します。うまくいけばデザインチームの新陳代謝を超えて OOUI が基礎知識として根付くかもしれません。これは不確実性を多分にはらんでいますが、だからこそとても楽しみなことです。