Yahoo!ショッピングのUIづくりでは相手に解釈を任せない　品質向上するために必要な意思疎通と共通目線

エンジニアとデザイナー両方を経験しているからこそ見えてくる課題

笹尾建斗氏（以下、笹尾）：私からは、品質向上に向けた意思疎通と共通の目線合わせというテーマで発表したいと思います。

私は笹尾建斗と申します。2017年にヤフーに新卒で入社しまして、現在4年目になります。iOSエンジニアとして入社して、1年半くらい前からデザイナーとしても仕事しています。

Yahoo!ショッピングとPayPayモールの両方のサービスを担当していますが、今回はYahoo!ショッピングの、特にiOSアプリに視点を当ててお話できたらなと思っています。

私はエンジニアとデザイナーの両方の領域で仕事していますが、この両方の環境に所属していろいろな目線を持てたからこそ、エンジニア側・デザイナー側で思っている課題点が可視化しやすくなったというのがあります。

今回はECデザイナーの取り組みがテーマなので、デザイン主体の話になるUIデザイン周りのことをベースに、スライドに課題点を書き上げています。

各領域で感じている課題点とかはたくさんありますが、その課題点に対してエンジニア内での課題の解決方法、デザイナー内での課題の解決方法、時にはこの点線にあるような横断をした課題解決が必要になってきます。

ただ今回はデザイナーの環境に注力しながら、デザイナーの内部で生じている問題点を洗い出して、その課題をどういうふうに解決していくのかとか、実際にどういうふうに解決したのかについて重点的に話していきたいなと思います。

課題の洗い出しから課題の解決部分のすべての部分を話しているとかなり長い話になってしまうので、前半のセッションと後半のセッションで分割してお話したいと思います。私からは課題点の洗い出しと、そこに考え方として必要なことっていうのをお話しして、後半で具体的に何をしたのかっていうところを説明します。

アプリの最終試験ではさまざまな課題が洗い出される

まず課題を洗い出すにあたって、Yahoo!ショッピングのアプリがどういうふうにリリースされているのかが少しわかったほうがいいのかなと思いますので、簡単にアプリがリリースされるまでの流れを説明しながら課題点を洗い出していきます。

今回の話のベースになるiOSアプリは、基本的には2週間に1回の頻度でリリースを行っています。リリースをするまでの流れは、ステップ1の段階で企画さん、いわゆるディレクターにあたるような部分が案件の仕様を検討し、ステップ2の段階でその仕様書をデザイナーが受け取ってUIデザインを考えていきます。

これは案件によって同時で進む場合もあれば分割をして進む場合もありますが、おおむねこういう流れで進んでいきます。そのあとステップ3の段階でエンジニアが実装をして、基本的にはそれ以降はエンジニアが主体となってリリースの作業までを進めています。

ここで1つポイントになってくることが、アプリの場合はエンジニアもUIの部分を実装しているところです。それに加えて、リリースを最終段階までもっていく結合試験のような最終試験の部分もエンジニア主体でやっているので、アプリのUIをかなりいろいろな人が見る機会が多くあります。

そうすると、Yahoo!ショッピングのアプリに対してエンジニアもデザイナーもかなりUIを見る機会が多くなってくるので、いろいろな課題点が挙げられます。例えば、使っている色の問題であったり、画像の問題であったり、状況によってはビジュアルの認識のずれっていうようなところも、この段階で課題点として洗い出しがされています。

この問題がなぜ起きているのかを考えたときに、すぐ思いつく話としてはエンジニアの意識の問題なのか、デザイナーの意識の問題なのかっていうのが浮かぶかなと思います。

「なんでそのデザインになったのか？」を共有しておく

両方の目線でいろいろ考えていったときに私が見えた1つの要因は、「なんでそのデザインになったのか？」という思考の部分がデザイナー側からエンジニアに対してしっかり共有ができていない問題があると思っています。

なので、その認識合わせが必要になってきます。例えばエンジニアとデザイナーが1つの案件を作り出すまでに見えているポイントとか重要視しているポイントはかなり違います。

例えばエンジニアであればバグを起こさないように付加対策を考えたりとか、そういう内部的なロジックも視野に入れながら作っていく必要があります。

一方、デザイナーの場合は見た目のバランスをどういうふうにしたらよくなるかとか、誤解の表現がないように作り上げるにはどうしたらいいかっていうビジュアルの部分をメインに考えながら進めていくケースがあると思います。

さらに言うと、デザイナーに関しては20名以上が1つのサービスに関わっているので、人の人数の多さや仕事の領域の関係上、どうしても各々が見ている目線がかなり異なってきます。

このように、お互いの見えているものや見えている部分が違う状態のままゴールに進んでいくと、その積み重ねで大きく認識のずれとかが起きると思っています。

じゃあ、共有できていないとどうなるのか？　というところを具体的にもう少し掘り下げてお話をしていくと、例えば今スライドに出しているようなデザインをデザイナーがエンジニアに対してデータを納品しましたと。このグレーの部分が商品の画像になっていて、その下にラベルと商品名と金額が表示されているデザインです。

