理想のデザインチームを作れると感じ、トレタに入社

私は、シックスアパートのデザイン責任者、クックパッドのデザイナーを経て、トレタに入社しました。

経験を積んでいくなかで自分なりの「デザインチーム・デザイナーの仕事」の具体的なイメージができていって、そして、それを実現できる環境を作りたいと思っていました。

ゼロからチームを作れるような機会って、そうそう無いと思います。もし機会があっても、創業者や経営面での理解はなくてはらないものですので…。デザインという視点から、経営にも関われる環境が必要だと考えました。

弊社は代表の中村が、デザインを非常に大切にしています。声をかけられた時も中村のデザインに対する思いを聞き「この人の下であれば、自分のやりたいことが実現できるんじゃないか」と思ったんですね。

デザインは「美しい画面」だけでなく「課題解決の設計」を提供

僕自身、デザインというものは、「美しいものを作る」とか、そういうことだけではないと思っています。

まず目的や課題があって、あくまでもそれを達成に導いたり、解決するためにどうあるべきかを考え、作りあげていく過程がデザインです。 その過程を経て作成した設計情報が、プロダクトの価値につながっていきます。

例えばお客さまがトレタを選ぶ理由は、iPadのアプリがswiftという言語で書かれているから、などでは無いと思います。お客様は、自分の仕事が楽になる、もっと質の高いおもてなしを実現できる、ということに価値を感じ、トレタを選んでいただいているわけです。

そういった体験を含めた設計を、デザイナーが責任を持って作っていくことが重要だと思っています。

トレタの「デザイン部」としての取り組みとは

チームメンバーは、現在、私を含めて5名です。

アプリのデザインを行うメンバーの他に、販促物などの営業ツールのデザインも行うメンバーもいます。デザイン部としてはひとつのチームなので、全体のアウトプットになるように、レビューしあったり、担当範囲に関係なくデザインについて話す機会を設けています。

デザインをかためていく過程は、GitHubのIssuesを使って運用しています。単純に完成したデザインを載せていくのではなく、なぜこうしようと考えたのか、どういう課題を解決しようと考えているのかを言語化して、決定に至るプロセスを見える化するように気をつけています。

▼GitHubのIssues上で、デザインをかためる過程を可視化

何を考えてデザインをしたのかを残しておくことで、セールスチームを含めたメンバー全員が「こういう理由でこのような画面になっています」ということを、お客様にも説明できます。

デザインの進捗は、「Trello」で確認できるようになっています。私たちは、単純な進捗確認はとても無駄だと思っているんですね。ですので、Trello上で誰が今何をやっていて、今週何を終わらせたか、今後何をするのかを、メンバーがいつでも確認できるようにしました。

▼実際に同社が活用しているTrelloのボード

結果として、デザイナーの定例ミーティングにおける進捗確認は無くなりました。そしてせっかくのデザイナーが集まる機会を、デザインのレビューや仕様の議論を中心とした内容にできるようになりました。

BtoBサービスでは、仮説検証プロセスを数多く回すことが重要

トレタは、飲食店に向けたサービスで、いわば「仕事道具」を提供しています。そういった背景から、「効果が出なかったら止めましょう」という、「試してみる」開発フローをとるのは難しいです。リリースしたタイミングでもう、ある程度大きな責任が発生します。

そのため、開発前に仮説検証をしっかりと行っています。

価値仮説に基づいた機能定義とプロトタイプ作成を行い、それをセールスと一緒にお客様のところに持って行って、検証するというフローを取っています。実際に開発を始めるまでに素早く何度も失敗を重ねることで、精度を高めていくという取り組みです。

「デザインプロセス」は、大量の手書きの画面案から始まる

具体的なデザインプロセスで言うと、まずはユーザーの欲求と課題をしっかりと定義します。その上で、作る目的、機能の名前、一言で言うとどんな機能なのか、ターゲットユーザーなどを明確にしています。

そこから、ペーパープロトのような物を作っていきます。特に新しい機能では、要件が決まった段階でいきなりデザインを作ってしまうと、細かい余白や既存機能との整合性などの細かい部分に気が回ってしまいます。

そこでまずは紙に、手書きで大量の画面案を書きます。

▼実際に手書きで書かれた、画面案の一例

そうして各状態の画を並べ、遷移図を作り、自分たちが定義したコア機能が、お客様にきちんと届くかを検証します。ペーパープロトの結果、仮説のところからやり直しになることもありますね。

