この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
健康診断の結果が思ったより悪くて、ちょっとへこんでいるたごです。こんにちは。
今回はよくある話題ではありますが、デザイナーとプログラマの共同作業について書いてみたいと思います。
はじめに
アプリケーション開発をするにあたって、デザイナーとプログラマの共同作業にはずっと課題がつきまとってきました。
互いの理解不足によるすれ違いだとか、一つの成果物を作り上げるのに両者でどう分業すればよいかとか。
前者は人と人の問題なので互いに歩み寄って行くしかありませんが、後者の課題にはこれまでもツールやフレームワーク、開発プロセスの面から解決の工夫がとられてきました。それによって最近はだいぶやりやすくなったんではないかとは思いますが、万事解決というわけには行かないのが実情です。
まあ理想としてはデザインもプログラミングもどっちも得意な人がやってしまえばいいんですが、そういうスキルを持った人をメンバーに集められるかと考えると、ちょっと難しいわけです。
やはり互いの得意なスキルを持ち寄って、うまいこと分業していく必要があります。
弊社のアプリケーション開発案件でも、ほとんどの場合でデザイナーとプログラマとの共同作業が発生します。
私がリーダーを担当したWebアプリ開発案件のフロントエンド開発ではどういうやり方をしていたのか、ふりかえってみようと思います。
ケース１ デザイナーとプログラマの成果物が別々
2012年なので少し前になります。フロントエンドのメンバーとスキルはこんな感じでした。
- デザイナー１名（プログラミングスキルなし）
- プログラマ２名（ある程度Webデザインのスキルもあり）
進め方はこんな感じでした。
- 仕様検討
- ワイヤーフレーム作成【デザイナー】
- ビジュアルデザイン（カンプ）作成【デザイナー】
- モックアップ作成【プログラマ】
- 実装【プログラマ】
このケースは新規開発案件で、UIもゼロから検討するところから始まりました。そのため仕様検討の段階からデザイナーに参加してもらい、直接お客様とやり取りもしつつUIの検討を進めてもらいました。幸い時間があったので（といってもスケジュール的にはギリギリでしたが）、行ったり来たりはしつつも段階的にお客さまと合意をとりながら作業を進める事ができました。
中でもワイヤーフレーム作成にはかなりの時間をかけました。ワイヤーフレームを紙に印刷し操作感や画面遷移も検証するなどペーパープロトとしても利用しました。このやり方はお客さまには好評だったのですが、成果物の目的が曖昧になってしまったので、ワイヤーフレーム作成とペーパープロトタイピングは別ものとして区別した方がよかったかも知れません。
ビジュアルデザインを経てある程度デザインが固まったところで、モックアップ作成に入りました。
このときのデザイナーはプログラミングスキルは持っていなかったので、ここでプログラマにバトンタッチです。プログラマはWebデザインもできる人だったので、デザイナーと会話しつつ意図を汲み取りながらモックの作成をしてもらいました。
モックと言いつつもサーバーサイドとの連携が無いだけで、そのままプロダクトコードとして利用できるレベルまで実装し、後の実装工程ではほぼそのまま採用することで作業を効率化をしました。こういった事ができたのもUIデザインの段階で十分に検討を重ねた結果です。
こうしてみると、この案件ではデザイナーとプログラマの担当工程と成果物がはっきり分かれていました。絵からWebコンテンツに起こす段階ではプログラマのスキルにだいぶ助けられましたが、デザイナーとプログラマの共同作業としてはうまくいったのではないかと思います。
ケース2 デザイナーもソースをさわります
こちらは最近の案件です。フロントエンドのメンバー・スキルは以下の通り。
- デザイナー１名（スクリプトも書けます）
- プログラマ３名（ある程度Webデザインのスキルもあり）
進め方はこんな感じでした。
- 仕様検討
- モックアップ作成【デザイナー】
- ビジュアルデザイン（カンプ）作成【デザイナー】
- 実装：マークアップとロジック実装【プログラマ】
- 実装：スタイリングなどデザイン適用【デザイナー】
この案件ではお客さまからUI案の提示があったので、それをベースにモックアップを作るところから始めました。
モックはAxureというツールを利用し、短期間で作成する事ができました。ただその後の仕様検討が難航してUIデザインも停滞気味となり、キツめのスケジュールの都合上ビジュアルデザインまで揃わない段階で実装を始めることになってしまいました。
実装での役割分担は進め方で書いた通りでしたが、プログラマが実装中の画面に対してデザイナーがデザインを適用する必要があります。デザイナーがあまりロジックのことを気しなくても作業ができるようにしたかったので、作業の分け方を悩んだ末、まず次のように進める事にしました。
- デザインを適用する段階で、プログラマは実装中の画面から静的HTMLを抜き出し（具体的にはWebブラウザで表示した画面のソースを別に保存）、それをデザイナーに渡す。
- デザイナーはHTMLにスタイルを適用しプログラマに返す。
- プログラマが実装中の画面にデザインをマージ。
この手順でしばらくやってみた結果、次のような課題がでてきました。
- 複数の画面の実装を同時並行で進めていたので、デザイナーがある画面に適用したスタイルが別の画面の作業の際に再利用できない。
- デザイナーの作業でDOM構造が変わってしまい、プログラマに戻されたときにスムーズにマージができない。
前者の課題に対しては次のように対応しました。
ソースはGit（Bitbucket）で管理しており、各画面の実装は別々のfeatureブランチで作業しています。デザイナーがデザイン反映作業をする前に、その前にデザイン反映したブランチをマージして、前の画面の作業結果を引き継ぐようにしました。結果として作業フローは複雑になってしまいましたが、デザイナーは順番に作業を進める事ができるようになりました。
ただ、フローの複雑さの点と、マージ作業はプログラマに頼んでいたので負担が増してしまった点については、課題として残ってしまいました。
また後者の解決の為に、作業手順を次のように見直しました。
- 画面の実装前に、ビジュアルデザインまではFixさせる。
- デザインをもとにプログラマがHTMLのマークアップをする。この段階でロジックの実装はしない。マークアップが完成したらデザイナーに引き渡す（渡し方は前の手順と同じく、ブラウザで表示した画面を保存したものを渡す）。
- デザイナーがスタイルを適用する。基本的にDOMの構造は変えず、やむを得ず変える場合はプログラマと合意する（勝手に変えない）。完成したらプログラマに引き渡す。
- プログラマはデザインをマージし、ロジックの実装を始める。
こういった感じで、課題が見つかったらチームで対策を検討し、少しずつ改善しながら開発を終わらせる事ができました。
最後に
フロントエンド開発の進め方が異なる２つのケースをふりかえってみました。
ケース１はシンプルな進め方だったのであまりトラブルもなく開発することができましたが、ケース２では作業が複雑な分だけ課題も多かったです。
今後は開発期間が短いといったことからケース２のような案件が多いと思うので、今回の経験を生かしてうまいことやれたらなと思います。
12
