「画面を作る前に、まず構造を定義せよ」
この問題に体系的に取り組んできた人物がいます。「画面を作る前に、まず構造を定義せよ」。そう説き続けてきたのが、Adobe、AT&T、Facebook、Autodesk、Mastercardなど、世界的な規模の複雑なプロダクト開発に携わってきたUXストラテジスト、Sophia V. Prater（ソフィア・V・プレイター）です。
彼女は「OOUX」という設計アプローチの提唱者でもあり、プロダクトが扱う「対象（オブジェクト）」を機能より先に定義することの重要性を、長年にわたって説いてきました。
OOUXにおけるオブジェクトとは、ユーザーとビジネスの関心の対象であり、システム上で明確に表現・管理される単位です。何をひとつのオブジェクトとして定義するか、その粒度をどう切るかは、プロダクトの分かりやすさを大きく左右します。先の「被害報告」の例で言えば、一つのオブジェクトとして扱われたものを実態に沿って複数の異なるオブジェクトに分けて定義することが、まさにこの粒度の定義です。
もう一つ、プロダクトの意思決定を担う人が気にすべきなのは、定義が具体的になるほどシステムは扱いやすく、制御しやすくなる一方で、硬直化し、扱う属性が増えてコストも上がるということです。
先の「被害報告」でいえば、道路上点検と施設点検を別々のオブジェクトに分けるほど、それぞれの振る舞いは明快になりますが、その分だけ定義し管理すべき属性も増えていきます。どこまで具体的に定義するか、その見極めが重要になります。
AIに指示を出す前に、まず何を扱うかを定義しておこう
よくある進め方の一つが、まず機能の洗い出しから入ることですが、それが最初の落とし穴です。なぜなら機能を洗い出す前に、そもそも扱う「対象」が定義されていないからです。重要なのは何ができるかの前に、どのような「対象」が存在するかの定義です。「被害報告」がまさにそうであったように、一つの言葉がチーム内で異なる対象を指している限り、どれほど精緻な機能一覧や仕様書を書いても、認識のズレは解消されません。
この構造のあいまいさは、AIが介在することでさらに深刻な問題になります。AIはざっくりした要件から、それらしい画面を瞬時に生成してくれ、早い段階で気軽にイメージが確認できます。しかし怖いのは、まさにその「それらしい」というところです。自分がその答えを導き出していないため、出てきた結果を正しく評価できません。しかもそれらしいアウトプットが返ってくるため、本来の課題にはさらに気づきにくくなります。
その結果、同じ「対象」が違う名前で呼ばれたり、違う「対象」が同じ名前で扱われたりしたまま、既存のあいまいな認識をもとにシステムが作られていきます。AIの速さは、あいまいさの伝播速度でもあります。画面や機能を考える前に、そしてAIに何を任せるかを考える前に、人間がまず「対象」を定義するという順番が重要になります。この思想がOOUXの出発点です。
次回はOOUXメソッドを用いて、リサーチから得た情報をもとにオブジェクトを抽出・整理する方法と、チームで定義を揃えるための具体的な手順を解説します。
