プロダクトを成功に導く！デザイン理解のある組織のつくり方｜filler×シロク×エウレカ×ザッパラス

ここ最近、デザイナーに求められる能力が広がりを見せています。たとえば、リーダーシップ、UX、マーケティング…さらにはフルスタック、経営参画など。世の中のデザイナー、ひいてはデザインに対する期待はどんどん高まっているといえるでしょう。

でも、デザインへの期待にデザイナーだけで応えていくのはとても難しい。未だに「デザインはデザイナーだけの特殊能力だ」みたいな考え方が根付いていますが、もはやデザイナーだけでカバーできるものではなくなってきています。そこで「デザインをデザイナーの持ち物から組織の共有物へと移行させていくこと」が必要となってくるわけです。

しかし、社会や組織におけるデザインの考え方を実践する仕組みはまだ醸成されてはいません。具体的な事例やロールモデルもない状況。デザインをデザイナーの持ち物から組織のそれへと移そうにも、誰にどのように渡せばいいのかがわからない状況だといえます。

私はまずデザイナーだということを忘れるところから始めました。裏方に徹して、デザイン以前の仕組みをつくっていこう、と。具体的に実践したのは次の3つです。

1つ目は、チームに対して。デザインのフィロソフィーを明確化することを意識しました。社外では積極的にイベントへ登壇し、社内ではQiitaやSlackを使ってしつこいぐらいデザインについてアップして、社内勉強会も頻繁に開催。外と内の二軸で全体を巻き込みながらチームを仕組み化させることを意識しました。

2つ目は、人材について。デザインのフィロソフィーやスタンスが固まっていると、それに内包されるようなかたちで理想の人材像が見えてくる。必然的に採用方針や育成方針も固まってくるわけです。そして、「好きにしていいよ」とただ言われても、特に若手は困ってしまうじゃないですか。本人にビジョンがないとこちらもバックアップしづらい。だから、まずデザイナーとしての価値観に気付いてもらうために、人生相談のように話し合うところから始めました。リーダーというよりも、伴走者として。

3つ目はスキルについて。デザイナーのスキルは、本を読んで学べるハードスキルと経験に基づくソフトスキル、そして自分のスキルを扱うメタスキルに分類されます。ハードスキルは時代の流れによって陳腐化してしまうこともあるので、ソフトスキルとメタスキルの向上にウェイトを置いていましたね。

組織のデザインへの理解を深めていくうえで、やるべきことは2つあると思います。

1つ目は、現場で手を動かしているデザイナーのマネージャー、リーダークラスのメンバーに向けて、改めて自分自身のデザインに対する考え方を明確に伝えること。そして、それをきっかけに「そもそもどうしてデザインって必要なんだっけ？」と一緒に考えてもらうこと。

2つ目は、デザインが持つ価値を客観的に証明し、事業および組織に対してそれがどのように貢献しているのかといった点も含めて共有することです。たとえば、チームとして掲げているKPIも、元々は事業目標からブレイクダウンされているわけじゃないですか。ボタンひとつ変えるだけだとしても、事業にどう貢献できるのかを言語化して伝えていくことが大事ですね。（藤井さん）

「デザインの意図を言語化すること」はとても大切です。デザイナーにとって、例えば”このバナーの文字のズレを真ん中に持っていく”というのは無意識にやっていることなので、特に社内ではそれを言語化していない場合が多い。でも、言語化しないと非デザイナーに納得してもらうことが難しいですよね。

私自身、デザインに対して非デザイナーから「ここが前と変わっているけど問題ないですか」といった意見をもらった場合には「これは位置のバランスが悪かったので修正しました」という風に、デザイナーにとっては当たり前と思えることでも意識的に言語化して伝えるようにしています。また、もっと大きなデザインにゼロから取り組む場合も、「なぜこの色を選んだのか」「なぜ直線ではなく曲線にしたのか」といった部分まで、自分なりに言葉で説明できるように心がけることが大切です。そうすることで、チームメンバーだけでなく組織全体にとってもデザインが理解しやすいものとなります。（渡辺さん）

企業としてそれなりに予算を使うことを前提とすると、デザインに取り掛かる前の段階で、その意義や価値みたいなところをしっかり社内へ伝えなければいけないと思っています。「やってやりっ放しで何も振り返らない」というのは、デザイン”あるある”なんですよね。そのあたりを地道に定量化して、やったことに対する価値を積み重ねていくと、組織内でのデザインへの信用度がかなり大きくなるんじゃないかと僕は考えています。（石山さん）

エウレカでは、現状プロダクトチームのコミュニケーションにおいて、メンバーからの理解が得られないということはありません。チームで同じKPIを追っていて、それを達成するためにどうするかはチームに任されています。また、もともとデザインを重視するという組織風土があって、その重要性を会社全体で継続的に伝えているのも要因かもしれないですね。エンジニアからデザインに対して「こうした方ががいいんじゃない？」と意見が出ることもあります。チームメンバー全員がプロダクトづくりの意思決定に関わっている感じですね。（渡辺さん）

シロクでもデザイナーがKPIを追っています。上谷さんからのアドバイスがキッカケで「とりあえずやってみよう」と。ハードルが高いかと思いきや、意外と利益や売り上げに対してデザイナーも目を向けるようになってきて、導入して非常に良かったと感じています。

意思決定に関してはプロダクトオーナーが、最終ジャッジをするかたちで取り組んでいます。ただ、意思決定より、問題発見の方が大事だと思っていて、エンジニアでも風通し良く発言できる状態をつくっています。仕組みづくりというよりはコミュニケーションを取りやすい雰囲気を意図的につくり出している感じですね。（石山さん）