『オブジェクト指向 UI デザイン』を読んだので書評を書いてみました。OOUI デザインのようなエンジニアとデザイナーの知識が交差する部分は、今後より一層重要性を帯びていく気がしますね。
オブジェクト指向 UI とは何か
タスク指向 UI は冗長で不便になる問題を抱えており、オブジェクト指向 UI はその問題を解決します。本の例を見ると最近の UI はオブジェクト指向 UI になっていると感じます。
オブジェクト指向 UI は、オブジェクトを手掛かりに操作設計された UI のことで、「オブジェクト指向 UI の原則」は下記のとおりです。
- オブジェクトを知覚でき直接的に働きかけられる
- オブジェクトは自身の性質と状態を体現する
- オブジェクト選択→アクション選択の操作順序
- すべてのオブジェクトが互いに協調しながら UI を構成する
ドメイン駆動設計 (DDD) を経験しているエンジニアは DDD の感覚でドメインモデルを構築してあげるとオブジェクト指向 UI 設計に入りやすくなる気がしました。
業務アプリケーションがタスク指向 UI になってしまうのは、業務分析によって「タスク」や「プロセス」が列挙されるからです。下記のような場合は、タスク指向の操作手順を回避できません。
- タスクによって処理対象となるオブジェクト集合が異なる場合。この場合、タスク選択はアプリケーションの選択と同じような位置付けとなる
- タスクによって、ユーザーに提示すべきオブジェクトの属性やアクションが大きく異なる場合。この場合、先にオブジェクトを提示しようとすると、情報量が多くなり過ぎて UI におさまりきらなくなる
- オブジェクトが（ユーザーのメンタルモデルにおいて）意識されていない、あるいはオブジェクトがひとつだけで選択の必要がなく、アクションの引数としての入力がタスクの大部分である場合。たとえば ATM
- ユーザーの創造的な作業を禁止し、一定の順序で限定的な操作をさせたい場合
このような場合を回避するためには、業務を変革する、つまり、デジタルトランスフォーメーションが求められます。
タスク指向を回避できない例が具体的にイメージし辛いです。1番目は、いきなり「社員」オブジェクトを選択せずに、「給与計算」業務か「勤怠管理」業務を選ぶみたいなことでしょうか。2番目は正しく捉えられている自信がないのですが、会計システムにおける決算処理のように、コンテキストを指定してから、作業した方が混乱が少ない場面はあると思います。3番目は、ATM という例が出ていますが、ユーザーが暗黙的にオブジェクトを想定しているため、オブジェクトを選択させるステップが増えることが嫌われることがあると思います。4番目はウィザードのようなもので、データインポートのために順番にデータ加工してもらいたいときなどは有益でしょう。
業務アプリケーション開発をしていると、上記の例のように、どうしてもタスク指向 UI を設計せざるを得ないことがあります。このあたりは取捨選択していかなければなりませんが、基本戦略としてオブジェクト指向 UI で設計した上で、例外的にタスク指向 UI になることを認めるという考え方になるかと思います。
オブジェクト指向 UI の設計プロセス
「ISO 9241-210 人間中心設計活動プロセス」における「利用状況の把握〜ユーザー要求の特定」と「デザイン試作〜デザイン評価」をつなぐのがオブジェクト指向 UI 設計プロセスです。
タスクから抽出したオブジェクトを手掛かりに設計していきます。ユーザーにオブジェクトを最初に見せるのがオブジェクト指向 UI です。業務分析で出てきたタスクをそのままにせず、オブジェクトを抽出するということは、オブジェクト指向設計としては当然のことなので、ドメイン駆動設計と親和性は高そうです。Naked Objects に似ていると感じたのですが、Naked Objects の Wikipedia にも OOUI の単語がありますね。
ソフトウェアデザインのレイヤーは下記の3つであると定義されています。
- モデル
- インタラクション
- プレゼンテーション
モデルは、ドメインモデルと認識しておけばよさそうです。インタラクションは、ちょっとイメージし辛いのですが、REST API におけるエンドポイント設計のように認識しています。プレゼンテーションは、レイアウトやスタイルですね。レイアウトが含まれているので、ワイヤフレーム以降のデザイン成果物はプレゼンテーションに含まれるはずです。
エンジニアはプレゼンテーション部分が弱く、デザイナーはモデル部分が弱いことが多い気がします。エンジニアとデザイナーが協業していたとしても、インタラクション部分できちんと認識を繋げられてないことも多そうなので、今後はインタラクション部分に意識を向けていきたいところです。
「オブジェクト指向 UI 設計の基本ステップ」は下記のように提示されており、各ステップについては、簡易なメールクライアントを例に説明されています。
- オブジェクトの抽出（モデルレイヤー）
- ビューとナビゲーションの検討（インタラクションレイヤー）
- レイアウトパターンの適用（プレゼンテーションレイヤー）
オブジェクト指向 UI 設計の実践
本章では、「学校名簿アプリケーション」を例に、「オブジェクト指向 UI 設計の基本ステップ」が実践的に説明されています。
モデルレイヤーに対応する「オブジェクトの抽出」は、ドメイン駆動設計を用いた設計に取り組まれているのであれば、ドメイン駆動設計の成果物で十分代替できると思います。十分なオブジェクト指向設計がなされていない状況では、本にあるように進めてもいいと思います。
インタラクションレイヤーに対応する「ビューとナビゲーションの検討」は、各オブジェクトについて「コレクション」と「シングル」のビューの有無を検討し、そのビュー間のナビゲーションを検討するステップです。ルートナビゲーションを検討していたりもするので、メニュー階層のようなものを作成して、ビューを木構造にしてもいいかもしれませんね。
プレゼンテーションレイヤーに対応する「レイアウトパターンの適用」は、レイアウトパターン集を参考にワイヤフレームを作成していくと考えればよさそうです。ワイヤフレームができたら、あとはビジュアルデザインの領域になってきます。
章の最後に、タスクはオブジェクトとアクションで実現されるというようなことが、そのパターンと一緒に書いてあります。ここで大切なのは、あるタスクがひとつのオブジェクトだけで達成されるとは限らないということです。あるタスクを達成するために、複数のオブジェクトを横断することもあるわけです。そう考えるとオブジェクト指向 UI デザインにも、ドメインサービスに相当するものを UI で表現すべきではなかろうかなどと考えてしまいますね。
ワークアウト：基礎編
本章は、基礎的な実践演習の章です。下記のようなアプリケーションの UI を設計します。
- メモアプリケーション
- 社員名簿アプリケーション
- イベント店舗管理アプリケーション
- 会議室予約アプリケーション
- 家族で遊べる場所を探すアプリケーション
- 商品管理アプリケーション
商品管理アプリケーションは業務アプリケーションのような要件がかなり多いので、実際の案件で UI 設計に困ったときは参考になる気がします。
ワークアウト：応用編
本章は、応用的な実践演習の章です。下記のようなアプリケーションの UI を設計します。
- スマートフォン用の営業支援アプリケーション
- イベント管理アプリケーション
- 保険契約の顧客管理アプリケーション
- アセット管理アプリケーション
- サイト管理アプリケーション
- 出張申請・精算アプリケーション
- 契約管理アプリケーション
- 通過換算アプリケーション
- 販売実績照会アプリケーション
タスク指向 UI をオブジェクト指向 UI に改善するという実践演習になっています。タスク指向 UI とオブジェクト指向 UI を具体的に比較できるので、タスク指向 UI とオブジェクト指向 UI の差を理解するのにも有益な章になっています。
オブジェクト指向 UI のフィロソフィー
オブジェクト指向そのものや GUI が発展してきた歴史、モードレスの重要性、オブジェクト指向 UI についての文献などが、その背景にある哲学を含めて説明されています。
純粋に読み物として面白い章です。モードレスの重要性については、この章を読むことで深く理解できると思います。GUI の歴史に Windows があまり出てこなかったのがちょっと残念です。
『オブジェクト指向 UI デザイン』は、これまでに取り上げられることのない内容だった気がしています。書名に「オブジェクト指向」と入っていることからも、エンジニアが興味を持って読むことになりそうで、デザインに踏み込むエンジニアが増えそうですね。その一方、書籍内で使用されている言葉が難しく、理解が追い付かないところもあり、もう少し平易な表現にしてもらえたらなと思います。ただ、その難しさを差し引いても得るものが多かったので、書名に惹かれた人はぜひ読んでみてください。