デザイナーと開発者のコラボレーションを改善する5つの原則 | アドビUX道場 #UXDojo

連載

エクスペリエンスデザインの基礎知識

人は、一歩ずつ前進できる学び方を好むものです。私はデザイン関連の出版物に関わる編集者ですが、「開発者への引継ぎを完璧に行うための10のステップ」や「デザインドキュメント作成の際にすべきことと避けるべきこと」といった記事を見るのは珍しいことではありません。こうしたタイトルは、日常的なタスクを実行する際に何らかの指針が必要だと思っているデザイナーにとって非常に魅力的なのです。そして、こうしたガイド記事には大抵、「100パーセント有効であることが証明されたデザインファイル名の付け方」「フォルダの整理方法に関するコツ」「最高に優れたドキュメントの例」などが含まれています。

デザインを開発者に引き継ぐ方法に関する規範的なガイド記事は、理解しやすく、あっという間に読み終えてしまうものです。ところで、その内容は、十分に将来にわたって有効性を持つものなのでしょうか？実際のところ、ファイルの整理、フォルダの命名、バージョン管理には数え切れないほどの正しい方法があります。あるひとつの正しいやり方だけに囚われると、チームごとのニーズの違いや、組織ごとの運営方法の違いを軽視する短絡的な見方になりがちです。

私たちが使用するツールは日々変化しています。デザイナーは、さまざまな業界のあらゆる形態と規模の会社で働いています。それぞれが独自の組織構造や課題を抱え、そのためにワークフローやツールの選択は大きく影響されています。さらに同じ企業内でも、従事するプロジェクトによって期間やチームの構成が大きく変わることがあります。

優れたコラボレーションに必要なのはヒントやコツではなく「原則」

この業界で15年間、私はデザイナーと開発者のワークフローを幾度となく目にしてきました。信じられないかもしれませんが、私がデザインの仕事を始めた頃は、デザインを描画したファイルを各自のコンピュータに保存するのが通例でした。保存したファイルは開発者に投げ渡され、開発者はファイルを開き、やや主観的に見た目について判断し、それをコードで使用できる数字に手作業で変換していました。

それ以来、デザイナーと開発者のコラボレーションの方法は何度も変化しました。ある方法は他よりうまく機能したものですが、ひとつのプロジェクトでうまく機能した方法が別のプロジェクトでは問題を引き起こしたことも幾度となくありました。もし私が具体的なガイドラインを書いていたとしたら、数週間ごとに書き直さなければならなかったことでしょう。だから、私は原則に注目したいと思います。原則は、その有効期間が比較的長く、デザインチームの構成や規模に関わらずプロセスを円滑にする傾向を持つからです。

デザイナーと開発者のコラボレーション（ファブリシオ・テイシェイラとヴァネッサ・サンタアナ。ニューヨーク州ブルックリンにあるWork & Co オフィスにて）

これから紹介するリストは、私の個人的な原則です。私はデザイナーとして、少なくとも1日の3分の1を開発者との共同作業に充てて、デザインの見直しや実装を行っています。時間の経過とともに具体的な方法やテクニックはかなり変化しましたが、これらの原則はいまでも有効性を失っていません。

1. 開発者はユーザーである

もし、デザイナーがユーザーに向けるのとと同じだけの注意を、開発者のデザイン（とデザインドキュメント）への関わり方に向けたならどうなるでしょうか。

デザイナーは製品体験の構想を考えるとき、常にユーザーのニーズと課題への配慮を忘れません。しかし、その体験をデザイナー自身が実装しない限りは、ユーザーがデザイナーの考えたデザインそのものに触れることはありません。ユーザーが使用するのは、デザインドキュメントに基づいて開発者が構築した最終成果物です。つまり、デザイナーにとって、プロジェクトの段階における実際のユーザーは開発者だということになります。

ひとたびその発想をデザインの実践に取り込めば、ワークフローに関するどんな決定も開発者を中心に行われることになります。ユーザー調査を実施するのと同じように、プロジェクトの開始時点でエンジニアリングチームにインタビューを行えば、開発者の好み、工程、課題を理解し、彼らのニーズに合った作業モデルを考え出すことができます。

• 開発者が好むドキュメンテーションの受け取り方は？頻度は？経路は？
• どの程度の詳細が必要なのか？文字による説明と視覚的説明のちょうどよいバランスは？
• システムの動作に関する視覚化されないルールについて、特定の開発者グループに伝えるにはどのような方法が最も有効か？その方法は、製品のほかの部分の担当チームや組織内のほかのグループと一致させられるか？

プロジェクト専用のウィキを立ち上げるチームがあるかもしれません。作成するドキュメントは、週に2回開催されるQ&Aセッションのような_ミーティング_をまとめたものかもしれません。すべてのユースケースが文書化されるまで実際の開発を開始しないチームもあれば、試作を繰り返して柔軟にルールを定義するチームもあるかもしれません。

デザイナーは、ユーザーのニーズに合わせてデザインするように、開発者のニーズに合うようデザインワークフローを調整するべきです。

2. 唯一確実なことは変更を求められること

デザイナーには柔軟さが必要です。チーム構成に合わせてプロセスを変えたり、プロジェクトの展開に合わせてワークフローを調整する必要があります。

ごく一部の例外を除き、デザイナーは新しいプロジェクトが始まるたびに、ワークフローとドキュメントを適応させることになります。経験を積むにつれ特定のドキュメントの書き方を身につけたとしても、それが有効であるかどうかは状況によって変わります。どのチームでも通用するデザインドキュメンテーションの扱い方やコラボレーションを成立させる方法は存在しません。

