2021.05.31 B2B SaaS Business

驚きではなく、違和感なく使えるUIを――FellowとUIデザイナーが語るフロントエンドの重要性

2020年10月に誕生した、ユーザベースのエンジニア組織の新たな役職「Fellow(フェロー)」。ユーザベースB2B SaaS事業のサービス開発に携わる板倉大輔は、10月にFellowに就任したエンジニアの1人です。現在複数のプロジェクトを兼任する板倉は、開発過程の中でも特に「フロントエンド」へ強いこだわりをもっています。ユーザーの第一印象に直結する「フロントエンド」に対して、エンジニアとUIデザイナーがどのような視点で臨んでいるのか、CDOの平野とUIリードデザイナーの茂木を交え、事例と共に語ってもらいました。

板倉 大輔DAISUKE ITAKURA

ユーザベース B2B SaaS事業 Fellow

SIerにて複数のFXトレーディングシステムの開発に従事。2012年にフリーランスとして独立。ユーザベースには、2013年にフリーランスとして参画。NewsPicksの立ち上げ時期から開発に携わる。2017年にSPEEDAの開発チームへ異動。2019年より正社員となりBtoB SaaS事業の各サービスの開発に携わる。

茂木 孝純TAKASUMI MOTEKI

ユーザベース SaaS Design Division / Lead UI Designer

2011年にUfit(現TIS)に入社しJavaエンジニアとして業務システム開発やインフラ構築を担当。2014年にデザイナーへ転向し、モンスター・ラボに入社。WEBサービスやアプリの情報設計とUIデザインを担当。クライアントワークを中心に数多くの案件に関わる。担当したサービスがiOSベスト新着APPに2度掲載される。2019年にユーザベースに参画し、B2B SaaS事業でのUIデザインを担当。現在はFORCAS Salesのリードデザイナーとして、デザインの力でプロジェクトを牽引することを大切にしている。

平野 友規TOMOKI HIRANO

ユーザベース SaaS Design Division CDO(Chief Design Officer)

株式会社デスケル 組織デザイン顧問/株式会社UB Ventures クリエイティブパートナー 多摩美術大学情報デザイン学科卒業、東京藝術大学大学院デザイン専攻修了。2017年にDesign school Kolding(デンマーク)で客員研究員。トランスコスモス、コンセントを経て、2011年にトライアンド(現 デスケル)を設立。 2019年にユーザベースのSPEEDA事業に参画。主な仕事は、SPEEDAのデザインマネジメント、三菱重工業の社会インフラ事業のDX推進に向けたビジョン策定支援、RICOH THETAの新規事業開発時におけるUX / UIデザイン。

驚きではなく、違和感なく使えるUIを

――はじめに、Fellowに就任したときの率直な想いを教えてください。

板倉大輔(以下:板倉):
率直に言うと、「あぁ、そうなんだ」ぐらいですね(笑)。Fellowに就任したからといって、特に意識は変わっていません。ただ就任後、複数のプロジェクトに携わるようになりました。これは以前より私が上長にリクエストしていたことで、Fellowに就任したタイミングでやることになりました。最近ではB2B Saas事業の中でも、セグメント比較という機能と、NewsPicksExpertの開発を主に担当しています。

――板倉さんが開発過程の中でも、特に「フロントエンド」を大切にしているのはなぜなんですか?

板倉:
一言で説明するのは難しいですが、「フロントエンド」はユーザーが最初に触れる場所なので、ここでどのような印象付けをするのか、設計が非常に重要だと感じています。

少し前までは「ユーザーに驚きを与えるフロントエンド」が良いと思っていたんですが、その感動って実は長続きしないんですよね。普段使いできるアプリって、やはり違和感なく使えるアプリなんです。そのことに気づいてからは、いかに初回のアクセスで違和感なく使っていただけるか? が重要だと思うようになりました。慣れ親しむというより、使いやすいUIになっているかどうかですね。それをUIデザイナーの茂木さんたちと一緒に作り上げていきます。

茂木孝純(以下:茂木):
ユーザベースでは、新たなプロジェクトを走らせるとき、板倉さんたちのような開発チームと、私たちのようなデザインチームが常に相談しながら進めていきます。板倉さんとは、新規事業のFORCAS Salesプロダクト開発の際に、初めて一緒に動くことになりました。

――違和感のないフロントエンドが重要とのことですが、デザイナーとしてフロントエンドを設計する際に、留意していることがあれば教えてください。

茂木:
板倉さんがおっしゃった「最初の印象になるからこそ、違和感のなさが重要」という点は、私も全く同感です。

