楽観的UIの賭け——確定を待たない設計

「いいね」を押すと、数字はその場で増える。実際にはサーバーへの問い合わせが走り、確定までに数百ミリ秒かかっているはずなのに、私たちはその間を待った記憶を持たない。なぜ待たずに済むのか。この設計の考え方について、二人の話を聞く形で整理してみたい。一人は実装する側、もう一人はそれを使う側の立場から発言する、という設定である。

——押した瞬間に反映される。あれは結果を先に見せているということですか。

実装する側「ええ。サーバーの返事を待ってから画面を更新するのが素直なやり方ですが、楽観的UIでは、成功すると見込んで先に画面を書き換えます。確定の通知が後から来て、見込みどおりなら何もしない。外れたら、こっそり元に戻す。だから『楽観的』なんです」

——その『見込みで進める』という発想は、どこから来たものなんでしょう。

実装する側「古いところでは、データベースの並行性制御に行き着きます。クンとロビンソンが一九八一年に提案した楽観的並行性制御は、衝突はめったに起きないと見込んで、ロックをかけずに処理を進め、最後に矛盾がないか確認する方式でした。先に進んで、ダメなら巻き戻す。UIの楽観性も、根は同じ賭けです」

賭けに勝つ条件

——使う側からすると、待たされないのはありがたい。でも、たまに数字がするっと元に戻ると、少し戸惑います。

使う側「そこが肝心なところだと思います。私が心地よく感じるのは、失敗がめったに起きない操作のときだけ。『いいね』なら、外れても被害は小さい。けれど、送金や予約の確定みたいに、取り消しが重い操作で先に成功を見せられると、かえって不安になる。即時の手応えがほしいのと、確実さがほしいのは、別の欲求ですから」

実装する側「おっしゃるとおりです。楽観的UIは万能ではない。失敗がまれで、取り消しても害が小さく、しかも取り消しを利用者へ無理なく伝えられる——この三つが揃わない場面では使えません。むしろ、確定を待つ正直な遅延のほうが信頼されることもある」

遅延を消すのではなく、隠す

——結局、遅延そのものが消えたわけではないんですね。

実装する側「消えてはいません。処理は裏で同じだけ走っている。私たちがしているのは、遅延を利用者の視界から外すことです。輪郭を先に見せる手法が空白を埋めるのに対して、楽観的UIは結果そのものを前借りする。前借りには返済——つまり失敗時の巻き戻し——がつきまとう。そこを雑にすると、一度の取り消しで信頼を失います」

会話を整理して残るのは、楽観性が技術の問題であると同時に、信頼の問題でもある、という点だ。先に結果を見せるのは、利用者に対して「たぶん成功します」と約束することにほかならない。約束を裏切る頻度が低いうちは、待機が消えたように感じられる。だが、裏切りが重なれば、前借りした手応えは一気に負債へ転じる。一方で、すべてを正直に待たせれば、今度は速さの利点を手放すことになる。どちらに振るかは、操作の重さと失敗の確率を見極めたうえでの判断になる。楽観的UIが扱っているのは、速さと確実さのあいだに引く、その境界線の位置なのだろう。