反OOUIのように見えるチャットボットは何故流行しているのか

# チャットボットはOOUIの原則に反している！？
最近、いろいろなサービスでチャットボットを見かけるようになりました。当社でも数週間前に、社内問い合わせ用チャットボットが導入されました。使っていてふと思ったのですが、実はチャットボットの特性は非常に不思議です。

近年、GUIといえばOOUI設計が王道とされがちですが、よく見てみるとチャットボットはOOUIの原則に則っていないように見える場面があります。
そもそもチャットボット＝GUIでは無いだろうというツッコミはその通りなのですが、せっかくなので今日は、**何故チャットボットがオブジェクト指向ではないにも関わらず、UIの世界でチャットボットが許容されているのか**を、UIの歴史とともに考察していきたいと思います。



# OOUIのおさらいと、チャットボットへの問題提起
まずOOUIではオブジェクトが操作の起点になります。
OOUIに関する有名な書籍を出版されている[上野氏のブログ記事](https://www.sociomedia.co.jp/7279#objectbase-taskbase)には以下のようなフレーズが書かれています。


```
釘を打つ時、我々はまずハンマーを持ち、それから振り下ろします。
振り下ろしてからハンマーを持つ人はいないのです。
```

つまり「操作の対象物」が先に来るべきであり、「対象物に対してどんな操作をするのか」が後に来るということです。
これはたしかに、**物理世界におけるモノの操作方法と同一**であり、OOUIがGUIの王道とされるのはたしかに納得が行きます。

しかしチャットボットにおいては、「○○したい」「XXはどこ」等、動詞が主体の問いかけが頻繁に行われます。

## 実物で見るOOUI vs. タスクベース
ではここで実物を見て比較をしてみましょう。

### amazon.co.jpの注文履歴

以下はAmazonの注文履歴ページです。これは典型的なOOUIが採用されています。
![](2022-04-04-11-01-33.png)![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/8778886c-79f4-a109-0d7f-376068966166.png)

このときのユーザの操作は以下のようになるはずです。
* ユーザが、リスト（オブジェクトの一覧）から対象オブジェクト（注文）を選択する
* ユーザが、その注文オブジェクトに対する操作を選択する（キャンセル等）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/84a6eeb5-5e8b-b52d-6b0c-fcc2ddbafc0c.png)


しっかりと、**対象注文オブジェクトをキャンセルする**という順序になっています。お見事なOOUIです。


### ZOZOTOWNのチャットボット
次に、ZOZOTOWNのチャットボットを見てみましょう。
こちらはユーザの行動が主体であり、典型的なタスクベースであると言えます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/d0619cd3-93ed-fd4d-e2ac-93427033c0de.png)

* ユーザが、「注文をキャンセルする」と投稿する
* Botが、どの注文をキャンセルするか提示する
* ユーザが、どの注文をキャンセルするか選択する

確かに、ユーザが**注文をキャンセルする**と投稿した時点で、ユーザは注文オブジェクトの話をしようとしていることはわかりますが、
どの注文の話をしているのかが確定していません。
その注文がキャンセルできるものなのかもわからず、そもそも勘違いで注文はしていなかったかもしれません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/c8b5fdd4-293e-4e2e-fc5f-0838cec550d8.png)


まさに、上野氏の書かれている**振り下ろしてからハンマーを握ったような**操作になっています。


このようにOOUIとチャットボットいずれもUI世界におけるメジャーな考え方ではありつつも、一見すると相反する思想を持っているように見えます。

### OOUIの例外
しかし、上野氏の記事には続けて以下のような記載もあります。

```
タスクベースの GUI が例外的に許容されるのは、
ATM のように対象オブジェクトが限定的で選択の必要がない場合
（ATM の場合は「口座」が対象オブジェクトでありその選択行為はキャッシュカードを入れる動作と一体化している）や、
自己完結的な手続きを定型入力フローとして提供する場合です。
```

つまり対象物が明らかに明確であり、言わなくてもわかる場合は対象物を省略しても良いということですね。
確かに、ATMを操作するときに一番最初のボタンがこんな感じであればちょっとイラッとしますよね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/dba396be-824a-0263-bd0b-d67cb687186f.png)
ATMではカードを入れた時点で自分の口座が対象物であることは明確なので、敢えてユーザに選択させる必要は無いのでしょう。


