🍉
画面遷移に順序があるUIの保守性を向上させる「順序ありオブジェクト指向UI」の提案

kima
2024/09/11に公開
画面遷移
オブジェクト指向ui
tech
 はじめにUIを設計するときにオブジェクト指向UIは大きな効果を発揮することがあります。一方で、オブジェクト指向UIの考えをそのまま適用できないけれども、タスク指向UIと呼ぶのも微妙な画面があります。
例えば、ECサイトの購入プロセスです。よくあるECサイトの購入プロセスは以下の図のような構成です。これだけだと簡単そうですが、実際のECサイトの購入プロセスはある画面をスキップしたりしなかったりという制御があり、なかなかに複雑なものです。

今回の記事は画面遷移に順序があるがタスク指向UIと呼ぶのも微妙な、複雑な画面遷移を持つ画面にオブジェクト指向UIの考えを導入することで画面遷移制御を簡単にする手法を提案します。
対象読者

画面遷移の制御の保守性を向上させたいITエンジニア

 この記事の概要複雑な画面遷移を持つUIに対して、オブジェクト指向UIの考え方を導入することで、制御フローをシンプルにする手法を提案します
ECサイトの購入プロセスを例に、画面遷移をオブジェクトの状態として捉え直し、「順序ありオブジェクト指向UI」という新しい概念を定義します
このアプローチにより、画面遷移の保守性が向上し、機能改修も素早くできます

 オブジェクト指向UIとは？オブジェクト指向UIとは、画面の入力や遷移についての設計手法です。オブジェクト指向UIと対比される概念としてタスク指向UIがあります。
オブジェクト指向UIとタスク指向UI

オブジェクト指向UI :

UIを構築する際に、アプリケーションのデータやオブジェクトに焦点を当てます。ユーザーは、オブジェクト（例えば、ファイルや顧客情報など）を選択し、それに対するアクションを次に選択します。このアプローチは、ユーザーのメンタルモデルに近いUIを構成するため、直感的で使いやすいとされています。

タスク指向UI :

ユーザーが達成しようとする特定のタスクや仕事に焦点を当てます。ユーザーは、一連の手順やワークフローのタスクを最初に選択して画面を操作していきます。このアプローチは、特定のタスクを効率的に行ったり、不慣れな操作を簡単に行うように設計されたインターフェースを提供し、ユーザーが何を達成したいかを明確にし、そのためのステップをガイドします。
オブジェクト指向UIのメリット

オブジェクト指向UIが優れているのは、操作の柔軟性と直感性にあります。ユーザーはオブジェクトを中心に操作を進めるため、自然な流れで複数のタスクを行えます。また、オブジェクトが操作の軸になるため、操作の一貫性が保たれ、ユーザーが自身のメンタルモデルに基づいて自由に行動できます。

一方、タスク指向UIはステップに沿った手順を強調するため、特定の作業に向いていますが、柔軟な操作には制限があります。
オブジェクト指向UIはメリットが多いため、多くの画面にも適用したいです。しかし、ECサイトのカートフローのような画面にはすんなりと適用するのが難しいです。

 複雑な画面遷移があるオブジェクト指向UIECサイトの購入プロセスの各画面はオブジェクト指向UIのようだけど、タスク指向UIのようなタスクの順序を強制する機能もあります。それはどうしてなのか次から説明します。

 事例:ECサイトのカート画面の複雑な画面制御ECサイトの購入プロセスでは、ユーザーは複数の画面を行き来しながら情報を入力していきます。以下の事例を通じて、購入プロセスにおける画面遷移の複雑さを示します。
事例1. カート確認画面から配送先画面に戻って内容を修正後に次の画面に進むとき、すでに支払い情報があるので決済選択画面はスキップする。

事例2. カート確認画面を見てたら購入予定商品に誤りがあったので商品を入れ替えた。そのあとまた購入プロセスに入ると、商品代金が代わり元々指定していた決済方法が適用できなくなったので、配送先はスキップして決済選択だけもう一度行った。

