デザイナーが開発者と密に連携することは多くのメリットがあります。この講演ではアプリケーションの設計を飛躍的に改善するために行った技術的な判断をデザイナーに伝えることで、デザイナーをコードベースに巻き込む方法について解説します。

---

はじめに (00:00)

このセッションの内容を考え始めたとき、「Xcodeでコードを書かずにできる10のこと」というタイトルで話そうと考えていました。 でも、ここにいらっしゃる素晴らしいiOSエンジニアの皆さんはコードを書かずにそういったことをしたいとは思いませんよね？ なので今日は、「デザイナーをSwiftのコードベースに巻き込む10の方法」という内容でお話ししたいと思います。

Helenです。Mozilla Firefoxでデザイナーとして働いています。開発ツールチームの一員として、Web開発者が1日中、それもほぼ毎日使うようなツールのデザインをしています。 私はこのチームに参加したばかりです、ということはこのツールの見た目からもわかってもらえるかと思います。 これは残念なことです。というのも世界中に同じようなことで苦しんでいる、素晴らしいたくさんのプロジェクトがあるからです。 言い換えると、デザイナーがいることはチームによって良いことなのです。 しかし、そのためにはデザイナーはプロジェクトに取りかかるだけでも、コードを理解する必要があります。 これは解決すべき大きな問題です、というのも大きなコードベースはデザイナーにとって怖いものになり得るからです。

コードベースにデザイナーを含めるべき？ (02:44)

たとえば、Firefoxではセットアップにかなり時間がかかります。最初に取りかかるまでにも、1時間半のビルドを行ったり複雑なバグトラッキングシステムに慣れる必要があります。 デザイナーにとってコードベースは怖いものではないかもしれませんが、コードは怖いものかもしれませんし、プログラムさえ怖いものかもしれません。 皆さんはXcodeに慣れているので、Xcodeはもう怖いものではないでしょう。でもAfter EffectsやPhotoshopは恐らく怖いものでしょうし、Microsoft Wordさえそうかもしれません。

開発ツールの開発が始まった時、チームにはデザイナーがいなかったので、開発ツールは不格好なものでした。 時々、Firefoxの別の場所からデザイナーを借りてくることはありましたが、それも限られたものでした。 開発チームがようやくデザイナーと働くことになったとき、チームはWeb開発を理解しており、一人でコードを書くことができるデザイナーが必要だと理解しました。 チームにデザイナーが加わった際に、デザイナーをコードベースに加え、デザインを実装へと反映するうまいやり方を学んだので、このことは開発チーム全員によって良い学びの経験でした。

Firefoxではコードベースにデザイナーを含めるのが良い考えだと皆が知っています。しかし、あなたは「自分のチームでもコードベースにデザイナーを加えるべきなのか？」と疑問に思うかもしれません。 その疑問に対する答えを探しているなら、デザイナーをコードベースに加えることの良い点と悪い点、 そして、プロダクトの成功だけでなく、エンジニア、チーム、デザイナーの成功のために、あなたが対応すべき設計上の変更を見ていきましょう。

良い点 (03:21)

最も基本的な点ですが、デザイナーがいないよりはデザイナーがいるほうが良いです。 デザイナーの仕事は、アプリの見た目を考えることやUXについて考えること、またはその両方です。 もし、あなたが美しくよく考え抜かれたアプリを作りたいと思ったら、デザイナーがその点を手助けしてくれるでしょう。

2つめに、コードベースにデザイナーがいると、エンジニアが考えるべき、あなたのアプリやニーズに特有の問題を提示してくれます。 ウォーターフォールでは、UXに関連してエンジニアが考える必要がある問題をデザイナーが理解することはとても難しいです、というのも考え方が違うからです。 しかし、デザイナーがコードベースに加わっている場合はそうではありませんし、会社の他のチームのデザイナーに手助けを求める場合よりも早く理解できます。 デザイナーが他のチームにいる場合、頭を切り替えて問題を適切に理解する時間が必要になるからです。

チームにデザイナーがいると、デザイナーはエンジニアの直面する問題を理解することができ、エンジニアが作るものの基準を引き上げることもできます。 たとえ、十分に作り込まれたモックを触ることができなかったとしてもです。