各開発者の性格も考慮しなければなりません。開発者によっては、特定の課題に一緒に取り組むためにデザイナーが席まで足を運ぶことを心から嬉しいと思うかもしれませんし、同じチームの別の開発者は、ヘッドホンをかけてワークフローに集中し、疑問はSlackやチケットのコメントを通じて解決することを好むかもしれません。

デザイナーはすべてをコントロールする存在ではありません。デザイナーにとって唯一確実なのは、「変化」です。どんなプロジェクトでも、デザイナーの領域の外で起きた変化が作業に影響を与えうるだろうと予測すべきです。たとえば、新しい関係者がチーム加わったり、リリース日が突然変更されたり、予期していなかったプラットフォームや技術の制約が見つかったりするかもしれません。目に見えないチーム内のコラボレーションの仕組みを見極める術を身に付け、迅速にワークフローを適応させる準備を整えておけば、短期的にはフラストレーションを減らすのに役立ちますし、長期的にはより良い協業の相手になることができます。

3. デザインが完成することはない

プロジェクトのデザイン作業がが完了したとしても、それはまだ半分終わっただけに過ぎません。

特にウォーターフォール型のプロジェクトでは、あるいはもっとアジャイル寄りのプロセスでも、デザイナーの仕事はすべての画面をデザインした時点で終了するという誤解が一般的です。本物らしさを感じる制作物（デザインのモックアップやプロトタイプなど）の完成が、デザイナーの責任は全うされたという誤った錯覚をつくり出すこともあります。実際には、デザイナーは画面上のデザイン以上に、画面の裏側で起きている機能について考えるべきなのです。

デザイナーにとって本当の問題が始まるのは、開発者がデザインの詳細を確認して質問し始めたり、品質評価の担当者がデザイナーには予測できなかったユースケースについて考え始めたときです。制約やルールが増えるにつれ、それらを回避しつつ体験のシンプルさと明確さを維持しながら新しい要件に対応することが困難になります。ここが、良いデザイナーと優れたデザイナーの間に線引きが行われる瞬間です。

デザイナーが責任をたらい回しにしようとする場面を本当に多く目にしてきました。これはあまり素晴らしい行為とは言えません。デザイナーが思い描いたような体験が最終的に達成できなかった場合、その責任は、ほかの人と同じくらいデザイナーにもあります。デザイナーの役割は、見映えの良い_モックアップ_を作成することではなく、スマートで使いやすい体験を実現することです。つまり、デザイナーには、チームによって実装される最終成果物に対する責任があるのです。

伝説的なデザイナーのひとりディーター・ラムスの「優れたデザインの原則」は、時代を問わず適用されるべきもの 出典: キリル・ジリンスキー

4. 少ないことは良いこと

プロジェクトマネージャーが実現する機能を縮小しようとしたときには不満を感じるかもしれません。しかし、それを体験の質を高めるチャンスと捉えることができます。

洞察力に優れたドイツ人デザイナーのディーター・ラムスは、20世紀で最も名の知れた影響力の高いデザイナーのひとりです。機能主義を固く信じたラムスのデザインに対する合理的なビジョンは彼の有名な言葉 「Less, but better.（より少なく、しかしより良く）」に集約されています。もちろん、彼は当時インダストリアルデザインについて述べたのですが、この考え方は、現代に生み出されるデジタル製品やサービスについても依然として当てはまります。

デザインが複雑化するにつれ、製品マネージャーは機能の優先順位をつけ始めます。そして、デザイナーは、もともと想定していた製品と体験に対するビジョンが縮小していくのを目にします。それは歯がゆいことかもしれません。ですが、優れたデザイナーはそれを機会に変えることができます。彼らは、デザインしている体験の質に集中してより良い体験を提供できるのであれば、機能が減らされても構わないことを理解しているのです。

デザイナーにとって、デザインする機能数が減ることには次のような意味があります。

• トランジション、ステート、アニメーション、コピーなどを、的確に文書化するために時間を費やせる
• デザイナーの持つビジョンを正しく伝えるために、開発者と働く時間を増せる

5. 情熱は伝染する

初期のコンセプトやデザインの模索、あるいは製品に関する戦略についての議論に開発者が関与しないケースがあります。そこに生まれるギャップを埋め、開発者の全体像に対する理解を容易にするために、デザイナーには何ができるでしょう。

開発者は、開発される製品が持つビジネス上の意味をある程度理解しているかもしれませんが、デザイナーの持つさまざまな意図をすべて理解しているわけではありません。ユーザーの体験を学ぶための調査において、開発者がユーザーと必ずしも対話してきたわけではありません。また、開発している特定の機能が、人々の生活にどのような影響を与えるのかを明確に理解していないかもしれません。

デザイナーには、ユーザーの声をチームに伝える役割があります。ユーザーの立場で物事を考えられることを当然のように捉えて、ユーザーの想いをチームに共有する重要な役割を忘れてしまうのはよくあることです。調査中にユーザーから聞いたちょっとした逸話、自分たちの製品が人生を完全に変えた人の個人的な話など、どんなストーリーでも共有しましょう。デザイナーの共感力、ユーザーへの注意力、そして情熱。これらは開発者を刺激し、機能がどのように動作するかということだけでなく、人々の生活にどのような影響を与えるのかを理解させることのできる、非常に高い価値を持つリソースです。

デザインは団体競技

昔ながらの典型的な「ロックスターデザイナー」は（ありがたいことに）いなくなりつつあります。デジタルチームが拡大し、プロジェクトの複雑さが増すにつれ、デザイナーの価値は、特定の成果物ではなく、コラボレーションスキルとチームへの貢献に見出されるようになっています。チーム内コラポレーションへの対応についての原則を確認することは、デザイナーの実践をより意図的なものにする第一歩になるでしょう。

この記事は5 Principles for Better Designer-Developer Collaboration（著者:Patrick Faller）の抄訳です