経験によるクライアントワーク/インハウスでのデザインワークの特徴と共通点

こんちには、ゆいです。
これまで3回転職し、クライアントワークも事業部付きデザイナーも経験したので、今回はそれぞれの特徴、経験から得た共通の学びについて書きます。

経歴
クライアントワーク時代：~15人ほどのデザイン部に所属、UIデザイナーとして3年弱勤務。
事業会社：サービスの開発チームに2人目のデザイナーとして配属され2年目、在籍中。

どっちもぺーぺーなので、リーダー等と全く違うと思います。内容はすべて個人の経験に基づくので全ての会社で同じではありません。

簡単な違い

クライアントワークと事業部づきのデザイナーは、端的に言うと「どうするとお給料がもらえるか」というが違います。

クライアントワーク：クライアントとの共創、納品してお金になる💰
事業部付き：事業の成長に貢献しないとサービスが無くなっちゃう😇

この関係性によって以下のような違いが出てきます。それでは細かく書いてみます。

トピック①デザインワークについて

事業部付きの場合：価値を届けることを意識
・作業範囲とスキル
現在の会社では事業部ごとに1~2人デザイナーが配属されています。
私は運良く、経験豊富で安定しているデザイナーさんと一緒の部署でした。心強いです。たくさんの配慮をして頂きながらプロダクトに対するデザインワークの全て、2人で分担しています。
と言っても、事業がスタートアップ・立ち上げ・リニューアルのタイミングではない限り、既存サービスを一貫しデザインすることは難しいです。トンマナ・ブランディング・コンポーネントは既存で、それに合わせて「このページだけ」「このボタンだけ」などパーツを選ぶ作業になってしまうことは、残念ながら少なくありません。表層的な作業を依頼されることのほうが多いです。
一方で、ユーザーに価値を届ける前提なら、主体的に行動できます。コーディングスキルや定性分析のスキルがあると有利で、私の部署は比較的自由にプロダクトへ変更を加えることが出来ます。もちろん売上に直結する変更には責任が伴います。しかしチャンスがあるだけでも素晴らしいです。伝聞にならず直接検討段階から介入することも出来ます。またユーザーの反応も直接届きます。自分が担当した部分でユーザーの反応が良いこともやはり嬉しいですし、チームみんなで喜べることも魅力です。

ツール選定
クライアントのセキュリティ都合を考慮する必要がないので、比較的自由にツール選定できます。既存ファイルとの多重管理が大変ですしチーム内の理解も必要ですが、最新ツールを上司の許可のみで使えるようになったときは嬉しかったです。

クライアントワークの場合：納品物としての完成度を意識
作業範囲とスキル
案件の殆どはサイト・アプリ全体のリニューアルや新規立ち上げでした。全体のトンマナ設計を含め、導線設計〜ビジュアルデザイン、実装確認まで広範囲をメインで担当できました。全体の設計ができることで、一貫性があるアウトプットが出せるようになります。このようなアウトプットを1,2ヶ月に１回は行うため、ポートフォリオも充実しやすくなります！ポートフォリオは大事ですね。
クライアントワークの場合、クライアントを満足させる完成度の高い納品物が大事です。そのためデザインで重視されることは、ロジック裏付けのある強いビジュアルです。クライアントが納得できるようなアカデミックな説明力とクライアントに刺さるビジュアル設計がスキルとして身につきます。
在籍していた会社では、デザイン部の中でノウハウが蓄積さていて、体系立てたプロセスやロジックを身につけられました。1つの事象に対して、クライアントの納得を得るためにも、深い知識を身につけることが求められていました。所属していたのはデザイン部署だったので、困ったことがあれば誰かしらからデザインの専門知識を教えてもらう事ができましたし、先輩も丁寧に教えてくれました。結果の測定までは行わないので、いい意味でビジネス的ではなく純粋にロジックやデザイン原則に基づいた設計を行うことができます。

ツール選定
ツールの選定はクライアントのセキュリティ都合で決まるため、条件に合うツールを探すため様々なツールを研究していました。比較表などをつくりクライアントと調整していました。
楽しかったですが、セキュリティ都合によっては使えないツールもあったりして、世間の流行りには乗れないこともありました。たとえばZeplinやFigmaはオンラインに情報をアップロードする必要があったので、使えないことが多く、代替手段を利用していました。

トピック②情報取得

デザインする際には、必要な情報をヒアリングする必要があります。情報取得の仕方、取得できる範囲、作業姿勢に違いがあります。

