こんにちは、DMM.comでEngineeringManagerをしている田中です。

2018年7月19日に渋谷ヒカリエのレバレジーズさんにて、
InHouseDesigners #3 「デザイナーから働きかける "チームビルディング"」に参加しました。
発表されたスライドに記載されていない部分を重点的にまとめているので、参加されなかった方の理解の助けになれば幸いです。

そもそもインハウスデザイナーとは？

インハウスデザイナーとは「事業会社の中で働くデザイナー」のことで、下記の特徴を持ちます。

・サービスを育てる意識が強い
・広範な領域のデザインを行うことが多い
・他職種を巻き込んだ業務遂行をすることが多い

---

いちデザイナーがチームビルディングのために何ができるか？

藤本 貫二郎さん / レバレジーズ株式会社

メディア開発チームは、デザイナー2名 / エンジニア2名の体制で開発している。
「曖昧さ」と「厳密さ」に起因する衝突が多く、デザイナーにありがちな「いい感じに、察して」というコンテキストが通用しない場面によく直面した。
そこで、相互理解を深めるためにデザイン思考の5つのステップの思考法をチームビルディングに応用した。その中で行ったワークが下記の4つ。

・弱音を吐く会
・ドラッカー風エクササイズ
・レトロ
・ウォーキング＆トーキング

弱音をはく会
目的は「相互の価値観のすり合わせ」。

◆上手くいった点
　メンバーが漠然と抱えている不安をデザイナーが
　文字や図で共有しながら深掘りをしたら上手くいった。
◆気を付ける点
　事前に会の必要性を説明しないと、
　相手から質問や答えを引き出すことができないことがある。

ドラッカー風エクササイズ
エクササイズの詳細に関してはこちらを御覧ください。
目的は「相互に期待する成果を明らかにすること」。

◆上手くいった点
　この人を動かすには、どういう動機付けや言動をすると効果的かを
　理解することができた
◆気を付ける点
　議題や構成を考慮しないままエクササイズに望むと、
　行動や姿勢の洗い出しに終始してしまい、その先にある
　他者に何を求めているのかまで深掘りできないことがある。

レトロ
目的は「相互に期待する行動を明らかにすること」。

◆上手くいった点
　「ものを食べる時に口を開けない」など、レベル感低めな行動から
　意見交換を始めると、重要な問題を出しやすい雰囲気作りができる。
　問題を指摘しあう関係値が築けたことの他に、日頃から相手のことを
　観察する習慣がついた。
◆気を付ける点
　初回の場合は目的を事前共有しないと、他人の行動を全く見ておらず
　話ができない状況に陥りやすい。
　議題的に本音が飛び出しやすいため、否定的な意見を言う場合は
　間に緩衝材としての話題や褒めを上手く使いつつ進行させる。

Walking&Talking
目的は「相手との関係値を深めること」。

◆上手くいった点
　インスタに上げたご飯のこととか雑談レベルで行う。
　共感による理解が大切。
　相互理解、相手に合わせた対話方法、相手の意見や態度の理由を
　理解できるようになった。

まとめ
チームビルディングは、責任範囲や役職関係なく、課題と感じた人が
やるべき。業務だけでなく、チームの課題に直面することもあるはずなので、前向きに改善していこう。

---

チームビルディング？ デザイナーから働きかける"チームビルディング"

佐伯 幸徳さん / 弁護士ドットコム株式会社

前回のInHouseDesigners #2でも近しい内容は語られているので参考にするとよい。また、「モチベーション理論」や「ステージ」に関してはGoogleのRe:Workでも語られているので割愛する。

チームビルディングにおける課題と解決手法
さて、チームビルディングにおいては下記のような状況がよく起こりがち。

・アイデアを発散しきれない
・メンバー全員が積極的に会話しない
・出た結論が腹落ちしていない

これら課題を解決するのに向いている手法として「デザインスプリント」の「クレイジーエイト」という手法を使うとアイデアを発散しやすい。
「クレイジーエイト」は参加者全員でアイデアをひねり出す必要があるため、強制的に全員参加になる。
社内ではクレイジーエイトを使って様々なワークを行っている。
会社やサービスの嫌なところを発散したりとか。

価値観（Customer Centerd Design）共有の範囲

【2018.07.26 追記】
業種縦割りに関する課題は、組織における一般的な課題であり、クラウドサインで起きた課題ではありません。
ご指摘ありがとうございました。

クラウドサインのチームは開発メンバーだけではないため、業種の縦割りも課題としてある。例えば、セールスは売れればOK、開発者は作ればOK、みたいな。
しかし、ユーザーにとってのサービスライフサイクルは業種を越えて連続しているため、顧客ファーストであることを啓蒙しなくてはならない。

そこで事業部でMission Vision Value（MVV）を定めることにした。
上記を策定する際にクレイジーエイトを使ってアイデアを発散し、それを元にマネージャで合宿して策定した。
しかし、MVVは事業部全体に浸透しなければ意味がない。
これを浸透させるために、新入社員に対して既存社員が一番好きなValueをプレゼンする場を設けている。（クエストと社内では呼んでいる）

MVVの他に事業部是としてCustomer Centerd Design（CCD）を大切にしている。デザイナーよりもエンジニアの方が顧客の意見を先に拾ってアドバイスくれたりすることもある。

