【読書録】オブジェクト指向UIデザイン──使いやすいソフトウェアの原理
オブジェクト指向UI（OOUI）は、タスク（すること）ではなくオブジェクト（モノ、名詞）を起点にしたUIである。
使いやすいツールやサービスはOOUIでデザインされていることが多く、その優れた手法は是非とも深く学んでおきたい。
以前、OOUIを学んで興味を持ったのでより深く知識を得るべく本書を購入した。重複する部分もあるが、さらに深く学べたのでまとめておく。
本書の構成は以下のとおり。
1 オブジェクト指向UIとは何か
2 オブジェクト指向UIの設計プロセス
3 オブジェクト指向UI設計の実践
4 ワークアウト：基礎編
5 ワークアウト：応用編
6 オブジェクト指向UIのフィロソフィー
オブジェクト指向UIとは
オブジェクトとは、アプリケーションが扱う情報オブジェクトのことであり、ユーザーが操作をするときの対象物のことである。
オブジェクト指向とは、ソフトウェアを作るときにこのオブジェクト（ユーザーの関心の対象物）に対応させるという考えのこと。
これはコンピュータ黎明期のCUI（いわゆる”文字だけ”のUI）では実現できなかったことであり、GUIになって（というよりGUIにするために）初めて実現した。
オブジェクト指向、そしてオブジェクト指向UI（OOUI）はGUIのコンセプトとなっているのにもかかわらずあまり知られていない状況になっている。
オブジェクト指向UIの原則
OOUIには以下の原則がある。
・オブジェクトを知覚でき直接的に働きかけられる
・オブジェクトは自身の性質と状態を体現する
・オブジェクト選択→アクション選択の操作順序
・すべてのオブジェクトが互いに協調しながらUIを構成する
・オブジェクトを知覚でき直接的に働きかけられる
OOUIでは、コンピューターを使ってユーザーが行う操作の対象がそこに知覚できる様態で示される。
操作の対象であるアプリ、入力フォーム、機能処理などが、アイコン、メニュー、テキスト、ボタンなどで画面上に表示され、ユーザーは指やマウスでタップ・クリック・ドラッグなどで対象を直接操作しながら表示内容を変化を確認し、作業を進められる。
これと対照的なのがCUI。画面上には操作対象が存在せず、ユーザーが頭の中で思い浮かべる必要がある。
・オブジェクトは自身の性質と状態を体現する
オブジェクトは、自身の性質や状態がどのようなものなのかを形状や色などによって常に示し続ける。
・オブジェクト選択→アクション選択の操作順序
OOUIの特徴は操作が「オブジェクト選択→アクション選択」の順番になっていることである。これは「名詞→動詞」とも言い換えられる。
これは現実世界と同じで「まずリンゴを見つけてから、拾い上げる」という流れと同じである。
先ほどのCUIのコマンドラインではこれとは逆に「動詞→名詞」の順序になっている。
・すべてのオブジェクトが互いに協調しながらUIを構成する
重要なものは大きく、そうでないものは小さく、情報は左から右へ、階層構造は上から下、右から左…といった、表現ルールに則ってUIが表示される。
タスク指向の問題点
オブジェクト指向とは逆に「動詞→名詞」の順序になっている操作モデルをタスク指向UIと呼ぶ。
例えば一般的な自販機ではまずお金を投入してから商品を選ぶが、「購入→商品」の順序になっているためこれはタスク指向と言える。
しかしこれでは一般的な買い物である「商品を選んでレジで購入」（「商品→購入」）とはならないので不自然である。
またお金を入れると「商品購入モード」に入ってしまうので、購入を辞めたい時は返却レバーを押す（モードを終了する）必要がある。また間違って商品を選択した場合も取り消しができない。
タスク指向UIでは、このモードが頻繁に出現するので操作の自由度を奪い、余計な手続きを生み出してしまう。
これをオブジェクト指向に変換してみる。
まず商品を選ぶ（従来の自販機のように先にお金を入れてもよい）。
もし一度選択したものを変更したいなら自由に変更できる。
購入の意思は選択後にお金を入れるだけで間違えるリスクも少ない。
「購入モード」が発動していないので、購入をやめたい時はその場から立ち去るだけで良い。
このようにオブジェクト指向UIではモードをなくせるモーダレスになるので操作性の向上につながる。
オブジェクト指向UI
・名詞→動詞・まずオブジェクト選び、次にそのオブジェクトに対するアクションを選ぶ
・ナビゲーションはオブジェクト（名詞形）を手掛かりにする
・あらゆる情報システム、特に作業者による探索や創意工夫が期待されるものについて有効
タスク指向UI
・動詞→名詞
・まずタスクを選び、次に引数としてオブジェクトやパラメーターを指定する
・ナビゲーションはタスク（動詞形）を手掛かりにする・オブジェクトを選択する必要がない場合や、定型の入力手続きだけを提供する場合にのみ有効
OOUIでは、最初にユーザーに見せるのはタスクではなくオブジェクト。はじめから興味の対象であるオブジェクトが見えており、さらにオブジェクトに関するタスクがまとめられているので操作もしやすく表示もシンプルになる。
しかし、依然として主に業務アプリにおいてモードを発生させてしまうタスク指向UIが多い。それは以下のような場合や理由が考えられるという。
・タスクによって処理対象となるオブジェクト集合が異なる場合。この場合、タスク選択はアプリケーションの選択と同じような位置付けとなる
・タスクによって、ユーザーに提示すべきオブジェクトの属性やアクションが大きく異なる場合。この場合、先にオブジェクトを提示しようとすると、情報量が多くなり過ぎてUIにおさまりきらなくなる
・オブジェクトが（ユーザーのメンタルモデルにおいて）意識されていない、あるいはオブジェクトがひとつだけで選択の必要がなく、アクションの引数としての入力がタスクの大部分である場合。たとえばATM・ユーザーの創造的な作業を禁止し、一定の順序で限定的な操作をさせたい場合
業務というものは決められた手順に従って進めていく一連の”タスク”なので、タスク指向UIになってしまうのはもっともである。そして、たとえどんなに使いづらいUIでも”タスクの完了”という目的は達成される。
しかしそんな事情があっても、使いやすいオブジェクト指向のUIを設計するためには、タスクを手順化して画面フローにするのではなく、タスクに必要な情報オブジェクトを定義して、ユーザーがそれらに対して自由な順序で働きかけながら目的を達成できるようにしなければならない。
オブジェクト指向UIを設計する
ここからはOOUIの設計方法をステップごとにざっくりとまとめる。
ステップ１では、オブジェクトを抽出しそれを手がかりにしていく。
オブジェクトの抽出は、まずタスクを書き出しそれに含まれる名詞を探していくとよい。なお、名詞には”食べ物”のような「もの」的もあれば”食事”などのような「こと」的なものもある。
抜き出した名詞の関係性を洗い出したら、優先度や目的に応じてメインオブジェクトを特定する。
メインオブジェクトを特定したら、それに付随するオブジェクトをサブオブジェクトとしてまとめ、プロパティにする。最初に書き出したタスクに書かれていなくても必要になりそうなら適宜追加する。
次にタスクの中から動詞を手掛かりにして、アクションを見つけメインオブジェクトと紐づける。プロパティと同様に適宜追加する。
ステップ２では、オブジェクトの表象されるビューとナビゲーションを検討する。
ビューには大きく分けて複数のオブジェクトを集合として現すコレクションビュー、単数のオブジェクトを現すシングルビューがある。
メインオブジェクトに機械的にコレクションビューとシングルビューを与えて矢印で繋ぎ、コレクションビューとシングルビューの呼び出し関係を整理する（参照可能性を検討）。
次に、ルートナビゲーションに配置するものを以下のルールに則り決める。
・ルートナビゲーションには、メインオブジェクトの中から特に大事なものを並べる→全体を俯瞰して見たときに特に重要になる最上位のもの
・ユーザーがアプリケーションを使用する際に最初に思い浮かべるオブジェクトを選択する・アプリケーションを「機能」ではなく「もの」が並んでいるイメージで捉える
・動詞ではなくオブジェクト名を用いる→動詞をおくとオブジェクトが見えていないので困惑する&パターンを網羅すると項目数が多くなる
・オブジェクト名の語尾に管理、一覧、閲覧、確認、照会、参照、登録、情報、編集などを付与しない→冗長なので
・ユーザーがルートナビゲーションを選択すると、そのオブジェクトのコレクションビューが表示される（コレクションビューが省略されている場合は除く）→そうすることでまずオブジェクトを見られる
ステップ３では、ルートナビゲーションやビューを配置する。レイアウトは以下のようにさまざまあるので本書を確認してほしい。
コレクションビューでは、オブジェクトを配置すると量が多すぎて選択に困ることが想定される。
そんなときは、ある条件で絞り込みを行うフィルタリングをかけるとよい。
キーワード検索やAND条件などやり方は様々。
次にアクションをその性質や用途に合わせて表示形式を決める。
基本的にはアクションの対象となるオブジェクトの近くにボタンなどで配置。
多くの業務アプリケーションではCRUD操作が主要なアクションとなる。CRUDとはCreate（作成）、Read（閲覧）、Update（更新）、Delete（削除）のこと。
このうち、Readについてはコレクションビューとシングルビューで表現されるのでアクションとして配置する必要はない。
プログラミングでのオブジェクト指向
オブジェクト指向という言葉はプログラミングでも使われる。
オブジェクト指向プログラミングでは、データと動作がパッケージになっているので、処理に必要なデータと動作を別々に管理したり呼び出す必要がなくなる。このパッケージを、オブジェクトと呼ぶ。
オブジェクト指向のプログラムでは、たくさんの小さなオブジェクトの集まりによる相互作用によって、大きな構造体を動かしている。
オブジェクト指向プログラミングではオブジェクトの型をクラスと呼び、このクラスから実体的なオブジェクトであるインスタンスを生成する。
クラスにはプロパティとして”車種”や”色”などの属性がある。プロパティはインスタンスによって異なるが、”走る””曲がる”といった動作（アクション）は共通する。
これをGUIに当てはめると以下のようになる。
作られるファイルの”Title”や”Content”はインスタンスによってそれぞれ異なるが、”Close”や”Save”などは共通したアクションである。
また、プログラミングの型にも手続き型とオブジェクト指向型がある。
前者の１つであるPHPで「helloという文字列を大文字にする」という命令を記述すると、
strtoupper('hello')となり、動作（関数）→対象物の順になる。
後者の１つであるJavaScriptで同じ命令を記述すると
'hello'.toUpperCase() となり、目的語→動作（関数）の順になる。
つまり、まず対象としてのオブジェクトを定めて、次にそのオブジェクトが持っている動作を指示している。主体と客体の視点が転回し、客体（オブジェクト）が主体的に扱われる。
本書を読み込みオブジェクトの発見からレイアウトの配置まで、デザインの設計ステップを詳細に知ることができた。トレーニング用のワークアウトも多く掲載されているのでぜひ参考にしてほしい。
個人的に衝撃的だったのが、以前プログラミングを勉強していた際に”オブジェクト指向”という言葉が出てきて、当時は正直なところよく理解できなかったのが、本書を読んでほぼ完璧に理解できたことである。長年のモヤモヤが一気に解決されたので、もしかするとエンジニア志望者こそ本書を読んだ方がいいかもしれない。
今回は割愛したが、オブジェクト指向が成立した背景や歴史なども非常に興味深い知識を得ることができた。GUIとOOUIの密接な関係は知識としてに頭に入れておくとよいだろう。
この記事が気に入ったらサポートをしてみませんか？