航空券をApple Walletに入れようとして苦労した話

主要なポイントは以下の通りです：

実際の使用経験：ある手続きを行う過程で、夫と妻は異なるアプローチや考え方を持っていました。

システムの設計思想：夫は「システムはもっと直感的で使いやすくなるべきだ」と考えている一方、妻は「古いシステムは新しいテクノロジーに追いついていないことが多い」という現実を受け入れる傾向がありました。

情報アクセスの方法：夫と妻は、情報を探す方法に関しても異なる認識を持っていました。夫はすべてのページから適切なページへのリンクが存在すべきだと考えているのに対し、妻は「トップページからはどんなに遠くてもつながっている」という考えを持っていました。

情報の整理方法：夫はScrapboxのような非階層的な情報の整理を好む傾向があり、妻は情報をツリーのような階層的な形で整理する方法を好んでいました。

理想と現実：理想的には、すべての情報が容易にアクセスできるように整理されているべきですが、現実的にはそのような整理が困難であることが多い。

この議論は、システム設計や情報アクセスの方法に関する一般的な問題を浮き彫りにしています。

---

僕の認知と妻の認知の違いが興味深いのでまとめてみる

僕の視点

PCでメールを見る

「搭乗用2次元バーコードはこちら」をクリック(画面A)

実際にはGETパラメータが積んである

「航空券番号で認証する」

予約番号6桁をコピー

エラー

メールに戻る

航空券番号が見つからない

混乱する(妻に「他のメールがあるのでは」と言われる)

予約のメールを見る→コピー

→認証する(画面A)→「eチケットお客様控え」のページがでる(画面B)

Apple Walletに登録する動線がない

"JAL Apple Wallet"で検索

【iPhoneをご利用の場合】

オンラインチェックイン完了後の「搭乗券の発行」画面にて「Walletに追加する」を選択し、『Apple Walletに追加』ボタンからご登録ください。

【その他の端末をご利用の場合】

「搭乗券の発行」画面にて「Walletを利用する」を選択し、メールを送信ください。添付ファイルよりWalletにご登録いただけます。

(画面B)に「Walletを利用する」はない

わからない！

妻に「JALのトップページに行ってみな」と言われる

iPhoneでトップページを開く

予約管理？搭乗・チェックイン？

予約管理→航空券　で　「予約検索」になる

「搭乗・チェックイン」だとeチケットお客様控えになるのでこの先行き止まり

すったもんだでログインしたらWalletに追加ボタンがあった！

妻の視点

(多分iPhoneで見ると思うけど、と言いながら)PCでメールを見る

「搭乗用2次元バーコードはこちら」をクリック(画面A)

「航空券番号で認証する」

ここでメールに「航空券番号」がないことを把握しているので「航空券番号について」をクリック

掲載箇所 ... 購入完了画面、購入完了メール

予約のメールを見る→コピー→認証する(画面A)→「eチケットお客様控え」のページがでる(画面B)

Apple Walletに登録する動線がない

"JAL Apple Wallet"で検索

【iPhoneをご利用の場合】

「iPhoneを使用すべき」と判断

ページがわからない？トップページからたどるべき

考察

僕「難しすぎる、必要な番号がメールに書いてないの意味不明、開くべきページがあるならメールに記載すべきなのに、なんでトップページからたどる必要があるの」

妻「何が難しいのかわからない。予約してメールで送られてくるシステムは遥か昔につくられて、Apple Walletが使えるようになったのは最近、なのでシステムが論理的に考えて最適な構造になっていることを期待しては行けない」

僕「なるほどー」

二人ともシステムがどう設計されているべきかの理想状態の認識は共通しているが、妻はそれに加えて「世の中のシステムは往々にしてそうなってない、仕方ない」という諦めの気持ちがある

僕「世の中のシステムがうまく構成されていない時に、トップページから辿ろうとするのはなぜなのか？」

妻「トップページからはどんなに遠くてもつながっていると思っている」

僕「その感覚は階層的整理を好んで、Scrapboxを好まないことと関連があるかもしれない」

妻「本には目次があるじゃないか、そのツリーをメンテすることが次善のデザイン」

すべてのページから適切なページへのリンクがあるのが理想だが、現実的にはそのメンテナンスコストは支出できない

理想では、ユーザの支払いコストはO(1)だが、提供側は新しい追加のたびにそれに関するページをすべて更新しなければならない

そこでO(1)でツリーに追加する

ツリーがうまく構成されているならユーザはO(logN)でアクセスできる

アクセスできないよりはまし

「ツリーがうまく構成されているなら」はしばしば失敗する

特に事前に構造があまり明確に決まってないものを言語化する時には

なので個人の知識管理ツールとして考えたときにはScrapbox的アプローチがツリー的アプローチに勝つ