Top▲
マーリンアームズ サポート   翻訳   コンサル   講座   アプリ   コラム

インタフェースデザインのお約束 —— 優れたUXを実現するための101のルール

Will Grant著   武舎広幸＋武舎るみ訳

★News★ 『実践 JavaScript！ プログラミングを楽しみながら しっかり身につける』（武舎広幸著、オーム社）出版   →詳細   →Amazon

オライリー・ジャパンのページでこのページ（訳者あとがき）のPDF版が公開されております。

訳者あとがき

「どうやら俺は、何かの欠点や問題点を見つけるのが得意らしい」。ある時からこう思うようになったが、本書を読んで、原著者も同類なのではないかと感じた。

こちらに悪意はなく、「こうすれば、もっとよくなるのに」と感じて、それを伝えるだけなのだが、反感を買ってしまうこともある（特に夫婦喧嘩のネタには困らない）。まあ「的確なご指摘をいただいた」と喜ばれることもたまにはあるが。

というわけで、この長すぎる「訳者あとがき」では、原著者があげなかった「ルール」を追加させていただくことにした。日本語が絡むものは原著者には無理なので、そうしたものを中心に（と思ったのだが、最終的には必ずしもそうならなかった）。

原著者は001から始めて101まで書いているが、訳者は201から始めさせていただく。102から200までの「ルール」は読者諸氏に埋めていただければ幸いだ。本書のサポートページ（https://musha.com/sc/101/）からご提案をお送りいただけば、訳者がまとめて、ウェブページに（あるいは本書の『続編』で！）公開して差し上げられるかもしれない（どれくらいの方がお寄せくださるかわからないが、その努力をすることはお約束する。本書がベストセラーになってくれれば、その余裕もできるだろうが(^_^)）。

いつものように、オライリー・ジャパンの皆様には大変お世話になった。とくに今回は、興味深い本の翻訳の機会を与えてくださっただけでなく、訳者のわがままな提案を受け入れてくださり、訳者が日頃感じていることを吐露する機会まで提供してくださった。感謝に堪えない。

それでは、次ページ以降で、訳者が常日頃思っている追加の「ルール」を提案する。訳者のツッコミに対するツッコミは大歓迎だ。議論を重ねて、さらに使いやすいものを追求していこうではないか。

2019年9月
訳者代表
マーリンアームズ株式会社 武舎 広幸

追加のルール　目次

201　文字情報は画像ではなくテキストで
202　パスワードを定期的に変更させるのはやめよう
203　「桁区切りのカンマ不要」「数字は全角で」は開発者の怠慢では？
204　メニュー項目はユーザーが見つけやすいよう分類しよう
205　英語として意味のとおらないカタカナ語を使うのはやめよう
206　重要な操作をしようとしたら、アプリをアップデートしなければならないのは最悪
207　インタフェースをコロコロ変えるのはやめよう
208　漢字は東アジア公認のアイコンセット？

201　文字情報は画像ではなくテキストで

会社名や店名、電話番号、住所などをコピペ（コピーしてペースト）して「住所録に登録したい」「メールやSNSにペーストして送りたい」と思っても、画像になっていてコピペできないことがある。スタイル指定やウェブフォントなどを使えば、見映えのする文字を、コピペ可能にするのは難しくない。

たとえば、ある政府機関が運営しているサイトの例（図1）だが、電話番号をコピペしてカレンダーソフトに記入しようと思っても、コピーができないのだ（月曜の受付時間になったら電話をかけようと思ったのに...）。なぜこんな情報をわざわざ画像にしてこのページに置くのだろうか。非常にユーザーアンフレンドリーなサイトと言わざるをえない。

図1: 携帯から電話をかけたり、住所録やカレンダーに登録しようと思っても、文字情報が全部画像になっているのでコピー・ペーストができない。なお、その後再度アクセスして気がついたのだが、画像の上にある「○○ダイアル」（0570-XX-XXXX）の部分はテキストだった。このテキストのコピー・ペーストは可能だ（だが、私のように気がつかない人もいるだろうから、下の画像を大きな文字にしておくほうが単純だしわかりやすいだろう）。

お店の名前や住所を「メモ」アプリや「住所録」アプリにコピペしたいことはよくあるのだが、多くの店が、見映えだけを重視して店名を画像で示したりしている。見映えのするロゴの隣に、コピペしやすいテキストを置いてくれると、その店の株はグッと上がると思うのだが、いかがだろうか。

文字認識機能をウェブブラウザに組み込むのは？

テキスト情報が画像になってしまっていて、コピー・ペーストができないページが既に大量に存在していることを考慮すると、そして（本書が爆発的に売れでもしない限り）そのようなページが今後も増え続けるであろうことを考えると、ウェブブラウザが対応してくれると助かる。

