非同期という選択——待たせる設計の合理性

動画をアップロードして「公開」を押すと、画面はすぐに次へ進む。だが動画そのものはまだ変換されていない。エンコードはサーバーの裏側で進み、数分後に完了の通知が届く。利用者は待たされていない。けれど処理は終わっていない。この一見矛盾した状態を成り立たせているのが、非同期(asynchronous)という設計の考え方である。

同期処理では、利用者の操作とシステムの応答が一本の線でつながっている。押したら、終わるまで待つ。シンプルだが、重い処理ではその「待つ」が利用者を画面に縛りつける。非同期処理は、この線を切る。操作を受け付けた時点でいったん利用者を解放し、処理は別のところで進める。結果は後から、適切なタイミングで届ける。

なぜ切り離すのか

非同期化の動機は一つではない。まず、利用者の時間を奪わないこと。完了まで数分かかる処理のあいだ、画面の前で待たせ続けるのは合理的でない。受付だけ済ませて、利用者には他のことをしてもらう方がよい。即時性を操作の受付に限定し、本体の処理は遅延を許容する。役割を分けるわけだ。

もう一つは、システム側の事情である。すべての処理を即座にこなそうとすると、負荷が集中したとき全体が破綻しかねない。非同期にして処理を待ち行列に並べれば、システムは自分のペースで仕事をさばける。瞬間的な混雑を時間方向に均す——この平準化は、安定したサービスを支える基盤になる。

解放の代償

もっとも、非同期は利用者を待ちから解放する代わりに、新しい不確実性を持ち込む。処理が裏で進んでいるとき、利用者には「いつ終わるのか」「本当に進んでいるのか」が見えない。進捗の伝え方で触れたマイスターの指摘——説明のない待ちは長く感じられる——は、ここでも効いてくる。受付だけ返して放置すれば、利用者は不安になり、同じ操作を繰り返したり、問い合わせを送ったりする。

だから非同期設計の良し悪しは、処理を切り離せるかどうかではなく、切り離した後の状態をどう伝えるかにかかっている。完了したら通知する。進行中なら、それと分かる表示を残す。失敗したら、理由とともに知らせる。これらの伝達が欠けると、解放したはずの利用者を、見えない待ちの中に置き去りにしてしまう。

遅延を引き受けるという判断

非同期という選択は、遅延を欠陥としてではなく、設計の前提として引き受ける態度から生まれる。すべてを即座に返すことが理想だとすれば、非同期は妥協に見えるかもしれない。だが裏を返せば、即時性に固執しないことで、利用者の自由とシステムの安定の両方を確保できる場面がある。

応答のタイミングをめぐる判断は、速いか遅いかの二択ではない。どの処理を即座に返し、どの処理を後回しにし、その後回しをどう見せるか。複数の時間軸を編み合わせる作業だといってよい。待ち時間の見せ方そのものを比べる視点は、ローディング体験の比較でさらに掘り下げる。