たとえばフロントエンドにあたるページに、見た目が同じ2つのボタンがあるとします。ボタンAを押すとこういう動きをするけど、ボタンBは全く違う動きをすると、ユーザーは混乱しますよね。何が起きるか分からないのって、不安になるじゃないですか。

デザインチームでは、使い勝手や見た目の一貫性をデザインシステムで表現するんですが、デザインのパーツや挙動を何のルールもなしに作ると、もう本当にフリーダムというか、無茶苦茶なものができるんです。

セオリーがないと、エンジニアも「何でこのときはこのボタンで、別のときはこのボタンなの?」と混乱するし、開発の工数もかかるし、ユーザーにとっても使いにくいサービスになってしまいます。そうならないためにも、デザインシステムをしっかりと作りこむことで、結果的にフロントエンドにも効いてくると実感しています。

平野友規(以下:平野):
フロントエンドがいいプロダクトって、たいてい使いやすいですよね。最近非常に感銘を受けたサービスがあるんですよ。多くの情報量を取り扱うサイトなんですが、ユーザーにとって使いやすいし、ボタンの定義もきちんとしているので、ユーザーが不安にならないなと。

情報量が少ないものを整理することは簡単だけど、情報量が多いものを整理するのは難しい。ユーザーインターフェイスやフロントエンドをどう魅せるかが非常に重要なんです。僕が感銘を受けたそのサイトでは、グラフの見せ方も非常に効果的で。

しかもオープンソースソフトウェアを普通に使っているんですよ。自ら開発する部分をどこに置き、どの部分で外部サービスを使うのか、判断が潔いんです。自分たちのコアバリューがどこなのかを見極め、いわいゆる「車輪の再発明」をしないフロントエンドは、もしかしたら非常に重要なのかもしれないと思いました。

開発者とデザイナー、それぞれから見る「絵に描いた餅」

――同じプロジェクトを異なる立場から動かすときに、互いに心がけていることはありますか?

茂木:
プロジェクト自体が「絵に描いた餅」にならないように気をつけて発言するようにしています。「絵に描いた餅」、つまり実現できない、スケジュールに全く見合っていない構想に陥らぬよう気をつける一方で、その餅を描く方法を模索することも重要です。

足元を見すぎて、実現可能なことだけを淡々と積み上げていくと、ユーザーの理想からはかけ離れたプロダクトに仕上がってしまうんです。かといって、ハイパーテクノロジーをひたすら駆使する構想も現実味がない。その中間にくる、「ちょうどいい塩梅」を常に模索するんですが、板倉さんはその塩梅を見つける感覚がすごく鋭いんですよ。

――具体的な事例はありますか?

茂木:
FORCAS Salesのプロダクト開発で板倉さんと一緒だったとき、使用シーンのイメージを開発とデザインで進めていたんですね。その際、インサイドセールス担当の方がFORCAS Salesで企業情報を調べ、それを営業担当に共有するシーンの話になりました。どのように共有するのが最も効率的だろうか? とチームでディスカッションしていたときに、板倉さんが「シェア用のURLを1クリックで発行して、そこにアクセスさえすれば、営業担当も同じ情報が見えるようにしたらどうだろうか」と提案してくれたんですよ。開発も複雑にならないし、共有するインサイドセールス担当の方の時間も手間も一気に省ける。さすがだなと思いました。

板倉:
私はデザイナーさんと一緒に仕事をする際、さっき話にでた「絵に描いた餅」を実際に作っちゃうようにしています。デザイナーさんが魂込めて設計してきたものを、開発側から「つくれません」とは言いたくないんですよ。

チームとしてより良いものを目指していくために、デザイナーさんにあまりブレーキを踏んでほしくない。デザイナーさんがいつでもアクセルを踏めるように、0→1のタイミングで実際にユーザーに使われるものを意識し、スピード感をもって開発するようにしています。

――平野さんと茂木さんは、以前にも「UB Journal」に登場しています。その際、開発やビジネス担当とコミュニケーションをとる際、共通言語をもつよう心がけていると話していましたよね。

茂木:
はい。基本的には以前の記事でお話したことを引き続きやっているんですが、最近Design Division内で「Vision(ビジョン)」なるものを作りました。私たちのチームは「DESIGN FORWARD」で事業を前進させることを掲げています。


これはデザインの力を使って事業やプロジェクト、人を引っ張っていくことや、デザインチームとしてこうありたい、やっていくぞという想いを言語化したものです。私個人としても、ユーザベースに入ってからずっと「DESIGN FORWARD」をやりたいと考え、チャレンジしているところでした。

