Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー

PHPカンファレンス2013 の #P4D ワークショップでお話させていただきました。

私がお手伝いさせていただいてる Forkwell のサービス開発のフローを例に紹介させていただきました

# 補足などを追記
http://d.hatena.ne.jp/ken_c_lo/20130915/1379237062

[PR]
エンジニアのためのポートフォリオサービス
https://forkwel.com

「スキル」と「こだわり」で選べる、エンジニア目線の求人サイト
https://jobs.forkwell.com

Transcript

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

   View Slide

2. 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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide