#Goodpatch_Sansan エンジニアとデザイナーとのやりとりをぶっちゃける勉強会のまとめ @Goodpatch×Sansan勉強会-開発者とデザイナーのモバイルアプリ開発-
「開発者とデザイナーのモバイルアプリ開発」をテーマにGoodpatch とSansanによるりエンジニア、デザイナーの現場で巻き起こるぶっちゃけ話を繰り広げる勉強会「Goodpatch×Sansan勉強会-開発者とデザイナーのモバイルアプリ開発-」にいってきたのでそのときのまとめです。
グッドパッチの紹介
石井 克尚様(株式会社グッドパッチ iOS Developer) @dtRock_19
瀧本 優様(株式会社グッドパッチ UI Designer ) @yuutakimoto
- ios developer とDesignerがどうやってコミュニケーションをとっているかのご紹介
- MoneyForward、Flat、Pathee、SoftbankなどのUI設計、デザインなどを担当しました
- 自社サービスはprott
- プロダクトを作る時に大切にしていることは、チーム全員でプロダクトを作っている
- 受託の場合はクライアントとともに巻き込んで作る
- チーム編成としてはPM、UIデザイナー、エンジニアの3名体制が多い
- エンジニアはデザイン、デザイナーもエンジニアリングに理解・興味がある前提で作っている
- 開発の流れは要件定義、設計・デザイン、実装でそれぞれ回して開発している
- 設計・デザインについては初期段階で開発者も関わっている
iOS DeveloperがUI設計フェーズで何をしているか
- プロダクトイメージの共有
- 実装に入った時にデザイナーとのコミュニケーションが楽になる
- iOSを理解したUI設計
- HIG (HumanInterfaceGuideline)に則ったインターフェイスを考えている
- モックアップによる検証
- デザインも考えながらモックアップも作っている
- 触り心地や、アニメーションなどをここらへんからやっていく
- 効率的な開発をするためにデザイナーとの認識を設計から早めに合わせている
なぜうまくコミュニケーションができているのか
- HIGや、マテリアルデザインなどの共通言語があるので、デザイナーはこれを読んでおくことでスムーズに話が進む
- グッドパッチはHIGの読み合わせ会（ここが気になる、など意見交換会）などもやっている
- マテリアルデザインはandroidエンジニアが翻訳してくれてたりしている
- 同じ場所で作る
- デザインを組んでエンジニアにすぐ見せたりする
- エンジニアからはこっちのほうがユーザインタラクションがおもしろいのではと提案があったりする
Sansanのご紹介
辰濱 健一様 (Sansan株式会社アプリエンジニア)
坂本 和大様 (Sansan株式会社 アプリエンジニア)
田邉 泰様 (Sansan株式会社 デザイナー)
- eightというアプリを作っています
パネルディスカッション
仕事をしていて楽しいこと
- 瀧本様
- Prottで組んだ後にエンジニアに実装してもらって鮮やかに動いたら楽しい。
- ユーザーのフィードバックも楽しい。
- 1pixel上げてみてとやりとりしている時が楽しい
- 石井様
- デザイナーが一番最初のユーザーなので、いじってもらってこだわりを感じてもらえるとモチベが上がる
- デザイナーとぶつかるときはどうしている？
- 設計でぶつかる部分が多いので、HIGに立ち戻ったりしている。
- 坂本様
- インタラクションでこったものを作った時に、そのこだわりを見つけてもらえると嬉しい
- ユーザーのFBが嬉しい。よくTwitterでユーザーの声を検索したりしている
- 辰濱様
- eight使ってますと言われると嬉しい
- UI操作を自動化して、いろんな画面のSSとって、一覧を作ってデザイナーに見せる…などのオレオレツールを作って、使ってもらった時に喜んでもられえると楽しい
- 田邉様
- 辰濱さんに相談すると画像容量を一気に縮めるものを作ってくれたりなど、世にないものをツールでサクッと作ってくれるのがすごく助かる
- お客さんの要求にデザイン設計でまるっと答えられると嬉しい
- 皆さんとの飲みニケーションが楽しい
Webデザイン経験者がスマホアプリのデザインに回ってきて困ったこと
- 石井様
- 普段からUIについて話しあったり、HIG読んだりしていてキャッチアップしやすい環境にあるのであまり困ったことはない
- 田邉様
- BBやptというpixelとは違う単位に最初困った
- androidで9 patchを考えて作ってねと言われたりした時も困った
デザイン納品時にモメることっでありますか
- 坂本様
- 1000枚位の画像をリネームするってなったときに、頑張って変えようとしていることがあったが、コミュニケーションで解決できた
- 画像サイズは一昔前はあった。デザイナーはきれいな画像にしたいが、エンジニアとしては小さくしてほしいという会話はあった
- 石井様
- Sketchでやっているので滞り無く進んでいます
もらった素材がアプリに組み込みずらい場合もそのまま使うべき？微調整はエンジニアがやるべき？
- 田邉様
- デザイナーの環境はphotoshopやイラレ使っているので1個1個パーツを切り渡しているので少し画像サイズが違うことがある
- 結論：都度相談する。コミュニケーションが大事
- 外部と会社が切り離れてる場合は？
- 辰濱様：サイズチェックツールなどを使って解決したりしています
- 瀧本様
- 開発が外注のことも結構あるので、デザイナとPMがエンジニアの会社に月水金の午前中か午後にガッツリ行ったりしている
- 直接行かないと細かいところが伝えづらい
デザイナが表現したい細かいインタラクションはどう伝えるとうまく伝わる？
- 瀧本様
- 最初に擬音で伝える。
- 次に参考アプリをquick timeとかで撮ったりして見せる
- それでも伝わらなかったら最終的にAfterEffectsで作る
- 田邉様
- 最終的にはFlashでやったりしている
- 絵でやってみて伝えて、伝わったらそのインタラクションに効果音を決めたりしている
- 石井様
- デザイナからいわれたらとりあえず一度作ってみて、だんだんと詰めていく
- 手を取る時間が無い時は参考アプリを見せてもらったりする
- 坂本様
- 一旦作ってみてデザイナーとレスポンス0.2秒縮めたりなど、微調整して詰めていったりする
- クライアントとの時はどうする？
- 瀧本様: 直接いって伝えるしかない
ものづくりの観点で作ったものに対してお客さんがYesと言わなかった時にどう戦っている？
- 石井様
- ユーザー目線で作るべきだと言って戦っている
- ビジネス要件で必要な機能かも知れないが、ユーザーにとってはいらないものは無くしたりしている
- しかし、クライアント/エンドユーザーがいかに喜んでいるかを考えて作っている。
- 自社のディレクターとも戦うこともある
- 坂本様
- 上がってきた仕様に対して、iOSの標準からブレるなどのリスクを説明した上で、機能を削ったり、もしくはリスクをわかってもらった上で機能を採用したりしている
- 辰濱様
- 出来上がる寸前に仕様が変わったりした時に、仕様変更に対する意図を聞いて、理にかなったら変えたりしている
- 田邉様
- 無茶難題に対してユーザーにとってどうなんだろうと考えたりしているが、正面切って戦うという感じではなく、無理難題の意見を取り組みつつ課題を超えて作っている
お気に入りの開発/デザインツールカスタマイズ
- 瀧本様
- Sketchを使ってデザインしている
- フォトショやイラレよりも軽い
- パーツの書き出し(@1x, @2x, @3xなど）が簡単
- ピクセルがずれることがあるが、プラグインで治せたりする
- テンプレ（iosのコンポーネントなど）もネットで充実している
- 社内共通で使っています
- ストア画像はフォトショで作ったりしている
- パスを上手く使えない時はイラレで作った後にSketchで読み込み直したりしている
- Sketch MirrorはデザインをiPhoneにそのままミラーリングできたりするので便利
- 石井様
- Xcodeに便利そうなプラグインを入れたりしている
- source tree, tower?などを使っている
- アニメーションの確認にkeynoteを使ってみたりしている
- 坂本様
- xcode, gitは使っている
- イラレを使っている
- adobe製品をやるときはまとめて書き出すときはスクリプトを作って書き出したりしている
- SansanでSkitchを使わない理由は？
- 田邉様：慣れの問題
- 瀧本様：効率が全然違うのでSkitchを使わないのはもったいない
- 田邉様
- scalar menu?, frint?などを使っている
- 辰濱様
- MSペイントで頑張って使ってます
- ツールを自分で作っちゃっている
エンジニア -> デザイナー / デザイナー -> エンジニアにお願いしたいこと
- 田邊様
- エンジニアの言葉が刺々しい時があるので優しくしていただきたい
- 辰濱様
- 正常時じゃなく、異常の時（例えば文字がはみ出た場合にどうなるかなど）にどうなるかを考えてデザインしてほしい
- 普段からタブレットなどを使っていてほしい
- 坂本様
- いろんなアプリをいじってほしい
- HIGなどの読み合わせなどをしてほしい
- エンジニアで自動化して、簡略化できることもあるので困ってることは相談してほしい
- 石井様
- いろんなアプリを触って欲しい
- WWDCなどでエンジニア向けの動画でたりするが、デザイナーも目を通して新しい機能をキャッチアップして、デザインに落としこんでほしい
- 瀧本様
- エンジニア視点での設計意見はどんどんいってほしい
デザイナー/エンジニアがやりやすいように配慮していることは？
- 辰濱様
- プログレスダイアログ/アクティビティインジケータっていわず「ぐるぐる」っていったりしている
試してできてないことはあるか？
- 田邉様
- Sketch使いたい
- 石井様
- 新しく発表されるプロダクトを追いかけて行きたい
- リリースと同時にアップルウォッチアプリを出せなかったのが後悔している
- 新しく発表されるプロダクトを追いかけて行きたい
- 辰濱様
- androidのxmlについて、デザインのどこが伸びるかを考えた上でデザインしてみてほしい
なんで1pxずらすの？という説明をどうしているか？
- 石井様
- 組んで翌朝みてみると1pxずらした結果が綺麗に見えたりするので、できるだけデザイナーの意見は汲むようにしている
- 瀧本様
- ロジカルに伝える必要があると考えている
- 1pxは感覚に近いものがあるが、なるべくロジカルに伝えている
- 田邉様
- しっかり説明するしかない
- 逆に説明しきれないのならそのデザインがそこまでだったという結論に至ったりする
- こだわりがあるなら説明し続ける
どうやって画像を渡しているか？
- 田邊様
- sansanはgitで管理していたりしていなかったりしている
- プロジェクト/ストーリー（機能毎に区切っているようです）ごとにスレッドをたてて、あげている
- 坂本様
- ストーリーごとに紐付いた画像を共有ストレージに上げたりしている
- 石井様
- Sketchファイルをそのままやりとりしている
時間の見積もりはどのように出している？
- 田邊様
- 時間の見積はわからない
- 一瞬で終わることもあれば中々終わらないこともあるので見積は非常に難しい
- 悩んでいるということを相談したりして解決しようとしたりはしている
- 辰濱様
- 画面一分を残して遷移すると大変など実装の問題があるときははやめに行っておく必要があると思っている
- 坂本様
- デザイナーと意識がずれたまま進んでしまうのはよくないので、はやめにデザイナーと相談してデザインで解決できればいい
- 石井様
- UI設計の段階ではやめにモックアップを作って、時間がかかるものがあらかじめわかるものは想定してスケジュールを組んだりしている
- 瀧本様
- 変更する際はすぐにエンジニアに話して、優先度を決めながら変更したりしている
- 一番初めにくんだスケジュールはあてにならないので、フレキシブルに動けるようにしている
所感
一番の解決法としてはやはり、日頃から蜜にエンジニアとデザイナー同士がコミュニケーションを取ることが大事なのだと改めて再確認しました。
中々忙しいのではと、お互い億劫になってコミュニケーションをとりづらいという場合もあるかと思いますが、臆せずどんどん話し合っていくのがいいものを作っていくコツですね。
そのため日頃から話し合ってコミュニケーションをとりやすい環境を作っていくのが大事だと思いました。
自分はプロダクトを作っていく時は朝会などを実施して情報共有したりしていますが、これが意外にデザイナーとも、意識すり合わせできたりしているのでお勧めです！
あとは最近Sketchが流行っているんですね。なんだか便利そうなツールな感じがしますね。
一応イラレとかでも等倍サイズで書き出す機能がつきましたけどやっぱりそれでもSketchが便利なんですかね？
また、読みあわせについてですが、やり方を聞いたところ、
- 自分でHIGを開催する
- 1回の開催で1章を担当
- HIGの項目で当てはまるアプリを実際に見せながら進める
- 終わった後に次のファシリテーターを指名する
- 毎週開催する
こんな形でやっているようです。
是非弊社でもHIGの読み合わせをやっていきたいなと思いました。