画像内の文字を認識して、透明なテキストのレイヤーを画像内の文字の上に載せ、テキストをコピーできるようにするのだ。それほど難しい技術ではなさそうに思える。この機能を組み込んだら市場シェアが少しは上がるかもしれない。

ポイント

その後（2022年6月27日追記）

Appleの2021年ののWWDCで、Safariの画像を文字認識してくれる機能が発表された。 筆者がこの原稿を書く前から考えていたんでしょうね...。
macOS Monterey（12.x）で、Safariやプレビューで使えるようになった。 ［システム環境設定］→［言語と地域］で、「テキスト認識表示」にチェックを入れれば使えます。日本語はサポート外のようだが、中国語はサポートされており漢字（や英数字）は認識されるので、十分使える。
iPhone/iPadでもできるようだ（私はモバイルでこの機能を使うことは多くなさそうなので、まだ試していない）

202　パスワードを定期的に変更させるのはやめよう

「有効ではない」との意見が少なくとも専門家の間では主流になっているにもかかわらず、相変わらずサービスを利用するためのパスワードを定期的に変更させるサイトが少なくない。ユーザーの時間を浪費している悪習である。

たとえば総務省のサイトでは、「パスワードを定期的に変更させても、安全にはならない」と明確に記載している*1（図2）。

[*1] http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/privacy/01-2.html
このページは「国民のための情報セキュリティサイト」というタイトルが付いている。にもかかわらず2019年9月現在、URLはhttpsで始まっていない。メジャーなブラウザから接続を拒否される日も近いかもしれない...。
（2022年6月8日追記）その後httpsに対応した（メデタシ、メデタシ）。

総務省のページでも「パスワードを定期的変更」は非推奨と書かれている

図2: 総務省のページでも「パスワードを定期的変更」は非推奨と書かれている

また新聞社のサイトにも同様の趣旨の記事*2が掲載されている（図3）。

[*2] https://www.nikkei.com/article/DGXMZO05876050Z00C16A8000000/

同じ趣旨の内容の新聞社のページ（日本経済新聞。2016年8月の記事）

図3: 同じ趣旨の内容の新聞社のページ（日本経済新聞。2016年8月の記事）

訳者は、実は以前から「なぜ定期的にパスワードを変更しなければならないのか」疑問に感じていた。パスワードを変えることでセキュリティがなぜ向上するのかその理由が見つからなかったのだ。

よりセキュリティの高いものに（定期的に？）変更するのならば話はわかる。たとえば、今よりも長いもの、今よりも文字種が多いものに必ず変えなければいけないのならば、変えることでセキュリティの向上は期待できる（そんなサイト、誰も使わなくなりそうだが）。

しかし、単にパスワードを変えるだけで、なぜセキュリティが強化されるのか。たとえば、lmnからopqに変えたところで、偶然マッチしてしまう確率はまったく変わらない。変えたからといって、安全になる保証は何もない。図2で指摘されているように「パターン化してしまう」のが関の山だろう。

それに「パスワードを変えるという行為」自体が、「悪意をもった他人にパスワードを知られてしまう危険を高める行為」なのではないかとも感じていた。こじつけ的なものも含め、思いつく理由をあげてみる。

さて、総務省のサイトに明確に「パスワードの定期的な変更は不要」と書かれているのだから、少なくとも政府機関が運営しているサイトは、この指針に従っているはずだと思いたいところだが、残念ながらそうはなっていない。2019年9月に訳者がアクセスした、ある政府機関のサイトには図4のような警告が相変わらず表示されている。もちろん訳者は無視している。

ある政府機関のサイトの警告

図4: ある政府機関のサイトの警告

パスワードの再設定には数分程度は時間がかかる。新しいパスワードを決めなければならないというのは心理的にも負担の軽い作業ではない。顧客に余分な時間と労力を費やしてもらうのに十分な根拠があるかを検討もせずに、単に「ほかの会社（組織）がそうしているから」という理由だけで定期的な更新を依頼していた組織が多いのではないだろうか。ユーザーの立場になって、自分たちの頭を使って、本当に使いやすいシステムを構築してほしいものだ。

パスワードリセットのリクエストが行われただけでパスワードを変える必要はないのでは？

同じような疑問を抱かせるのが、「パスワードリセットのリクエストが行われたので、パスワードを変えろ」という連絡だ。たとえば、誰かが訳者のアカウントに不正に（あるいは誤って）アクセスしようとして、パスワードリセットのリクエストを行うと図5のようなメールが届くことがある。

パスワードリセットのリクエストが行われた旨を知らせるメール

図5: パスワードリセットのリクエストが行われた旨を知らせるメール

この文面に従えば、自分がパスワードリセットのリクエストを行っていなくても、パスワードを変えなければならない。

だが、（悪意をもった）誰かがパスワードリセットのリクエストを行ったということは、アカウントへの侵入に失敗したことを意味する。つまりパスワードがその役目を果たしたということだ。

