けんごのお屋敷

2013-11-28

本当にあったプログラマとデザイナの怖くない話 in Fukuoka.php Vol.11

Fukuoka.php Vol.11 に参加してきました。

リンク先にもあるように今回は NO PHP DAY ということで Fukuoka.php という名前を冠しながらも、誰一人として PHP の話をしなかったという珍しい勉強会でした。残念ながらUstreamの中継はなかったためオープンにはなりませんでしたが、いろいろと勉強になってたくさんインプットができたイベントでした。素晴らしい発表の数々は、後々各発表者の方より資料やブログが公開されると思います。Twitter では #fukuokaphp ハッシュタグで流れを追えると思います。

そんな NO PHP DAY な Fukuoka.php で僕も LT 枠をもらっていたので、ひとつアウトプットをしてきました。

プログラマとデザイナのコラボレーション

Web 業界では、プログラマとデザイナが一緒に仕事をすることは多いと思います。一般的にプログラマはデザイン業はできません。そしてその逆もしかり、デザイナはプログラミング業はできません。(たまにプログラミングもデザインもどっちも出来て、RailsやるしPhotoshopやるし、なんでも一人でやるぜ、というようなスーパーな人はいますが、そういうのは除外)

そんな中でいかにして効率よくお互いに協力し合いながらサービス開発を進めていけばいいのか、というのはベストプラクティスがありそうでなさそうな、そんな一概には言えない難しい話です。今回は Intobox ではどうやってプログラマとデザイナが協力して開発をしていたのかというプラクティスについて紹介してきました。あくまで Intobox ではこうやった、という事例紹介です。LT では 5 分しか割り当てられてなかったので充分にしゃべれませんでした。補足も込めて、もう一度資料の紹介と内容のまとめを書きたいと思います。

Fukuoka.php でしゃべった資料はこちら。本当に怖くないです。

本当にあったプログラマとデザイナの怖くない話

Intobox を知らない人はこちらの記事も合わせて。送るをもっとシンプルに。ファイル送信サービス「Intobox」をリリースしました。
https://intobox.in

Intobox の開発フロー

Intobox ではソースコード管理に git を、リモートリポジトリとして bitbucket を使っています。開発フローは

  1. bitbucket でイシュー発行
  2. デザイナがモックを作成してイシューに添付
  3. プログラマがモックを元にある程度まで開発する
  4. 今度はデザイナがディテールを調整する
  5. デザイナがプルリクエストを出す
  6. プログラマがプルリクエストを確認してマージ

という流れです。デザイナしかプルリクエストを出していないあたり若干プログラマがリードしてる感じではありますが、プログラマがデザイナに対してプルリクエストを出してもデザイナがわかるところが無いので Intobox ではそれはやってません。逆にデザイナからのプルリクエストをやっているのは、プログラマが作っておいた JavaScript の DOM 操作や Ajax 処理なんかが、タグやクラス名の変更によって壊れていないかどうかを確認するというところで有効に働いていました。

コミュニケーションを欠かさない

プログラマとデザイナはお互い畑違いのところでそれぞれ作業をやっています。ともすれば、私達はお互いに何をやっているかをわかっていません。なので、コミュニケーションはとても大事です。進捗確認という意味でも、モチベーションを保つという意味でも、欠かさずに意識しておきたいところです。

Intobox チームでは Skype と LINE で常にリアルタイムに情報をやりとりできるような状態にありました。また、それらのツールを使っても相手が気付かなかったりオフラインだったりした時は bitbucket のイシューに残して忘れないようにしてイシュー上で話しを続けたり、常にコミュニケーションし続けていました。

そして、もうひとつ大事なのはお互いがやっていることを理解 しようとする ことです。別に全部理解できなくてもよくって、ただその姿勢が大事。理解しなくても、気にかけておく、ぐらいの。わからなければすぐ聞きます、これもコミュニケーションの一環です。Intobox では、デザイナがプログラマのコミットログを読んでわからない単語を質問してきたり、プログラマがデザイナのモックに口出したりして、お互いがお互いを刺激しあっていました。

コミュニケーションの先にあるものとして、先に言ったモチベーションの維持と、もうひとつ情報共有があります。プログラマもデザイナもお互い最初から何でも知ってるわけではありません。git の使い方、開発環境の構築の仕方、CSSの良い書き方、シャドウの効果的な使い方、Facebook と Dropbox の OAuth 認証の仕組み、DB への接続情報、などなどお互いが共有できる情報は山ほどあります。そういうものを見落としてはいけません。Intobox では bitbucket のイシューをメインに開発を進めていますが、議論や調査などもイシューでやりとりをしていました。そういった議論や調査などのイシューは、書きっぱなしではなく必ず Wiki にまとめるという文化が Intobox にはありましたので Wiki が非常に充実しています。これらの情報は財産となりえるでしょう。

そして僕らは週1回程度ハッカソンもやっていました。お互いやることは普段とは変わらないのですが、集まって一緒にやることでお互いの最新情報を交換しあえますし、なにより楽しいです。終わった後の達成感は何にも変えられません。

良いサービスを作っていくために

僕ら Web 屋は自分の自己満足のためにものづくりをしているわけではないですね。作ったサービスの先にいるユーザーの満足を夢見て試行錯誤しているわけです。そのために何が必要か、どうすればいいのか、というのは永遠の課題です。

良いものを作りたい、みんなそう思ってるはず。この Intobox での事例が、良いものを作るためのひとかけらとしてひっそりと、どこかの誰かの心に残ってくれればそんなに嬉しいことはありません。

  • このエントリーをはてなブックマークに追加