事例3. ユーザーは事前にデフォルト配送先とデフォルト決済を選択できる。もしも配送先のデフォルト設定があたら配送先画面はスキップする。決済選択画面も同様である。そのため、両方ともデフォルト設定があれば、配送先画面も決済選択画面もスキップする。

これらの画面遷移を図に表すと以下のようになります。この図から画面遷移の制御が複雑であることがわかります。もちろん実務ではもっと複雑です。[1]

 オブジェクト指向UIともタスク指向UIとも分類しにくい画面ECサイトの購入プロセスのような複雑な画面遷移では、オブジェクト指向UIやタスク指向UIのどちらか一方だけで設計することが難しい場合があります。購入プロセスの各画面はオブジェクトに情報を入力したり確認するもので、オブジェクト指向UIの特徴を持っていますが、同時に購入という一連のタスクを順序に従って進めなければならないという性質から、タスク指向UIの要素も含まれています。

ECサイトの購入プロセスには、オブジェクト指向UIやタスク指向UIだけでは対応しきれない独自の複雑さがあり、状況に応じて画面をスキップしたりする柔軟さが求められます。では、この複雑な画面遷移をどのように整理し、保守性を高められるのでしょうか？

 画面遷移の制御をオブジェクトの状態で捉えなおすここで考えられるのが、各画面がオブジェクト指向UIでありつつも、画面遷移に一定の順序や制御が存在するUIと見なす方法です。

ECサイトの購入プロセスでは、画面ごとに異なるオブジェクト（例：配送先情報や決済情報）を操作する必要があるため、各画面はオブジェクト指向UIの特徴を持ちます。しかし、同時にその情報が特定の順序で入力されなければならないというタスク指向UI的な要素も含まれているのです。
次からは実際にそのように捉え直すことで、画面遷移の制御を簡単にしていきます。

 ECサイトの画面をオブジェクトの情報を満たすためのUIとして捉えるECサイトの購入プロセスの各入力画面は、ユーザーが購入手続きを進めるために必要な情報を入力するためのUIです。つまり、各画面はカートオブジェクトの特定の情報を満たすために存在します。このように捉えると各画面はオブジェクト指向によるUIです。
つまり、各画面は次のように説明できます(図は説明のために複雑なフローの矢印は省略しています)。

配送先画面: これはカートの配送先情報を入力するための画面です。ユーザーはここで自分の住所や受け取り場所を入力します。

決済選択画面: これはカートの決済情報を入力するための画面です。ユーザーはここで支払い方法を選択し、必要な支払い情報を入力します。

上の説明をもとに、カートを商品と配送先情報、決済情報によるオブジェクトと解釈します。この解釈によるカートオブジェクトに対する配送先画面と決済方法画面の関係を図で示します(商品は省略)。こうすることで、カートの各画面がオブジェクト指向UIであることを説明できます。

 ECサイトの画面遷移をオブジェクトの情報を特定順序で満たす制御と捉える配送先画面と決済選択画面をオブジェクトの入力であるとすると、画面遷移をオブジェクトの情報を特定順序で満たす制御と考えられます。

配送先情報 : ユーザーが商品をどこに送るかを決定するための情報です。これが入力されない限り、どこに配送するかが決まりません。

決済情報 : ユーザーが商品代金をどのように支払うかを決定するための情報です。今回の事例では、配送先情報が入力された後でなければ、決済情報を入力することはできないという制約があります。
こうすると画面遷移の設計が容易になります。実際に簡単になったかは次の画面スキップの例で説明します。

 ECサイトの画面遷移時の画面はオブジェクトの情報が満たされてるならスキップできる今回のECサイトの購入プロセスが複雑になっている理由は各画面をスキップできるからです。ここでは画面をスキップする事例を示し、オブジェクトの観点からこれを整理します。
事例1. カート確認画面から配送先画面に戻って内容を修正後に次の画面に進むとき、すでに支払い情報があるので決済選択画面はスキップする。

事例2. カート確認画面を見てたら購入予定商品に誤りがあったので商品を入れ替えた。そのあとまた購入プロセスに入ると、商品代金が代わり元々指定していた決済方法が適用できなくなったので、配送先はスキップして決済選択だけもう一度行った。