役目を果たしているものを変える必要はないではないか。先ほどの例とまったく同じ理由で、パスワードを変えただけでは破られやすさは変わらない。

この疑問をサポートに送ってみたのだが、返事は来たものの、内容はトンチンカンとしか言いようのないものであった（図6）。訳者の疑問にはまったく答えてくれていないのだ。

疑問に対する返信は届いたが、内容は...

図6: 疑問に対する返信は届いたが、内容は...

ポイント

その後（2022年6月8日追記）

「国民のための情報セキュリティサイト」はその後、httpsに対応した。この文章がきっかけになったのなら、書いた意味は少しはあったかも(^_^)。 なお、「国民のための情報セキュリティサイト」は全面刷新し、新ページが公開された—— 刷新後の「安全なパスワードの設定について」はこちら

203　「桁区切りのカンマ不要」「数字は全角で」は開発者の怠慢では？

ウェブページで金額や住所の番地など、数字を入力しなければならないことは多い。その典型とも言えるのが金融機関のサイトだろう。

そうしたサイトで「数字は半角でカンマ区切りなしで」とか「住所の数字は全角で」などと指定されることが多い。ユーザーにとっては面倒な話だ。

ひとつ例を見てみよう（図7）。ある証券会社の投資信託の買付（購入）のページで購入金額を入力しようとしているところだ。制限いっぱいの金額を購入したいので、すぐ下にある「買付可能最大額」をコピー・ペーストして「985,000」と入力した。

図7: すぐ下にある金額（985,000）を入力したいので、コピー・ペーストしたくなるのが人情というものだ

ところがこれで［送信］ボタンを押すと図8のようなエラーメッセージが表示されてしまう。

図8: 金額をコピー・ペーストするとトンチンカンなものを含むエラーメッセージが3つも表示された

どうやら「985,000」を数字とは解釈してくれなかったようだ。エラーメッセージもトンチンカンに思える。「0より大きい数値を入力しているぞ！」「金額は整数だぞ！」とツッコミを入れたくなる。

システム側で「買付可能最大額」を「985,000円」と表示しているので、システムは「985,000」を「額」として扱っているということを意味している。「額」ならば「数字」として扱ってくれるのが当然というものでないだろうか。少なくともユーザーがそう思っても不思議はないように感じる。

なぜ、単に「,」を削除するだけの処理をしてみないのだろうか。多くのプログラミング言語では関数をひとつ呼べば済むだけの話だ。訳者には開発者の怠慢に思える。

それともセキュリティ上なにか問題があるというのだろうか。このあと確認画面が出るのだから、その危険性があるようには思えない。文字列を評価（eval）する必要はない。3桁ごとの「,」があれば削除するだけの話だ。訳者の経験ではほとんどの日本語サイトがこのような処理をしている。ユーザーに時間の無駄を強いる悪習だと思うのだが、いかがだろうか。

電話番号の入力についても同じような問題がある。電話番号について「ハイフン『-』は不要」などと書かれているページがあるが、これも開発者の都合ではないだろうか。「-」を書いてはいけないとなると、手入力時の確認が大変だ。コピー・ペーストしたなら、いちいち「-」を消さなければならない。どちらもユーザーの手間を増やす、「痒いところに手が届かない」システムになっている。

クレジットカードについても同様だ。システムの立場からすれば余計なスペースは不要かもしれないが、入力を確認するユーザーの立場になってほしい。スペースがないと、何桁目まで確認が済んだのか覚えにくい。照合がとても大変になるのだ。

こういったページの開発者は自分で電話番号やクレジットカード番号を入力した経験はないのだろうか。いや、ほとんどの開発者は経験があるはずだ。「自分の体験」を「ユーザーの体験」として見ていないのではないだろうか。本書の原著者も繰り返し書いているが、「共感力」の欠如が疑われる。

「ほかのシステムも同じだから、これでいいや」「『ほかのサイトがみんなこうですから、これでいいと思います』と上司に言い訳ができるから、大丈夫」とばかり、従来のコードを使い回しているのかもしれないが。

ポイント

204　メニュー項目はユーザーが見つけやすいよう分類しよう

論理的に意味のある位置にメニュー項目を置くのは当たり前のことだと思うのだが、気になる例が結構簡単に見つかる。

あるサイトで登録住所の変更をしようとした時のことだ。ページ下部にあったナビゲーション用のメニューを見たら、「登録情報の変更/サポート」という項目が見つかった（図9）。99%（100%？）のユーザーは、この下位項目に「住所変更」があると考えるだろう。

だが、その下位項目には「住所変更」がない。「登録情報の変更/サポート」の下位にあるメニュー項目を行ったり来たり、数分（以上？）費やしたが見つからない。

あるページのナビゲーションメニュー。「登録情報の変更」の下に、住所変更がない！

図9: あるページのナビゲーションメニュー。「登録情報の変更」の下に、住所変更がない！

