私は、成功はSOW（作業範囲記述書：statement of work）から生まれると信じています。UXデザイナーとUXリサーチャーによる私のチームが、クライアントのニーズを完全に理解して最適なソリューションを作り出すのに必要な時間と貢献を得られるかどうかは、適切で達成可能なSOWを作れるかにかかっています。
残念なことに、私たちは事前に定義されすぎた、問題を理解する前にソリューションを指定しまうSOWに従って働くことが多いです。プロジェクトの範囲を正しく定義できない理由の１つは、クライアントが曖昧さを嫌うからです。「チームには誰がいるのか？」「彼らに何が出来るのか？」「どのように実現するのか？」「どのくらい時間がかかるのか？」というように、クライアントが自分たちの投資から何を得られるのか知りたがるのは当然でしょう。
しかし、アウトプットをあらかじめ固定すると、デザイン戦略の価値を制限してしまいます。デザイナーには、情報を十分に集めてからソリューションを定義できる柔軟性が必要です。
デザインスクールでは、方向性が不明瞭なせいで生徒が自信を持てずにいるとき、私たちはプロセスを信頼するよう彼らを後押ししました。ありきたりな応援でしたが、学生だけでなく私たちにも有効でした。しかし、これは役員の集まる会議室では大して説得力がありません。クライアントが求めているのは、それ以上の説得材料です。
この記事では、クライアントがプロセスを十分に信頼してくれないときに、彼らを安心させる３つの方法について述べます。
プロジェクトを通してクライアントを巻き込む
クライアントに自分たちが投資している形のないものを確認し、理解してもらうために、私たちの立場に立ってもらいましょう。クライアントがプロジェクトを通して常にチェックすることで、クライアントはソリューションの進捗状況を追うことができます。一方で、私たちはクライアントのユーザーインタビューに同行し、検討中の不完全なアイデアを共有し、もっとも適切なデザインの成果物を決定するために協力します。
私たちと一緒にプロジェクトに携わることで、クライアントはクリエイティブなプロセスに何が導入されているのか、リサーチのインプットがどのようにアウトプットに繋がるのかを直接知ることができます。そうすれば、私たちの仕事に大きな衝撃を受けることはなくなるでしょう。私たちのスタジオには、プロジェクトの結末にクライアントが驚いたら、私たちの仕事は失敗だというルールがあります。
人間中心のデザインを実践する以上、私たちが関与し終わったあとも、ユーザーの意見が反映され続けるようにすることが必要です。優れたペルソナをクライアントに提供するだけでは十分ではありません。クライアントには、ビジネスの人間的な側面に目を向けてもらう必要があります。
わかりやすく伝えるために、私たちが６月に終えた10週間のプロジェクトを例に挙げましょう。このプロジェクトでは、ある医療機器会社の研究開発チームと、直接ワークショップとインタビューを実施しました。解りやすく伝えるために、ここではその会社をHerchek Medical Suppliesと呼びます。このプロジェクトの目的は、研究開発スタッフにネガティブな影響を与えているプロセスと技術的な課題を見つけ出し、彼らの問題に対処する方法を推薦することでした。
リサーチを始めるとき、私たちはプロジェクトの重要なステークホルダーである研究開発チームのリーダーを招いて、すべてのワークショップに出席し、あらゆる小さなグループの議論を聴いてもらいました。直接関与することで、チームに共感してもらいたかったのです。当初、彼らは自分たちがその場にいる価値を分かっていませんでしたが、自分たちが知らなかった話や不満、要望を聞くとすぐに興味を持ちました。
参加者の立場から考えると、研究開発チームのメンバーは、マネージャーが積極的に意見を聞いてくれるのが嬉しかったようです。マネージャーが率先して関与していることは、彼らが本当にチームやチームのニーズに注目していることを裏付けていました。マネージャーたちは、ただ言うべきことを言うのではなく、行動すべきことを行動していたのです。
リサーチが終了した後、私たちは中間報告のプレゼンの中で、Herchekのリーダーに発見事項のサマリーを提供しました。ユーザーの不満を強調し、チームの話を共有し、私たちが考える次のステップについて説明しました。
マネージャーにとって、この報告においてもっとも重要な要素は、共有された情報を知ることではありませんでした。彼らは現場にいたので、すでに内容は知っていたのです。彼らにとって価値があったのは、私たちが従業員から得られた情報をどのようにまとめ、テーマに落とし込んだのかでした。彼らの関与のおかげで、私たちは貴重なプロジェクトの時間を無駄にすることなく、より素早くソリューションを構築することができました。
また、研究開発チームのリーダーに最後のプレゼンをする時点では、リーダーのほとんどが私たちの発見と提案を詳しく知っていました。彼らの継続的な関与から私たちが得られた最大の成果は、すでに信頼を獲得していたことです。このように早い段階で信任を得ることは、リサーチに参加していなかった人が懸念を表した際、非常に貴重でした。一緒に取り組んだリーダーが、そのような懸念に対処してくれたのです。
議論は「どのような提案か？ この話は本当か？」という段階から、「今知ったことに基づいて、どのようにこの提案を実装するべきか？」という段階に素早く移行しました。信頼感はすでに全員に共有されていたため、次のステップへの移行はさらにスムーズで素早かったです。
この事例は、リサーチを通してクライアントを巻き込むことの重要性を示しています。もし私たちが部外者として提案をすれば、クライアントに明らかな擁護者を作ることなく、私たちの仕事は価値を失ってしまうでしょう。
成果物ではなく、プロセスを売る
私たちはセールスチームに、特にチームの中で最初にクライアントに会う従業員には、成果物ではなくデザインプロセスを売り込ませています。私たちはデザインの工場ではありません。過去の作品はもちろんインスピレーションの元にはなりますが、私たちはすべてのプロジェクトを新しいユニークな挑戦と見なしています。
適切なソリューションを生み出すための柔軟性があるので、私たちはクライアントの課題に完璧に対応できる素晴らしいデザインを考案できる裁量を維持できます。もしSOWによって、あまりにも早く成果物の可能性が狭まると、クリエイティブの可能性が限定されてしまいます。この柔軟性こそが、私たちとほかのデザイン会社を差別化する要因であり、私たちがクライアントの投資に提供する真の価値です。
この価値を分かりやすく伝えるために、１つの事例を挙げましょう。そのプロジェクトの目的は、クライアントの技術を助けるプラットフォームのコンテンツ戦略とガバナンスモデルを作り上げることでした。
このプラットフォームで重要な部分が、ヘルプ記事とCMSでした。ユーザーは検索バーを使って関連する記事を見つけられました。そのためコンテンツ戦略は、検索結果に関連性があり、役に立つ記事であることを保証するために不可欠なものでした。
SOWには、成果物はコンテンツ戦略をまとめたWord文書であると記載されていました。そこで、私のチームは忠実に、コンテンツ戦略を導くのにクライアントが必要になるすべての要素を文書に含めました。
文書の中には、記事のタイトルの付け方やフォーマットのルール、タグ付けのガイドライン、コンテンツを新鮮に保つためのROT（冗長さ、古さ、些末さ）分析を実行するプロセスなどがありました。
しかし、コンテンツ戦略の文書を作り上げるうちに、私たちはこの文書がほとんど使いものにならないことがわかりました。網羅できてはいるものの、読み解くのが難しく、したがって実際に適用するのも難しかったのです。
クライアントが本当に必要としていたのは、たとえばフォーマットのルールを示したスクリーンショットや、編集可能なタグのライブラリ、ROTを特定するルールを解説したインフォグラフィックのような、視覚的で動的なものでした。もし私たちがSOWに定められた成果物にこだわらず、条件の変更を求めていたら、クライアントは私たちの労力からより多くの価値を得ていたでしょう。
この事例から得られた教訓として、より多くの不確定要素が具体化するまでは、成果物のフォーマットを変更しても許容することが重要なのです。
柔軟性を組み込んでおき、期待値を調整する
最後に、私たちはプロジェクトマネージャーとセールスチームに、SOWの時点で柔軟性を保証してもらっています。
クリエイティブプロセスについて多くの人が誤解しているのが、制限がないほうが優れていると考えられている点です。そうではなく、制限があるからこそ創造性が発揮されます。何も制限がなければ、どの道が行き止まりなのか判明するまで空回ってしまうかもしれません。反対に、ある程度の制限が与えられていると同時に、さまざまな方法で答えを出す自由も存在するとき、創造性は十分に発揮されるのです。
柔軟性を制限するメリットも踏まえると、SOWの特定の項目を固定して、チームに切り口を与える必要があります。しかし同時に、方針を見直し方向転換するためのチェックポイントも設けるべきです。
どのソリューションがもっとも合理的なのかを理解してからSOWを再定義する可能性を予期して、チームがコストをかけずに指示を変更することもあるでしょう。SOWが柔軟に作られていれば、デザイナーもクライアントも制約と期待値をより明確に把握することができます。
この主張を実証するために、私たちがデザインから開発まで掛かるプロジェクトを２段階に分ける方法を紹介します。
デザインから開発まで掛かるプロジェクトでは、デザインだけで終わるプロジェクトや、開発から始まるプロジェクトよりも高い柔軟性が必要です。開発にかかる労力がどれだけ大きく複雑になるかが判明するまで、要求される労力を知ることはできません。労力は、リサーチとデザインによって決まるからです。
当たり前のように思えますが、多くのスプリントが事前に決められていたせいで、チームがあまりにも短い制限時間の中にタスクを詰め込んで失敗したプロジェクトを、私はたくさん見てきました。このような調整は、結果的に双方を失望させます。チームはタスクが溢れてフラストレーションを抱えることでしょうし、クライアントは約束が果たされないことに失望し、腹を立てるでしょう。
このような結果を避けるために、私のチームはデザインから開発までのプロジェクトを２つのフェーズに分けています。フェーズ１は価格が固定された発見のフェーズです。私たちはコードを書き始める前に機能や技術、ユーザー、システム、時間、アクセスなどの要件を調査します。続くフェーズ２では、私たちはクライアントと一緒に開発の範囲やコスト、期間などを見積もります。
フェーズ１の目的は、フェーズ２において正確な見積もりが出せるよう、システムの複雑さを十分に知ることです。たとえば、どれだけのユーザーの種類に対応する必要があるのか、どのリサーチ方法が適切なのか、リサーチにはどれだけの時間がかかるのか、どれだけコードをカスタマイズする必要があるのかを調査します。この調査は、外部から中身を明らかにするアプローチのように考えてください。内部の詳細を知ることなく、システムの制約を定義することができます。
このようにフェーズを分けることで、柔軟性と具体性の最適なバランスを保つことができます。
わからないことがあることを受け容れる
結論として、曖昧なことを受け容れることがイノベーションの鍵になります。しかし、そのような状態に至るのは言うほど簡単ではありません。革新的な思考ができる余地をクライアントに与えてもらうには、私たちは彼らをプロセスの中に巻き込み、プロダクトよりもプロセスを強調し、柔軟なSOWを構築する必要があります。
プロジェクトの初期には、必ず曖昧な要素に直面するものです。タスクを進めることで最終的に、わからないことを明らかにするには何が必要なのか知ることができるでしょう。
安心したいと思っているクライアントに対して私ができる最善の提案は、質問してもらうことです。デザイン戦略のプロセスをより深く理解するにつれて、プロセスを信頼しやすくなるでしょう。