事例3. ユーザーは事前にデフォルト配送先とデフォルト決済を選択できる。もしも配送先のデフォルト設定があたら配送先画面はスキップする。決済選択画面も同様である。そのため、両方ともデフォルト設定があれば、配送先画面も決済選択画面もスキップする。

上の図を見ると、次のことが言えそうです。
配送先の情報があるとき、配送先画面をスキップする
決済の情報があるとき、決済選択画面をスキップする
つまり、各画面はオブジェクトの入力を行う画面なので、すでにオブジェクトの情報があるならばスキップできます。

 オブジェクトの状態にもとづく操作のために画面があるここまでの流れから、購入プロセスの画面遷移を整理すると次のようになります。
次の画面に進むとき、配送先情報がないならば配送先画面で情報を入力させる。あるならばスキップさせる。
次の画面に進むとき、決済情報がないならば決済選択画面で情報を入力させる。あるならばスキップさせる。
満たす情報の順序は、配送先情報→決済情報である。
最初の仕様に比べると画面遷移の仕様が簡単になりました。これは各画面単位で画面制御を考えるのではなくて、各画面が操作しようとしているオブジェクトの状態にもとづいて遷移する画面を選択してるからです。これは画面とオブジェクトの主従を逆転させたとも言えます。配送先画面ではカートの配送先情報を入力すると考えるのではなくて、カートの配送先情報を満たすために配送先画面が存在すると考えます。
オブジェクト指向UIとして考えるならば、最初にあるものはオブジェクトです。オブジェクトに対する何らかの操作をするために画面があります。そのようにとらえれば画面遷移の仕様はグッと簡単になります。[2]

 順序ありオブジェクト指向UIの提案先ほどのカート画面のように画面はオブジェクトを操作していました。そういう意味でオブジェクト指向UIのようでしたが、画面遷移に制御があるためただのオブジェクト指向UIと呼ぶべきなのかも判断に迷います。

一方で、UIはオブジェクトを操作するものと見ることで画面遷移をスマートにできることも示しました。このようなUIをオブジェクト指向UIの一種として、本記事では今まで説明したこのような画面を順序ありオブジェクト指向UIと呼ぶことにします。
順序ありオブジェクト指向UIの定義

各画面はオブジェクト指向UIになっているが、その画面を利用するプロセス全体はタスクを達成するための何らかの制御がある画面構成。

 順序ありオブジェクト指向UIの利点順序ありオブジェクト指向UIは各画面内ではオブジェクト指向UIですが、その画面によって構成される作業フローはタスク指向UIのような制御があります。

このような画面の分割の利点は主に次の二つがあります。これらの利点を得たいとき、順序ありオブジェクト指向UIの採用を検討すべきです。

 利点1:大きな枠組みで作業フローを強制しながら細かなオブジェクト操作はメンタルモデルに合わせられる利点の一つ目は、画面遷移に制御順を設けることで作業フローを強制しながらも、オブジェクト単位の操作は画面ごとにできることです。

タスク指向UIの利点であるユーザーの不慣れな操作をガイドするという機能を大粒度では提供しつつも、より小さな粒度である画面単位ではオブジェクト指向UIの利点を享受できます。

 利点2:ユーザーの入力を細かく分けられる利点の二つ目は、ユーザーの入力を各画面へと細かく分けることです。

ユーザーは一度に入力する項目が多いと、データの入力にうんざりしてしまうことがあります。これを回避するテクニックとして画面内で一度に入力する情報を減らすことができます。

また、一度に入力する項目が多いとシステム的に難しいことがあります。あるデータが別のデータに依存しているため、先に別のデータを確定しておいて欲しいということは少なくありません。これを容易に達成するために、一度に入力する情報を画面ごとに分割させることは作業工数削減のために有効なことがあります。

 順序ありオブジェクト指向UIは画面遷移の改修が楽順序ありオブジェクト指向UIの利点は説明しました。一方で、このような画面構成は従来も行われています。ここまでの本記事を読むと、順序ありオブジェクト指向UIと画面を解釈しても、タスク指向UIの複雑な画面遷移を整理するぐらいしか効果がないと思う方もいると思います。[3]