組織を走らせる原動力、「熱量」について
組織は、構成する人が持つ「熱量の総量」で原動力は決まる。
とはいえ、自分は熱量が高くない方の人間だし、熱量のある人ばかりで組織を構成することは難しい。
なので、熱量が高くない人は「熱伝導の高い人」を目指そう。
伝導力を高めれば、チームにとって大切な人になれる。

---

デザイナーがいないプロダクトにジョインしたときの失敗と成功から学んだこと

五十幡 梓弓さん / 株式会社Speee

Speeeでは正社員デザイナーが３人しかいない。
しかも、最古参のデザイナーよりもプロダクトの方が古くからある。
そこで、上記テーマで経験談を話そうと思う。

リリース後にスモールチームにジョイン　結論：失敗
開発チームのリクエストはリリース優先で作ったプロダクトを「デザインいい感じに、デザイナーにおまかせ！」だった。
そこでデザイナーとして下記の業務を主に行った。

・デザインガイドライン制作
・UI改善案提出（いわゆるキンアカの修正など）
・デザインの責任者という認識

この結果、「デザイナー」としてではなく「アウトプット」を評価されてしまい、デザイナーが不必要だと判断されてしまった。
後になって判明したが、エンジニアはアウトプットに困っていなかった。
本質的な課題としては、デザインに対する論理的な良し悪しが判定できず、チームのプロダクトを壊し続ける人間だと認識されてしまい、エンジニアから疎まれてしまった。

成長過程にあるチームにジョイン　結論：成功
プロダクトの作り方はスモールチームと一緒。
競合プロダクトベースで、フレームワークを利用して要求は最大に。
デザイナーに求められていた能力は、

・自分にないアイデアや新しい提案を出す
・プロダクトを言語化できない何かで良くしてくれるという魔法使い

だった。
上記の通り魔法使い扱いだったため、具体的なタスクやミッションをチームが与えることができない状況だった。
そこで、チームメンバーに対するヒアリングや改善提案を行い、実行時には周りのメンバーに協力を仰ぐ働き方を意識した。
結果として、職種関係なくプロダクトを一緒に作る文化が生まれた。

振り返り
失敗事例では「できるところを見せなきゃ！」と意気込みすぎて、
エンジニアが持つプロダクトへの思い入れを踏みにじってしまった。
プロダクトの背景を理解した上で提案し、相手を巻き込むんで協業する姿勢が必要だった。

成功事例では周りの人を巻き込んで、課題の洗い出しやプロセス、依頼内容などを明らかにして一緒に協力してもらえるように動いていた。

この事例から学んだことで大切なのは「理解と共感」。
みんなが作りたいと考えている「いいもの」が何なのかを正しく理解することが重要。
チームメンバーと同じ方向を向いているかをコミュニケーションすることが大切だと感じた。
チームの思いを形にして見えるようにするのがデザイナーの仕事なのだと心得ている。

---

デザイン組織立ち上げ時のチームビルディング

アタラシ タケシさん / 株式会社クラウドワークス

クラウドワークスにおけるデザイン組織
デザインやエンジニアなどの横断組織があり、
それぞれのプロダクトに各職能人員がアサインされているマトリクス組織。
今回は横断側（デザイン組織）、約2年半前の立ち上げ前夜から今まで行ってきたことを話す。

デザイン組織立ち上げ前～現在
Ph0：立ち上げ前夜
会社としてもデザイナーをどう活かせば良いかわからない。
デザイナー自身のスキルも知識も高くなく、「言われたものをただ作っている」状態だった。これを何とかしたいと考え、デザイン組織を立ち上げることにした。

Ph1：立ち上げ期（デザイナー4人）
プロダクトごとにデザイナーが散っているため、横断組織の帰属意識は希薄だった。
まずはお互いの知識の偏りをならすため、デザインワークショップやUXガイドラインの策定を全員で作ったり、1on1を行うなどしていた。
その中でもUXガイドラインはデザイナーの意識づくり・価値観の共有に良い影響があった。

Ph2：定着期（デザイナー6名）
デザイン組織への帰属意識向上と知識共有を目的にデザイナーの席を一か所にかためた。と同時に全員でデザイン組織の運営に協力してもらうことで一体感の向上を図った。

この頃は会社におけるデザイナーの立場はまだ低かった。
そこでデザイナーの地位向上のため、社外活躍や自社のデザイナーが注目を浴びたエピソードを社内に向けて積極的にアピールした。
雑務を楽しくやってもらうために大臣制度を導入したのもこの頃。

この頃行った施策で、デザイン書の読書会はチーム内コミュニケーションの活性化に効果があった。
読書会はスライド形式と付箋形式で行っており、付箋形式は読書会の日までに予め読んでもらっている。

Ph3：拡大期（デザイナー12名以上）
お互いの業務内容の把握、デザイナー価値観の共有・朝会などでコストが増大してきたことと、プロダクトチームとデザイン組織の多重所属でメンバーの負担が大きくなってきているのが現状。

今は共有会を開いて、お互いの業務やプロダクトをどうしていくかを話し合い、組織への帰属感を高めている。

まとめ
ここまでを振り返って思ったことは

・小さいうちに課題はつぶす
　未来に大きくなりそうな課題は種のうちに対処する
　放置するとマズいと思ったものを解決するする
・チームビルディングは継続施策、やったりやらなかったりは無い
・仕事に関係ない提案もチームビルディングに効果が出そうなら受理する
・リードする人は決めない
・手法に固執しない、経験主義的に取り入れ改善していく
・チームごとの成功パターンを見つけてそれに則る

---

おしまい。