プロダクトデザインの裏側には何がある？　成功の鍵は”体温あるコミュニケーション”にあり

「見えないデザイン」は、「人」のこと

羽野めぐみ氏：よろしくお願いします。たぶん私、登壇者の中で唯一のデザイナーだと思っていますが、この中で「エンジニアです」という方はどれぐらいいますか？

（会場挙手）

みんなほぼ、エンジニアですかね。では「デザイナーです」という人は？

（会場挙手）

ありがとうございます。何人かいますね。

これから「エンジニアとチームを組んで見えないものをデザインする」というタイトルで、デザインに関係する話をします。とくに職種に関係なく、なにか今後の考えるきっかけになったり、明日からなにか取り組めるようなものを提供できたらいいなと思っています。

タイトルに「見えないもの」というワードを含めたのですが、「見えないもの」とはずばり何でしょうか？　と、いきなり言われてもピンと来ないと思うので、まずは考えやすい「見えるもののデザイン」を紹介します。

私は株式会社キッチハイクという会社で、「食べるのが好き！」で集まるグルメアプリ「キッチハイク」というプロダクトをデザインしています。

このプロダクト開発におけるデザインとは何でしょうか。デザインの領域は、とても幅広いですし、たぶん人によって答えがぜんぜん違うと思いますが、今日の登壇の内容に関連づけて考えると、「プロダクトを使う人のことを考える」ではないでしょうか。

例えば「どんな背景やニーズがあって、どのようなキモチで、どういうプロダクト――アプリやWebサービスを使ってくれているのか？」「何に価値を感じて、このサービスを使ってくれているのだろう？」ということを考えることです。

プロダクト自体が具体的なアウトプットになるので、それ自体は見えるのですが、実はこの背後にある「人のこと」って、なかなか見えにくいと思っています。

そこでプロダクトというよりも、そのプロダクトの内側というか裏側にいるチームのことにフォーカスを当てて、デザインの考え方を応用して考えていきたいと思います。

OSSも経験。プロダクトを育てるのは楽しい

では、あらためて自己紹介をさせてください。株式会社キッチハイクでプロダクトデザイナーをしている羽野めぐみと申します。以前はフリーランスで2年ぐらいやっていましたが、今はキッチハイクのデザイナーとして働いています。インターネット上では「featherplain」というアカウント名で活動しているので、気軽にフォローをお願いします。

フリーランス時代は主に受託の制作をしていました。そのなかで、いつか自分の手から離れていってしまうタイミングというものがどうしてもあり、そこでちょっと寂しさというか、もっと関わって自分の作ったものを一緒に育てていきたいと思っていました。

その一方、業務外で何をしていたかというと、スライドには、テックカンファレンスと書きましたが、実際には、プロダクト開発の一連のエンジニアリングっぽいことです。OSSコミュニティ主催のカンファレンスの運営に深くコミットし、それに感化されて自分自身でもOSSを作ってみたいと思い、ゼロから作ってリリースしてメンテナンスまでしていく作業を経験しました。

そうしたなかで、多くの人と関わりながら1つのものを作り上げるのが楽しく、そしてやはり自分には、プロダクトを育てるのが、とても楽しいことだったんだなと、改めて感じました。

このような経緯から、「チームを組んでサービスにコミットするって、どのようなことなのだろう」という点に、とても興味が湧き、今は、キッチハイクに入社してプロダクトデザインをしています。

若きころ、コミュニケーションの問題で相手の不満が爆発

今日はこのキッチハイクに入社してから、私がどのようなことを考えて取り組んできたのかを話していきたいと思います。ですがその前に、フリーランス時代の失敗談をみなさんと共有します。この失敗によって、すごくチームと向き合うきっかけになったと思っています。

まず、1つ目。自分のせいでチームが炎上しかけた話です。あるプロジェクトでチームを組んで、リモートでいろいろやり取りをしていたときのこと。ある方がとても積極的な方で、頻繁に提案をしてくれたんですが。けっこう頻繁に提案をしてくださるので、通知もたくさん来ました。

ただその提案自体は、率直に言うと、そんなにすぐに「じゃあやろう！」というものではなく、またけっこう的を射ないものも多くて、実はちょっと対応に困っていました。

その当時、私は正論だけ振りかざして「いや、それは違うと思うので、このIssueはクローズします」みたいな、けっこう相手のことを考えない態度を繰り返して対応していたんですね。本当によくないと思いますが、その当時は、「いや、客観的に見て自分が正しいのだから、何がいけないの？」といったことを思っていました。

結果何が起こったかというと、「もう、あなたとは仕事したくありません」と言われてしまいました。やりとりしていたグループ上で「もう仕事をしたくありません」みたいな、けっこう長文の怒りの投稿がされました。さすがにこのとき、マズイというか、自分が相手に対して何をしていたかに気づいたのですが、私が知らないうちに相手がすごく不満を溜めていて、それがある日突然、爆発してしまったんですね。

幸い、チームのリーダーがすぐに気づいてくれて、うまくコミュニケーションをとって鎮火してくれたので、そんなに大事になることもなく、事なきを得たのですが、なかなか……。

