オブジェクトは単独では存在しない
前回は、プロダクトの中に存在する「オブジェクト」をどう見つけ、粒度と呼び名をどう揃えるかを解説しました。しかしオブジェクトは、そもそも単独では存在しません。ほかのオブジェクトとの関係の中で、初めて意味を持ちます。
本連載で扱うOOUX（Object-Oriented UX：オブジェクト指向UX）は、プロダクトが扱う対象（オブジェクト）を起点に、情報の関係性や構造を整理していく設計思想です。
では、この考え方を実際にどう取り入れていけばよいのでしょうか。PIVOTでは、OOUXの提唱者であるSophia V. Prater（ソフィア・V・プレイター）によるORCAというフレームワークを取り入れています。ORCA（オルカ）は、Object（オブジェクト）、Relationship（関係性）、CTA（Calls-to-Action：行動を促すアクション）、Attribute（属性）の頭文字を取ったもので、これらの観点からプロダクトの構造を具体化していきます。前回はこのうちのO、オブジェクトの見つけ方を扱いました。今回は、残るR・C・Aの3つの観点から、構造をさらに具体化していきます。
関係性を定義すると、良質な問いが生まれる
第2回の案件管理システムの例で紹介した「案件」「顧客」「契約」というオブジェクトは、互いにどう関係しているのでしょうか。
これを確認するために、オブジェクト同士の組み合わせをマトリックスに並べ、1つずつ関係を確認していきます。この確認を通して、これまで意識していなかった関係が見つかることがあります。逆に言えば、本来存在するはずの関係が設計上表現されてこなかったために、プロダクトのどこかが使いにくくなっていた、という可能性にも気づけます。
関係性を定義する作業には、大きく2つの問いがあります。1つ目は、そもそも2つのオブジェクトの間に直接的な関係があるかどうか。2つ目は、関係があるとして、それがどのような関係なのか、という問いです。
例えば「案件」と「顧客」には、どのような関係があるでしょうか。1つの案件には必ず1つの顧客がひも付きます。一方で、顧客として登録されていても、まだ案件が存在しないこともあれば、複数の案件を持つこともあります。つまり、案件から見れば顧客は「1」、顧客から見れば案件は「0〜複数」という関係になります。
では「案件」と「契約」はどうでしょうか。案件には必ず契約があるのか、それとも契約前の案件も存在するのか。こうして関係を1つずつ確認していくことで、それまであいまいだった業務上のルールが問いとして浮かび上がります。
関係があるかどうか、そしてその関係がどのような形か。この2つの問いに、チームは即答できるでしょうか。もしすぐに答えられないとしたら、それは設計の詰めが甘いというより、そもそも業務の実態を十分に理解できていないサインかもしれません。答えられない問いによって、リサーチや業務理解がまだ十分ではない部分が可視化されます。
関係性を定義する作業は、単に図を完成させるための手続きではありません。チームがそれまで気づかなかった問いに向き合い、業務の実態とプロダクトの構造を突き合わせる機会でもあります。