また、社内向けに「UI Design Book」というドキュメントも作りました。ユーザベースでは、デザイナーだけでなく、技術関連やカスタマーサクセスなどさまざまな部署や担当が集まり、みんなでUIを作ったり議論したりする機会が多くあります。

業務や管轄が異なるメンバーが集まり、UIやデザインについて話をするんですが、全部署に共通する言語が存在しなかったんですね。それを解消すべく、UIをつくるうえで大事なポイントを明文化したのが、この「UI Design Book」です。


UI Design Book

――全25ページと壮大なドキュメントですね。これをつくったことで、どんな変化がありましたか?

茂木:
これは私を含めUIチームのデザイナー3名で制作しました。共通言語を作ったのは、単に話し合いをスムーズに進めることだけが目的ではありません。エンジニアやビジネスサイドに展開することで、みんなで目線を合わせ、同じ目標に向かって議論していくことが一番の目的です。

その後メンバーへの個別説明を経て、現在はプロダクトを跨いでUIや仕様について議論する時間が週2回あるんですが、そこでもしばしば言及され立ち返る契機になったり、エンジニアやCSの方が「8割のユースケースってなんだろうね?」と言葉を引用してくれたりするシーンが徐々に増えてきたように思います。

板倉:
互いに共通言語をもって話をしようという意思はあるんですが、これまで会社として明確な「共通言語」はなかったんですよね。「UIデザインブック」の登場を受けてUIチームが徐々に変わってきているのを感じ、開発サイドとしても非常にわくわくしています。

スピードとクオリティの担保の秘訣は「スコープの切り方」

――板倉さんと茂木さんは、FORCAS Salesのプロダクト開発のプロジェクトで初めて一緒だったとのことですが、プロジェクトの難しさ、やりがいについて教えてください。

茂木:
新規事業でデザインシステムを作るのって結構大変なんですよ。これからどんな機能が追加されていくのかわからない中でデザインのベースになる部分を作るので、どんな風にデザインが育っていくのかを想像しながら手探りで組み立てていくんです。

後々の手戻りなどを考えると、全体像がある程度見えたタイミングで一機能の作り込みを始めるほうがいい。作ったものが無駄にならない方がエンジニアにとっても嬉しいはずですから。一方リリースまでのスケジュールを考慮すると、ゆっくり全体像を詰めている時間もないので、目の前の一機能をどんどん形にしていく必要性にも迫られて……。

でも板倉さんの開発スピード、めちゃくちゃ速いんですよ。さっき「絵に描いた餅を作っちゃう」という話がありましたが、まさにそう。「素早くTRY & ERRORのサイクルを回していこう」という姿勢で接してくれるので、非常に進めやすかったです。

板倉さんは、「スコープを小さく切っていく」ことを常に意識されていて、「どう区切れるか」みたいな部分をよくアドバイスしてくださいました。

――「スコープを小さく切る」とは、どのようなイメージなんですか?

茂木:
プロダクトをつくる過程で「これって本当に正しいんだっけ?」って、開発もデザインも何度も自問するんですが、最後はやはり実際にユーザーに使ってもらわないとわからない部分も当然あります。でも何ヶ月もかけて作った機能が使われなかったら悲しいですよね。なので、まず一番重要な部分を切り取って作ったり、提供する判断が必要なんですが、この切り取り方が板倉さんは絶妙なんです。

板倉さんから「じゃあまずこの形でやってみませんか」という提案をたくさん受けたなと思っていて。それが結果的に、サービスリリースまでのスピード感を早めたんだと考えています。

――どのぐらいのスパンで作り上げたんですか?

板倉:
フロントエンドのベースを作ったのは3ヶ月ぐらいですかね。その後は粛々と、少しずつ洗練させていくみたいな感じになっていたと思います。スコープの話でいうと、小さく切って、作って、リリースして、フィードバックをもらったら修正して――これを最後まで繰り返しました。

茂木:
外部提供する前に、まず社内のユーザーにテスト利用してもらうんですよ。そうすることで、いろいろなフィードバックが来ます。ポジティブなものもあれば、当然ネガティブなものもたくさんあって。想定どおり「良い」と言ってくれる意見もあったし、悲しくなったのもあったし(笑)。

――特にフロントエンドはユーザーの好みで左右される部分があると思うので、判断軸が難しいように思います。

茂木:
基本的にはサービスのペルソナを理解し、使ってくれるユーザーの声を一番大切にしています。でもそれだけを頼りにしていると、あれもこれもと機能やデザインを追加し、結果的に本質的ではないものが出来上がってしまうことが多いんです。

