#p4d デザイナー向け プログラミング部 Presents @ken_c_lo TAEKO AKATSUKA Pull Request 4 Designers in PHP Conference Sep. 21th, 2013 for GitHub を使った プログラマとデザイナーの イテレーティブな 開発フロー co-sponsored by

1 Pull Request 4 Designers - #p4d in #phpcon Who? フリーランスで Web デザイン＆グラフィックデザインしてます 赤塚 妙子 TAEKO AKATSUKA @ken_c_lo （ケンシロウと…読むけど正直後悔しています） twitter https://twitter.com/ken_c_lo/ rss http://d.hatena.ne.jp/ken_c_lo/ github https://github.com/taea/ ・ 最近は Forkwell.com のリニューアルデザインとかをお手伝い ・ Git と GitHub を使って Rails アプリにデザインを入れる仕事 ・ @IT に 「ズルいデザイン」連載中 　http://www.atmarkit.co.jp/ait/kw/zurui_design.html

2 Pull Request 4 Designers - #p4d in #phpcon $ git rebase -i $ git cherry-pick 好きな Git コマンド Git 歴 ちゃんと開発で使い出してからは 1 年

3 Pull Request 4 Designers - #p4d in #phpcon 提 供 エンジニアが楽しく働く場所や仲間との出会いをサポートする Forkwell の提供でお送りします。 私が現在お手伝いさせていただいてる、Forkwell さんでの実際の仕事の様子を紹介します。 アウトプット志向のエンジニアのための、 ポートフォリオサービス 「スキル」と「こだわり」で選べる、エンジニア目 線の求人・転職サイト

4 Pull Request 4 Designers - #p4d in #phpcon ちょっと CM タイムすみません… アウトプット志向のエンジニアのための、ポートフォリオサービス https://forkwell.com こんな感じの、自分のスキルが並んだ自己紹介ページが作れます。

5 Pull Request 4 Designers - #p4d in #phpcon ちょっと CM タイムすみません… アウトプット志向のエンジニアのための、ポートフォリオサービス 自分のアウトプットを登録して、ポート フォリオページを作ることができます。 ブログ記事 / スライド / プロダクト / リポジトリ / インタ ビュー / 寄稿 / 著書

6 Pull Request 4 Designers - #p4d in #phpcon ちょっと CM タイムすみません… 「スキル」と「こだわり」で選べる、エンジニア目線の求人サイト https://jobs.forkwell.com

7 Pull Request 4 Designers - #p4d in #phpcon ちょっと CM タイムすみません… 「スキル」と「こだわり」で選べる、エンジニア目線の求人サイト 求人ページは、どんな会社がどんな 開発をしているかが詳細にわかり、 読み物としても結構おもしろい。

8 Pull Request 4 Designers - #p4d in #phpcon ちょっと CM タイムすみません… 「スキル」と「こだわり」で選べる、エンジニア目線の求人サイト Forkwell Jobs では、エンジニアが楽しく働ける 会社さんからの求人情報を募集中です。 ぜひ、お声がけください！ 掲載だけなら、無料です。

9 Pull Request 4 Designers - #p4d in #phpcon この発表の内容 「生煮え Pull Request」 を使った、 デザイナーとプログラマの 間を行ったり来たりする イテレーティブなワークフロー の様子をご紹介

10 Pull Request 4 Designers - #p4d in #phpcon 「生煮え Pull Request」 とは？ トピックブランチ開発において、機能的に不完全な状態で早めに Pull Request にしてしまい、その状態から複数人でブランチを煮 詰めて機能を洗練させていく。 デザイナーは、機能を全て自分で作れるわけではないので、こうや りたいなという UI をフロントエンド部分のみ作った状態で、ぷる りにしてしまい、プログラマにバトンタッチする。

11 Pull Request 4 Designers - #p4d in #phpcon 一つの機能ができるまで Designer 仕様を整理し、紙にラフを書く Designer マークアップを書き、スタイルを 当てる（ざっくり） Designer Pull Request 出す Designer 機能が入った状態で使ってみて、 デザインをブラッシュアップ Programmer branch を切り、view が表示され る枠を作る Programmer 機能を開発し、FIXME つぶす Programmer 良さそうなら master にマージ Programmer FIXME つぶし、リファクタしたり 何度か行ったり来たりを繰り返す

12 Pull Request 4 Designers - #p4d in #phpcon Deploy Designer 全体のデザイン調整のための branch を切る Programmer branch を切り、view が表示され る枠を作る Programmer 追加機能、FIXME があればつぶす Programmer 良さそうなら master にマージ Designer デザイン修正して再度ぷるり

13 Pull Request 4 Designers - #p4d in #phpcon Designer 仕様を整理し、紙にラフを書く ・ざっくり手書き ・ 紙とかホワイトボード ・あんまり作りこまない。適当。 ・GitHub Issues や Pivotal Tracker に貼って共有

