SVO構文で考えるOOUI

業界内でも弊社内でも一大旋風を巻き起こしている「OOUI」。

ソフトウェアのUIモデリング手法として自身も経験してみて、DB設計との親和性やプロジェクト全体のスピードアップなどメリットがあり、欠かせないものという理解になりました。

しかし、プロジェクトの性質によっては、もう一段のレイヤーが必要かな？と思うことがあったので、整理のためにnoteを記述してみます。

具体的には、主にtoBやtoEの業務ソフトウェアのUI開発においては、オブジェクトの抽出とスコープ定義に関して、慎重にアプローチする必要があると思いました。
※なおOOUIについて知識が浅い状態で書いていることをご了承ください。

SVO構文で考える

文章は基本として、Subject、Verb、Objectで成り立ちます。
I　　　see　　a picture.
(S)　　(V)　　　(O)

ソフトウェアデザインへのアプローチとして、Objectを追いかけてSubjectを置き去りにすると、適切にデザインできない場合があるように思います。

大丈夫なケース
コンシューマ向けソフトウェアは、SとVの関係が密であり、Sの行動を暗黙的に理解できるので、Oから類推して（Sを透過して）モデリングしてもいいのしれません。
例えば、マップアプリ。
地図というオブジェクト上の地点というオブジェクトに対し、行くという動詞（タスク）を実行するソフトウェアにおいては、UIをモデリングするデザイナーは、単一のユーザーを想起するだけでよいです。
Sがなくても、ユーザーのOに対するVを考えればそれで正解に近づくといえます。

困るケース
ビジネス向けソフトウェア、おもに業務ソフトウェアにおいては、同じオブジェクト（O）でも、扱う主体者（S）によって実行（V）する内容が異なる場合があります。
Sを明確に定義しないと、対象としてのOだけを見つめていてはデザインできない可能性があると考えます。
例えば
ビジネス向けの顧客（Ｏ）管理（V）ソフトウェア
主語（S）は誰？営業マン？本部管理者？コールセンターオペレータ？
タスク(V)は登録？追加？閲覧？承認？
SがによりVが変わる、もしくはSに対して不要なVを提供ないようにすることを考慮して、ビジネス向けのUI検討にはSubjectを意識する必要があると思います。
そのOは、ユーザーにとってどんな対象なのか？　
それは、「業務フロー」と呼ばれるもののなかに記述されているもののはずです。