4章Lean UXキャンバス

4.1 「思い込み」は新たな要件

物事が予測しやすい業界では、「会社が何を作るか」「プロダクトを作るのに何が必要か」「完成するプロダクトはどのようなものになるか」「顧客はプロダクトをどう使うか」などについての見込みが立てやすいため、厳密な要件を事前に定義しても支障なく仕事ができます。こうした製造業式の考え方が主流の業界では、前もってデザインを確定しておくのが一般的であり、プロダクトを作る過程で生じる変更はすべて、「マーケットの変化に対する機敏な対応」ではなく、計画からの高コストな逸脱だと見なされます。ソフトウェア業界でも、誕生間もない時期にこのような「要件ありき」のモデルが採用されて以来、数十年にわたって支配的であり続け、今日でも多くのチームの仕事の進め方に影響を及ぼしています。

要件は、「何を構築しなければならないかが正確にわかっている」ことを前提にしています。理想的なのは、エンジニアリング分野に見られるような厳密さがあることです。しかし、ソフトウェアの世界には通常、そのような厳密さは存在しません。それにもかかわらず、要件は定義をした人の信頼性や組織の肩書きがあるために、額面通りに受け取られがちです。しかも、その根拠のなさは「以前はうまくいったから」という言葉で補強されています。要件の完全性に疑問を持つ個人やチームはトラブルメーカーと見なされ、プロジェクトの納期が遅れたり当初のスコープを超える作業が発生したりしたときには責任を押し付けられます。また、筆者の友人であるジェフ・パットソンがよく言うように、チームに指示を与える手段として要件を重視している組織では、要件は「黙って従え」という意味で使われることもあります。

しかし、今日のソフトウェアベースのビジネスは、一貫性や予測可能性、安定性、確実性が低い現実の中にいます。事前に自信を持って、「このコードとコピー、デザインの組み合わせが望ましいビジネス成果を達成します。それを期限までに確実に提供できます」と断言するのは、単に高リスクであるだけでなく、嘘に等しくなります。ソフトウェア開発は複雑で、予測不可能です。変化はとてつもなく速く起こります。ソフトウェア企業は前例のないスピードでプロダクトを出荷し続け、消費者行動も同じように速く変化します。プロダクト開発チームがこれから開発する機能やデザインアプローチ、ユーザーエクスペリエンスを決定したときには、ユーザーは他のオンラインサービスでの経験をもとに、新たなメンタルモデルへと進化し始めているのです。 ...

Get Lean UX 第3版 ―アジャイルなチームによるプロダクト開発 now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.