仕方がないのでFAQを探してみたところ、「ご利用状況の確認」の「お客様情報照会」にある「編集」ボタンを押せと書いてある。「照会」は「変更」ではないだろう。

ともかく、「お客様情報照会」を選択してみると、そのタイトルが「お客さま情報の照会／変更」となっているではないか（図10）。

「お客様情報照会」を選択して表示されたページ。タイトルが「お客様情報の照会／変更」となっている。「照会」をクリックすることで「変更」ができると思うユーザーは何人いるだろう？

図10: 「お客様情報照会」を選択して表示されたページ。タイトルが「お客様情報の照会／変更」となっている。「照会」をクリックすることで「変更」ができると思うユーザーは何人いるだろう？

「このメニューを作ったヤツは、いったい何、考えてるんだ」と独りブツブツ言いつつ、「お客様情報」の［変更］ボタンを選択して住所変更を無事終えることができた。

「登録情報の変更/サポート」の下に「お客様情報照会・変更」というメニューを載せておいてくれれば、無駄な時間を費やさずに済んだのに*3。

[*3] とてもわかりやすいサンプルを提供していただいたことになったので、訳者にとっては悪いことばかりではなかったが...。

ともあれ、ツッコミどころ満載のサイトではある。ちょっと考えただけでも、次のようなものが見つかった。

2019年5月にこのサイトの「お問い合わせページ」から上記の問題のうちいくつかを指摘してみたのだが、2019年8月現在、メニュー項目の構成は（まったく？）変わっていない。

メニュー項目の並び替えに2ヵ月以上もかかるのだろうか。せめて住所変更だけでも右側の「登録情報の変更/サポート」の下に入れてほしいと思うのだが...。「お金を払ってくれるお客様から、毎日毎日、無駄な時間を盗み続けている罪深いサイトだ」と思ってしまったユーザーが、果たしてこのサービスを利用し続けてくれるかどうか*4。

[*4] 2019年10月になって同じページにアクセスしたところ、ようやくメニュー構成が変更され住所変更が簡単にできるようになっていた。しかし、メニュー構成の変更に約半年かかるというのは遅すぎるのではないだろうか （新しいメニュー構成はこちら）

書籍サイトの分類はメチャメチャなところが多い？

ショッピングサイトの本の分類も気になる。

あるサイトでオライリー発行の『JavaScript 第6版』を検索してページを見たら、「プログラミング」の下の「java」の下位項目になっていた（図11）。開発者ならご存じだろうが、JavaとJavaScriptはまったく別の言語だ。それに、javaではなくJavaと表記してほしいところだ。

JavaScriptの本がjavaの下位項目となっているのは困る

図11: JavaScriptの本がjavaの下位項目となっているのは困る

もう1冊、JavaScriptの本を検索して見たら図12のように表示された。この本は「ネットワーク・通信」の下位項目の「ネットワーク・通信」の分類のようだ。

こちらの分類は間違いとは言えないだろう。確かに、JavaScriptは「ネットワーク・通信」でも使われる。しかし、類似の内容の本が、まったく違った分類になっているのは困りものだ*5。

同じサイトで、JavaScriptに関する別の本が「ネットワーク・通信」に分類されている

図12: 同じサイトで、JavaScriptに関する別の本が「ネットワーク・通信」に分類されている

[*5] 実は、訳者が「ご要望ページ」から「『初めてのJavaScript』の分類を変えてくれ〜」と依頼した結果、こう変わったのだ（対応はすごく早かった）。すべてのJavaScirpt本に関して同様の要望を出せば、不当なるjavaの支配下からJavaScript本を解放してやれる日が到来することになるだろう。

ものはついでとばかりに、あと2つ別のサイトで、1冊目の本を検索してみた結果が図13と図14だ。

2番目のサイトでは「Java」に分類されていた。「java」でないだけマシではあるが...

図13: 2番目のサイトでは「Java」に分類されていた。「java」でないだけマシではあるが...

3番目のサイトでは「プログラミング」に分類されていた。細かくはないが妥当と言える

図14: 3番目のサイトでは「プログラミング」に分類されていた。細かくはないが妥当と言える

分類がメチャクチャだと「このショップは、内容については無関心な人が作っているな〜」という印象をもたれてしまうこと必至だろう。「安くてすぐ届く」ほうがユーザーにとっては重要かもしれないが、「わかっている人が作っている、きちんとしたサイトから買いたい」というユーザーも少なくないと思うのだが、皆さんはいかがだろう。A書店で、自分の訳書（一応、数十冊ある）が置かれている位置に感動して、ほぼその書店でしか本を買わなくなってしまった訳者のような例もある（並びがゴチャゴチャな大型書店Bには、もう10年以上入っていないかもしれない）。

ポイント

205　英語として意味のとおらないカタカナ語を使うのはやめよう