そして、最も重要なことですが、デザイナーがいるとデザインやプログラムと実際のアプリの間の齟齬を解消することができます。 ビルドして実行したり、触ったりすることで、デザイナーはあなたのアプリが想定している全てのシナリオについてより良いフィードバックを返してくれるでしょう。 これは、現実的なシナリオのデザイン、と呼ばれます。

悪い点 (05:06)

デザイナーをコードベースに加えることによる悪い点は、時間に関するものです。 デザイナーをコードベースに加え成功させるためには、デザイナーのために実装上の変更を加えなければなりませんし、メンタリングも必要です。 そして、デザイナーをコードベースに含めることによるメリットもまちまちです。 というのも、すべてのチームは同じということはありませんし、すべての人についてもそうです。 また、それぞれのチームのニーズやアクセスできるリソースというものも異なっているからです。

あなたのチームにとって、良いデザインがそのために費やす時間よりメリットが大きいか考えるために、 実際にどのようにしてデザイナーをコードベースに加えるか、ということを考えていきましょう。 つまり、このセッションのメインタイトルである「デザイナーをSwiftのコードベースに巻き込む10の方法」についてです。

1. まず、デザインと実装に興味を持っているデザイナーを見つけましょう。 あなたがコードベースに追加できるデザイナーは一人前のUIエンジニアから、完全にコーディング初心者までいるでしょう。 いかなる場合であっても、デザイナーをコードベースに含めることによるメリットを享受するためには、実装を学びたいと考えており、 そのための努力をする意欲があるデザイナーを連れてくる必要があります。 みなさんは実装が簡単ではないことを理解しているでしょうし、実装を学ぶことはそれなりのの学習が必要になることも理解しているでしょう。 デザイナーをコードベースに加えることによるメリットを享受することは、実装についても熱心なデザイナーがいる場合にのみ可能なのです。

2. 次にあなたのチームは、メンタリングのための余力を残しておく必要があります。 デザイナーはメンタリングを必要とするでしょうし、そうすべきなのです。 たとえそのデザイナーが熱心であっても、その人からの質問への回答やきちんとしたコードレビュー、などのためにチームに余力を残す必要があるのです。 先に言及したように、デザイナーはUIエンジニアから、完全なコーディング初心者までのどこかに当てはまります。 そして、彼らの遭遇する不足の事態に対応するための人が必要なのです。 Xcodeが心を折るようなアプリケーションだと言っているわけではありません。 一度デザイナーを見つけて、メンタリングに十分な時間を割いてしまえば、あとは実装するだけで大きなメリットをもたらすものがあるのです。

3. まずStoryboardです。Storyboardがあなたのチームやプロジェクトにとってベストかどうかには賛否あると思います。 XMLはバージョン管理が難しいですが、かといってバージョン管理しないわけにもいかないものです。 また、Storyboardがコンフリクトしないようにするためのオーバーヘッドも存在します。 しかし、Storyboardを使うと、あなたのプロジェクトの概要を素晴らしく簡単に把握出来るようになります。 きちんと設計されよくメンテナンスされたstoryboardは、新たに加わったデザイナーがプロジェクトにキャッチアップするのに役に立つだけでなく、 新たに加わったエンジニアがアプリ全体に対して全体的な理解を深めるための素晴らしい手段でもあるのです。

4. AutoLayoutへ切り替えましょう。多くの開発者がプログラムでレイアウトを定義するのを好みますが、 あなたのアプリにAutoLayoutを適用できるのであれば、Storyboardを使うべき理由と同じ理由により、AutoLayoutへの切替を検討すべきです。 AutoLayoutを使うと、新たに加わった開発者やデザイナーがビルドなしに制約を簡単に理解できるような形で制約を追加することになります。 これにより、デザイン変更と実装のフィードバックループが短縮されるのです。

5. IBDesignableを使いましょう。IBDesignableを使うと、ビルドを行うことなく、様々なUI上の変更をStoryboard上で確認することができるようになります。 コードベースへの適用も比較的簡単ですし、Border WidthやBorder Color、Border Radiusなどといった属性を変更したいと思っているデザイナーにとっては価値のある機能です。 もう一度いいますが、これらはすべてデザイン変更とその反映のフィードバックループを短くするためのものです。 デザイナーは、コードベースの中でUIの変更を少しずつ加えることができ、しかもそれぞれの変更の結果をビルドすることなく確認できるのです。 これは、生産性に大きな違いをもたらすでしょう。 Storyboard、AutoLayout、そして、IBDesignableはエンジニアの作業ですが、 デザイナーがそれらに精通したり、Xcodeに慣れるのを手伝うことで、デザイナーにやってくれるよう頼むことができるものでもあります。

