UI Crunch#8行ってきた #uicrunch
UI Crunch行ってきました。倍率8倍とか凄すぎ。 まとまったブログとかはメディアの方からありそうなので、口頭のみの内容込みで書き起こしたので見てみてください。 発表資料は公開され次第追加します！
感想
- 早く会社に持って帰りたい。語りたい。
- デザイナーがエンジニアリングする、といえど関わり方は様々だった
テクニカルクリエイターが担う、サービス開発のUIモックの現場 〜サイバーエージェント流〜
スピーカー
- 株式会社サイバーエージェント
- チーフ クリエイティブディレクター 佐藤洋介さん
- 元DNP
今日のポイント
- Point1:ネイティブアプリ市場ではより高度な表現が最重要
- Point2:心地よいユーザー体験が強豪優位性となる(日本のUIはまだまだ低い!)
- Point3:デザインとエンジニアリングの中間を担うツールが整ってきた(Prottとか) デザインの敷居が下がってきたし、Swiftもデザイナに近寄ってきたと思っている。
テクニカルクリエイターとは？
- 一人多彩(いっとたさい)なクリエイター
- 表現の幅が広く、プログラム言語/アニメーションを自在に扱えるクリエイター
CAのモックアップ紹介
AbemaTV(インターネットテレビ局)
- 藤田「そろそろテレビをスマホで見る時代が来てもいいよね？とにかくスマホで快適に。番組制作はテレビ朝日と組むからさ。」
- 藤田「アプリの品質にこだわってくれ」
- ラフモックアップ(開発当初のモックアップ)はFlashで作成。iPadアプリを想定していた
- コンセプトモックアップ(性的デザインと同時に、Flashでアニメーション化してサービスの全体ループを作成し、**「心地よい視聴体験」＝「ザッピング」にフォーカス。
- DetailMockUpはPixateで詳細に作り込んだ。
AWA
- 藤田「avexの松浦社長と釣りしてたら音楽アプリやることになったんだけど、とにかくオシャレで一見海外から来たような世界観でお願い」
- Interaction専用アプリ「AWA-IxD」を開発(XCode)。Pixateとかではなく製品版として作ってた。
- ローカルで動けば十分な程度で書いた。
- 現実世界の動きとアニメーションの間にギャップを作らない。ユーザーの連続的な動作とアニメーションの間にギャップを作らない。
- 横スクロール時にパララックスエフェクトを掛けることで「背景であること」を直感的に理解する手助けをしている。
ぺこり
- モックアップはPixate
- デザイナーがクオリティの高いモックを作る
3Q
Design/Interaction/Planningサービスの品質の構成要素
Design Quality
- UI・デザイン
- 約３０サービスを佐藤さんが月１チェック
- デザイナー・プロデューサーへのFB
- 全体でのデザインFB
Iteraction
Planning
- 代表の藤田さんはじめ現場のトップがレビュー
Conclusion
- サービスづくりにおいてデザイナーとエンジニアが近づいている
- テクニカルクリエイターには十分なベーススキルが必要。それがなければただの器用貧乏。
- サッカーのDFでいうとリベロみたいなもの。エンジニア、デザイナーの「新しい役割」。
- 自分の強みを理解し技術を巧みに応用する。すべてに長けている必要はなく、最適なアウトプットのための応用力が重要
エンジニアリングするデザイナーが領域を超えて見えたこと
スピーカー
- 株式会社ディー・エヌ・エー
- デザイナー 成澤真由美さん
- iemoとかKenComとかやってます。
なぜ領域を超えたのか
きっかけ
- とあるプロジェクトの失敗がきっかけ
- プロジェクトの状態(バグだらけ。作り直しが必要な状態。リリースまでに残された時間が2か月。厳しい)
- リリース時点でのタスク消化率がSystemばかりだった。
- リリース後「文章が途中で見切れてて最後まで読めない」「変なマージンが空いてる」「これではユーザー体験が損なわれてるじゃないか」
- 反省点：(1)ユーザー体験が損なわれず実装コストも下げられるuI変更の判断が瞬時にできず、エンジニアの負担が減らせなかった。(2)リリースに最低限必要な期間を見積もれず、ビジネス側へ説明することができなかった
- デザイナーが変わらなければ何も変わらない
- 実装に関する知識と自分で実装できるスキルを身につける必要があった
領域に入り込む前の葛藤
- 両立の手法が未知→やってみなきゃわからない
何をしてきたのか？
環境セットアップ
UI実装
- Xcodeでチャレンジ
- 難易度1:storyboardで配色とFontsizeを変更した
- 難易度5:マージンの調整しはじめる。auto-layout難しかった
- 難易度3:画像の比率をしてい
- 難易度2:角丸つけたい
- コード書き始める（ここまで3か月くらい)
- 難易度4:viewDidLoad()内にコードを書き始める
- 難易度5強:TableViewのレイアウト実装。UGCの実装になると絶対必要になる。
- 今はアニメーションの実装できるようになりたい(CoreAnimationでInteractionとTransition)
- これができればXcodeでデザイナーがプロトタイプ作れるようになるのではと思っている
なぜ領域を超えられたのか
- スキルセットの原点があった。
- Flash制作していた時のAction ScriptとかWeb制作じのJava ScriptがSwift書く力の元になった
- 組織のサポートがあった
- チームに積まれているタスクのうちエンジニアリングの内容のものをできる範囲で消化する開発ルールで、現場で学ぶ環境となった(Google20%ルール)
何が変化したのか？
領域を超える以前と今
開発スタイルが変わった！
- 以前はガイドを書いてエンジニアにレビューしてもらってた。開発の人がタスクいっぱいになる。
- デザイナーが実装すると、エンジニアの全体タスク量が減る。開発終盤にプロデューサーからくるデザイン修正をデザイナーができる。
作業コストが変わった！
- 両立の手法は見出せた！
- 実装に参加し始めた頃は作業コストが増えたが、UIの実現方法で悩む時間が減ってエンジニアリングのタスクと両立できるようになった。
アウトプットが変わった
- エンジニアがパッと見て実装イメージをつかめるようなアウトプットに変わった
スキルを活かす
- 高速プロトタイピングの実現。デザインプロトタイプを廃止し、デザイナーとエンジニアが並行して作れば実装レベルのプロトタイプが作れるはず。
- ゲームの現場はもうそうなりつつある。
- 見込める効果：企画プレゼンやユーザーテストをより早く実現できる。本開発に向けての明確な課題の洗い出しが可能となる。プロデューサーや上のレイヤーにも理解を得やすくなる
領域を超えることのススメ
- デザイナーが実装することは今となっては当たり前の概念となりつつある。
- デザイナーの学習コストは避けられない。周囲の理解が必要。
コードをコミットできなくたって大丈夫
スピーカー
プロダクトやサービスの実装に関わらなくても大丈夫？
- 実装するとなると不安なこと：時間/品質/プレッシャー/必要性/学習/他に重要なこと・・・
- 他に重要なことって何？：デザインとか！
- コードを書かないほうがいいのか？→プロダクトの周辺で積極的に書きましょう！
- プロダクトの周辺：開発にコミットするようなコードではないところ。開発の助けになるコードを書く。
おすすめすること
(1) STUDY :自分の関わってるものを勉強してみる。
アイデアを形に/アプリや断片,気づきがある/問題の解決。
エンジニアの人に笑われそうなコードでもまずは形にしてみる。
Processing.jsのエディタを作ったことをきっかけに、どうやって作るかどうか(2) TOOL :自分が使うものを自分で作ってみる
日々使うツールを自分で作ってみる。気の済むまでアップデート
Illustratorのプラグインをjsで書いた。
スクリプトを使って選択したパスを出力し、それを貼ればiOSのコードに使える、みたいなことをやっていた。
「自分で作ったほうが早いな。」(3) PROTO :コミットしない程度だけど製品に生きる
ちょっとハードル高くなったよ！
動くプロトタイプ/実際のデータ/テストしてみる/本番に近い/フィードバック
実際のデータで実際のユーザーに使ってもらえる。
リリースするものには書いていないので気楽にコード書いてテストできる。
なんでこの話した？
- 外国人に道を尋ねられた時の「英語勉強しよう」というのと同じ。勉強しようと一時的に思う、でも長続きしない。
- テンション上がるけど、実際のプロダクトにコミットするのはかなりハードルが高い。
- だから、その前くらいのレベルでコードを書いて、良さを得ていくのから始めていってもいい。自分がそう。
全員がコードを書く会社では どんな感じでデザインしてるの?
スピーカー
「デザインもコードも書きたいデザイナーWanted!!」を見てWantedlyにJoinした
- Wantedlyでは社員のほとんど、デザイナーの全員がコードを書きます
- CEO/人事部長/デザイナー多かれ少なかれ書いています
なんで書いてるの？
デザイナーに聞いてみた
- 学生時代建築・プロダクトを勉強していたが作るのにはお金がかかる。「ソフトウェアならタダじゃん！」
- HTMLマークアップの延長で、ごく自然にやっている
- 作りたいのは絵じゃなくてプロダクトから、自分で書いた方が効率的に目的に近づけるんじゃないですか？
つまるところ
- 技術によってしか到達できない表現がある
- チームでの開発プロセスの効率化
- デザイナーもコードを書ければリリースまでの時間の仕事の幅が広がる
Wantedlyでやってること
- よくあるデザインのプロセス：コードが書ければ実は全部不要かもしれない!?
- ワイヤーフレーム・画面遷移：MTG中に済ませてしまう。デザインに時間があれば、画面デザインと一緒に
- 画面デザイン：標準的なグラフィックであれば、描かない
- プロトタイピング・指示書作成：作ってしまった方が、早いかも？
- エンジニアとのコミュニケーション：GitHubのPull Requestベース。
- エンジニアと共通の基盤・言語で会話できてスムーズ
- 実装時に巻き取れる自信があれば、リリース時のクオリティは担保できる
- 毎回のプロセスをシンプルにする一方で何度でも使える「環境」を整備
- アイコンライブラリをWebフォント化していつでも使えるように
- ガイドラインとしてパターンを出して、実装にコンポーネントとして組み込んでおく。
- デザインの一貫性を確保し、後の追加・変更を簡単に。
- 理想：作りたいことをつくる！！間にあるものは無駄！減らしたい！
まとめ
- プロジェクトの進め方を大胆に最適化して、無心で完成度にフォーカスできる
デザインと技術をつなぐ
スピーカー
Goodpatchのデザインプロセス
- チームビルディングをしてからものを作っていく
デザインと技術をつなぐ
Why:良いプロダクトを作りたい
- エンジニアが要件定義や設計フェーズから関われないと、良いデザインが作れない
- 例）サービスの基本設計とか、バックグラウンドでのタスク実行とか
How:早いフェーズでプロジェクトに関わる
- よくある(1)：要件定義の期間が長く、開発期間が短い。
- よくある(2)：開発に入らないと、エンジニアがアサインされない。
What:プロジェクトへの関わり方を見直す
- AndroidデベロッパーがMaterial Designアドバイザーとしてプロジェクトに参加する
- iOSデベロッパーがUXデザイナーとしてプロジェクトに参加する
- Material DesignやHuman Interface Guidelinesは実装の経験がないと理解することが難しい
- メタファーを理解した上でアプリケーションの設計をする必要がある
Android
iOS
- iOS DeveloperをUXデザイナーというロールを持ってプロジェクト（サービスのアプリ対応)に関わる
- どうサービスを切り出してアプリケーションにするか提案
- サービスの強みを生かすためにどういったアプローチができるか提案
Webのこれから
- Webアプリもネイティヴアプリのように設計する必要が出てくる
- サービスデザインから考える必要がある
- ネイティブアプリを作るのか？Webの方が良いか？
- インストール試作、プッシュ通知の設計、オフライン対応、コンポーネント・・・
Progressive Web Apps
- ネイティブアプリに近づくWebアプリ。
- オンラインでもオフラインでも動作する
- Engagement(プッシュ通知とか。Service Workerとか)
- インストールできる
Web Components
- Webのパーツ
- elements.polymer-project.org
まとめ
- レビュー/インサイト発見/コンセプト設計/デザイン実装
- ここをスムーズにするためにデザインと技術をつなぎたい。
- 1991:HTTP, 1993:HTML, 2007:iOS, 2008:Android
- 技術によって領域が広がり、デザインによって洗練される
- デザインを実現するために技術が必要で、自分の持ってる技術を魅せるためにデザインが必要。
質疑応答
佐藤さんへ：開発の時にどれくらいデザインにこだわって投資対効果を出すか
- 自社サービスなので基本的にこだわる
- ただ、リリース優先の場合はかなり機能を削る場合はある。
- そこでも、エンジニアとデザイナーの目線を合わせる。妥協しないものづくりは大事。
青山さんへ：どうやって開発プロセス改善できた
- スタートアップだから元々そういう文化だった
- ただ、文化を作るのは人だから、今いる人から考えていけばいい
それぞれの会社の人へ：どういうエンジニアにJoinしてほしいか。特にネイティブアプリについて
- ひらいさん：デザインに興味があるエンジニアと一緒に働きたい。ネイティブだと自分でアプリを公開まで持って行ったことある、ガイドラインを理解した上で開発している人。
- 青山さん：一緒に作りたいものを作るエンジニア。自分が作りたいと思ってるものを作ろうとしているエンジニアはかっこいい。アプリの仕様変更をしなきゃいけないって時に、そんなこともあろうかと３ヶ月前から準備してました、って言われた時はかっこよかった。
- 森さん：その道のスペシャリスト+自分の専門領域外に目を向けられる人。
- 成澤さん：責任をもたせてくれるエンジニアと、アプリの配色を作り上げる途中に「これってどういう雰囲気のアプリなんですか？」って聞いて、「それに合わせたエフェクト作ってみたよ」って関わってくれるエンジニアさん。
- 佐藤さん：柔軟なエンジニア。
デザイナーはエンジニアによるべきか、経営によるべきか
- 佐藤さん：CAの場合、技術を見てる場合じゃないということもある。デザインの指摘をしている途中に企画の指摘をしている時がある。デザイナー・プロデューサーと意思疎通できるように。エンジニア・デザイナー・プロデューサー三位一体で企画を練って、開発しています。
- 成澤さん：DeNAもCAと似ていて、実装の段階と企画の段階が分かれている。三位一体で企画からエンジニア・デザイナーが入る、むしろエンジニア・デザイナーが覆す時も。判断のスピードをどんどん上げていくべき。自らがプロデューサーになったつもりでキャリアアップしてくべきという社風。
- 森さん：エンジニア・経営どちらかではなく、全方向向かざるをえない。
- 青山さん：Wantedlyにはディレクターがいない。一人の人間がデザイナー・エンジニアリング・経営など全てバランスを取ろうという必要はない。尖ったとこがある人間がチームを組むのが一番いいと思ってます。
- ひらいさん：尖っているところを合わせていけばいいと思ってる。ビジネス的感度が高い人がエンジニアだろうがデザイナーだろうが誰でもチームに一人いるといい。スキルとしてビジネス・エンジニアリング・デザインを高いレベルで保つ必要がある。