事業部付きの場合：一次情報を取得できる
自社サービスの場合、知識があればどんな情報も自分から見に行くことができます。受託では手に入らなかった情報をもとに、ユーザーの行動を定性的に把握することができます。ビジネス観点を持ち、定性的な分析をもとにした提案能力を身につけることができれば会話を発展させることができそうな気もしています。
一方、情報取得をできる知識がなければ一から身につける必要があります。分析ツールの使い方、分析の仕方、データの使い方を現在勉強中です。私の環境の場合、基本的に周りの人はプロなので、一緒に働くだけでも勉強になりますし、みなさん時間を作って教えてくれます。みんな優しい。デザインにどんな情報が必要か分かっているのはデザイナーだけなので、デザイナー以外とチームで働くときは、自分で揃える必要があります。

クライアントワークの場合：デザインワークに集中できる
私の在籍していた会社では必要な情報はすべて窓口担当のPMの方、または組んでいたシニアサービスデザイナーから揃いました。もしくは直接クライアントに伺い、デザインに必要な情報は揃えてもらうことができます。そのため、デザイナーはデザイン領域の作業に集中し、知識と技術を深めることができました。
先方からの情報待ちで作業が止まることも多くありましたが、できる範囲で最善をつくすことも納期に間に合わせる工夫の一つです。

トピック③業界知識

デザインする際には、対象の界隈について深く知っている必要があります。横に広げるか縦に深堀りするか、が大きく異なります。

事業部付きの場合
業界のドメイン知識を深く持っている人がたくさんいます。(ドキュメント化されていなかったりするため新しく入った人は私含めて混乱していましたが、だれかしらが知識を持っています)。１つの業界について、自分で実際に体験してみたり、経験者に深く話を聞いてみる必要はありますが、基本的には１つの業界に対してじっくり深く知ることが求められます。その他知見に関しても、事業部で扱う範囲は深く身につける事ができます。

クライアントワークの場合
クライアントワーク時代は、教育、銀行、イベント、EC、コーポレートサイト、FinTech…など、色色な業種の案件を扱いました。案件ごとに業界知識が必要になりますので、広く浅く情報を集めました。集めた情報はトンマナ規定などに利用しアウトプットも行います。競合調査も行い、業界調査も行うので、業界・知識に関して偏り無く知見を得ることができ、インプットした情報は必ずアウトプットするので知識が定着します。

余談ですが、色色な情報をしょっちゅうドキュメントにまとめます。先輩がしっかりとしたFBをくれるので、ドキュメント作成スキルは上がります。簡単に作ったドキュメントでも完成度が高いと言われるのでドキュメント作成スキルはクライアントワークのほうが鍛えられそうです。

トピック④多職種・社外とのコミュニケーション

デザイナーは専門職ですが、誰とも喋らず作業が終わるわけではありません。他の職種の人の考えていることを形にする必要があるので、コミュニケーション範囲は基本的に広めです。その視点から両者を比べると会社全体の雰囲気にまで違いがあります。

事業部付きの場合：社内の人とのやり取りメイン
一緒に仕事をするメンバーはほぼ固定です。私は失言が多いので慣れない相手と話すことにプレッシャーに感じたり、服装や身だしなみを毎日整えることも苦手です。その点、一旦事業部のメンバーに慣れてしまえば、慣れない人と話すことは極端に少なくなります。また毎日顔を合わせるので、一回の失言に対して謝罪できるタイミングも多くなります。クライアントの前ですっぴんでいるわけには行きませんが、事業部勤務でそのプレッシャーは感じません！
一方で事業部では日々広い職種の方々と仕事をします。職種を飛び越えて「自分たちのサービス」について議論を重ねることは基本的な仕事内容に含まれます。広い職種の方の考えを形にして理解を得るためには、専門用語の使用は控えたほうが良さそうです。これは後述の「共通言語」で触れます。

クライアントワークの場合：クライアント・社内
クライアントワーク時代では、案件アサイン制度だったので案件ごとにメンバーが異なりました。社内外広い範囲の方仕事するので、言葉遣い、宛名の順番、電話応対、電話を取るタイミング、名詞の渡し方、服装…などビジネスマナーを実践で身につけることができます。社内でクライアントが仕事をしている場合もあるので、緊張感もあります。
デザイナー間でのコミュニケーションも密でした。所属していたのはデザイン部署だったので、困ったことがあればすぐデザインの専門知識を得る事ができました。売上につながるので頻繁に勉強会も開かれていましたし、デザインレビューを自主的に行っていました。社内では頻繁にデザインの専門用語を使っていました。今考えると、専門用語を用いることは専門家として扱われる上では必要なことだったと思うので、組織ブランディング的に意図されていたのだと思います。
一方で、エンジニアさんや営業の方と日々やり取りを取ることは少なかったと思います。アサイン制で質問やコミュニケーション時間を貰うにも社内調節が必要でした。

