はじめに
この記事に関心を持ってくれた方は、デザイナーとして仕事をしている中で、「もっと事業に踏み込んで、事業課題の解決に貢献したい」と思ったことがある、もしくは今後そうなりたいと感じている方なのかなと思います。
事業課題を解決するデザイナーになりたい。でも、実際の現場でどうすればいいのかはよくわからない。
たぶんこのあたりで、一度立ち止まったり、「自分にはまだ早いのかも」と距離を取ってしまった経験があるデザイナーは、少なくないんじゃないかと思います。
少なくとも、継ぎ目なく制作物を頼まれる社内受託状態だった昔の昔の私はそうでした。
だって、表層のデザインのクオリティを上げるための知識や観点は教えてくれるけど、「事業課題を解決するデザイナー」について具体的にどう考えて、どう動けばいいのかを教わる機会ってあんまりないんだもん..!
この記事では、これまでの自分自身の経験を振り返りながら、改めて「事業課題を解決するデザイナー」とはどういう人なのか。そして、そうなるためには、何に目を向ける必要があったのかを整理してみたいと思います。
デザインのアプローチを「アウトプット制作」ではなく、まずは「課題の前提整理」に向ける
事業課題を解決するデザイナーになるためには、「もっともっとビジネス知識が必要なんだ」と思う人も多いと思います。
自分もそうでした。
戦略、経済、KPI、マーケティング、ビジネスシーンで使われる様々なフレームワーク。
確かに、知っていれば役に立つ場面はたくさんあります。
ただ、実際に現場で感じたのは、それらを完璧に理解することよりも、その事業の目指すところや、現状課題の構造などの「前提」に向けているかの方がずっと重要だったということでした。
たとえば、
- 今、会社はどこを目指していて現在地はどこなのか
- 課題の構造はどうなっているのか
- 事業の前提がどこで曖昧になっているのか
- みんながうまく言葉にできていない違和感はあるか、それは何か
そういったものを整理して提示することのほうが、事業を前に進めるきっかけになることが多いと感じます。
「事業課題」というと、少し難しく聞こえるかもしれませんが、実際にやっていることは、そこまで特別なことではありません。
- 散らばっている情報を整理する
- 前提や認識のズレを見つけ、統一する
- 「今、何を決める必要があるのか」を明らかにする
こうしたことが多いです。
これって、画面設計や体験設計の前に、デザイナーが自然とやってきたことに、かなり近いと思います。
事業の上流に関わる、というと「全部理解しないといけないのでは」と感じるかもしれません。
でも実際には、最低限押さえておいたほうがよい知識は、意外とシンプルでした。
- その事業は、何でお金を稼いでいるのか(ビジネスモデル)
- 何がうまくいっていて、どこで詰まっているのか(全体感把握・課題の構造化)
- どの数字が動けば「前に進んだ」と言えるのか(KPI)
最初からすべてを一人で理解するのは難しいと思います。
私も、営業担当やマーケティング担当など他の部署の人に話を聞きいて少しずつ情報を整理し、理解を深めていきました。
こうしたプロセスは、UXデザインの「ユーザーや文脈を理解するための思考」とかなり地続きだと感じています。
事業の上流に関わることは、デザインとは別の仕事をするというより、UXデザイン的な考え方を、事業の文脈に広げていくことに近いと思っています。
実際、セブンデックスではプロジェクト時にどう動いているのか
セブンデックスで相談いただいた事業課題に向き合うとき、最初から「どんなアウトプットを作るか」の話に入ることは、ほぼありません。
最初に時間をかけているのは、このプロジェクトで、事業として本当に解きたい課題は何なのかを、ステークホルダーと一緒に整理することです。
参考までに、とあるプロジェクトでの動きを例にご紹介します。
事業の前提や目指す方向を揃えるところから始める
あるプロジェクトでは、サービスの成長を次のフェーズに進めることがテーマでした。
ただ、話を聞いていくと、
- 何をもって「成長」と考えているのか
- どんなユーザー体験を強化したいのか
- 今、どこが一番ボトルネックになっているのか
といった前提が、人によって少しずつ違っていました。
そして、経営層や事業責任者へのヒアリング、これまでの戦略資料や数値の整理を通して、事業の背景や目指す方向性を言語化・構造化するところから関わっていきます。
ここでやっているのは、答えを出すことではなく、「みんなが同じ前提で話せる状態」をつくることです。
ユーザー理解を、事業の意思決定につなげる
次に行ったのは、ユーザーや提供価値の整理です。
ユーザーインタビューや既存のデータをもとに、
- 誰が
- どんな状況で
- 何に困っていて
- どんな価値を求めているのか
を整理し、ペルソナや体験の軸として可視化します。
ここで重要なのは、「ユーザー理解そのもの」が目的ではないという点です。
その理解を通して、事業として、どこにリソースを集中させるべきか、どんな判断を優先すべきかを考えるための共通の材料をつくっています。
デザインを使って、認識のズレを揃えていく
こうした情報をもとに、デザイナーはラフな図や体験フロー、いくつかの選択肢案を用意しながら、ステークホルダーと議論を進めていきます。
この段階のデザインは、完成形を見せるためのものではなく、認識のズレをあぶり出し、意思決定を前に進めるための道具です。
実際に可視化することで、話し合いの中で、
「本当に変えるべきポイントは、ここかもしれない。」
「目的から下ろすとこの施策で狙っているのは、こっちの体験なんじゃないか?」
と、チーム全体で考えが整理されていくことも少なくありません。
補足ですが、事業会社・支援会社の両方を経験して個人的に思うのは、事業会社の方が暗黙の了解的に言葉が曖昧に交わされていくことが多いように思います。
同じ事業を一緒にやっているからこそ、お互いに「伝わっている・理解している気」になってしまうことで、結果的に細かいところで認識がズレていく…と言うことが起こりやすい印象があります。
(あくまで個人の意見です..!)
そのズレを防ぐのが、それまでの議論を整理・可視化し、テーブルに上げること。
言語ではなく、視覚的なものをみんなで見て議論ができるため、認識がズレずに本質的な会話ができます。
これは、これまでの文脈を全て理解しているデザイナーだからできることであり、とても重要な役割だと思います。
結果として、アウトプットが事業とつながる
最終的にアウトプットされるデザイン自体は、一見するとUI改善や体験設計といった一般的なデザイン業務に見えるかもしれません。
ただ、その手前で、
「今回のアウトプットは、何を解くべき課題なのか」
「このアウトプットで、どんな成果をねらっているのか」
が整理されていることで、アウトプットが事業の意思決定としっかり結びつく状態になります。
「事業課題を解決するデザイナーとして動く」というのは、特別なことをしているというより、こうした関わり方・考え方を当たり前に行なっていくということなんじゃないかと思っています。
整理:
事業課題を解決するデザイナーと、そうでないデザイナーの違い
こうした前提を踏まえると、事業課題を解決するデザイナーと、そうでないデザイナーの違いも、少し見えやすくなる気がします。
自分の整理のためにも、事業課題を解決するデザイナーとそうでないデザイナーで違うことをざっと整理してみました。
①「最初に見ているもの」の違い
事業課題を解決するデザイナー:
- 事業側の「困っていること」を起点に考える
- そのアウトプットで、何が変わるのかを見る
- 提示されている要件そのものを疑うことも仕事のうち
そうでないデザイナー:
- 目の前のアウトプットがゴール
- 要件を満たすことに集中する
- 事業の話は前提条件として扱う
💡 デザインを見るか、課題を見るかの違いがある
② 「問いの立て方」の違い
事業課題を解決するデザイナー:
- 「それは、どんな問題を解きたいのか?」から考える
- そもそも作る必要があるか・課題に対するアプローチとして、そのアウトプットが最も適切なのか?から問い直す
そうでないデザイナー:
- 「どんなデザインを作ればいいか?」から考える
- 課題はすでに定義されている前提で動く
💡 制作の問いを立てるか、課題の構造を整理するための問いを立てるかの違いがある
③「関わり方」の違い
事業課題を解決するデザイナー:
- 事業課題を理解するための関わり方をする
- 事業に関する議論の場にも参加し、情報を整理しながら話を前に進める
そうでないデザイナー:
- 依頼されたアウトプットの制作にベストを尽くす
💡 上流から関わるのか、デザイン制作から関わるのかの違いがある
まとめ
あくまで自分自身の経験を通してですが、事業課題を解決するデザイナーとは、「アウトプットを考えて制作する人」というより、事業を推進しているステークホルダーと一緒に、「何が課題なのか」「どんなアウトプットが適切なのか」を考え、それを形にしていく人なのではないかと思っています。
制作物の質を高めることはもちろん大事ですが、それだけでは届かない領域がある。
だからこそ、制作物をつくるの前提にあることに少しずつ関心を向けていくことが、 事業課題を解決するデザイナーへの一歩なんじゃないかと思います。
【引用元のnote】事業課題を解決するデザイナーになるために必要なこと|るい