作るものが変わっても、構造は変わらない──人とAIの共通言語としてのOOUX

構造図は、作って終わりではない

　前回までで、プロダクトの中にあるオブジェクトを見つけ、関係性・アクション・属性という観点から構造を具体化する流れを紹介してきました。ただ、オブジェクトマップやマトリックスは、完成させること自体が目的ではありません。

　最終回となる今回は、描いた構造を実際のプロダクト開発でどう使っていくのかを紹介します。

ORCA（オルカ）は手順書ではなく、ツールキット

　第3回までに紹介したObjects（オブジェクト）、Relationships（関係性）、CTAs（行動を促すアクション）、Attributes（属性）の4つのORCAの観点は、実は4つのラウンドを通して繰り返し深めていくもので、全体では16のステップがあります。

• ラウンド1（Discovery）：業務やユーザーについて問いを立て、構造の材料を集める
• ラウンド2（Requirements）：ルールや条件を詳細に詰める
• ラウンド3（Prioritization）：優先度を決める
• ラウンド4（Representation）：構造を画面やコンポーネントに落とし込む

　これまで扱ってきたのは、おもにラウンド1と、ラウンド2の一部にあたります。

　16ステップと聞くと重く感じるかもしれませんが、すべてを順番どおりに実施する必要はありません。PIVOTでも、案件の課題やフェーズに合わせて、必要なステップを選んで使っています。

　例えば、社内で開発中の新規プロダクトでは、あるアイデアをシステムにする価値があるのかを検証することがゴールだったため、そもそも何を扱うのかから決める必要がありました。そこで、最も時間をかけたのは、ラウンド1（Discovery）でした。

　このプロダクトでは、まず形にして検証することを優先し、ラウンド2と3は後から詳細化する進め方を選びました。その結果、動くものを早い段階で確認できた一方、実際に触ることで、さらに詰めるべき仕様も見えてきました。

　このように、目的や状況に合わせて必要なステップを選んで使うのが、ORCAというツールキットの使い方です。利用者のロール（役割）が多く、承認フローなどが複雑なプロダクトであれば、誰が何をできるのかというアクションの整理に重点を置く。1つの作業を進めるのに複数の画面を行き来しなければならず、作業がうまく流れていないプロダクトであれば、オブジェクト同士の関係性を見直す。そのプロジェクトに応じて使い分けることが有効です。

MVPは、構造の上で判断する

　プロダクトや対象とするスコープにもよりますが、ここまで作成したオブジェクトマップには、10、20、場合によっては50以上のオブジェクトが並ぶこともあります。これをすべて一度に実装しようとすれば、相当な時間とコストがかかります。そのため、ここからはプロダクトのコアとなる部分を見極め、それ以外は思っている以上に大胆に削ったり、優先度をつけたりしながら、スケジュールと予算に合う形にしていきます。

　このとき、機能の一覧だけで判断すると、外したものがどこに影響するのかが見えません。だからこそ、関係性まで描いたオブジェクトマップの上で判断します。

　見極めの観点は2つです。一つは、そのプロダクトならではの体験や利益につながるオブジェクトはどれか。もう一つは、最小限でテストできる単位になっているかです。ユーザーに使ってもらい、価値を確かめられるまとまりになっているかどうかが、MVPの成否を分けます。

　ただし、削ることは捨てることではありません。今回作るものだけを残し、それ以外は将来の戦略に向けた地図として手元に残しておきましょう。

　ドメイン内のオブジェクトとその関係性がすでに整理されていることで、将来プロダクトを更新・拡張するときも、構造を一から作り直したり、影響範囲を一から洗い直したりする必要はありません。オブジェクトマップは、オブジェクトや属性を付け加えながら育てていける資産になるのです。