« September 2005 | Main | April 2006 »

無確定のすすめ

小指というのは薬指の第一関節くらいまでの長さがあるのが通常らしいです。私の場合、第一関節までは数mm足りません。道理でリコーダの穴を塞ぐのが難しい訳です。もっとも数mm長くてもo1ao3dを押さえる難しいので全体的に手が小さいのではないかという気もします。

小寺さんは横に長いReturnキーだと小指が短くても楽に届くということを書いていらっしゃいますが、これは横に長いから押しやすいということではありません。US配列なのでキー一つ分Returnキーが近いのです。「横に長いから届きやすい」と誤解されやすい文章に思えました。具体的にはJISキーボードで言う「む」のキーが無いためにReturnがキー一つ分近くなります。

さて、Returnキーは変換結果の確定のために多用するという話なのですがそれほど多用するのでしょうか。むしろ無確定というのはどうでしょうか。

今時の連文節変換IMEであればcannaで(setq renbun-continue nil)とした時のような動作(ってどんな?)ができるはずなので、変換操作中や候補一覧が表示されている時にわざわざ確定しなくてもそのまま入力を続けることができます。たまに、かな漢字変換の癖などによる誤変換を避けるためにひらがなで確定しておきたい、というような場合には(そして割とこのケースが多い)確定操作が必要になりますが毎回確定する必要はありません。と、ここまで書いて思いましたが、このくらいは普通におこなっているでしょう。

こうして確定操作を減らしたとしても「ここで改行」と思ったときには残念ながらReturnで確定して、もう一度押して改行というのがちょっと煩わしいところ。つまり、Returnキーが確定操作と改行の2つの役割を持っているのが不便の原因です。

後は仮名入力の宿命か、日本語とASCIIの切替えをするときには一度確定してからIMEをOFFにというのが面倒。(確定 IME/OFF)という一連の流れができれば便利です。これも変換キーが変換/次候補とIMEのON/OFFという2つの役割を持っているためです。

しかし、ローマ字入力であればそのままアルファベットや数字も入力できますから。IMEのON/OFFを繰り返す必然性はありません。改行に伴う確定も、Returnキーの定義を「確定した上で改行」というように設定すると解決します。つまり、確定する必要は無いのです。

というわけで私が確定操作をする理由も判ってきたのでこれを排除することを考えます。要は

  • 改行する際にReturnキーの挙動が確定になっているため、確定してしまう。
  • IMEをOFFにしたくても変換キーの挙動が変換になっているためモードを切替えために確定する必要がある。
  • Returnキーは確定した上で改行
  • 親指確定を採り入れて、無変換を確定+IME OFFに。

しかしJapanist 2002ではIME OFFというコマンドが無く、常にON/OFFのトグルしかできません。しかも確定とON/FFを同時に割り当てると先にIMEのON/OFFが発動してしまい変換候補が消失してしまいます。変換キーはIMEのON/OFF専用にしてスペースで次候補、無変換は確定とするのが限界の模様。確定してIME OFFというのが欲しいところです。

とりあえずemacsでは希望の動作をさせられるように設定できました。Returnで確定しないというのはなかなか新鮮というか意外と確定だけを行いたいということもあるので難しい所。「Returnで確定しない」という入力だと

  • 「Return」と入力
  • 「でかくてい」と入力して変換
  • 「で確定」と変換される可能性が低い

というわけで「で」の直後で確定したくなることが。無変換キーはIMEのOFFだけにしたほうが無難かもしれません。こうなると快適な日本語入力のためにはますますキーが必要ということでHHKではキーが圧倒的に足りなくなります。つい先日には「必要なのは漢字キーであって変換キーや無変換キーは不要」と書いたばかりですが。

| | Comments (53) | TrackBack (0)

どの口がそれをいうか

テレビ、雑誌、新聞、Web、blog。情報が掲載されているメディアがなんであるか、ということは情報の信頼性の基準とするべきではありません。Webに書いてあるから信頼できない、という人は同じ内容を紙に印刷したら信用してしまうのでしょうか。雑誌記事、新聞記事になっていたら信用してしまうのでしょうか。

