こんにちは、Goodpatchでサーバーサイドエンジニアをしているかみのうらです。

先日Goodpatchで第３回目となるEngineer Meetupを開催しました。
今回のイベントでは70名の参加枠に対し、200名以上もの方にご応募いただきました。今回は大盛況のうちに終わったMeetupの内容をご紹介させていただきます。

今回のテーマは「エンジニア目線で考えるデザイン」でした。
Goodpatchではエンジニアは常に開発だけではなく、デザインの提案をしたりするなど、UI/UXに深く関わりながらサービスをつくりあげていきます。そんなGoodpatchのエンジニアがどんな風にデザインと関わりながら開発を進めているかを発表させていただきました！

よりよいUXを実現するための開発プロセスとは

まずは初めにiOS、Android、Webと幅広く活躍しているデベロッパーの重田から、より良いUXを実現するためにエンジニアとしてどのように開発プロセスに関わっていくのかお話させていただきました。

開発プロセスの中でプランニングやデザインの段階がうまくいっていない時は、後になってエンジニアが苦労することもしばしば。そうならないためには開発プロセスの中に存在する「不確実性」を見極めてプロセスを設計することが大事になってきます。

不確実性については以下の３つが挙げられます。

  1. 技術的に実現できるか不確実
  2. ユーザーにとって価値があるのか、ユーザーにどんな形で届けるのが最適かが不確実
  3. 要件が不確実

技術的に実現できるか不確実

サービス開発において終盤になって実現不可能だと判明することは最大のリスク。そのような、そもそも「技術的に実現できるかどうか」という不確性がまず挙げられます。

では、いかにしてその不確実性を排除するのか。実際の例を交えながらご紹介します。集中力を可視化するJINS MEME OFFICE 2.0というサービス開発に携わった時は以下のようなことが技術的な不確実性として存在していました。

  • 文字盤にどういう情報を出せるのか
  • OSの制約などを考慮するとどれくらいの頻度で更新、反映ができるのか

このような不確実性を排除するために簡単なデータを文字盤に反映させるというようなシンプルなプロトタイプをつくり、何が実現可能かを調査しました。そしてそのプロトタイプをクライアントに見せることにより、合意形成もスムーズに進みました。

ユーザーにとって価値があるのか、ユーザーにどんな形で届けるのが最適かが不確実

次にユーザーにとって価値があるのかどうか、という不確性があります。
この不確実性を排除しておかなければ長い時間をかけてサービスをつくったものの、それがユーザーに刺さらない。というようなことが起こり得ます。

そうならないためにはサービス開発の序盤でプロトタイピングしながら開発を進めて行く必要があり、その時に大切となる視点が「当たり前品質」と「魅力品質」です。
「当たり前品質」とはユーザーにとってあって当たり前で、ないと困るような機能。一方で「魅力品質」とはなくてもサービスとしては成り立つが、あったら嬉しい機能のことで、他のサービスではなくそのサービスを使い続ける要因になるものを指します。
「当たり前品質」は着々と開発し「魅力品質」にフォーカスしてプロトタイピングすることでユーザーにとって価値があるプロダクトに近づいていきます。

要件が不確実

そして最後に要件の不確実性が挙げられます。
サービス開発のリスクの1つとして、開発段階で当初想定できていない要件に後から気づき、スケジュール内での実装が難しくなっていくことがあります。そしてそれは結果としてバグや動作の重さを引き起こしてしまいます。要件の不確実性を完璧に排除することは難しいですが、不確実性をできるだけ減らす方法として3つの方法があります。

1つ目はAssumption Mapping。プロジェクトを進める上で曖昧になっていることを付箋に書き出し、未知・既知、リスクが高い・低いでマッピングする方法です。チーム内で認識をあわせリスクが高く未知の項目から対策を講じます。

2つ目はUIまで一貫したデータモデリング。
サービスを利用する登場人物やユースケースを洗い出し、考慮もれが起こらないようにします。特に当たり前品質が多く求められるサービス（例えばECなど）では重要です。
また「形態は機能に従う」という言葉があるように「UIはデータ構造に従う」と感じていて、DBやAPIによって表示できるUIはある程度決まってきます。後から「UIを変更したいけどDBやAPIの構造が決まってしまっているために変更しづらい」ということが起きないように、エンジニアが情報設計の段階から関わっていく必要があると重田は話していました。

