デザイナーの開発的コミュニケーション力

Editor's Notes

1. お疲れ様です 初めまして はじめにお話しさせて頂きます、 Amebaブログデザイナーの戸塚です よろしくお願いします〜 お題は「デザイナーの開発的コミュニケーション力」です
2. はじめに簡単に自己紹介をさせてください 2014年にサイバーエージェントに新卒で入社し、今までにQAサービスや広告のデザインを経験を経て、 現在Amebaブログでアプリのデザインを担当しています
3. まずAmebaブログの組織体制についてですが Amebaブログは関わる人数が多いです！
4. 開発関係者だけで60名以上 私はその中のデザイン室という ブログ、プラットホームに関わるデザイナーが 所属してるチームにいます。 ここのデザイナーがそれぞれフロントやアプリとやり取りをして 日々連携しながらアメブロを作っています
5. これだけ大型チームのため 同時に大きなプロジェクトが走ることもしばしば ブラウザで大きな施策をやりながら、アプリも別のプロジェクトを進行 とかがよくあります
6. アプリは人数比で言うと エンジニアさんが各デバイス4,5名に対して デザイナーは一人という状態です なのでそれぞれAさんBさんが担当された施策を デザインチェックしなくてはならず 確認も結構な手間です
7. だからコミュニケーションがめちゃくちゃ大事です デザイナー同士もですし、エンジニアとのやりとりが本当に大事です
8. アメブロでやってみた エンジニアと仲良くなれる デザイン確認方法！今回はこちらをご紹介したいと思います！
9. まず一般的なアプリの確認方法をお伝えするのですが 基本エンジニアさんにテストアプリをもらわなくてはならず、 デザイナー手動では動きづらいところがあります 一つはテストアプリを配信してもらう もう一つは直接アプリを構築して端末に入れてもらう形になります。これをビルドと言います
10. 次に問題点を見てみます ビルドが面倒でキャプチャでもらう場合もありますが、 静止画だと実際のモーションがわからなかったり、 先ほど人数が多いと話しましたが 一人ずつ確認するのが大変だったり テストアプリの配信が特に通知がくるわけでもなく、 配信されている場合が多かったため、デザイナーが見落とすことがありました
11. というわけで実際の流れをiOSから具体的に見ていきます
12. ざっくりフローはこんな感じでテストアプリ 配信、GitHub上でプルリクをもらい、 デザイン確認、修正、そしてLGTMという流れにしています 割とこのスタイルがアプリ開発では多いと思います
13. もう少し具体的に言うとこんな感じです
14. ちなみにご存知かもしれませんが GitHubはソースコード管理サービスです アメーバブログに関しては基本的にこれでソースコードの管理を行っています ソースコードという単語が出てきてハードルを感じたかもしれませんが、
15. 大丈夫です私はコードは書けません、 コーディングをしないでどこまでエンジニアリングに入っていけるか、の実例だと思ってください
16. では具体的に見ていきますー 先ほどテストアプリの配信に気づかない場合があると言ったのですが、 そこを相談して、エンジニアさんにチャットに配信情報を流してもらうようにしました。
17. 見逃すとエンジニアさんが教えてくれます 優しいですね〜 まあそれには次に理由がありまして
18. プルリクは本来コードレビューの依頼のことですが 今回はデザインチェック依頼をデザイナーにプルリクとしてもらっています エンジニアさんはGitHubでの案件を終わらせないとリリースできないので でチャットで修正をお願いするより確実です！
19. OKだったらLGTM この流れが定番になりました
20. 良かったところは このデザインチェックフローを確率することで、知らない間にリリースされることがなくなった！
21. AndroidはiOSと少し違いまして、個々のエンジニアが作った案件をアプリに構築して端末で確認することができる
22. 図で見るとこんな感じです iOSはAさんBさんの案件をまとめてからテストアプリで配信して確認するのですが Androidは Aさん、Bさんとそれぞれの案件を見ることができます。ここをブランチと言います IOSと比べると確認のタイミングが早くていいのですが、 一人ひとりにビルドしてもらわなくてはいけないため時間がかかります
23. 流れはこんな感じ で私気づいたんです
24. というわけで私もAndroidスタジオを入れてもらいました Androidの開発ツールです
25. そうすることで何ができるようになったかというと 私の端末に自分でそれぞれの案件、 ブランチを自分で構築して端末に入れることができるようになりました。
26. では具体的な流れを見ていきますAndroid Stuidioでは本当にビルドしかしてません たまーに色が何色かとかを見てます
27. あとは同じですね
28. 良かったことは 自分でビルドができて確認もできる。エンジニアさんの席に行かなくてよくなり効率が上がりました コードが覗けるのもいいです！ エンジニアさんが普段どんな風に作っているのかが、わからないなりに見ることができるのはとても勉強になります。
29. ただ今回の試みはデメリットもないわけではないです 例えばiOSの場合
30. でもこのやり方を確立して 開発のスムーズさプロダクトのクオリティはとても上がりました！ アメーバブログのアプリチームでは現在もこのやり方をベースに開発しています！
31. 最後にまとめに入ります
32. 今回エンジニアとのコミュニケーションについてアメーバブログで行った事例を紹介しました デザイナーはデザインを作るだけでなく、プロダクトのクオリティを保つこともとても重要なことだと私は思っています。 なので今回の内容が皆さまの開発でのコミュニケーションに少しでも役立てたら幸いですー
33. ご清聴いただき、ありがとうございました！