私は今28歳なんですけど、当時は20代前半で、今よりもっと未熟だったため、コミュニケーションの引き出しも、あまりなかったなと、今振り返って思っています。今でも、とても印象に残っているできごとです。

無言のマージでメンタルがつらい

次にもう1つ、これは失敗談とは違うのですが、メンタルが少しつらかった話をします。

これは、先ほどとはぜんぜん違うプロジェクトの話です。そのときあるエンジニアとチームを組んでいたのですが、自分がGitHub上で送ったプルリクエストに対して、言葉によるフィードバックが何もないという状態が続いたのです。機械的に無言で、どんどんマージされていく状況が続いたことがありました。

これはけっこうつらかったです。何がつらかったのかというと、相手の感情が見えないというか、相手のことがわからない。マージしてくれたのはもちろんいいのですが、どういう判断をしてボタンをポチっと押してくれたのか、理由も背景もよくわからなかったので、メンタル的につらいと思いました。

体温あるコミュニケーションに必要なのは、文脈の共有

「なんでこういったつらいことが起こるのか」を考えると、炎上しかけたときもそうですし、無言マージのときもそうですが、一言でいうと、体温あるコミュニケーションが、私も相手もとれていなかったのかなと、今振り返って思います。

こうした経験から、キッチハイクでは体温のあるコミュニケーションを意識してやっています。「コミュニケーションに体温があるな」と思う条件というか要素は、文脈をお互いに共有することではないかと考えています。

先ほど冒頭で少し紹介した、この背景やキモチというところは、実はデザインする上でも、とても大事な視点です。こうしたデザインの考え方や視点をチームに応用してみると、こういういいことがあった、ということを今からご紹介します。

自分にとっていいものは、チームにとってもいいものなのか

事例として、チーム全体の体験を少し良くした話を紹介します。2019年の3月に、これまでデザイナーとエンジニアで共通して使ってきたデザイン用の共有ツール「InVision」を「Figma」に移行しました。

デザイナーがUIを作ってエンジニアに共有し、その共有されたものをエンジニアが見て、フロントやサーバサイドを実装したり設計したりするのが、具体的な業務プロセスです。以前使っていたInVisionだと、どうしても作業効率が悪かったり、プロセスが煩雑化してしまったりする課題がありました。

私も個人的にFigmaに興味があったので、いろいろと試したところ、私が感じていた課題感が、もしかしたら解決されるのではという感触を得ました。そこでチームに導入したいと思ったのですが、意識したのが、ツールを使う「ユーザー」は決して自分だけではない、ということです。チームでやっているので、私以外にも実際に使う人のことをきちんと考えたいと思いました。

確かめたかったのは「自分だけではなく、エンジニアの体験も本当に上がるのか？」「チームでワークするのか？」という視点です。そこでまずは、「私がこういうことを感じていて、こういうことを解決したい」「こういうメリットがある」「Figmaを導入すれば、こういうことが変わります」といった文脈を、ていねいにエンジニアに伝えるようにしました。

試用期間として2週間ぐらい時間をもらって、それぞれ実際に実務で取り組みました。そのあとエンジニア全員に感想をヒアリングして、相手がどのように感じていたかを、きちんと対話して把握していったのです。

結論としては、満場一致で「Figmaいいね」となりました。ここでめでたしめでたしでもよいのですが、「何に価値を感じてくれたんだろう？」ということを考えたとき、みんなが口を揃えて言ったのが、「俯瞰して画面遷移を確認できるのがすごくいいですね」ということでした。

デザイナとエンジニアで注目するところが違う

ここでもう少し踏み込んで、「じゃあ、なぜ俯瞰して画面遷移を見たいのだろう？　相手は何を求めていて、ニーズや背景があるのかな？」というのをさらに考えてみました。

そのために、簡単なサンプルを用意しました。例えばアプリ上などで、ちょっとしたアンケートがウィザード形式で続くものを想定してもらえるとわかりやすいです。

このときデザイナーであれば、「この質問設計でユーザーさん違和感ないかな」とか「ストーリーに沿っているかな」「やはりこの質問は最初のほうがいいのではないか」「言葉選び大丈夫かな」などといったことチェックしをます。

その一方で、エンジニアであれば、もちろん体験というのも見ると思いますが、やはり実装の専門家なので、重視するポイントはデータの流れやどのようにデータを処理するかであり、そうしたところにすごく関心があるというのが、キッチハイクでのエンジニアとの協業を通してわかってきました。なんかお互いちょっと考えることが違っているぞ、というのがあるんですね。

デザイナーの気持ちとしては、一連のユーザー操作をきちんと線で捉えて、あるべき体験になっているか確認するために画面遷移を見ています。その一方でエンジニアは、やはりデータの型やデータの流れを知りたいというのが、背景としてあります。

同じFigmaを見てたり同じ言葉を使っていたとしても、違う意味や視点で語ることは実はとても多く、それは文脈を共有することで、はじめてわかることなのではないかと思っています。同じものを見ていても、その先はたぶん違っていると思うので、表層的な「ことば」に囚われずに、相手ときちんとコミュニケーションをとることが、すごく大事だと思っています。