訳者は確定申告を毎年ウェブ経由で行っているが、お役所の収入（我々が払う税金）に直接影響するためだろうか、訳者が今までに利用したことのある官公庁のサイトの中では、群を抜いて使いやすいと思う（図15）。

確定申告書等作成コーナーのトップページ。ボタンにはわかりやすい説明が付いているので、迷うことなく選択ができる

図15: 確定申告書等作成コーナーのトップページ。ボタンにはわかりやすい説明が付いているので、迷うことなく選択ができる

馴染みのない用語はひとつもなく、読めば何ができるのかがすぐにわかる。「ご利用ガイド」も用意されているが、訳者は一度も読んだことはない。それでも何の苦もなく使えてしまう。

たとえば、源泉徴収票とか証券会社から届いた取引の証明書とか、自分の手元にある書類と同じようなイメージのフォームが表示されて、書類に書かれているとおりに入力していくと、申告書が少しずつ完成していく（図16）。心地よいほどに明解だ。税金のことゆえ、ややこしい部分ももちろんあるのだが、それはシステムの問題というより、税制の問題だろう。

図16: 源泉徴収票のイメージが表示されて、どの欄の数値をフォームのどこに記入すればよいかが簡単にわかる

官公庁のサイトだと以前は「macOSはダメ」というところが多かったが、確定申告のサイトは最新のmacOSまで対応しているし、WindowsでもFirefoxやGoogle Chromeなどサードパーティのブラウザにも対応している。

どの官公庁サイトもこれくらい頑張ってくれるとうれしいのだが、なかなかそうはなっていないのが残念だ。この項では、英語由来の用語に絞って検討してみよう。

パーソナライズログインとは？

ある手続きの電子申請をしたくてリンクをたどっていたら図17のページにたどり着いた。

パーソナライズとはなんぞや？

図17: パーソナライズとはなんぞや？

「パーソナライズログイン」「パーソナライズの開設」「パーソナライズパスワード」といったリンクが並んでいるのだが、このリンクを見てこの日本語（英語？）の意味がわかる人が何人いるだろうか。確定申告のサイトとは大違いである。

「パーソナライズログイン」は "personalize login" ということなのだろうか。loginをpersonalizeするとはどういうことなのか。personalizeはどう見ても動詞にしか見えない。「個人化する」つまり「個人的なものにする」といった意味だろうか。「ログイン」を「パーソナライズ」するとはどういうことなのか。ログインなんてそもそもが個人的なものではないのか。

などと考えているうちに、このサイトを利用する気が失せてきた。

いちいち用語の説明を読んで、多分英語ができない開発者が考えた意味を理解して、あえて電子申請をしたいほど暇な人はそうはいない。

電子申請が必須のケースなぞめったにない。なぜ電子申請をしようと思ったかというと、手間が省けると思ったからだ。逆に手間が増えてしまうのに、電子申請をする気にはなれない。

世の中で広く使われているカタカナ語なら使うのもやむをえないだろう。たとえばログイン、ログアウト、ダウンロードなどの用語は、ほぼ100%のインターネット利用者が知っている。

どうしても新しい用語を作らなければならないのなら、そして英語をカタカナにして使わなければならないのなら、英語として筋の通る用語を使ってほしい。英語として正しいかを複数のネイティブスピーカーにチェックしてもらうのも当然だろう（できれば3人以上で、言葉の専門家を含むのが望ましい）。

これが一般企業のサイトなら短期間で閉鎖に追い込まれそうだが、このサイトは利用者が増えなくても閉鎖されることはない。我々の税金が継続して投入されていくのみである。

まあ、電子申請が必須で、必ずこのサイトを利用するという方々もいらっしゃるかもしれないので、そう断言するのは少し乱暴かもしれないが、少なくとも訳者のような潜在的ユーザーを着実に失い続けている。

「メインへスキップ」とは？

ある日、なぜかは忘れたが、ある議会のページに到達した（図18）。

目についたのが「○○院」というタイトルのすぐ右にある「メインへスキップ」というリンクだ。

何の意味かわからなかったが、ひとまずクリックしてみると、ナビゲーション部分が隠れて「本会議開会情報」が一番上に表示された。

これでも意味がよくわからなかったが、リンクをたどって何ページか見てみても、必ず一番上に「メインへスキップ」というリンクがあり、そこをクリックすると少し下にスクロールしてナビゲーション部分が隠れるようだ。

どうやら、「ナビゲーション部分を飛ばして本文へ移動する」というの意味で「メインへスキップ」という言葉を使っているらしい。読み上げソフトを利用している人のためのリンクのようだ。「本文へ進む」などといった日本語のほうがずっとわかりやすいのではないだろうか。なぜ、「メイン」「スキップ」などという表現を使う必要があるのか。

図18: ある議会のトップページ

