はじめに
この連載の第1回では異なる職能間でデザインについての認識を合わせるためのデザインコンセプト、第2回はユーザーと向き合ってプロダクト開発するためのUXリサーチについて解説してきました。今回は、デザインコンセプトをプロダクトに実装するための要件定義について解説したいと思います。
要件定義とデザインの関係について
プロダクト開発における要件とは、そのプロダクトに実装する機能や満たすべき性能のことを指しています。この要件を、ステークホルダーが客観的に分かる形で定義する(=要件定義)ことで、プロダクトを開発するメンバーが、どういうものを作るかについて共通イメージを持ち、開発計画を立てることができます。
職能や役割によって、デザインの捉え方は異なります。表現として捉える人がいると思えば、プロダクトやシステムのインターフェースとして捉える人もいます。また、マーケティングのツールをつくるための手段として捉える人もいるでしょう。このような認識の違いが発生することはデザインに限った話ではないのですが、特にデザインはその定義が多岐にわたり、いろんな文脈で使われることが多いため、人によって概念や定義が異なります。そのため、異なる職能・役割間で開発するプロダクトについてコミュニケーションを取る場合、要件定義を行うことで作りたいものについての共通認識を持つことが大事になってきます(※1)。
(※1) インドの古典に「群盲象を評す」という寓話があります。物事の一面を見てすべてを理解したと思うことの例えとして引用されることがあります。この話の解釈には諸説ありますが、デザインを取り巻く状況もこの寓話に通ずるものがあります。
プロダクト開発の現場では、開発に着手する前にビジネスやシステムに関する要件をまとめますが、ビジネスやシステムに関する要件だけまとめても、デザインコンセプトを実現できるプロダクトを開発することはできません。ビジネスやシステムの観点だけから抽出した要件は、デザインのアウトプットを実現するために必要な機能要件とイコールとは限らないからです。そのため、デザインコンセプトを実現するための要件を定義して、プロダクトの開発要件に盛り込む必要があるのです。
そうでないと、プロダクトをデザインしてそのデザインを実装しようというタイミングで、そのデザインを実現する機能が開発されておらず、デザインの仕様を変更しないといけなくなってしまいます。後から要件を満たす機能やコンテンツを追加開発できる場合はいいのですが、できない場合は、デザインを変更しないといけなくなってしまいます。そのため、デザインコンセプトをプロダクトに実装したい場合は、デザインを実現するための要件(以後、これをデザイン要件と呼びます)を定義しておき、この要件を満たすために必要な機能やコンテンツを開発することになります。
プロダクトにおいて、デザイン要件を定義することは、以下2つの点において重要です。
- コミュニケーションミスを防ぐ:デザインしたものをどう仕様に落とし込んでいけばいいのか、デザインした後にデザイン指示書を作らないと、設計側に伝わらないことがあります。あるデザインを実現するためには、どういう機能を開発しないといけないのか、どういうコンテンツが必要かを開発者に理解してもらうために、デザイン要件をまとめることが有効です。
- 実装漏れを防ぐ:デザイン要件の定義があいまいなままデザインだけ進んでしまうと、プロダクトの開発が進んでいくうちにデザインコンセプトでデザイナーが意図していたものと違うものになってしまったり、デザインのモックアップとしては動いているものの、実現・実装できないものになってしまったりするため、結局仕様変更をせざるを得なくなります。デザイン要件をまとめておくことで、こうしたミスや手戻りを防ぐことができます。
ユーザーにとって価値あるプロダクトを開発するためにUXデザインの手法を取り入れ、ジャーニーマップやシナリオ、モックアップを作成することは多いと思いますが、これらUXデザインのアウトプットで可視化されたユーザー体験を実現しようとすると、機能やコンテンツを新たに開発しないといけなくなることが多くなります(例:ユーザーが情報を調べようとすると検索という「機能」が必要。ユーザーにある情報を伝えるために○○という「コンテンツ」が必要、など)。
デザインについて詳しくないエンジニアが要件をまとめる場合、ユーザー体験やユーザーインターフェース、ユーザビリティなどデザインに関するポイントを要件としてまとめることが難しい、あるいはポイントそのものが抜けてしまうことがあります。このようなことが起こると、デザインコンセプトをプロダクトに実装することができなくなってしまいます。よって、デザインコンセプトを開発・実装するためにデザイナーと一緒にデザインコンセプトのポイントを理解してデザイン要件を定義することが重要になってくるのです。
要件定義の中に自然とデザインに関する要件が入るようになれば、わざわざデザイン要件と呼ばなくても良いのかもしれません。しかし実際は、システムやビジネスの要件が優先され、デザインに関する要件が十分に議論・整理されないまま開発が進むことも多いため、デザインコンセプトを実装するために意識的にデザイン要件を定義していく必要があるのです。
次節では、このデザイン要件を定義する方法を紹介していきます。
補足
本稿では要件定義とデザインの関係について解説しますが、スクラム開発におけるプロダクトバックログに入れるストーリーとデザインの関係についても同じことが言えると思います。要件定義というドキュメントとプロダクトバックログという入れ物はイコールではないので当てはまらない部分もあるかもしれませんが、デザイン要件を、デザインに関するストーリーと置き換えて読み進めていただいても結構です。