「プロトタイプ」は、できるだけユーザーが触れる画面を「再現」

その後はデザインを「Sketch」に書き起こして、1個1個のボタンを押したらどうなるか、細かい部分までを作っていきます。そして作ったデザインから、「Flinto」を使ってプロトタイプを作ります。

▼Flintoで制作された、実際のプロトタイプ（一部切り取り）

Flintoでのプロトタイプは、できるだけ実際にユーザーが触れる画面を再現するようにしています。

例えば、画面遷移でローディングが発生するところや、文字を入力するときにキーボードが表示されるなど…わかっているからといって、省いてしまいがちなところも再現します。

この段階で出てくるものを、セールスチームに渡すことも多いです。そしてお客様からフィードバックをいただくのですが、その要望も一度解釈をして、解決に至っていない課題と、その理由はなんなのかなどを明らかにするようにしています。

インタラクションのデザインは「Keynote」を使ったり、参考にしたサービスを共有したりします。弊社のエンジニアは、このあたりに関してもとても良い知識を持っているので、イメージを伝えて提案してもらうことも多いです。

BtoBサービスですと、画面遷移などを派手にするわけにはいきませんが、道具として手になじむと感じられるものだったり、使っていて楽しい、トレタを使って仕事をしたいと思っていただけるように、様々な部分に気を配っています。

ユーザーテストは「普段サービスが使われている」現場で

開発が進むと、既存のお客様にベータテスターとしてご参加いただいています。テストですと伝えて、構えて使っていただくのではなく、普段の使われている現場で実践導入いただくことで「自然に」使ってもらうことを意識しています。

こういった仮説検証の中で気が付くことも、実は多くありますね。

お客様の要望に対して、解決策を提案するのもデザイナーの役目

また、既存のお客様から営業チームに出る要望は、「Googleフォーム」に入力してもらうようにしています。

その要望と、ユーザーがアプリで入力したフィードバックが、チャットツールの「Slack」に通知されるような仕組みです。

そこで出てきた1つひとつの質問や要望に対して、回答するのもデザインチームの役割です。セールスチームのメンバーとは週一回、集めてくれた要望について話します。その場所が、要望の中から課題を見つけ出す機会にもなっています。

そして、お客様がその要望を実現されることで何を得たいとお考えなのかを理解するためにも、私たちは「現場に行くこと」をとても大事にしています。

要望が発生している現場に行って、その場に身を置きながら、直接声を聞くことで要望の奥に潜む課題は明確になります。「要望の聞き方・解釈」はとても重要ですね。

例えば、いまトレタに備わっている「テーブルレイアウト」という機能を実装したときもそうでした。

▼トレタの「テーブルレイアウト」機能

この機能に関しては、僕が入社する以前から「欲しい」という声をいただいていて、何度かトライした経緯がありました。ただ、なかなか形にできず…。

そんな中、改めて「作ろう」となったときにはまず、「本当にないとダメなのか」ということを、既存のお客様に聞きに行くことから始めました。

お客様の課題をしっかりと分解して考えることで、「本当の課題」が見えてきます。このケースで言うと、「いま来店した方をどのテーブルにご案内したらいいか」「もうすぐ空きそうなテーブルがどこにあるのか」といった、「現時点での状況」を素早く確認したいというニーズがあることがわかりました。

これまで提供していた時間軸での予約管理と、空間軸での予約管理という視点の違いを明確にできたので、新機能として開発することを決めました。

▼もともと提供されていた、時間軸での予約管理ページ

BtoBtoCの世界を見据えて、より「価値」に注力していく

いま私たちが進めているプロジェクトに、POSシステムのような外部サービスと連携をし、より飲食店とそのお客様に高い価値を届けるというものがあります。

業務効率化を超えてその先のお客様まで価値を提供する意味でも、BtoBtoC と言って良いと思います。

そうなってくると、トレタだけでは完結しないことが増えていきます。連携企業様との取り組みのなかで、そこでも我々が実現したい世界をしっかり伝え、開発をすすめる関係づくりを重視しています。

そのような背景から、私たちデザイン部がしっかりとプロダクトマネージャーとして開発の中心となり、リードしていけるようになる必要があると思っています。より一層お客様に提供する「価値」に注力するためにも、今後さらにデザインプロセスを詳細に作り上げていきたいです。（了）