トピック⑤評価

お給料に直結する評価についても、こんな違いがあります。

事業部付きの場合：デザイナー以外からの評価
評価者は、デザイナー以外の職種の方が多いみたいです。現在の職場もそうです。そのため自分のデザインが如何に事業貢献できたのか、を定性的に説明する必要があります。私は苦手なので、得意なデザイナーの方に手伝ってもらったりしています。デザインスキルに関する評価は特に難しいみたいなので、noteなどに専門知識を発信したり外部的な評価を得ることで間接的にデザインスキルの評価に繋げることができます。（評価者によるみたいですが、運よく評価してもらえています。ありがとうございます）

クライアントワークの場合：専門家からの評価
案件の納品数や、クライアントの満足度、など比較的指標が明確になっていた印象があります。評価者のデザイナー像と自分のデザイナー像があっていれば不満には思いづらいと思います。また専門職からの評価なので、アウトプットに対する評価は納得感があります。
実績の外部発信は機密の関係があり難しい印象がありました。社内でどんな素晴らしいドキュメント・実績を残してもそのまま世間に公表することは難しいです。

まとめ①クライアントワーク→事業部転職直後の失敗段３つ

上記の差から発生した私の転職後の失敗を戒めとして３つ書きます。

失敗①
転職直後の仕事で既存デザインとの比較表を作り変更点を対応付けしメリットを説明するドキュメントを制作しました。修正が入ると修正FBを書き込み版を更新していましたが、時間をかけドキュメントを制作する必要はありませんでした…。ドキュメントにする文化は全くありません。現在は、直接アウトプットを作成し、Figmaのコメントを付けたり口頭で説明する程度にしています。事業会社ではチームのメンバーに確認が取れればOKなので逐一ドキュメント化する必要はありません。

失敗②
すべてのアウトプットに対し、納品物としての完成度を基準にしてしまったため、他者のアウトプットに対しても「納品物としての完成度」を求めてしまい、相手に対して不必要なアドバイス(クソバイス)を送ってしまいました。その時は必死でしたが今思い出すと申し訳ないです🙇‍♂️😭
納品物じゃないので、中間成果物の「評価」は必要なく開発関係者の納得や同意のため「レビュー」を行います。懸念を覚えた案は実際の数字も悪くすぐに切り戻される事が多いため、ユーザーからの評価を待ったほうが平和でした…。

失敗③
納品物として自分の仕事が終わればゴール、と無意識に思っていたため、営業の方からの依頼で行った修正作業の進捗報告で、デザインが終わった段階で「作業完了しました！」と伝えてしまました。実装を全く考慮に入れられてなく、実装担当の方に「まだ終わってないです…」と申し訳無さそうに言わせてしまい、今思い出しても苦い気持ちになります😇
本当にすみませんでした😣

失敗たくさんあるのですが、転職直後は戸惑いが大きかったですし、1年以上経った現在でも戸惑うことはたくさんあります。迷惑かけながら日々学びです。

まとめ②共通して役立っていること３つ

両方の働き方で大事にしたほうがいい、と思ったこともあります。

①共通言語を早く獲得する
コミュニケーション、共通言語を早く獲得すること。これはCIIDのMOMOさんも同じことをLTでおっしゃっていました。
まずはクライアントでもチームでも彼らが使っている「単語」を知る必要があります。人は同じニュアンスで同じような単語を頻繁に使うことで仲間意識や集団帰属意識が高まります。共通言語(Rudy等ではなく、もっと抽象的な意味)がないと日本語は通じるけれども話が通じなくなります。
その言葉の背景・ニュアンス・使われている文脈を注意深く知る必要があります。
例えば「デザイン」に対する期待も組織によりだいぶ異なります。「デザイン」が表層を指す場合もあれば低層工程での設計段階を指すこともあります。このように言葉に対するニュアンス、期待値は組織に拠って異なります。（これはもしかしたら普通の人はできるのかも。私は特に苦手です…）
単純に、言葉の意味が食い違って苦労することもあります。例えば「ラベル」と言った場合、デザイナー間ではボタンの文言などを指しますが、他職種の方の間だとタグやChipsのようなものを指してしていたことがあり、MTG中ずっと食い違ってしまったこともありました。
早く組織内で使われている言葉を覚え自分でも使うことで組織に馴染め、同じ土俵に立つ事ができます。
これは「デザインの伝え方」という本でも紹介されていますのでご興味がある方はぜひ読んで見て下さい。