14 Pull Request 4 Designers - #p4d in #phpcon Designer 仕様を整理し、紙にラフを書く 比較的細かく詰めたい時は、Illustrator でワイヤーフレームを作ったりする。 また、Photoshop や Illustrator で原 寸で素振り程度に作ってみたり、画像部品 を作ったりもするが、カンプをガッチリリ アルに作り込む事はあまりない。

15 Pull Request 4 Designers - #p4d in #phpcon Programmer ブランチを切り、view が表示される枠をざっくり作る ・この時点ではまだ Pull Request にはなっていない ・基本的に、デザイナーは Controller ・ Model や Routing は あまりいじらない（いじれない）ので、それが必要な場合は最初に やってもらう ・ビューが既にある場合は、このプロセスを省いてデザイナーがブランチ を作って開発進めることもある

16 Pull Request 4 Designers - #p4d in #phpcon Designer マークアップを書き、スタイルを当てる ・ フロントエンド部分だけ （Haml テンプレー ト (html) / Sass(CSS) / 一部 JS（coffeeScrpt)) だけ作る ・プログラミングが必要な部分には FIXME 　コメントを入れて必要な仕様を 　書き込む ・この時点でのデザイン、割と適当。 　ざっくり作って後から調整。 ・デザインは全体のバランスが重要なので、機能単位での開発で作りこみに注力すると、 バランスがちぐはぐになってしまいがち。 　 （というのと、スピード重視なため）

17 Pull Request 4 Designers - #p4d in #phpcon Designer デザインを commit して、生煮え Pull Request を出す ・新規ページのデザインの commit は多くの場合あまり分割しない。 マークアップ、スタイル、JS という ファイルごとにざっくりわけている。 （JS は処理単位ごとに分割できる時は分割する） ・ マークアップとスタイルを分けておくと cherry-pick しやすくてよい（後述） ・ git add -p で add する内容を再確認しながら commit してる マークアップと スタイルで commit わける

18 Pull Request 4 Designers - #p4d in #phpcon Designer デザインを commit して、生煮え Pull Request を出す 概要や連絡事項を書く 関連ストーリーの URL とかも プログラマさんにお願いしたいこと を checkbox に - [ ] hogehoge って書くと checkbox にしてくれる Pull Request がタスクリストに（ 便利！

19 Pull Request 4 Designers - #p4d in #phpcon Programmer 機能を開発し、FIXME をつぶしてデザイナーに投げ返す ・この時点で機能やデータがひと通り揃った状態で見ることができる ・デザイナー、たまにエラー画面のこととか忘れてることあるので、そういう 　プログラマサイドからの指摘も FIXME で戻ってくる

20 Pull Request 4 Designers - #p4d in #phpcon Programmer 機能を開発し、FIXME をつぶしてデザイナーに投げ返す ぷるり上で、指摘をし合ったり相談したりしながら、機能をブラッシュアップしていく

21 Pull Request 4 Designers - #p4d in #phpcon Designer 機能が入った状態で使ってみて、デザインをブラッシュアッ プする - 機能が完成し、実際のものに近いデータが入った状態で使ってみる - 細部の作り込みや、やはりここはこうした方がいいなーとかが出てくる - その時点で再度、プログラミング必要なものはまた FIXME に書く このプロセスを何度か行ったり来たりするうちに、 機能が、フロントエンド / サーバサイド両面で洗練されよいものになる （そんなに回数は多くないです。時間ないし。 ） Programmer FIXME をつぶしたり、リファクタリングしたり - この過程でもちろん、一緒にコードレビューも行われる

22 Pull Request 4 Designers - #p4d in #phpcon Programmer ひとまず問題無さそう -> master にマージ 複数人でレビューし、問題なければ master にマージする ただ、この時、デザイン的には 70% くらいの作りこみであることがままある。 機能毎に分割されたトピックブランチ開発だと、 全体のバランスを見たデザインがしづらいので、あまりがんばって作りこま無い時がある 再度、画面内で機能が出揃った時に、デザイン再調整用のブランチを master から切る

23 Pull Request 4 Designers - #p4d in #phpcon Designer 全体のバランスをみながら、 再度デザインを整える用のブランチを master から切る 他の機能が出揃ってきたら またリデザイン用の branch を 切り、全体のバランスを取りな がら再度デザイン調整する プログラム必要な箇所は FIXME にしてプログラマさんに 同じプロセスでまた、 見た目・機能両面を ブラッシュアップしていく