なので、「何が本当にいいのか」をプロジェクトメンバーでよく話し合っていました。そのうえで最後は自分たちで考え抜いたところを拠り所にする――信じたものを出してみて、ダメなら改善していくことを繰り返していました。

――板倉さんはフロントエンドのゴールをどこに置いていますか? 「いい仕事した」と思える判断基準があれば教えてください。

板倉:
難しいですね。プロダクトの特性にもよるんですけれど、「自然とさわっちゃう」とかですかね。やはり違和感なく日々使えることが大事かなと思います。

茂木さんと一緒だったFORCAS Salesのプロジェクトでは、「これって本当にユーザーに刺さるものができているのか? 作れているのか?」と、自問を繰り返しながらつくっていきました。

AIが「フロントエンド」を作る時代、人に求められるのは「職人気質」

――今後、自分のキャリアとフロントエンドをどのように結び付けていきたいですか?

平野:
今後はノーコードでフロントエンドが作れる時代に突入すると思います。今でもデザインデータをアップすると、いきなりコードが吐き出されて、AIが一瞬でフロントエンドを作るようなサービスがあります。そうなってくるとフロントエンドにおいて人がやる部分には、かなりの職人気質やカリスマ性が求められる可能性があります。

別の観点でいうと、茂木さんが先ほど「デザインシステム」と話していましたが、私も今SPEEDAのデザインシステムをつくることに注力しています。行き着く先は、そのデザインシステムの中にフロントエンドのコード――CSSスタイルなどを埋め込んで、コピペすればできるような世界を作りたいと思っているんです。

たとえばSPEEDAでいうと、SPEEDAのカスタマーサクセスが何か新たにちょっとした改善をしたいという場面があったとします。そのときに、わざわざデザイナーに頼まなくても、そのデザインシステムを使ってCSSコードをぱっと貼り付けると、プロトタイプレベルで簡単に試せる。そんな状態を目指しています。

板倉:
少し技術的な話になってしまうんですが、昨今HTMLでもカプセル化できるようになっています。具体的にはWebComponentsという技術です。今後はこの技術を取り入れて、より柔軟かつ高速にプロダクトを作れるようにしていきたいです。レガシーブラウザのサポート次第となる技術ですが、一部プロダクトでは適用可能なので、小さく始めていきたいと考えています。

茂木:
フロントエンドでいうと、今後インタラクション周りがリッチになっていくと思っています。「リッチなインタラクション」とは、無駄に派手なアニメーションなどではなく、ユーザーにとって本当に必要な情報をリアルタイムで出していくというか、ユーザーの行動にしっかり吸い付いていくイメージです。

細かいインタラクションがあると、それだけで使いこなせている意識になり、ユーザーの気持ちが上っていくと思うんですよ。その理由が通信速度なのか、フロント側のパフォーマンスのチューニングなのか、まだ分析しきれていないですが、ローディングの時間ひとつをとっても、それが短いだけで途端に使いやすいサービスであるように感じる。インタラクションがすごく気持ちいいフロントができたら面白いなと考えています。

板倉:
細かなインタラクションはB2Bのプロダクトでもやっていった方がいいと思うので、一緒にやれたらいいですね。

ユーザベースでは
仲間を募集しています。

Choose Brave.

採用情報を見る

UB Journal is powered by Uzabase, inc

01 自由主義で行こう 02 創造性がなければ意味がない 03 ユーザーの理想から始める 04 スピードで驚かす 05 迷ったら挑戦する道を選ぶ 06 渦中の友を助ける 07 異能は才能

Related関連記事

See more
  • 2021.05.31 B2B SaaS Business

    驚きではなく、違和感なく使えるUIを――FellowとUIデザイナーが語るフロントエンドの重要性

  • 2021.04.12 B2B SaaS Business

    エンジニアに管理職以外の選択肢を――「Fellow」が語るエンジニアの多様なキャリアパス

  • 2020.12.09 B2B SaaS Business

    データ×人の力で、パナソニックの新規事業開発コンテストを加速

Latest最新記事

See more
  • 2021.07.28 NewsPicks

    新聞でいうなら一面と速報を考える人――NewsPicksの顔をつくる編成(コンテンツ・キュレーション)チームの仕事

  • 2021.06.29 Uzabase Corporate

    ミッションとバリューを軸に、1人ひとりが自走している組織を作る――ユーザベースのカルチャーチームが目指す未来

  • 2021.06.17 NewsPicks

    「正解がない道を自ら思考し意思決定する」――大手SIer出身の2名が語るNewsPicksのエンジニア組織のリアル