6. デザイナーにSketchを使ってもらうようにしましょう。 SketchはBohemian Codingからリリースされているデザインアプリケーションで、多くのデザイナーが愛用しています。 というのもAdobeのアプリケーションよりコンパクトになっているからです。 私もSketchが好きですが、それはSketchとStoryboardがとても似ているという理由からです。 Adobeのアプリケーションの代わりにSketchを使えば、デザイナーはXcodeによりすばやく慣れることができるのです。 SketchのキーマッピングはStoryboardと同じになっていて、素材の書き出し設定もXcode向けになっています。 Sketchのプラグインは、Swift、Objective-C、JavaScriptのいずれかで書くことができ、たくさんのプラグインがすでにGitHub上にあります。 つまり、あなたとデザイナーはチームのために便利なワークフローを作ることもできるのです。 ここまで紹介してきた内容をあなたのコードベースに適用した後でも、まだあなたができることはあります。

7. まず、デザイナーがあなたに何かを依頼してきた時に、彼らと作業するようにしましょう。 デザイナーが、仕事をより簡単にするためにライブラリやフレームワークなどの導入を依頼してくることが必ずあるでしょう。 そういった時に、デザイナーの依頼を無下に断らないようにしてください。 代わりに、デザイナーがフレームワークによって解決しようとしている問題を一緒に作業することで理解し、 その問題について調査し、優先順位をつけてあなたのプロジェクトに追加するようにしましょう。

8. デザイナーを放っておかないでください。 メンタリングだけでなく、定期的にデザイナーとコミュニケーションをとり、デザイナーがコードベースで苦闘している内容を理解することも必要です。 人はそれぞれ違います。何かわからないことがあった時にためらうことなく人に質問できる人もいますが、そうでない人もいます。 あなたのチームのデザイナーがデザインと実装をすることに不慣れなら、何かわからないことがあっても チームのメンバーの邪魔になると考えて黙って質問できないでいるかもしれません。 デザイナーがそうならないように、質問することを勧め、彼らが1人で苦闘することがないように定期的にコミュニケーションをとるようにしましょう。

9. デザイナーをコードベースに追加することはエンジニアを新しく追加することに似ています。 まず、ドキュメント作成に時間をかける必要があります。 新しく追加されたエンジニアでさえ、コードベースを見て回ることによってコードを追加できるようになります。 デザイナーであれば、設計のドキュメントやインラインコメントからより一層メリットを享受することができるでしょう。 とにかくドキュメント作成は良い習慣です。デザイナーが1人でコードを書けるようになるまでのスプリントの間は、ドキュメント作成の時間を取るようにしましょう。 そして、デザイナーに、チームのドキュメントにわかったことを追記したり、個人的に新しく学んだことのログを付けるようにお願いしてみましょう。

10. デザイナーをプロジェクトに加えることはワクワクするようなことです。 デザイナーは、コードベースの中にいる初心者です。 エンジニアにとっては、いいデザインやグラフィック、インタラクションを学ぶ機会になりますし、 デザイナーにとっては、自分が作ったデザインが実際はどの程度実装するのが難しいのかを理解する良い機会になります。 デザイナーは所々でなぜそのようになっているか質問し、コードベースの中でうやむやにしてしまっている問題を明確にすることを助けてくれるかもしれません。 デザイナーがコードベースに加わっていると、デザイナーはデザインが静的な表示だけでなく、インタラクティブにもなりうることをと学ぶことになり、 実際のアプリについて考えざるをえなくなるので、インタラクションデザインはどんどん良くなっていくでしょう。

ポジティブな環境 (15:23)

エンジニアについてもUXについて賢く考えるようになり、完全に作り込まれたデザインの先を考える場合でも 良い見た目のものを作れるようになるでしょう。 学習環境では、誰もが何かを学びますが、それを成功に導くためには、学習環境がポジティブで落ち着いたものである必要があります。 もし、コードベースにデザイナーを加えたことによるメリットを享受したいのであれば、上手くいくだろうタイミングで加える必要があります。 エンジニアとデザイナーが過度にストレスを感じてしまわないタイミングを見計らう必要があるのです。

