現代のプロダクトチームが抱えるもっとも大きな課題の１つに、大規模なチームでいかにデザインを進めるか？ということがあります。
大規模チームでは、どのような活動が求められるでしょうか？ どのように協調関係を築き、意思決定をすれば良いのでしょうか？ 質の高い成果物をスケジュール通りに届けるにはどうすれば良いのでしょうか？
Atlassianのシドニー支社
このスケールの問題にどのように対処しているのかを知るために、今回私たちはAtlassianのデザインチームから以下の３人に話を伺いました。
- Ashleigh Sterzenbach―シニアプロダクトデザイナー
- Erin Howard―シニアユーザーリサーチャー
- Alastair Simpson―デザインチーフ、Confluence、Hipchat、プラットフォーム担当
2,200人以上の社員を抱える企業において、どのように効率よく協力しながら、プロダクトの品質を保てるデザインチームとプロセスを構築しているのかを、彼らは明かしてくれました。
チーム構成
2012年にたった６人のデザイナーで始まったAtlassianのデザインチームは現在、デザイナーとライター、ユーザーリサーチャーを含めて約200人の社員を抱えるまでに成長しました。
チームは、現在デザインチームの主任を務めるJürgen Spangl氏が率いており、彼が直接CEOに報告します。
デザインチームの組織は、５つの部門から構成されています。
- 情報体験：プロダクトのコンテンツとインターフェイスのコピー、技術のドキュメントを作成する
- ユーザーリサーチ：ユーザーのニーズを調査、実証する
- プロダクトデザイン：プロダクトを改良し、新プロダクトを開発する
- クリエイティブチーム：インタラクティブなマーケティングプロジェクトを作る
- デザインオペレーション：適切なツールやプロセス、ビジョンを設計してデザインチームを成功に導く
５つ目のデザインオペレーショングループ内のデザインシステムチームは、最新のデザイン言語を作るために、すべてのプロダクトチームと協力して常に新しいことに挑戦しています。
一方で、情報体験とユーザーリサーチ、プロダクトデザインのチームは、プロダクトチームに配属されます。
プロダクト開発を統括するために、Atlassianでは「トライアド（３つ組）」のモデルを採用しています。これは、エンジニアリング、プロダクトマネジメント、デザインの３つの部門がすべて協力して意思決定をするモデルです。
この組織について、Alastair氏は次のように述べます。
「エンジニアリングとビジネス、顧客問題を解決するためには、トライアドが健全な関係にあることが必要です。技術的問題からプロダクトのパフォーマンスが損なわれているのなら、その機能がどれほど洗練されているかは問題ではありません。このように、トライアドは体験全体に対する最終的な責任を負います。」
マネージャーは、ロードマップのあらゆる段階を規定するのではなく、企業の年次戦略とプロダクトスケジュールに基づいて、チームを適切な方向に導きます。マネージャーは戦略全体に対して影響をもつ一方で、トライアドは完全に自律して意思決定ができます。そのため、マネージャーが常にあらゆる事項を承認する必要はありません。
プロジェクトが始まると、マネージャーは定期的にチェックと評価をします。これによりトライアドの仕事は、企業の高度な戦略に適合したものになります。Erin氏は次のように主張します。
「すべてをあらかじめ定義づけたロードマップに従うのではなく、個々人がきわめてフレキシブルに働くことで、使用状況や課題を検証しています。また、締切のせいで適切な問題が解決されているのかをチェックせずに納品してしまうような、習慣的な技術問題を避けることにもこの方法は役立っています。」
Atlassianのアジャイル型デザインプロセス
実装スピードとプロダクト品質のバランスを保つために、Atlassianではデザインのプロセスとして、体系的でありながら流動的でもあるプロセスを実践しています。アジャイル型の定期的なアップデートを行う方法論に従い、プロダクトチームでは線形的に作業を進めるのではなく、協力しながら作業を進めることを重視します。
１. チーム内のコンテキストを揃える
知識のギャップを明らかにするために、プロセスは常にデータとリサーチを参照することから始めます。
たとえば、既存の機能を改善する作業を行っているとしましょう。このときチームは、使用状況やユーザー行動に関する、質的データと量的データから参照し始めます。しかし、新しいプロダクトや機能を開発するときには、生成的調査（generative research）による質的なインサイトがより重要です。
適切な問題に着手しているのか確かめるために、チームは数週間を用いて、即席のプロトタイプを検証したりユーザーリサーチを実施したりします。
- だれがその問題を抱えていますか？ 私たちは問題の存在を認識していますか？
- 何が問題になっていますか？ 私たちの仮説はどんなデータやリサーチに基づいていますか？
- なぜその問題を解決するべきなのですか？ 顧客やビジネスへの影響はどのようなものですか？
- どこでこの問題は生じていますか？
チームメンバーには、リスクが生じるエリアを特定することが求められ、また時にはプロセスを中断してさらに検証を続けることが推奨されます。Erin氏は言います。
「ユーザーリサーチャーとして、私はデザインプロセスを懐疑的に見がちです。たとえば、ユーザーへの理解が必要な部分を理解できていなかったとき、私たちはプロダクトのアップデートのプロセスを中断しました。そしてもう一度リサーチをいくつか実施して課題を解消し、結果的に正しいものを届けることができました。」
カスタマージャーニーの完成図を作るために、トライアドは複数の調査活動やワークショップを実施しています。これらはAtlassianのチームプレイブックでより詳しく説明されています。
- 競合分析
- アイデアに対するプレスリリースの作成 ※Amazonの逆向き解決法より（Working Backwards：プロダクト開発以前にプレスリリースを作成する開発方法）
- ユーザーインタビュー、コンテキストインタビュー、アンケート、その他の民族学的リサーチ
- 基準となる体験
- プロジェクトキャンバス
- ユーザー体験キャンバス
- ジョブストーリー
- ペルソナや役割のカード
Alastair氏は言います。
「このプロセスでは、すぐにソリューションを考え始めるべきではありません。すべての解決策が、等しく成功するわけではありません。顧客やビジネスに応じて指標を動かすことで、成功につながるのです。」
２. アイデア出しと制作におけるコラボレーション
顧客に価値をできるだけ早く届けられるように、プロダクトマネージャーは、エンジニアやデザイナーが大きな課題を小さな作業ごとに分割できるよう手助けします。そのあとトライアドのメンバーは、２人組になって分割された作業に対処します。この点についてAshleigh氏は次のように述べます。
「エンジニアはピクセルを扱う仕事ではありません。しかし彼らは必ずアイデアの作成に関わります。私たちは作業プロセスの一部として、デザイナーとエンジニアをペアにして作業させています。」
コンセプトを考えるうえで、Ashleigh氏のようなデザイナーが綿密なスケッチセッションをするのはきわめて良くあることです。このセッションには、デザイナーとプロダクトマネージャー、エンジニア全員が参加します。実際、スケッチにしろワイヤーフレームにしろ、忠実度の高いプロトタイプにしろ、チームがフィードバックを収集せずに丸１日放置することは滅多にありません。
プロダクトチームは単独での作業と協力するセッションを使いわけています。この活動は、以下のようにしっかりと決められています。
- スタンドアップミーティング（毎日）：トライアドは、プロジェクトに関するアップデートや課題、やるべき項目の要点を共有します。
- チームスパーリング（毎週）：デザイナーはデザインの背景にあるコンテキストや理由を説明し、トライアドでフィードバックを求めます。それぞれ個別でフィードバックを考えてから、グループで討論します。続いてデザイナーは、どのフィードバックを次のバージョンに反映する予定なのかを説明します。
- デザインディテンション（隔週）：プロダクトチームのデザイナー全員が、３時間から１日ほど集まり、個人かペアで課題に取り組みます。取り組み終わったら、チームスパーリングを行います。メールやチャット、ミーティングはすべて中断されます。
- デザインブリッツ（毎月）：デザインスプリントを凝縮したようなもので、トライアドは何時間にもわたって、協力して複雑な課題に取り組みます。
Alastair氏は次のように主張します。
「『デザイナーだけ』で仕事する段階は一度もありません。確かにデザイナーは、ある程度は自分だけでモックアップを作成するでしょう。しかし顧客の問題を解決するのには全員が関わります。独力では優れたプロダクトを作れません。」
３. 効果の測定
トライアドは、プロダクト開発のプロセスを通じて最初に決めたベースラインの指標を基に、定期的に自分たちの仕事を測定します。
AtlassianではAttrakdiffやTreejack、UserTestingのようなツールを使って、ユーザーリサーチやユーザビリティテストの結果を、測定機能のないUXのスコアカードにまとめます。扱うデータは以下のようなものです。
前出のAshleigh氏は言います。
「新しい体験が良好に進んでいることを確かめるために、私たちは常に、現在のプロダクトに含まれるものを測定して基準にしています。こうすることで、デザインプロセスを進めて反復し続ける中で、意思決定に対して確信を持ちやすくなります。」
AtlassianのUXスコアカード
４. 慎重に納品をして定期的に点検を行う
Atlassianの納品でのポリシーは、「点検２回、カット１回」という言葉にもっとも現れています。
Ashleigh氏は言います。「私たちは代理店の形式で仕事をしてはいません。デザイナーは、納品に関するすべての工程に関わります。」
実際、技術に精通したデザイナーであれば、コードの見直しに参加することもあります。反復し、品質評価し、測定するサイクルによって、トライアドはクラウドプロダクトを毎日フロントエンドからもバックエンドからもアップデートすることができます。
プロダクトや機能が公開されたあと、トライアドは測定機能付きのUXのスコアカードで指標を記録します。顧客態度の指標の変動を測定することで、チームは新しい体験の実際の影響を確認することが可能です。Ashleigh氏は言います。
「世界中のチームの何百万人の人々が、仕事で私たちのプロダクトを頼っています。どのように変化を公開するのか、私たちは目的意識と思いやりを持たなければなりません。」
結論
Atlassianでのプロセスが示す通り、測定可能なプロセスの鍵は、基本をきちんと実行することにあります。
役員レベルの場でもデザインの話をできるようにしましょう。そして自然と協力できるようなプロダクトチームを構成して、意思決定を行う機会を毎日設けてください。トップダウンの官僚制をやめて、チームの自主性に任せるモデルに替えることで、実際に大規模なデザインチームでも成功できるでしょう。
Alastair氏は言います。
「行動をいちいち細かく管理されたいと思うチームは存在しません。どんなチームも作業に対して、権限と責任を望んでいます。マネージャーがすべてを細部まで見ることは不可能です。賢い人材を採用して、適切な質問をしましょう。そうすれば、あとはなるようになります。」
Atlassianのデザイナーに興味はありますか？ Atlassianのデザインキャリアページをチェックして、応募可能な職種を見てください。