実は順序ありオブジェクト指向UIとして解釈し、設計することにはもうひとつ利点があります。UIを順序ありオブジェクト指向UIとして画面を捉えると、画面遷移の改修が簡単になります。

 事例:定期購入画面も欲しい！！！また購入プロセスを例にします。あるECサイトにて、後から定期購入をサポートしたいという要望が来たとします。図はこの要望を叶えた後のものです。
新しい要望

定期購入に対応するため、定期情報の入力を購入プロセスでやって欲しい。ただし、この処理は定期購入画面という形で新しい画面を配送先画面と決済選択画面の間に入れて欲しい。

あと、スキップ関係の機能は定期購入画面に対しても全部有効にして欲しい。

 順序ありオブジェクト指向UIによる画面遷移の改修順序ありオブジェクト指向UIとして解釈していないと、画面遷移の制御の影響範囲はすべての画面です。

一方で、順序ありオブジェクト指向UIの場合、次のような制御を追加するだけです。
元の制御(再掲)
次の画面に進むとき、配送先情報がないならば配送先画面で情報を入力させる。あるならばスキップさせる
次の画面に進むとき、決済情報がないならば決済選択画面で情報を入力させる。あるならばスキップさせる
満たす情報の順序は、配送先情報→決済情報である。
新しい要望にもとづいた制御(太字が新規要素)
次の画面に進むとき、配送先情報がないならば配送先画面で情報を入力させる。あるならばスキップさせる。
次の画面に進むとき、決済情報がないならば決済選択画面で情報を入力させる。あるならばスキップさせる。
次の画面に進むとき、定期情報がないならば定期購入画面で情報を入力させる。あるならばスキップさせる。
満たす情報の順序は、配送先情報→定期情報→決済情報である。
このように、オブジェクトの状態にもとづく制御として画面遷移を捉えると、画面遷移の改修も簡単になります。

 まとめこの記事では、複雑な画面遷移を持つUIに対して、オブジェクト指向UIの考え方を導入し、順序ありオブジェクト指向UIという新しいアプローチを提案しました。この手法により、画面遷移の制御がシンプルになり、保守性が向上することを説明しました。

順序ありオブジェクト指向UIの設計・開発においては、画面遷移の条件をオブジェクトの状態にもとづいて集約することが鍵となり、将来的な改修も容易に行えるようになります。
この手法は、特にECサイトのような複雑なプロセスを持つシステムで有効であると考えられます。皆さんのUI設計に役立てたら嬉しいです。

 参考文献
オブジェクト指向UIデザイン : オブジェクト指向UIに関する本。オブジェクト指向UIはこの本で学びましたが、UIによっては本当に銀の弾丸で凄いと思いました。

脚注
購入中に商品マスタの情報が変わって入力済みの配送情報が無効になったり、規約同意の画面があったり、ゲストの場合はログイン画面が表示されたり、ブラウザバックや明示的に他画面に戻る機能など、実際はもっと色々あります。 ↩︎
より正確に言うと、まずオブジェクトがあり、オブジェクトの操作方法としてAPIが提供され、そのAPIを使いやすくするためのインターフェースとしてGUIがあると解釈します。画面遷移の制御とは、GUI上でのUXを考慮した制約に過ぎないと考えます。一方で、このようにオブジェクトとAPI、GUIを安直に結びつける方法には批判もあります。例えばこの記事の「ハンドル」に関する議論です。ここでは「直進」や「左折」のような機能に着目するとハンドルというインターフェースにたどり着けないと説明しています。このようなことがあるため、オブジェクトと安直に結びつけない注意が必要です。ちなみに、この事例の場合は少数の関数で多機能を目指すディープモジュールの考え方に則ってAPIを設計すれば多少良くなるとは思います。 ↩︎
画面遷移の制御を中央集権化するならば、ただ画面遷移を状態遷移表に紐付ければいいと思われるかもしれません。それはひとつの正解ですが、この記事で述べてる手法への批判にはなりません。この記事で述べてるオブジェクト指向を画面遷移の制御に導入する手法は、その状態遷移表を簡略化することを目指しています。 ↩︎