オブジェクトが明確になると、アクションが整理しやすくなる
オブジェクトとその関係性が見えてくると、次に確認したいのは、それぞれのオブジェクトに対して誰が何を行えるのかです。
同じ「契約」というオブジェクトを扱っていても、営業担当者と管理者では行えることが異なります。これを画面ごとに考えていくと、「誰が何を行えるか」というルールが複数の画面や仕様書に散らばり、プロダクト全体として整合しているのかを確認しにくくなります。
そこでORCAのフレームワークでは、ロール（役割）とオブジェクトの組み合わせごとに、実行できるアクションをマトリックスの形で整理していきます。
例えば「契約」というオブジェクトに対して、営業担当者や管理者が何を行えるのかを整理すると、次のようになります。
こうしてロールとアクションの組み合わせを1つずつ確認していくことで、「誰がこのアクションを実行できるのか」「本来必要なアクションが定義されていないのではないか」といった問いが生まれます。
つまり、アクションをマトリックスの形で整理する目的は、単に操作を一覧化することではありません。各画面に散らばりがちな権限や操作のルールを、オブジェクトを軸にまとめて確認することで、見落としや矛盾を画面設計に入る前に見つけやすくすることにあります。
なお、実際のプロジェクトでは、単純な「誰が・何を」だけではなく、オブジェクトの状態やその人との関係によって行えることが変わるなど、さらに複雑な条件を扱う場合もあります。ここではまず、基本となる考え方までに留めます。
属性を書き出すと、概念が実態を持ちはじめる
もう一つ確認するのが、それぞれのオブジェクトがどのような情報、つまり属性（プロパティ）を持っているかです。
例えば「契約」というオブジェクトなら、契約番号、開始日、終了日、ステータスなどの情報を持つでしょう。こうした属性を1つずつ整理していくことで、単に「契約」という名前だけだった概念が、プロダクトの中でどのような実態を持つものなのか、より具体的になっていきます。
ここでも、属性の一覧そのものが目的ではありません。「契約のステータスには何があるのか」「開始日は必ず存在するのか」と確認していくことで、それまで資料や関係者の頭の中に分散していたオブジェクトの構造や詳細が明らかになり、「契約」という概念の輪郭がはっきりしてきます。
RFP（提案依頼書）や既存画面、Excel、業務資料など、情報の出どころはさまざまです。それらをオブジェクト単位で整理することで、「この情報は何についての情報なのか」が明確になり、チームが同じ対象について話しやすくなります。
こうして整理した属性、オブジェクト同士の関係をまとめていくと、プロダクトの基本構造をオブジェクトマップとして可視化できます。
なお、ORCAのフレームワークでは、オブジェクトの情報を「コアコンテンツ」と「メタデータ」に分けて整理します。契約番号やステータスなど、それぞれの情報がどちらに分類されるのかを図で示します。
