OOUXについての良いページがあったので社内メンバー勉強用に噛み砕いてみた
2年前に公開された内容ではあるが、全然古臭さがない。むしろ古臭い基幹の業務システムを扱ってる身には新しい発見しかなかった。
非常にためになる内容ではあるがなにせ非常に長い（数えさせたら23,855文字！！）ので、会社のメンバーに理解してもらう前にまず自分で噛み砕いてみた。
ちなみに量的には1/10になったが、内容的には1/100とかになってるかもしれない。
時間があれば直接元ページを読んだほうが良いし、少しでも興味が持てたら元ページも読んだほうが良いと思う。
理解した内容
GUIはオブジェクトそのものなので、画面要素は名詞で表す
画面に表示させるコンテンツはは名詞で統一し、表示されてるコンテンツ（名詞）に対してアクション（動詞）を配置する。
特にナビゲーションは動詞にしたくなるが、次のコンテンツを表示させるコンテンツなので表示内容は名詞にする。
ギリギリまでモードを固定せず、最後まで選択肢に自由度をもたせておく
アクションを選択するということはモードが固定されるということ。モードが早い段階で固定されてしまうと「アクション → 選択」という処理が何度も続く「対象物が見えないまま暗いトンネルを進まなければならないタスク」になりやすくストレスになる。
オブジェクトベースにすることで業務システムの画面数は1/5以上も削減できる
「アクション → 選択」を繰り返す流れでは、選択用として似たような画面がいくつも必要になる場合が多い。「選択 → アクション」の場合であればアクションを複数用意するだけで済む。
選択画面を共用させることも可能だが、その場合はどこから呼ばれてるかを意識してないと改修の際にバグの温床になることは容易に想像できる。
要求事項をベースにしてシステムを作ってしまうとタスクベースになる
要求で扱うもの（オブジェクト）をよく理解し、他オブジェクトとの関連性やシステムで利用するスコープを元にして画面をつくってみる。
ユーザーが解決したい課題や欲しい機能ではなく、タスクに必要な情報オブジェクトを定義する必要がある。
タスクベースで作ってしまうといずれ破綻してしまったり一貫性がなくなる
「選択 → アクション」であれば処理内容に変更があってもアクションを調整するだけで済むが、単なる線形的な紙芝居のようなタスクベースで作ってしまうと入り口を増やしたり処理の途中で分岐を入れる必要が出たりで破綻してしまう。ひどい場合には一連の流れの中で他アクションを実行したりもするので処理内容にしてもデータにしても一貫性が無くなる可能性がある。
UIは「コレクションビュー or シングルビュー」の2つで構成できる
タスクベースではアクション選択後の画面をなるべく少なくしたい心理が働くので、画面が必要以上に複雑になりやすい。定形処理であればウィザード化してしまうのも手だが、ウィザード画面では処理が複雑で不安定なものになることが多い。データベースのトランザクションやロールバック等は考慮する？変数はどうする？次の画面に持ち回す？
コレクションビューとシングルビューの組み合わせであればアクションに対する必要最低限の情報のみに抑えることもできるので、画面の作りもシンプルにできる。
表示させるデバイスによってコレクションとシングルの組み合わせや遷移方法は変えるがモデルは変えない
スマホサイズのデバイスであれば、コレクションとシングルを個別に遷移させる。また、タブレットやPCであれば2カラムや3カラム表示もしくはメーラーのように3ペインの表示にすると各エリアの表示内容を揃えることができる。
基本的な構造をモデル化できていれば、組み合わせるだけでいろいろな場面で応用できる。
引用しておきたい文章
簡単に言えば、ナビゲーションのラベルに動詞を使うと、わかりにくくなるのです。特に情報コンテンツの検索と閲覧を行うシステムにおいては、ナビゲーションのラベルはコンテンツの性質に応じた名詞であるべきです。
タスクの入り口として動詞を使うと、例えば「登録」みたいに汎用的なアクションでは「製品を登録」「伝票を登録」「取引先を登録」な感じにアクション名が長くなってしまい画面が煩雑になる。オブジェクトに対してであればアクション名が重複するということはないので表示もシンプルになる。
ナビゲーションはオブジェクトの塊を表すので名詞にし、アクションに動詞にする。
iPhone の学習効率が高いのはそのUIがオブジェクトベースで設計されているからです。つまりモードレスであることが大きなファクターになっています。優れた GUI アプリケーションに対してユーザーが「マニュアルを読まなくても使える」と感じるのだとすれば、それは手順が覚えやすいからではなく、そもそも決まった手順が無いからなのです。
これは目からウロコだった。わかりやすくするにはウィザード方式が有効かと思ってた。
確かにウィザードを使えばマニュアルがなくても使えて一見わかりやすく感じるけど、一つでもウィザード方式を採用すると他の処理でもウィザードにしたくなって結果的に複数存在することになり、該当するウィザードを探す処理が発生するので余計に混乱する。
ウィザードは基本のオブジェクトを作成する場合だけに限るべきなのかも。
事業体において、オブジェクト（主要な概念物）は変化しにくく、タスク（業務）は変化しやすいのです。
事業における管理対象はプロパティが増えたり減ったりすることは多少あっても、管理対象オブジェクトの構造自体が変わることはまずない。変わるとしたらそのオブジェクトが追加もしくは削除されるときだけ。
だが、その管理対象の扱い方が変わればタスクは変わってくるので、タスクが増えたり減ったりすることはもちろん内容自体が変わることは多々ある。
アプリケーションのトップメニューから業務名という形骸を取り去り、ユーザーを仕事の本質に向き合えるようにすることが、オブジェクトベースUIモデリングの目的となります。業務システムのデザインはすなわち仕事のデザインなのです。このことを、アプリケーション設計に関わるすべてのステークホルダーが意識するべきだと考えます。
最後のまとめも非常に良い。
最近「再構築」という単語は使わずに「リデザイン」という単語を意識するようにしてるのだが（これもどこからかのパクリ）、まさにこういうことなのだと思う。
だとすると、オブジェクトのモデリングというのが非常に重要で、そのでき次第でシステムの出来が決まり、システム次第で業務が円滑にすすむかどうかが決まるわけだ。
・システムは互いに協調するオブジェクトおよびそれらのビューによって構成される
・ユーザーが見るのはタスクではなくオブジェクト
・タスクに対する入出力よりもオブジェクトに対する入出力を重視する
・オブジェクトはそれ自身が役割を体現する
・ユーザーは自分なりの方法でタスクを遂行でき、またそれを改善できる
・限定的なオブジェクトを複数のタスクで使い回す
・オブジェクトの状態はリアルタイムに視覚的にフィードバックされる
・ひとつのオブジェクトは複数のビューを持てる
・直接操作かつ可逆的
・全てのオブジェクトが常にアクティブ
・システムの内部的な仕組みを隠匿する
・名詞 → 動詞 のシンタックス
上記はUIをモードレスにする具体的な手法とのこと。
業務システムは多数のテーブルで構成されているので「テーブル ≒ モデル」「モデル ≒ オブジェクト」「オブジェクト ≒ ビュー」と考え、「ビューを通してオブジェクトであるテーブルを更新する」と理解すると非常にしっくりと来る。
この図はシンプルだがわかりやすい。ER図の情報もありながらビューの情報もあり、おまけに画面遷移の情報もついている。
業務システムなんてテーブルごとに画面があるようなもんだから、こういう感じで図を作っておくといろいろなケースに対応できそうである。
まとめ
素人がまとめるのは憚れるが、非常にためになる情報だった。
UIやUXとは一見縁がなさそうな業務システムではあるが、この内容を意識することは開発者と利用者の双方にメリットがあると思う。
利用者目線に立つとタスクベースのほうが選択肢が少ない（とはいえ少ないのは入り口だけ）ように見えるが、実際はシステムの全体像が見えない利用者と利用者目線に立ったつもりでいる開発者だけにそう見えていたのだと思う。もしくは利用者の慣れとか。
早速明日から業務に使いだして、部内のメンバーにも布教して行こうと思う。
・・・
この方は、他にも良い記事がある。何個か前のノートでも書いたのだが、下記のページも非常にためになる。まだ読んでない人がいたら合わせて読んでほしい。
・・・
Twitterにも時々顔だしてます
趣味のプログラミングにもいろいろとお金がかかって大変なんですわ。特に小遣い制の妻帯者は。