音声読み上げに対応するという姿勢ははすばらしいが、このページには視覚障害のない人も当然アクセスする（というか、そういう人のほうが圧倒的に多いだろう）。そんな人が戸惑うようなリンクを置かないでほしいものだ。「086 読み上げ機能に配慮して［本文へ進む］のリンクを追加せよ」にあるCSSを使えば、視覚障害のない人には無用なリンクは表示させずに済むのだから、そういった工夫をしてほしい。

英語をカタカナにするなら、英語の発音に近い表記にしよう

その昔、日本の鎖国が終わって外国の言葉が入ってきた。

縫い物をするための機械はまだ日本には存在していなかったので、新しい単語を作るしかない。そこで、sewing machineのmachineから「ミシン」という言葉ができたのだそうだ。

その昔、大型コンピュータ（大型機）ではアルファベットの大文字しか表示・印刷ができなかった。だから警告のメッセージは「WARNING」と表示されていた。これを「ワーニング」と読んだ開発者が多かったらしく、訳者が最初に就職した会社の先輩も「ワーニング」とおっしゃっていた。

訳者が「ワーニングってなんですか？ ヒョッとして、ウォーニングですか？」と言ったら、しばし沈黙の時間があったことを記憶している。その後の先輩の反応は忘れてしまったが。

そして、現在。漢字も含め世界中の文字が表示も印字もできる時代になっても、警告メッセージは相変わらずWarningと表示されている。一時期、開発者向けシステムのメッセージを日本語に翻訳していたアプリケーションも存在したが、現在はほとんどのメッセージは英語のまま表示される。バージョンアップのたびに訳している時間がないのである。

多くのIT技術者は多かれ少なかれ英語と付き合わなければならない。そして、英語ができたほうがはるかに便利なのだ。情報を入手するのも簡単だし、プログラミングをするなら変数や関数などの名前（識別子）を考えるにも、他人のプログラムを読むのも英語ができたほうが効率がよかろう。最近の言語では識別子には日本語も使えるようにはなってきてはいるものの、英語ベースの識別子のほうが圧倒的に多く使われている。

一般の人が、award（賞）を「アワード」、reward（報酬）を「リワード」、feature（特徴、〜を特徴とする）を「フューチャー」と読むのは、とやかく言っても「多勢に無勢」的なところがあるので、（ある程度は）諦めるしかないようだ。しかし、自分がIT関連の技術者だと思うのならば、自分の価値を高めるためにも、「通じる英語」を身につけようではないか。

そのためには発音にもこだわろう。「フューチャー」では英語が母国語でない外国人にはfuture（未来）しか思い浮かばないだろう（ちなみに、futureに動詞はないようなので、時々耳にする「フューチャリン（グ）」と読む英単語は存在しないのではないかと思う）。まあ、[fíːtʃǝr]と「フィーチャー」は違うと言えば違うのだが、「フューチャー」よりはだいぶ近いので、ネイティブスピーカーや英語ができるノンネイティブスピーカーに意味が通じる可能性も高まるだろう。

顧客の原稿に文句をつけるわけにはいかないだろうが、映画関係者から依頼されたサイトの原稿に「●●アワード発表」という表現があったとしたら、「石原さとみさんが受賞したのは『東京ドラマアウォード』で、アワードとはなってませんが、『●●アウォード発表』に変えなくてもよろしいのですね？」とお伺いを立ててみるのも、悪くないかもしれない。

ポイント

206　重要な操作をしようとしたら、アプリをアップデートしなければならないのは最悪

ある日、外出先でノートパソコンから銀行振込をしようとした。「ワンタイムパスワード」を入れる必要があるので、そのためのスマフォのアプリを起動した。ところが「アプリをアップデートしないと使えません」と表示され、振込ができなかった。

ワンタイムパスワードの入力ぐらい、アップデートしなくても（ひとつ前のバージョンでも）できるように作るのが当たり前ではないだろうか。この時はそれほど急いではいなかったのでよかったが、一刻を争うものだったら大ごとだった。

「いっそのこと、銀行変えたろか」

何年か前に、スマフォをアップデートした時にもワンタイムパスワードの生成アプリが使えなくなってしまったことがあった。古いアプリがスマフォの新機種に対応していなかったのが原因だった。ウェブを検索したら、書類を介した手続きが必要だとわかって、仕方がないので、カミさんの口座から振り込ませてもらった。

銀行アプリで、機種依存のことをする必要があるのか大いに疑問なのだが、なぜか新機種に変えると動かなくなることが多い（OSの提供元が、新バージョンで新しい仕様に対応するよう求めてきている可能性もあるかもしれないので、必ずしも銀行のせいではないかもしれないが）。

アプリ利用者には1週間以上前にメールで「○月○日以降、××銀行アプリからお振込になるには、アプリの新版（x.y.z）へのバージョンアップが必要です。お早めにダウンロードをお願いいたします」と知らせることが必須だと思うのだ。数日たっても新版のアプリを起動していなかったら、もう一度メールで連絡してくれれば確実だろう。