デザイナーとエンジニアの関係が悪いと、お互いにストレスを感じるようになります。 デザイナーは、エンジニアからモックを受け取る度に、それが納得のいくものでないことに不満を言うでしょう。 エンジニアは、デザイナーと話す度に、実装が不可能と伝えたデザインについてまたしても話すことに苛立つでしょう。 デザイナーがコードベースにいると、こういったストレスはなくなります。デザイナーがチームの一員になるのです。 デザイナーは自分で実際に実装を試すことにより、いくつかのデザインは実装が不可能なものであることを理解するようになりますし、 エンジニアは、デザイナーがコードベースにいるので、デザインから実装を行う過程で、誤った色やフォントで実装してしまったり、 デザイン詳細を実装しないでいてしまうことに対する心配をしなくてよくなります。 チームには、デザインに関する問題を取り仕切ってくれる人がいるのです。デザイナーがいるとストレスが軽減されるのです。

Firefoxでは、チーム全員にとっての学びの経験があったため、デザイナーがコードベースにいることがプロダクトに対して良い影響を与えると皆が理解しており、 また、そのことはFirefox devtoolsの将来について私達を非常にわくわくさせてくれるものでした。 私が学んだことが、あなたやあなたのチームの役に立ち、あなたのプロダクトが真に美しくデザインされたものになる役に立てばと思います。

私を呼んでくださったtry! Swiftの主催者の方々、そしてセッションを聞いてくださった皆さんありがとうございました。質問があれば、Twitterで聞いてください。.

Q&A (16:32)

Q: デザイナーを加えにくい、コードの匂いがするようなコードベースについてはどう思いますか？

Helen: コードベース内にコードの匂いがするようなコードが含まれている場合、間違いなくデザイナーを加えるのはとても難しくなるでしょう。 コードの匂いがするようなコードや、悪いコードを書くことが好きな人はいませんし、悪いコードを書こうと思って書いているわけではないと思います。 メンテナンスしやすく、きれいな���ードを書こうとしていれば、デザイナーがコードベースに参���することは容易になります。 しかし、理由がどうであれ、そのようなコードを書いてしまうことはあると思います。 その場合もドキュメントをちゃんとメンテナンスしていれば、複雑で悪いコードの匂いがするようなアプリであってもデザイナーはある程度作業できるでしょう。

Q: どのようにして開発者にPhotoshopからSketchへの移行を提案しましたか？Sketchに言及した際に反対されたことがあります。

Helen: あなたがiPhoneアプリの開発をしているのであれば、storyboardとSketchのキーマッピングが同じであることは大きな理由の1つになるでしょう。 他の適切な理由としては価格面が挙げられます。Photoshopは600米ドルしますが、Sketchはたった70米ドルと大きな価格差があります。 概して、人に何か新しいことに挑戦するよう説得するのはいつも難しいです。 Sketchで格好いいものを作り、彼らに見せるという手もあります。 そうすれば、ゆっくりですが確実にあなたの作ったもので皆を納得させることができるでしょう。

Q: 開発者とデザイナーがアニメーションを一緒に作り上げる方法について、何か良い考えはありますか？

Helen: デザイナーと一緒にアニメーションを見るということが、1つ良い手助けにはなると思います。 というのも、アニメーションについてPopや、Sizzle、Swooshという言葉を使いますが、言葉だけでアニメーションを表現し伝えるのは難しいからです。 実際にSwooshしているアニメーションを見ないと多くは伝わりません。 なので、一緒にアニメーションを見て、アニメーションに関する共通言語を作ると、上手く伝わるようになるのではないかと思います。

Q: プロトタイピングについて、Swiftで実装してしまうのと、プロトタイピングツールを使うのはどちらが良いと思いますか？デザイナーが一旦実装を学んでしまえばSwiftでもできると思いますが、仰っていたように準備期間が必要ですよね？これに関して何らかの経験はありますか？

Helen: 私はコードとプロトタイピングツールのどちらも使ったことがあります。 個人的には実装してしまう方が好みです、というのも結局のところ、多くのプロトタイピングツールは学習コストが高く、 それなら実装しているとの大差ないからです。 これはあくまで私の意見なので、別のデザイナーに聞けばまた異なった答えが返ってくるでしょう。人によって答えは違います。 ただ、もしあなたのアプリがAutoLayoutや、Storyboard、IBDesignableを使っているのであれば、デザイナーがそれを編集してしまうのがいいでしょうね。