タスクベースUI、オブジェクトベースUIってなんだ？を役所への手続きで説明してみた

このnoteについて

タスクベースのUIではいけない、オブジェクトベースのUIにするべきだ！というようなお話をよく聞くようになりました。上野さんの銀の弾丸も発売になりましたね。

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 WEB+DB PRESS plus

タスクベースUIが動詞→名詞の構造で、オブジェクトベースUIが名詞→動詞のアクションになっているのである！と説明はされますが、どうでしょう、皆さん理解できていますか？

ここでは、UIを現実の手続き論（こどもが生まれたときの役所への手続きを例に）に置き換えてみました。

山田さんに子供を生んでもらう

まず、いきなりですが、山田さん（仮称）にこどもを生んでもらいます。

はい。生まれました。

生まれたら、いろんな手続きが発生しますね。出生届、住民登録、母子手帳をもらう、保育園・・・

手続きの構造

タスクベースUIだとどうなるか

お子さんが生まれました。
タスクベースだと、まず子供が生まれたときの手続きを山田さんが自分で調べる必要があります。

そして、それはどこでできるのか？をユーザーである山田さんが確認し、
タスク（＝しなければならない行動）を起点にひとつひとつ手続きを処理するはめになります。

山田さんが、戸籍を登録する行動（＝動詞）を選んで、
戸籍課にいって出生届けというオブジェクト（＝名詞）を出すというかたちですね。

そして準備したタスクの一つ一つが別々の場所になるので、別々に本人確認（＝認証）の手続きが発生してしまいます。

ちょっと、面倒ですね。

オブジェクトベースUIだとどうなるか

お子さんが生まれました。
オブジェクトベースだと、山田さんが考えておくことは、
子供がうまれたら役所というところで手続きをするんだな、という一般常識（＝コンテクスト）をもっておくだけです。

子供がうまれたというコンテキストを持った山田さんがきた時点で、窓口の本人確認（＝認証）が走り、山田さんのできるオブジェクト（＝名詞）が全て明示されます。そこから、手続きという行動（＝動詞）を起こします。

結果、バックエンドの処理として、山田さんのやりたいことが、それぞれの部門にタスクとして渡されて、それぞれの部門で処理されます。

エージェントUIだとどうなるか

もう一歩先にいくと、エージェントという考え方もあると思います。

この場合は、山田さんは「こどもがうまれた」というコンテキストを宣言する必要もありません。
監視（＝センサー）によって、山田さんに子供がうまれたことはシステム側が感知しており、また山田さんが手続きのために役所にもうすぐ来ることも察知しています。
※そもそも役所にいかなくても処理させることもできるかもしれませんね。

山田さんが役所に来る前の時点で、山田さんという本人確認（＝認証）が済んでおり、また必要な手続きもリストアップされ、担当者までその場に呼ばれています。

このように手続きを擬人化して分類してみました。
山田さん（＝ユーザー）視点では、タスクベースでは負荷が高く、
オブジェクトやエージェントになったほうが負荷が低いため、
オブジェクトベースやエージェントが好まれると思います。

一方、役所（＝システム）視点ではどうでしょうか？

処理の構造(＝計算リソースの所在)と、問題点

タスクベースUIだと

主な処理
・「しなければいけない手続きの選定」という処理
　　　　→これは山田さんが行います。
・山田さん認証処理
　　　　→これは各システム毎に発生します。
・オブジェクト処理
　　　　→各システム毎に、限定された範囲で行われます。

この場合、人間の負荷が高くなり、
またシステム自体は互いに接続しない疎結合で、
かつそれぞれの処理単体は単純で軽いものとなります。
システム構築的には一番コストがかからないでしょう。

オブジェクトベースUI

主な処理
・「しなければいけない手続きの選定」という処理
　　　　→前面に出ているシステムが一括して行います。
・山田さん認証処理
　　　　→前面に出ているシステムが一括して認証します。
　　　　　認証したデータは、各システム毎に渡す必要があり、
　　　　　渡すための仕組みも必要です。
・オブジェクト処理
　　　　→各システム毎に、限定された範囲で行われます。

こちらでは、人間の負荷はほとんどありませんが、
前面に出ているシステムで、認証からタスク選定・タスクの受け渡しまでを担う必要があるので、かなりの計算リソースが必要となりそうです。
また、後続システムへ認証データを渡す仕組みも造るため、若干密結合となり、システム改変のときには前面に出ているシステムと後続システムとの間で連携的に作業する必要がありそうです。
但し後続システムにおける処理単体は単純で軽いものとなります。
システム構築的には前面に出ているシステムのコストが重そうです。

エージェントUI

主な処理
・「しなければいけない手続きの選定」という処理
　　　　→エージェントになるシステムが一括して行いますが
　　　　　そもそもそれを検知するセンサーを張り巡らし、
　　　　　システムにそれを送らねばなりません。
・山田さん認証処理
　　　　→前面に出ているシステムが一括して認証します。
・オブジェクト処理
　　　　→認証したうえで各システムをシステム内で呼び出し、
 　　　　　同じシステムとして振る舞う必要があります。

こちらも、人間の負荷はほとんどありませんが、
センサーを張り巡らし、データを通信し、さらにシステムで認証からタスク選定し、必要なタスクは同じシステムとして処理する必要があるので、膨大な計算リソースが必要となりそうです。
システムは完全に密結合となり、システム改変の影響範囲は大きくなるでしょう。トラブル時はおそらく全体が長時間停止する必要がありそうです。
人には便利ですが、システムのコストがめちゃくちゃ重そうです。

このように、
人間中心の思考で「UXとしてどうあるべき、UIはこうあるのが最善である」というアプローチは必要　ですが、一方で、
システム思考として　計算リソースと影響範囲も見据えたアプローチも必要です。

オブジェクトベースであるべきなんだけど、
全体コストを考えてまずはコンテキストの種類で振り分けるとか、
オブジェクトベースとタスクベースのあわせ技、
みたいなものも必要かと思います。

サービスデザイナーはこのような全体視点での思考がもとめられます。