このようにOOUIにするまでもないケースや、OOUIにすると冗長になるケース等が存在するということで、もしかするとこれ以外にもOOUIが適さないケースがあり、それがチャットボット台頭の鍵になっているかもしれません。


# CUIとGUIで見るUIの歴史
しっかりと考察をするために、今回はUIの歴史を振り返りたいと思います。
コンピュータシステムにおけるUIの歴史はそこそこ長いのですが、今回は**CUI、GUI**それぞれの時代を見てみたいと思います。

## CUI時代
初期のコンピュータシステムにおける、人間とコンピュータの対話方法はCUI（コマンド）でした。CUIの場合は文字列で対話をしますが、その操作方法はタスクベースでした。

### コマンドはタスクベースである
例えば以下のようなコマンドを見てみましょう。

```shell
cp ./foo.txt ./foobar/foo.txt
```

この操作は典型的なタスクベースUIです。
日本語に直訳すると**コピーする foo.txtを foobar/foo.txtに**となります。
当然ながら不自然ですし、UIとしても人間の特性には反しているというのがOOUIの考え方です。

### 何故タスクベースが否定されやすいのか？
何故ダメなのでしょうか？
それは使用者が、「このオブジェクトはコピーができるはずである」ということを記憶しておく必要があるからです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/2fae75ab-64b7-fa4f-6dd0-2d9332de2e33.png)

記憶が正しければ良いですが、記憶が曖昧であったときには利用者の挫折感が大きくなります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/97514acc-1e0f-6319-91d2-b4a7624bde81.png)

CUIも進化はしていて、最近はファイルの一覧を補完できたり等色々機能が豊富になってきましたが、
やはりOOUI的な考え方では **foo.txt自身が** 「自分はこれこれこういう操作ができますよ」ということを自ら示してくるべきであり、人が覚えておく必要は無いのです。

### 再生と再認
この差は人間の認知科学で言うと**再生と再認**に当たります。

たとえば、花の「バラ」を漢字で書けるかと言われると、書けない人は多いです。
私も書けません。過去に記憶したものを100%再生しなければならないからです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/e543fcc2-8136-4afe-0f64-6a30528bb6fa.png)

しかし選択肢が与えられていて、「バラはどれですか？」と聞かれると正答できる方は多いでしょう。過去に見たことはあるはずですからそれを思い出すことができる、これが「再認」です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/1da96067-6be5-1a25-bce6-45ff104495db.png)


こういった理由から、再生しないと操作できなかったCUI時代において、コンピュータシステムが非エンジニア層にまで浸透することは稀であったと思われます。

**(ちなみに)**
不思議なことにCUIの文法は英語圏であれば非常に自然であり、先のファイルコピーの例であれば以下のようになります。
```
"Copy foo.txt to foobar/foo.txt"
```
CUIがはじめに英語圏で作られた（であろう）ことを考慮すると、別に「タスクベースで作ろう」と考えて作ったのではなく、単純に文法的に自然な方法をとったのだと思います。
そのような意味では、SOVの語順をもつ言語の話者はオブジェクト指向に馴染みやすいのかもしれません。完全に予想でしかありませんが。



## GUI時代
さて、しばらくするとUIの世界に革命が起きます。

### GUIの誕生
世界初のGUIは1963年ごろのSAGEという米国防空システムに搭載されていたそうですが、一般化のきっかけになったのは1970年頃にアラン・ケイ氏により開発されたDynabookでした。アラン・ケイ氏はまさにCUIの課題であった**記憶を再生しなければ使えない**という点を見事に克服し、「再生」を中心とするGUIを作り上げました。

GUIにおいてはすべてがグラフィカルであり、たとえば「ゴミ箱」を右クリックすればゴミ箱に対して何ができるのかという選択肢が、システムから提示されます。**人が100%覚えておく必要は無い**のです。
これによりコンピュータは非エンジニア層にも受け入れられるようになり、文字通り「パーソナル・コンピュータ」化していきます。

実はアラン・ケイは**オブジェクト指向プログラミングの父**とも呼ばれており、アラン・ケイ氏がGUIを開発したときにはおそらくオブジェクト指向な発想が頭にあった可能性が高いでしょう。GUIの本質はオブジェクト指向であり、これを考えればOOUIがGUI設計におけるの銀の弾丸とされるのは何も不思議なことではありません。