②ゴール認識を一致させる
クライアントワークの場合は納品することが仕事ですね。なので納品物のクオリティも大事です。自社サービスの場合、私の印象では「定性的に検証できる」ことは重要な要素のようです。仮説検証のポイントからズレるとなかなか実装できない、それどころか議論が進みません…。「そもそも」ラインの話になってしまうみたいです。実装までさせてもらえないと価値はユーザーに届かないので、完璧じゃなくても前に進むことが大事だと学びました。そのために「背景」のすり合わせを丁寧に行い、作業のゴールを一致させることはとても大事です。
一方クライアントワークでは、ゴールのために、クライアントの意向と利用者の目線の両方取り入れることがとても難しいです。ユーザーに対しての配慮はクライアントの意向と反しているように感じることが多くありました。クライアントワークじだいには分かっていませんでしたが、責任を取るのはクライアントですし、クライアントがあって初めて成立している仕事です。「クライアントにとって良いもの」と「クライアントにとって都合の良いもの」は違う、と営業の方が言っていたそうで、度々この言葉が身にしみます。
このように、自分の作業は何をゴールとしているのか、を意識することは大事だと思います。意識しないと骨です。

③判断軸を相手に委ねない
デザイン案を複数提案し、相手に選んで貰う場面は両者で多くあります。それ自体に善悪もないと思いますが、どれを選んだら良いかはなるべく自分の判断を相手に納得してもらうようにしたいと考えています。
複数案から、１つを選ぶ作業をするメリットは、選定に関わった関係者が「自分で意思決定を行った」と思えることで安心感を得たり、帰属意識・主体性を感じることです。
複数案それぞれにメリデメを書き出し、なんとなくでも「コレが良い」という１案を決め、決定的なメリットを多く書き、当たり障りないデメリットを添えておきます。
選定の際には、上記を丁寧に説明することで多少他の案が気に入られても、だいたい自分の推し案に決まることが多いです。
判断軸を自分で持たす、ただメリデメを並列に並べると、相手は判断に迷います。迷うときは心理的な負荷を感じるので判断者の「なんとなくの好み」で決めてしまうこともあります。
この「なんとなくの好み」は厄介です。デザインが「相手の不透明で不安定な好み」で決定されてしまうと作業者は「好み」のデザインにたどり着くまで何度も手を動かさなければならず、相手のよくわからない主観に振り回されてしまい、こちらの首がガンガン締まります。
私は複数案デザインを提案するときは、相手の負担を軽くし納得感を持ってもらうために、各デザインのメリット・デメリットを相手に提示し、最終的な目的に沿っているデザインを「選ばせる」という手法をとっています。これはクライアントワーク時代に先輩から教わったことで、今でもできる限り実行しています。もちろん出来ないときもありますが…！

④やれない理由＜＜＜＜どうやるか
最近忘れちゃうので戒めです。
あまり実用的でないと思えるような、同意しかねる提案をされることは多いかと思います。たとえば「目立たないので大きい赤字にして点滅させて下さい」みたいなときです。そのときに「XXXだからできない」と延々と説明してしまうことがあります…。これはただ単にやりたくない言い訳と受け取られる可能性が高いです。そのため相手の要望をなるべく正しく汲み取り、その要望を実現する代替案を出すことで話し合いを前にすすめることができます。
書いておいて出来てないので明日から気をつけます。

終わりに

転職するときのヒントとして読んでほしいと思い書き始めましたが、かなり個人的な体験に拠ってしまいました。2020/03/22書き始め、とメモしてあったのですが、随分時間が経っていますね。その間にnoteの書き方を忘れていて、見出しスタイルが１つしかなかったので記事の形成にも苦労しました😵この記事たいそう読みづらくてすみません🙇‍♀️
書いていて私の辛い部分が出てしまいました。GWの最後なのでコレを供養として明日からは、…来世からこそは明るく生きていきたいと思います。

ではまた