24 Pull Request 4 Designers - #p4d in #phpcon こんな感じのフローで プログラマ / デザイナ間で GitHub 開発しています。 もちろん プログラマ →デザイナ のぷるりもあるよ ・今回、デザイナー主体の例を紹介しましたが、逆ももちろんあります。 ・プログラマが機能だけ作ってこの部分デザイン頼む の場合。 ・これもスタート地点が違うだけで、同様のフローでやる ・お互いの手の空き具合や、機能の特性に応じて、どちらが主体でやるかはフレキシブルに

25 Pull Request 4 Designers - #p4d in #phpcon Pull Request にしなくても branch のやりとりはできるのになぜ？ GitHub の Pull Request の UI が優れているから ・ディスカッションしやすい。ログを残しやすい ・コード上だけでは不可能な提案や議論が展開しやすい。 ・TODO リストも作れる ・ スクリーンショットだって貼れる ・意図や経緯が全員で把握しやすい。過去に遡ってもわかりやすい。 なぜ、早い段階で Pull Request にするのか？

26 Pull Request 4 Designers - #p4d in #phpcon Pull Request ≠ Merge Request まだマージできない状態でも、ぷるりにしてよい。

27 Pull Request 4 Designers - #p4d in #phpcon トピックブランチ開発が長引いて、 master との乖離が大きくなってきたら、 $ git rebase master $ git push -f

28 Pull Request 4 Designers - #p4d in #phpcon トピックブランチ開発が長引いて、 master との乖離が大きくなってきたら、 $ git rebase master $ git push -f ・割と頻繁に、カジュアルに行われる ・ （ウチだけかもしれないが、特に深刻なトラブルになったこともない） ・rebase しましたー って pull request に書いておく ・みんな pull --rebase する ・うっかり普通に pull しちゃったら、reset --hard でやり直せばよい

29 Pull Request 4 Designers - #p4d in #phpcon デザイナーが知っておくと、マジ便利 $ git cherry-pick ・デザインは機能ごとにきれに分割しづらい問題 ・CSS もプログラムほど機能ごとに分割できない場合が多い ・他のトピックブランチ（まだ marge されてない）で作った Sass を 　新規のトピックブランチで使いたい場合、marge されるのを待たなければ 　ならない ・Sass だけ別の commit にしておけば、cherry-pick で簡単に 　別のトピックブランチにスタイルのみを取り込める

30 Pull Request 4 Designers - #p4d in #phpcon デメリットというか、 必要な心構えとか前提とか… みたいなのはある。 このように、生煮えぷるり開発素晴らしいのですが、

31 Pull Request 4 Designers - #p4d in #phpcon デザイナーの負荷、少し高めにはなる ・設計や作り込みにかける時間を削られがち ・特に全体的な設計にかける時間が油断してるとなくなる （機能単位で話が進みがちなので） ・事前にユーザーフロー、コンセプトの整理、 おおまかな全体の完成図をある程度描いておくの必要 これをやらないと、いつしか場当たり的な機能追加、UI 追加地獄に陥ることになる ・やっぱりこの機能要らなかった、がやはり出てくる なるべくなくそうとは心がけるが、やはり出てくる。大変申し訳ないが、出てくる。本当すいません。 必要ないならとっちゃいましょうか！とあっさり言ってくれるプログラマさん、超ありがたい。

32 Pull Request 4 Designers - #p4d in #phpcon 一度に完璧を目指さず、 段階的にブラッシュアップしていく。 …ので、 おのずと「気持ち悪い」状態がある程度続くことになる。 ・デザイナー・プログラマもそうだけど、プロダクトオーナーや マネージャー、お客さん含め、ステークホルダー全員に、 その段階的変化を許容してもらえる土壌が必要。

33 Pull Request 4 Designers - #p4d in #phpcon デザインの Why? を説明する プログラマと相互理解する ・デザインや仕様にも、必ず客観的な視点で納得できるような 「Why」を説明する。 ・ 「why」を共有できていれば、路線変更が必要になった時も、 みんな納得して気持よく仕事ができる。 ・逆に、プログラミングの制約上、無理のあるデザインや UI 設計だった場合も、プログラマサイドからの「why」を わかりやすく説明してもらえると、代替手段を一緒に考えてい ける

34 Pull Request 4 Designers - #p4d in #phpcon まとめ： 生煮え Pull Request はデザイナーにも素晴らしい ・実際動くもの、ユーザーが実際使うものに価値がある。 ・仕様や要望は刻々と変わるものである。 ・デザインカンプのブラッシュアップにかける時間を、 プロダクト本体にかけて、実際動くものを見ながら作りこめる。 ・より、一緒に開発してる感じを味わうことができる。 ・納得いかないところは自分で Pull Request 出せばよいし、 組み込みの都合で勝手にデザイン変えられてしまい直せない！ みたいなことも、ない。

ありがとうございました Pull Request 4 Designers in PHP Conference Sep. 21th, 2013 for GitHub を使った プログラマとデザイナーの イテレーティブな 開発フロー