最近の若者の行動を見ると、アプリの使いやすさで、色々なものが選ばれる時代になってきているような気がする。IT系企業に限らず、開発者の技術力が、組織の命運を左右する時代が来たのかもしれない。

ポイント

207　インタフェースをコロコロ変えるのはやめよう

地図や予定表などユーザーが頻繁に利用するアプリのUIが変わってしまって戸惑うことが少なくない。馴染んだ使い方を変えなければならないのはユーザーにとっては大きな負担だ。とくに年齢が上がれば上がるほど変化に対して感じるストレスは大きくなる。とてつもなく重要な理由があるのでない限り、頻繁に使う機能のUIは変えないでほしいというのが、多くのユーザーの願いだろう。

2018年10月のこと。スマフォでいつも使っている予定表アプリにイベントを加えようとして目を疑ったことがあった。［＋］→［予定］とタップして、［終日］の予定であることを示すスイッチをオンにした時に、「タイトル」の選択肢として図19の項目が表示されたのだ。それまでは、単に予定を記入するだけだったが、なぜか10個ほどの選択肢が表示されるようになった。

この画面で、「タイトル、時間、参加者、場所を入力」の欄を何度タップしても文字が入力できない。「歯医者」とか「散髪」とか「マッサージ」とか、それほど頻度が高くなさそうな選択肢を選べるだけなのだ。

「母の誕生日」を予定表に改めて入力する機会はあるのだろうか。入力するなら大昔に入力してるはずだし、母親の誕生日なんて予定表に入れなくたって覚えている。第一、訳者の母親はもう彼岸へ旅立ってしまった。だから今さら母親の誕生日を入力する機会はない。

『この選択肢考えたヤツは、ナニ考えてるんだ？ それともお得意のAIにやらせてるんか？ 俺の年齢を（勝手に）推測しているのか』とも思ったが、それなら「休校」は何だろうか。

実は、ここで［終日］のスイッチをオフにすれば普通に自分が入れたいフレーズを入力できたのだが、それに気がつくまでに、5分以上は経過していた。これに気がつかない限り、自分の入れたいタイトルは入力できず、［×］をタップして、この画面を抜けるしかなかった（カミさんも同じ状況になり、「結局スマフォでの入力は諦めた」とのことだ）。

予定表アプリで表示された「タイトル」の選択肢（その時の画像は低解像度のものしか残っていないので、文字部分を書き直した）

図19: 予定表アプリで表示された「タイトル」の選択肢（その時の画像は低解像度のものしか残っていないので、文字部分を書き直した）

もともと出先で予定を追加することは少ないのでこの機能を使う頻度は高くない。しばらくしてやってみた時には、意味不明の選択肢はさすがに表示されなくなっていたが、バグとしか思えないような「仕様変更」を施したバージョンが、品質管理のハードルを飛び越えて一般に公開されてしまったようだ。

全世界で何百万人、何千万人も利用者がいるであろうアプリであってもこの種の出来事が起こるのだからユーザーは安心できない。「こんな機能入れたんだから使ってもらわなくちゃ」という開発者のエゴのほうが勝ってしまった結果ではないのかと疑いたくなる（「092 デフォルト設定を過小評価するな」も参照）。

本当にユーザーのことを第一に考えているのか。自分たちの都合を優先しているのではないのか。

まったく別のアプリケーションを同じ名前にするのはいかがなものか

数年前のこと、あるOSに標準で付いてくる動画編集用のアプリケーションのインタフェースがまったく別物に変わってしまった。

図20は数年前まで使われていた旧バージョン（旧版）で、図21が新バージョン（新版）だ。

ある動画編集用アプリケーションの旧版

図20: ある動画編集用アプリケーションの旧版

同じ名前の動画編集用アプリケーションの新版

図21: 同じ名前の動画編集用アプリケーションの新版

見た目も大きく変わったが、なにより作業手順も使い方も、根本の思想とでもいうべきものも大きく異なる、「共通点はムービーの編集という目的だけ」と言ってもよいような、まったく別のアプリだ。

訳者は何年ものあいだ、新版を使う気になれなかった。旧版は直感的でわかりやすく機能的にも十分で、変える理由がなかったのだ。マニュアルなんて全然見ないでスイスイ編集できた。すばらしいインタフェースだった。

姪の結婚式のDVDを作って発売されたばかりのタブレットで再生し、知人に見せたりしたのも懐かしい思い出だ。

しかし旧版は標準では提供されなくなり、まったく違うインタフェースをもった（同じ名を冠した）別アプリが登場した。そしてしばらくして、旧版は起動もできなくなってしまった*6。

[*6] 今でも古いマシンの別「パーティション」に保存してある古いOSで起動すると、旧版を使うことはできる。だが、このためだけに再起動してOSを切り替える気にはなれないし、セキュリティ上の問題もありそうだ。もっとも、図20はこの方法を使って「キャプチャ」したものだ。

