正常系だけでは、設計は終わらない

ボタンを押す。

処理が始まる。

結果が表示される。

システムを作るとき、まず考えるのは、こうした「作りたいもの=理想」の流れです。

注文する。
決済する。
確認メールが届く。

電話番号を入力する。
認証コードが届く。
コードを入力して、ログインする。

一つひとつの処理が予定通りに進んでいく。

もちろん、この流れをきちんと作ることは大切です。

でも、実際に人が使うシステムでは、いつも予定通りに進むとは限りません。

「届かなかったら？」

たとえば、SMSで認証コードを送るシステムを考えてみます。

電話番号を入力する。

SMSを送信する。

ユーザーが認証コードを入力する。

認証が完了する。

これが、期待している流れです。

では、SMSが届かなかったら？

電話番号を間違えて入力していたら？

コードの有効期限が切れていたら？

通信が途中で切れたら？

APIから期待した応答が返ってこなかったら？

ここから先も、システムです。

「うまくいかなかった」という事実だけを知らせて終わるのか。

もう一度試せるようにするのか。

入力内容を確認してもらうのか。

別の方法を案内するのか。

時間を置いて再度試してもらうのか。

必要なら、人に問い合わせられるようにするのか。

失敗したあとに何が起こるかも、ユーザーが体験するシステムの一部です。

エラーは、ユーザーにとって「想定外」とは限らない

開発する側から見れば、エラーは「例外」かもしれません。

けれど、使う人にとっては違います。

その瞬間に画面に表示されているものが、その人にとってのシステムです。

「エラーが発生しました」

そう表示されて、先へ進めなくなった。

ユーザーにとって重要なのは、内部でどんなエラーが起きたかだけではありません。

「では、私は次にどうすればいいの？」

ということです。

正常に動いているときには、システムがユーザーを次へ案内してくれます。

それなら、うまくいかなかったときにも、

「次にできること」

を示すことができるはずです。

失敗をなくすことと、失敗に備えること

もちろん、エラーそのものを減らす努力は必要です。

安定したシステムを作る。

十分にテストする。

問題を監視する。

不具合があれば修正する。

それでも、すべての失敗をなくすことはできません。

システムの外にも、さまざまな要因があります。

通信環境が変わることもあります。

外部のサービスが一時的に利用できなくなることもあります。

そして、人は入力を間違えることも、操作に迷うこともあります。

だから、

「失敗しないシステムを作る」ことだけではなく、
「失敗しても、その先へ進めるシステムを考える」。

それも設計の仕事ではないでしょうか。

正常系の隣に、もう一本の線を引く

設計するとき、

「これをしたら、次はどうなる？」

と考えます。

その横に、もう一つだけ質問を置いてみます。

「もし、そうならなかったら？」

送信できなかったら？

届かなかったら？

応答がなかったら？

入力が違っていたら？

途中でやめたら？

戻ってきたら？

この問いを一つ加えるだけで、設計図には正常系とは別の線が見えてきます。

その線は、必ずしも複雑な仕組みである必要はありません。

再試行できるボタンかもしれません。

分かりやすい案内文かもしれません。

別の連絡手段かもしれません。

あるいは、

「ここからは人が対応します」

という線かもしれません。

大切なのは、行き止まりをそのままにしないことです。

「うまくいかなかったとき」に、設計が見える

システムが予定通り動いているとき、ユーザーは設計を意識しないかもしれません。

それでいいのだと思います。

でも、何かが予定通りにいかなかったとき。

そのシステムが、次の道を示してくれるか。

何が起きたのかを伝えてくれるか。

もう一度やり直せるか。

必要なら、人につながれるか。

そんなところに、そのシステムがどれだけ使う人を考えて作られているかが表れます。

正常系を作ることは、設計の始まりです。

でも、

正常系だけでは、設計は終わりません。

Xoxzoから

SMSを送る。

電話をかける。

認証コードを届ける。

APIを使えば、こうした機能をシステムに組み込むことができます。

けれど、その機能を呼び出すことだけが設計ではありません。

届かなかったらどうするか。

利用できなかったらどうするか。

状況が変わったらどうするか。

そこまで考えて初めて、その機能はサービスの中で生きてきます。

そして、もう一つ考えておきたいことがあります。

今は必要のない「別の道」が、将来必要になるかもしれません。

使う人が増えるかもしれない。

サービスの形が変わるかもしれない。

新しい選択肢が登場するかもしれない。

では、そんな未来の変化に対応できるシステムは、どう作ればいいのでしょう。

次回は、

「APIは、未来のために選ぶ」

について考えてみます。