雑誌記事、新聞記事になっているということはそれだけコストを掛けているということですからその分信頼できる、と考えることは可能です。逆に、「それだけのコストを掛けないと信頼性が得られない」という見方もできます。掲載メディアがなんであるか、ということと信頼できる情報であるか、ということは別の問題なのです。新聞や雑誌などのメディアであれば掲載、公表に至るまでに編集者のチェックが入るため安心、という主張もあります。この「編集者のチェック」というのは一般には誤った情報を取り除くためのフィルタと考えられます。目的はともかく、装置としてはただのフィルタです。情報の伝達経路にフィルタがあるから安心、というわけです。これも逆に考えるとフィルタがあるから安心できない、と考えることができます。本来受け取りたい情報であるにもかかわらずのフィルタが取り除いてしまうかもしれません。また、発信したい情報がフィルタによって取り除かれるかもしれません。フィルタを通すということは、生の信号では無くて加工済み、検閲済みの信号を得るということです。フィルタを通すということはフィルタによって変質させるということです。フィルタが信頼できない場合にはフィルタがあるから安心とは考えられません。

では、どういうところから得られた情報なら信頼できるのか。信頼できる「人」からの情報が信頼できるのです。伝達に用いられたメディアは関係ありません。社長がメールで「緊急・シークレット扱いで口座に入金するように」と指示するのと、内容証明郵便で、口頭で、手書きメモで、狼煙で、モールス信号で指示をするのとで信じたり信じなかったりするというのはおかしいです。

では、どういう人からの情報なら信頼に足るのか。これはなかなか難しい判断が必要で、お湯を掛けて3分というような訳にはいきません。信頼する、というは簡単です。自分で何も考えず言われたものを受け入れればよいのです。しかし、このような情報を鵜呑みにするという行為はリスクがありますし、そのような頭を使わない人に信頼されてもうれしくは無いでしょう。そのような考えの無い信頼には価値がありません。検証可能な情報を提供している、というのが一つのポイントになります。ある人が「1+1は2だ」と主張していたとして、その主張を信じるかどうか。この場合「1+1」という所まで開示していますからこちらで検証することができます。理屈の上では検証可能である、ということが重要で実際に検証できる能力があるかどうかは別問題です。「1+1くらいならともかく、耐震強度の検証だと実際に地震を起こして建物を壊さないと検証できなくなります。さて、これが「この問題の答えは2だ」という主張だと問題自体が提示されていないので検証することができません。何か隠しているということになるのでうかつに信頼する訳にはいきません。「100人のっても大丈夫」という主張は、実際に試すことができます。検証可能ですから信憑性は高いと考えられます。さらに深く考えると、嘘をつくメリット、嘘がばれたときのコストなどを考えたうえで真実である可能性を考える訳です。

「新聞記事ならともかく、Webに書いてあるようなたわごとを真に受けるなよ」という考え方があることは理解できます。新聞記事であればフィルタによって誤りが除去されているだろう、と判断することはそれほど不自然ではありません。しかし、書かれている内容の信頼性は書かれているメディアではなくて書いた「人」に強く依存していると私は考えます。

たとえば私の場合、仕事を進めてきた中で他の方が書いたプログラムに対して「このプログラムは間違っている」「これでは意図したようには動かない」と誤りを指摘することがあります。最初のうちは「どこが間違っているのか」と言われました。私からの情報だけでは信頼性が欠如していたためです。その度にシーケンスチャートなどの資料を作成し納得していただけるような解説、レビューを行ってきました。こうした活動を2年近く続けてきたいか、今では「このプログラムは間違っている」と言うとすぐに「どこが間違っているのか」と訊かれるようになりました。……ってこれでは何も変わっていないように見えますが。最初の頃に言われていた「どこが間違っているのか」と今言われる「どこが間違っているのか」では大きく意味が異なっています。

2年ほど継続していることにより、ある種の信頼が生まれていると考えられ、当初は上司経由で連絡していたものでも直接通知しても問題なく期待したような対応が取られますし、もちろんメールでも電話でも口頭といった伝達手段、メディアの違いによって信頼されずに対応が変わるということありません。

小寺さんのツールとインフラという文章を読んで「メディア」とは単にインフラだけを指すという発想をする人間がすでに現れているという記述にちょっと違和感を覚え、瀬在丸紅子のセリフを思い出したのでした。

どのようなフィルタを経由するか、どのような伝達経路で到達するか、ということは関係なく発信者が誰か。これが重要なのだと思います。

| | Comments (25) | TrackBack (1)

« September 2005 | Main | April 2006 »