このデザインに対してラベルをトルツメしたいといった状況のときに、デザイナーの思考とか情報設計の部分から赤い部分のマージンを残してトルツメしてほしいのが想定の仕様だったとします。

これがうまく共有できていないと、エンジニアのほうだと例えばどこに基準をおいてマージンを詰めたらいいのかわからなくなってしまうので、単純にトルツメをして青い部分がマージンとして残ってしまうことが起こります。

このような表現の違和感は気づくだろうなっていう感覚ももしかしたらあるのかもしれないですけど、ビジュアルのことを見ることが少なかったりとか、そういうスキルとか知識がないとこういう問題が起きてくるのかなと思っています。

共通の言語化をするには「ルールが必要」

これは一例ですが、一つひとつのモジュールとか細かいものが積み重なっていくと最終的にできあがったものがすごく違和感のあるものになってしまうことが起きています。

今回はこの1モジュールの話だけなので、なるほどなっていう感じになるかもしれません。例えば端末のサイズ違いとか、テキストを折り返すときに何段まで表示させるべきなんだっけ？　っていうところが漏れていると必要な情報が表示しきれないままリリースされてしまうようなことが起きてしまいます。

その共有の漏れを防ぐためには、まずはデザイナーの中でも共通言語をもち、デザイナーとしての考え方をしっかり共有していく必要があります。また、自分が考えていることを伝えなくても相手が解釈してくれるだろうと思わない、ということがすごく重要かなと思っています。

自分の考えを間違った解釈にさせないためには、自分がどういう考えをもっているかをしっかり伝えることが必要だと思います。例えばここで今書き出しているようなかたちで共通の言語をもっていたり、フォーマットだったりデータの扱い方とか、そういうのも含めて共通のものが必要になってくるのかなと思います。

運用とガイドラインの改善チームを結成

今までのYahoo!ショッピングの環境には実はこういうものがあまり存在していませんでした。どうなっていたかと言うと、歴史も長くて、人がたくさん関わっていて、なおかつ改修規模とかも大きくなっていくような規模の大きいサービスなのにルールが個人個人に偏っていたりしました。

デザインのレベルで言うのであれば、どこに合わせるのかがわからなかったり、各々がデータをもっているので、そのデータがどこにあるのかも不明な状態だったので、例えば1つの案件を探し出すために担当者は誰かから探すようなことが必要になっていました。

なので、まずは環境を調整して、必要なものは足していく必要があるのかなというところから、2018年6月にアプリのデザインを改善するプロジェクトが動き始めました。このPJはデザイナーとエンジニアが関わった全9名で動いていて、このとき私はまだデザイナーではなかったのでエンジニアとして関わっていました。

ただこの計画が、実は3ヶ月くらいで解散となってしまいました。理由は、期の変わり目で組織の変更があったり、あとはAndroid、iOSと分割しながらかなり大きい規模で改修をしようとしていたので、今までの状態でも回ることは回るのでっていうことで戻ってしまった感じです。

そこからしばらく時間が経って、自分もデザイナーとして仕事に関わっていくようになって、やっぱり必要なことはどんどん導入していくべきだし、少しでも環境をよくして最終的に全体の品質が向上できればと思い、2019年、約1年前に運用とガイドラインの改善で再結成をしました。

今話している自分と、次のセッションで話してもらう関さんの2人で改善計画を立てながら行動を取っています。

具体的にそこでは何をやっているのかと言うと、まずはデザイナーの内部向けのところから情報を整理していく必要があるので、マスターデータを作ったりとか、保存方法だったり命名規則の運用面のアップデートと。あとはデザイナー同士やデザイナーとエンジニアをつなぐための仕様書をフォーマット化して、アップデートしました。

さらにデザインを作り出していくための共通のルールも必要になってくると思いますので、ガイドラインを新しく導入するっていうこの3軸を立てながら4つのことを改修していきました。この4つで具体的にどういう改修をしたり、どういう導入をしたのかは次のセッションでお話をしてもらいたいと思います。

自分の考えをしっかり伝える一言が大切

私のセッションのまとめとしては、小さい案件でもどんな状況だったとしても、エンジニアとデザイナーとか、デザイナー同士とか、いろいろな人と関わってくるような場合にはやっぱり必要なコミュニケーションは取っていく必要があるということです。自分の考えをしっかり伝える一言が大事かなと思っています。

全体の方針のずれを防ぐためにも、部やチームから共通の認識を持てるようにガイドラインは最低限設けることっていうのも必要だと思っています。

そして自分のいる環境になれてしまうと、新しい課題点とか解決方法を見つけ出したりするのは難しくなってくるといます。

できるだけ広い視野をとる、あるいは自分のようにエンジニアとデザインの両方を見ている人がもしいるのであれば、いろいろな人から意見を聞いてみて、自分の部はどういうふうに見えているのか確認できると新しい課題点や問題点は見つけ出せるのかなと、自分は思っています。

ということで、この3つが大きい組織とかで動いたり、職種をまたいだ動き方をしていく仕事が多くなる場合には必要になってくるんじゃないかなと私は思っています。私からは発表は以上になります。