訳者は「旧版が使えないビデオ編集」をヤル気が起こらず、しばらくの間、動画再生ソフトでムービーを「トリム」する以外、動画には触らなくなってしまった。

ここに来て、仕事でビデオ編集が必要になったので、仕方なく新版を使ってみた。マニュアルを読むのは嫌いなので、試行錯誤していろいろ試していたら、そこそこ使えるようになった。しかし、旧版に比べると、ひとまず使えるようになるまで3倍ぐらいの時間はかかったような気がする。

何年もバージョンアップを重ねると、新機能の追加が徐々に困難になるのは理解できる。しかし、主要な機能を使えなくしたり、大幅にインタフェースを変えたりするのは避けてほしいものだ。少なくとも、基本的な使い方は、「前と同じにもできます」と謳（うた）ってほしい。

「俺は若いから平気さ。どんどん便利に変えてほしいね」というあなたへ。誰もが歳をとることを、お忘れなく。ユーザーへの共感なくしてよい製品はできない。

どんなに大きな企業が作ったどんなにユーザーの多いアプリであっても、信じられないバグが混じり込んだり、あり得ないと思うような仕様変更が行われる場合があることは歴史が証明している。ユーザーは常に疑いの目をもち、心の準備をしておこう。決して安心しないことだ。

自分が使いたいアプリをできるだけ長く使えるよう、できる限りの対策を立てよう。もっとも、最近の「自動アップデート」の潮流に逆らうにはかなりの労力が必要なので、諦めるしかないのかもしれないが...。

ポイント

208　漢字は東アジア公認のアイコンセット？

書籍の翻訳を始めてしばらくした頃、外資系出版社の招待でその会社の米国、中国、台湾、フィリピン、インドネシアなどにある支社の方々が集まる会議に参加したことがあった。開催地はシンガポールで会議の「公用語」は英語だったが、参加者の多くは漢字の読み書きができた。

中国からの参加者の中に「武（ウー）」さんという男性がいた（奥さんは別の姓だったような気がする）。訳者の姓は武舎なので、「同じ漢字だね」としばし盛り上がった。「武」は戦いを連想する漢字だけれど、「戈（ほこ）（武器の一種）を止（と）めること」つまり「戦いを止（や）めること」を意味するんだよと、この漢字の成り立ちを武さんが教えてくれた*7。

[*7] もうひとつ「戈を持って歩く」という意味だという説もあり、そちらのほうが有力なようだ。ただ、今の時代には武さんの解釈のほうがふさわしいような気もする。詳しくは次のページなどを参照——https://www.kanjicafe.jp/detail/6559.html

原著者が「019 絵文字は世界公認のアイコンセット」に書いているように、絵文字はアイコンとして使える。それぞれがものや動作、感情などを表しており、ユーザーに意味や意図を伝えられるからだ。

漢字も意味をもっている。だから、漢字文化圏の人たちとは筆談ができる（中国・台湾の人とは英語のように「主語+動詞+目的語」の語順にしたほうが通じやすいようだが、地域によって意味が異なる漢字がある点には要注意だ）。

そもそも漢字も元をたどれば「絵」から始まったものが多い。「笑」という字は、それ自体が笑っているようにも見えるし、田、川、山などは簡略化（抽象化）された「絵文字」に見える。

漢字文化圏の人ならば漢字の意味はわかる。だから、絵文字同様、漢字もアイコンセットと見なせるのではなかろうか。地の文と区別がつきにくくなるのが絵文字とは違うところだが、色や大きさ、囲みなどのスタイルを変えれば、この問題は解決できそうだ。

印刷が始まるまで文字は手で書かれていたので、簡略化（抽象化）され、絵としての細かさは削ぎ落とされていった。簡略化されたがゆえに、ある程度の時間をかけて覚えれば、誰でも手で書けるようになる。まれに、非常に画数が多くて誰も書けそうにない文字も存在はするが、ごく少数だ。

一方、絵文字を手で書く機会はまずない。コンピュータを使うことで、手で書けない「文字」を使って意思疎通できるようになったわけだ（ちなみに、絵文字は文字であるにもかかわらず多くの人は読み方を意識せずに使っているという特徴ももっている）。

非漢字文化圏の人々にとってはどうだろうか。漢字はアイコンセットになりうるのだろうか。

アルファベットや仮名などの表音文字は単独では意味をもたないので、綴りあるいは発音を覚えなければ、意思疎通には使えない。しかし漢字は形で覚えることができる。漢字の偏（へん）や旁（つくり）の意味を理解してもらえば、読めない漢字でも意味をある程度は理解してもらえそうだ。

日本語の世界に入るのに「まず漢字から」というアプローチはどうだろう。結構面白がる外国人がいそうな気もする。

ポイント