# チャットボット時代
正直なところチャットボットがCUI、GUIのように一時代を築くのかどうかはまだわかりません。
しかし明確に広まりつつあり、無視できない規模になってきています。ここまでの話を踏まえて改めて理由を考えると、以下のような可能性が考えられます。

* 行いたい操作はわかるが、対象物が全く検討もつかない（名詞→動詞の語順が作れない）
* 技術の発達
* ただの興味本位（または何らかの先見の明）

## 行いたい操作はわかるが、対象物が全く検討もつかない（名詞→動詞の語順が作れない）
おそらくこれが最大の理由ではないかと考えています。
OOUIにおいてはオブジェクトが操作の起点になる以上、オブジェクトの階層化が必要になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/c9f0187c-c3dc-d856-81a6-12f7310b4d20.png)

例としてWindowsのコントロールパネルを挙げます。綺麗に階層化されていますね。
では、パスワードを変更したいときにどのような階層を順に辿ったら目当てのオブジェクトにたどり着けるか、わかるでしょうか？初心者目線で考えてみてください。

パスワードですから、「システムとセキュリティ」な感じもします。
いや、「ユーザアカウント」かもしれません。
もしかすると「コンピュータの簡単操作」かもしれません（※Windowsを批判する意図はありません）。

先のAmazonの例でも、「注文履歴」内の「注文オブジェクト」内で注文キャンセルができることが世間的に明確であれば良いのですが、言われてみれば「注文履歴」内にあるというのは、**人によっては常識ではない**可能性があります。

そういえば先日100均に排水溝ネットを買いに行ったのですが、見つけるのに非常に苦労しました。
確かに階層楮的な分類はなされているものの、衛生コーナーなのか、キッチンコーナーなのか、清掃コーナーなのか初見ではわかりませんでした。
ちなみに何故かお風呂コーナーにありました。

対象物の階層構造が常識的であり誰にとっても明確なら良いのですが、初めて見るシステムにおいて何がどこにあるかの階層構造がわからない場合は大量のトライアンドエラーをする羽目になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/e9c266cf-540e-ed15-ca8d-05bf6ce9e2d1.png)

上野氏の言葉を借りるならば、**ハンマーを振り下ろしたいのに、ハンマーが道具箱の中にあるのか、ラックにかかっているのか、倉庫にあるのかわからない**のです。確かに、この場合に助手のような人がいて、「ハンマーどこや！」「ここっす！」的な会話が成り立てばすごく楽になるかもしれません。そして利用者がこの階層構造についての知識が少ない場合、この傾向はさらに強くなります。

結論として、特に初見のシステムの場合はチャットボット的な「助手」は有用であると考えられます。
しかし2回目以降はただの冗長な機能かもしれません。


## 技術の発達
そもそも昔は技術的な理由でチャットボットが使いにくかったという可能性もあります。
特に日本語のような言語の場合、利用者の意図を正確に解釈するには
* 入力を受け付け
* 分かち書き/形態素解析をして
* 意図を解釈して　云々...
というように長いフローが必要であり、言われてみれば**このあたりの技術が発展したのは最近**です。

思えば最近の検索エンジンは「もしかして：XX」というサジェストをしてきますが、ある意味これはチャットボットの走りのようなものかもしれません。

## ただの興味本位（または何らかの先見の明）
もしかすると、ただの興味本位かもしれません。ガートナー社が毎年技術のハイプ・サイクルを出していますが、2021年のサイクル図によればちょうどチャットボットは幻滅期真っ只中です。あとは、近いものがありますが少し先を歩いているセマンティック検索も気になりますね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/62edaee6-f49c-2ca1-a475-1304f8e20055.png)


2020年のものを見るとチャットボットは幻滅期を転落している最中のようです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495652/afe18cc1-cbd0-7699-26f1-b44dd643a964.png)

今公開されているチャットボットの多くは、幻滅期を脱する兆候をつかんだ企業によるものか、
あるいは遥か前の「過度な期待」時期に開発されたものという可能性があります。

# 結論
長くなりましたが、チャットボット流行の理由には以下のような理由が考えられました。
* OOUIが苦手とするシチュエーションを補完できている、つまりOOUIとチャットボットが共存する時代の到来
  （初見はチャットボットが有用、2回目以降はただの邪魔な可能性もアリ）
* 技術が発展したおかげでチャットボットの利用が現実味を帯びてきた
* ただの興味本位で作っている、使っている人が多い可能性もある