3つ目は要件が確実になっているところから先につくり始めることです。そうすることによって、パフォーマンス・チューニングやブラッシュアップの期間をしっかり確保することが大切になります。パフォーマンス・チューニングというのはエンジニアにしかできないUX改善であり、特に重要だと話していました。

フロントエンド的Webベースプロダクト開発でありがちなボトルネックとその解決法

続いてフロントエンドエンジニアのじぇしーからWeb開発におけるボトルネックとその解決法についてお話させていただきました。

「Webベースの開発において、クリエイティブの追求を阻害する第一要因はWeb開発独特の煩雑さ。まずはその煩雑さ(ボトルネック)を解決することからクリエイションは始まる。」という考えから今回のテーマとしたとのことでした。
Web開発で直面しがちなトラブルとしては、以下の4つがあるようです。

  1. クロスブラウザチェック
  2. プロジェクトごとに自家製ビルドツールが使われていて引き継ぎ工数がかさむ
  3. CSS命名規則が守られておらず、複雑すぎてリファクタリングが不可能
  4. HTML/CSSをWordPressやRailsへ組み込む作業が退屈でミスがかさむ

クロスブラウザチェック

1つ目にクロスブラウザチェックです。対応する必要のないブラウザを明確にして削ることが重要と話しており、適切なサポートブラウザを決めるために要件定義段階からエンジニアも積極的にプロジェクトに参加していくべきとのことでした。

プロジェクトごとに自家製ビルドツールが使われていて引き継ぎ工数がかさむ

2つ目はプロジェクトごとに独自に組まれたビルドツールの引き継ぎに工数がかかるということが挙げられます。その対策としては社内にフィットした統一のビルドツールを、既存のビルドツールなどを参考にしながら作るのが良いとのことでした。

CSS命名規則が守られていない、複雑すぎてリファクタリングが不可能

3つ目はCCSの設計が複雑すぎてリファクタリングが不可能になってしまうというです。「CSS設計は破綻する」という前提の元、次のような方針でCSSコーディングをしているそうです。

  • 解釈に余地のある命名規則を導入しない
  • マイナーな命名規則を導入しない
  • 継承やSassのネストを利用しない

HTML/CSSをWordPressやRailsへ組み込む作業が退屈でミスがかさむ

最後はHTML/CSSのWordPressやRailsへの組み込み作業が挙げられます。
その対策としてDockerやVagrantなどのgitで共有可能(コードベースで共有可能)な仮想環境を構築し、直接CMSのテンプレートをコーディングしていっているとのことでした。

ユーザーインターフェイス解剖学

最後にiOSデベロッパーのusagimaruから、優れたプロダクトを解剖することで分かってくるデザインの意味についてお話をさせていただきました。

UIコンポーネントの実装を考える

アプリケーション開発においてUIコンポーネントは、公開されているUIライブラリを用いる方法と自作する方法があります。UIライブラリは開発時間を短縮でき、UI以外に注力することを可能にしてくれるので非常に便利なものです。しかし、アプリの設計をUIライブラリの設計に合わせなければならなかったり、たいていは意図した通りの動きにならなかったりと扱いづらいことが多々あります。そのためユーザーインターフェイスをきちんとデザインするのであれば、UIコンポーネントは自作する方が良いと感じています。
実際に中川政七商店さまの「さんちの手帖」アプリ開発においても、UIは作っては壊しを繰り返しながらすべて自ら実装しました。御朱印帖のようにスタンプを集められる機能「旅印（たびいん）」は、自らPhotoshopで用いて画像合成処理を試行錯誤したり、旅印を獲得した際の押印アニメーションにはiPhoneのTaptic Engineを利用した触覚フィードバックを取り入れたりしていました。

ユーザーインターフェイスを理解する

usagimaruは正しく美しいプロダクトはユーザーインターフェイスの内側を理解することで作れるようになるはずだと話していました。
今回はmacOSやiOSを例に以下の3つの観点からユーザーインターフェイスの仕組みをご紹介します

  1. ユーザーに近いものは丸い
  2. 階層構造
  3. モード vs. モードレス

