デザイナーと読みたい『チーム開発実践入門』

kagata

2014.05.30

来週末の WordCamp Kansai 2014 を今から楽しみにしている kagata です。地元京都への帰省を兼ねて、横浜から遠征します。関西のみなさまどうぞ仲良くしてください。

さて今回は読んだ本の紹介です。先月、技術評論社さんから『チーム開発実践入門──共同作業を円滑に行うツール・メソッド』という本が刊行されました。この本は、主に次のような内容を取り上げています。

バージョン管理
チケット管理
継続的インテグレーション（CI : テストの自動化）
継続的デリバリー（CD : デプロイの自動化)

書名もチーム「開発」をうたっているし、取り上げるテーマもエンジニア向けに見えます。が、わたしはここで訴えたい。

エンジニアじゃなくても Web 制作を仕事にする人はみんな読もう（特に前半）！！

この本が取り上げるテーマの中でも、特にバージョン管理とチケット管理はエンジニアでないにもいっしょに使ってもらいたいものです。この本を読んでもらえれば、それらが何をするもので、何の役に立つのか、感じてもらえるのではないかと思います。

しかし、理屈ではわかっても実際に運用するにはいろいろと心理的な抵抗があるものです。そこで、それらのデザイナーを含むチーム全体でそれらのツールを運用する中でエンジニアは何に気をつければいいのか、少し考えてみました。

なお、以下の文章で「デザイナー」といっているところは「ディレクター」「プロデューサー」あるいは「マーケッター」などに読み替えても ok です。弊社 Web ソリューション事業部の職分が大きく「エンジニア」「デザイナー」に分かれているので今回はデザイナーとしていますが、ほとんどがエンジニアでない人みんなに共通する内容です。

デザイナーとしたいバージョン管理

『チーム開発実践入門』が説くバージョン管理システムのメリットは次のとおりです。

変更内容という最も基本的な記録が残る

バージョン間の差分をかんたんに確認できる

間違って他人の変更を上書きしないで済むしくみがある

任意の時点まで巻き戻すことができる

複数の派生を作ることができる、ある時点での断面を保存できる

特に重要なのが「変更内容の記録」です。作業ログやバックアップをとる方法はいろいろありますが、エンジニアとしてはデザイナーにも統一したツールを使ってもらえると一緒に仕事がしやすいと考えるわけです。

デザイナーにバージョン管理システムを使ってもらうにあたって、エンジニアは次のようなことに気を遣うとよいと思います。

こわくないよ！という雰囲気づくり

コミットエラーやマージの衝突など、トラブルにはいつかかならず出会います。それがうまく解決できないと、バージョン管理そのものへの印象が悪くなり、結局チームに根付かないということになりかねません。

トラブルが起こったら気軽にエンジニアに相談してもらえる雰囲気を作ったり、トラブルシューティングのノウハウを文書化して共有するなど、ていねいなケアが大事なところです。

使ってもらえるようデザイナーにお願いする気持ち（？）

というと言い過ぎかもしれませんが…デザイナー個人の作業は、意外に省力化されない場合があります。例えば、画像などバイナリデータをよく扱うデザイナーにとっては、差分取得やマージの恩恵を享受しづらいという面があります。

そんなときにも、エンジニアの都合をおしつけるのではなく、チームのみんなが気持ちよく作業できるような環境やフローをつくっていきたいものです。

デザイナーとしたいチケット管理

そういえば、チケット管理ってそもそも何のためにするんでしょう。『チーム開発実践入門』では、バージョン管理システムの導入に続いて次のように述べられています。

これでもう、いつ、誰が、どう変更したかについてはきちんと記録でき、いつでも追跡できるようになりました。（中略）

ですが、その変更がなぜ入ったのかについてはバージョン管理システムだけではわかりません。これを解決するのがチケット管理システムです。

バージョン管理システムで記録した作業ログに、「変更した理由」を紐づけるためのシステムということですね。

エンジニアは「ログを残す」ことが大好きです。メールは日々埋もれてしまうものです。作業の連絡をメールで取り合っていては、あとから作業のいきさつを探し出して振り返るのも一苦労です。なので、あとから情報をすぐに取り出せるようなシステムを使って作業のいきさつを記録したいと思うわけです。

バージョン管理システムと比べれば、エンジニアでない人たちにもチケット管理システムはとっつきやすいツールだと思います。でも、どうして電話やメールですませないのか、「ログを残す」という発想がエンジニアほど染み付いていない人にとっては手間が増えるようにも見えるかもしれません。ここでもやはり、そういった負担ができるだけ小さくなるような運用フローをエンジニアが一緒になって考えることが大事だと思います。