Goodpatch Engineer Meetup Vol.4 「Goodpatchのエンジニアが考える『エンジニアリングとデザイン』」
こんにちは。Goodpatchでフロントエンドエンジニアをしているかみのうらです。
先日開催されたEngineer Meetupのレポートをお届けします。「Goodpatchのエンジニアが考えるエンジニアリングとデザイン」をテーマに、Goodpatchの開発メンバーと、CTOのひらいさだあき、アドバイザリーボードの及川が登壇しました。
目次
Design-Developのサイクルを活性化する仕組みづくり
まず初めにProttの開発チームに所属している西山から、プロダクト開発においてチーム内でいかにデザインと開発のサイクルを回すための仕組みを整えているかについての話でした。
まず1つ目が情報を見える化し、同じプロセスを共有するということ。Prottチームの作業スペースの横にはいくつかのホワイトボードが設置されており、そこには開発中の機能のフローが描かれたスケッチや、機能開発における全体のワークフローがポストイットに書き出されています。そうすることで誰でも仕様やプロセスを常に確認できるようになり、課題を見つけて改善するのが容易になります。また、エンジニアもユーザーテストに参加し直接ユーザーの反応を見ることにより、プロダクトに対するオーナーシップを持ち、エンジニアの視点で課題を見つけることにもつながります。
2つ目が異文化を尊重するということです。デザイナーやエンジニアなどの職種の違いは文化の違いとも見なせます。何気なく使っている言葉が他の職種のメンバーにとっては理解不能であることも珍しくありません。スムーズなコミュニケーションを取るには違う職種の言語や知見を学んだり、全員が理解できる共通の語彙を用意することが重要となります。
３つ目が確認環境を整えるということです。Prottチームでは2週間ごとのスプリントを行っており、最終日にステークホルダーを交えてデモをするという形をとっています。しかし、フィードバックを得るタイミングはデモにこだわる必要はありません。常に開発状況を確認できるように環境を整えることによってフィードバックを細く早くもらって開発スピードを上げています。また、そうして動くものを見られるようにすることにより「プロジェクトが動いている感」を出していくことでチームのモチベーションを上げることができます。
最後がツールを活用するということです。特に、エンジニア主導でツールを導入していくだけではなく、デザイナーの感性に合ったツールを尊重することも大事です。Sketch、 Zeplin、 Prottはもちろん、デザインのバージョン管理を行なうAbstractを利用したり、ボードの上に画像やテキストを貼って共有できるMilanoteというツールによってUXデザイナーがまとめたユーザーテストの結果などをスムーズに共有してもらえるようになっています。開発サイクルの活性化につながるツールは積極的に利用しています。
これらの仕組みを整えながら開発を進めていくことがスピードを上げてプロダクトをつくっていくのに重要だそうです。
複雑なアプリケーションにオブジェクト指向UIで立ち向かう
次に主にクライアントワークを行っている大角から、実務で複雑なアプリケーションをどう改善していったかについて発表がありました。
アプリケーションは時としてサイトの導線や機能が複雑になり、使いこなすのが難しくなってしまうことがあります。そのような問題の解決策の１つとして「オブジェクトベースでUIを設計する」方法があります。
UIの設計方法論には大きく「タスクベース」と「オブジェクトベース」の２つがあり、タスクベースはCUIの様に動詞→名詞の順に操作を行うもので、オブジェクトベースはGUIの様に名詞→動詞の順に操作を行うものです。名詞にあたるオブジェクトは変化しにくい一方で、動詞にあたるアクションは機能の追加や変更に応じて変化しやすい性質があります。
また、タスクベースのUIは機能を追加するにつれて情報が重複しやすく無駄が発生しやすいですが、オブジェクトをベースにUIを設計する事で情報の無駄をなくし、機能の追加も行いやすくなります。このようにUIの複雑性を無くす事によって、エンジニアとデザイナーのイメージも合わせやすく、コミュニケーションが円滑になります。
最後にオブジェクト指向はエンジニアにとって馴染みのあるケースも多いため、エンジニア側の提案でデザインに貢献できる事もあるとの事でした。
デザインと技術をつなぐために(トークセッション)
最後は、今月Goodpatchのプロダクト&テクノロジーのアドバイザリーボードに就任した及川とCTOのひらいのトークセッションでした。「デザインにどう関わるか」と「組織」というテーマで各々の観点からトークセッションを進めていきました。
デザインにどう関わるか
ひらい：
元々SIerでシステムエンジニアとして業務システムの開発やデータベース設計をしていて、デザインとはあまり関わりのないところににいました。その時はデータベースのテーブルにindexを貼ったり正規化したり、データベースにとってどうやったらデータが使いやすくなるかについてよく考えていました。
HTML5というキーワードが盛り上がり始めたころにIA(情報設計/インフォメーションアーキテクチャ)という存在を知りました。そして今度はどう情報を整理すれば人にとってわかりやすく、見つけやすくなるのかを考えるようになり、それがきっかけでデザインを身近に感じるようになりました。そのような広義のデザインに対して、エンジニアリングのバックグラウンドを活かしていけるのではと感じ興味を持っていきました。
及川：
私も狭義のデザインにはあまり関わってきませんでした。
Microsoftにいた時は主にセキュリティやネットワークプロトコル、GoogleではChromeのBlinkというレンダリングエンジンに関わっており、ユーザーに直接インタラクトするようなものではなく、UIなどのようなDesignにはあまり触れていませんでした。
ただGoogleでWebという世界を見た時に、情報を発信してはいるもののユーザーには届いていないことが多いと感じました。
それをGoogleなどの検索エンジンに向けて最適化するのがSEOです。良いSEOはユーザーに価値を届くようにするということが本質であり、そこにデザインが深く関わってきます。
また、デザインのコアの多くの部分をパフォーマンスが占めてるのではないかと感じています。パフォーマンスが改善されるとユーザーの問題の多くは解決するのではないでしょうか。もちろん、パフォーマンスには関係のない課題も存在しますが、速くすることだけで、ユーザーへの体験を大きく変えることは可能です。
ひらい：
情報設計がしっかりとされているサイトでも、そもそもパフォーマンスが低いと気持ちよく使えないですよね。フロントエンドエンジニアはUIが身近でデザインとの関わり方はイメージしやすいですが、サーバーサイドエンジニアにもデザインを意識していってほしいと思っています。わかりやすいところだとレスポンスタイムなどのパフォーマンスが大事になります。プロダクトを開発している時にパフォーマンスチューニングをしたりもしますが、レスポンスタイムを改善することがユーザー体験を良くするという事を意識してほしいと思っています。
及川：
サーバーやインフラ、クライアント側を見るエンジニアがいる中でデザインという観点での全体の設計は誰がやっているんですか？
ひらい：
Goodpatchだと基本的にはUXデザイナーが体験を考えていきます。
ただ、こういう風に遷移するとかユーザーはここに辛さを感じるので改善しようみたいなことは提案できますが、デザイナーが非機能要件の部分まで把握するのは難しいのでエンジニアが積極的に関わって一緒に考えていきます。また、インタラクションにしても、ビジュアルデザインやプロトタイプのフェーズで細部までしっかり考えると時間がかかります。それなら細かいインタラクションを除いたプロトタイプを作ってもらって、その上でエンジニアと一緒にインタラクションを考えて、良い体験をつくることに協力していくことが大事だと思っています。
組織について
ひらい：
社内のエンジニアに対しては、「デザインの力を証明する」というミッションに向けて「デザインと技術をつなぐ」というミッションステートを用意しています。会社の軸としてデザインがあり、エンジニアがミッションをどう実現するかを考えています。
及川さんは以前の会社ではデザイナーとどう関わっていたんですか？
及川：
エンジニアリングに比べると人数は少ないですが、ビジュアルやUXなどを担当するデザイナーがいました。エンジニアもデザインを提案はできますが、製品として一貫性を保つために最後はデザイナーが決めていました。専門家に任せたほうが良いデザインフィロソフィーのようなものがあるので、その決定は完全に任せていました。
ひらい：
これまで及川さんが関わったChromeやGoogle日本語入力などでは、メニューの中身をどうするかやどのような使い心地にするかなどは考える必要があったと思うんですが、そのあたりでデザイナーとはどう関わっていたんですか？
及川：
「こういう目的をもったUIを考えてほしい」というお願いをしていました。難しかったのはブラウザやOS、日本語入力などにしてもすでに人が慣れ親しんだUIがあるのに対して、自分たちがすごいものを考えたからといってそれが通用するかどうかは別だということです。そのバランスや最終的な判断が難しかったです。
会場からの質問：
新しいサービスを世の中に出す時に既存の概念が邪魔をするという話があったと思うんですが、ガラケーからiPhoneに移り変わった時のように短い期間で新しいものに完全に乗り換えるにはどういう要素が必要なのでしょうか。
ひらい：
短い期間で新しいものに完全に乗り換えることが、本当に必要なのかをまず考えてもいいのかなと思います。がらっと変えることが目的なのか、使いやすいものをつくることが目的なのかで結構違うと思います。デバイス自体のインターフェースも変わると思いますが、使いやすいデザインは人々の習熟度によって変わってくると思います。新しいものが出てくる中で、その時々で何が使いやすいのかを考えていく必要があると思っています。
及川：
やはりユーザーによると思います。iPhoneを買うような人はApple信者だったから、そのような劇的な変更にすぐに慣れるという推測も成り立つのではないかと思います。
MicrosoftがWindows ８でMetro UIを出しましたが、その時の既存ユーザーにはかなり使いづらいものでした。正直自分にとっても使いづらかったです。ただ面白かったのは自分の娘は完全に使いこなしたという事です。
つまり、誰がユーザーかが重要だということです。既存のUIに慣れ過ぎてる人にとっては互換性はそれなりに大事です。一方で、既存のUIに慣れ親しんでいない人にとっては完全に新しい世界なので、そこでベストなユーザーインタラクションはなんだろうと考えていくことが可能です。今のユーザー層が誰で、それを大事にする必要があるかどうかが、がらっとUIを変えることが出来るかどうかにつながってくると思います。
セッションが終わった後の懇親会では、発表の内容をプロジェクトに取り入れていきたいという声が多数聞こえてきました。ご来場いただいたみなさんありがとうございました！