ユーザーに近いものは丸い

Apple製品はApple TVからAirPodsへと、ユーザーとの距離が近くなるに連れて角に丸みを帯びていくことがわかります。それはiOSでも同様で、アプリやウィジェット、通知バナーのような浮遊していてユーザーに近いオブジェクトの角には丸みがありますが、ホーム画面の下に表示されているドックの部分には丸みはありません。このことからユーザーに近いオブジェクトは丸くなっていることがわかります。

階層構造

以前、社内のSlackのUI談義チャンネルでiOSのMailアプリのUIについて盛り上がりました。それはMailアプリの新規メッセージ作成画面は開くと、前のビューは後ろに下がりモーダルビューの奥に少しだけ見えている状態になるということ。またこのモーダルは下にドラッグすることで、画面の下にメッセージビューをスタックできるようになっているということです。このようなことはiOSの標準部品ではありえません。
議論はそもそもタブとはなんなのか、ということにまで立ち返りました。そしてタブとはウインドウが変化した形であり、Safariのタブ一覧でウインドウが層になって表現されていることからわかるように、タブはウインドウが重なっている状態を表しているという結論に至りました。
MailアプリはこのようなマルチなウインドウのUIを表現するために標準部品を使用せず、あえてカスタムUIを用いてそれを表現しているようです。

モード vs. モードレス

モード

モードの例として、牛丼屋という身近な例で説明します。
牛丼屋の食券機では店内モードと持ち帰りモードが分かれています。しかしこのようにモードが分かれていると、モード内でできることが限られてしまい商品選択中にモードの切り替えができません。これは、これまでの選択を全て放棄して始めに戻らなければならないので操作しづらくなってしまいます。

モード階層

iPhoneでは電源を入れた段階からアプリを使用している段階まで、様々なモードが積み上げられています。このような、システムが生み出すモードはユーザーの行動と思考を制限してしまいます。その対策として、iPhone自体にはアプリが生み出すモードからいつでもホームに脱出することができるホームボタンがあり、画面上にはモードから抜け出すためのボタンが用意されています。
このようなiPhoneのモード階層から分かることとして以下の2点が挙げられます。

  • モードをデザインする場合はモードから脱出する手段を必ず提供すること。
  • モードを積みすぎるとユーザーの自由が奪われてしまうので、モードレスにUIをデザインすること。
Macのデスクトップインターフェイス

デスクトップインターフェイスの中でもモードレスを実現するための仕組みとして、First Responderと”名詞→動詞”の操作体系についてとResponder Chainについての話がありました。

First Responderと”名詞→動詞”の操作体系

First Responderとはすでに選択しているオブジェクトのうち最前面あるものを指し、次に選んだ「情報を見る」などのアクションがオブジェクトに送られる仕組みになっています。
これはCUIとGUIの違いに大きく関わっています。CUIでは$ cd /Systemのように動詞→名詞というように特定の行動に制約されていてモードがあり、GUIではオブジェクトを選択した後の行動はユーザーに任されていてモードレスであると言えます。

Responder Chain

そしてGUIではResponder Chainというクリックなどのイベントを子から親へ渡す仕組みがあり、簡単にアクティブなオブジェクトにイベントを送信できるようになっています。
これらの仕組みによって、Macのデスクトップインターフェイスにはモードレスな操作体系が実現されています。

このように優れたプロダクトを解剖することでデザインの意味がわかってくるとのことで、良いプロダクトを生み出すためにもデベロッパーがユーザーインターフェイスの仕組みを理解し、デザインと技術をどう繋いでいくかを考える必要があると話していました。

そしてセッションが終わった後はピザを食べながら懇親会を行いました。
そこではこの日のセッションへの共感や発見の声が多く聞けました。
ご来場いただいたみなさんありがとうございました！

グッドパッチでは一緒に働く仲間を募集中です！
http://recruit.goodpatch.com

We are hiring. 採用情報を詳しくみる

Share on

Goodpatch
Goodpatch公式アカウントです。