Skip to content

Latest commit

 

History

History
68 lines (39 loc) · 12.8 KB

0.background.md

File metadata and controls

68 lines (39 loc) · 12.8 KB
Raw

タイピングというのは結構楽しい。特に颯爽と風を切るようなスピードでタイピングするとなるとストレス解消とかにもなるかも知れない。

しかし単にスピードのあるタイピングするのが私の目的なのだろうか? そもそも理想的なタイピングとはどのようなものなのだろうか。そのへん少し掘り下げて考えてみた。

あ、一応 disclaimer しておくと、内容の正確性は保証されておりません。単なる個人の作文です。

日本語について:

そもそも私がタイプしている日本語の平仮名は音節文字というものに分類されるらしい -- ちなみに漢字に限っては表語文字なるものに分類されるらしい。普段気にすることは少ないが、考えれば考えるほど今の私のイシューの根源はここにある様に思える。

人間に備わっている口の形というのはある程度一定である。そこから音素単位で見れば個々の言語が持つ音素の数というのはある程度同じような数に落ち着くのではないかと想像する (というか IPA の記号の数を見ればそれは明らかだ)。

日本語の平仮名 (と片仮名) は音節文字とあるが、普段耳にするような他の言語で使われている文字の多く (英語などに代表されるヨーロッパの言語のラテン文字、アラビア語やペルシャ語で使われているアラビア文字、ロシア語のキリル文字など) は音素文字というらしい (一つの音が一つの記号に対応するから)。すでに書いたが中国語で使われている漢字は表語文字というくくりの文字らしい。同じ中国語でも台湾には中音符号なるものがあるらしく、こちらは音素文字にカテゴライズされるらしい。

それから日本語には「モーラ」という概念もあるのだけれど、ここではそのことについてはあまり考えないで先に進むことにする。

日本語のタイピングについて:

日本語 (のタイピング) に限った話をすると、平仮名/片仮名だけではなく漢字とアルファベットが出てくるのでややこしい。T-Code/TUT-Code などの極めて特殊な入力方式を除くと、日本語の IME というのは最初に平仮名を確定前の文字として入力し、その後漢字仮名混じり文としてユーザーが選択するという動作を行い入力を確定する。世にある多くの IME は、この「入力してから確定までの動作をいかに楽にするか」を競い合っているように見える (Google IME が人気の理由だろう)。

ちなみに SKK のことを忘れたわけではない (というか日本語の IME について語る上で避けては通れないのが SKK だと私は考えていたりする)。とても割り切った考え方の SKK だが、他の IME と比べて実装が比較的簡単 (他の IME のキモと言えるであろう変換候補を表示するための辞書について考える必要がない) であるため、技術的な難易度だけで考えると、全く新しいプラットフォームで最もコストをかけずに実装できる IME ではなかろうか。とはいえその割り切りの良さは凄まじい…。

親指シフトなどの「(バーチャルおよび物理) 配列」は、ここにある IME と多少切り離して考える必要があると思う。というのも両者はそもそも分離可能だからだ (一般的に世にある多くの IME が「ローマ字入力」と「かな入力」(という名前の JIS かな入力) だけをサポートしているというだけの話だ)。そもそもなぜこれら二つの入力配列しか多くの IME ではサポートされていないのか考えてみると疑問に思うのだけれど、それは多分「経済合理性」というやつなのだろう。

さて、この「ひらがなの文字」を入力して「漢字仮名混じり文」を IME を介して得るというフローにどれほどの合理性があるのだろうか。上にも書いたとおり日本語というのは音節文字の平仮名/片仮名と表語文字の漢字 (そして音素文字のアルファベット) により構成されている。これらの異なる種類の文字セットを同列の方法で入力しようとすると、おそらく漢直入力 (つまり T[UT]-Code) を行うということになる (「同列の方法で」となると定義上そうならざる得ない)。しかしこれは酷というものだろう。私だって今まで漢直入力を問題なくできている人に一人しか会ったことないぞ (私自身は学生の頃に二度挑戦して両方とも失敗した)。やっぱり大多数の人にとってなんらかの変換は (少なくとも日本語に限っては) 必要で、その入り口が平仮名というのも理解できなくはない。多分中国語のように (表語文字の) 漢字だけで構成される言語をタイプするのであれば話は違ってきたかも知れないが、今は日本語の話だ。

しかしですねー、そうすると「感覚的に」アルファベット (ラテン文字) に対する外様感が凄いわけですよ。そもそも音素文字のアルファベットが刻印されているキーボードでタイプしているのに、IME に送信される (入力される) 文字は平仮名で、そこから何らかの変換作業をかますわけですよ。漢字の数はそもそも (常用漢字だけでも) 数千というオーダーなので、ある程度煩わしい変換作業も致し方ないと思えるのであるが (というか殆どの人にとって他に方法無いよね?)、基本的に辞書ベースの IME で望みのアルファベットを出力させるために変換予想からの変換を行うというのは非効率すぎるでしょう。なので F10 による直接入力への変換なんていうある意味「救済措置」みたいなものもあるのだと思う (完全に個人の意見です)。

タイピングの使用目的と私自身が望むタイピングの環境について:

そろそろ個人的な話をしていこうと思う。新下駄配列を実装して実際にタイプしてみて気がついたことなのだけれど、私は思ったよりも色々な文脈でアルファベットをタイピングしているということに気がついた。例えばブラウザーの URL がわかりやすいかも (プログラミングも勿論そうなのだけれど、そもそもそういう文脈では日本語を全然打たないので問題にはならない)。ブラウザーの URL を入力する時に使われる文字列というのはほとんど ASCII で表現されているのだけれど、日本語入力モードでタイピングし始めて 0.2 秒後ぐらいに日本語を入力していることに気がついても、従来のローマ字入力 (または JIS かな入力) であれば、F10 キー (私の場合は Ctrl+; のコンボキー) により、それまで入力したキーのシーケンスに従ったかたちで入力した文字列が ASCII 文字列に変換される。私が以前行った新下駄配列の実装というのは IME に入力が届く前の段階でキーの入れ替えを行うというもので、一旦 IME まで入力データが渡ってしまうと、そこから元の (素の?) キーのシーケンスを復元することはできない。というか、新下駄配列は同時押し配列なので、例えば "D+K" => ["R", "E"] といったマッピングが IME の前で行われると、IME は "D" と "K" のどちらが先のキーストロークだったのか判断することは原理上できない。これは (私がそもそも日本語をそこまで入力していないということを横に置いても) なかなか由々しき問題である。

とは言え新下駄配列の練習をしながら「楽にタイピングができる」と感じたのも事実である。特にホームポジションからの指の移動が減ったと感じられたのは良かった。例えるならば日本語版 Dvorak 配列とでも言うのだろうか。習得すれば (実際に出力される文字列の数が増えるという意味で) タイピングのスピードが上がることも期待されるが、指の運動を減らせることができそうであるという期待も新下駄配列には持つことができた。

ここまで読んで分かったかも知れないが、私自身が求めるタイピング環境というのは以下のようなものだろう:

  1. ASCII 文字列への変換が一旦日本語を入力した後でも (素早く) できる
  2. なるべくホームポジションから指が離れることなくタイピングできる (つまり楽にタイピングできる)
  3. 素早くタイピングできる (これは単に打件数が多いという意味ではなく、単位時間あたりに IME に入力される文字列が多くなるということ)
  4. 個人レベルで実現することができる (つまり本格的な IME の開発や改造に手を出すつもりはない)

残念ながら親指シフトや新下駄配列などの配列は 1. の条件には合っていない。そもそも IME の方でこのような配列に対応すれば問題ない話ではあると思うのだけれど、私の知る限りそのような可能性を持った例は (すでに販売終了となった) 親指シフトの Japanist だけで、それも対応している環境は Windows だけである。

UPDATE: Japanist では漢字仮名混じり文への確定前状態で F10 キーを押下しても「何も起こらない」と教えてもらった。うーむ、そうかー。

今後について:

…とここにきて AZIK 配列なるものを知る。なるほど、IME にてユーザーが編集することのできるローマ字の配列テーブルをいじって、より効果的な日本語入力環境を手に入れるというものらしい。確かに日本語の子音/母音の組み合わせというのは、ほとんどが CV か CjV であり、子音だけ連続するという例はまれだ (/N/ など)。英語は最大子音 (の音素) が 3 個続くこともあるらしい (初めて知ったぞ)。ということは、子音のキーが連続するようなキーストロークのシーケンスに何らかのマッピングを埋め込むというのは理にかなったアイデアに思える。それにローマ字入力がベースとなっているので学習コストもそこまで高くない。何を隠そうこのドキュメントも全て AZIK 配列で書いたのだ。実装と言っても、技術的には TSV ファイルを用意してインポートするだけで実現できてしまう。これは良い着地点かも知れない。

とは言うものの、現状公開されている AZIK 配列に対して個人的に改善点が無いと思わないわけでもない。すぐに思いつくのは "ん" の文字単体の扱いと ("-aN" を入力するための) "Z" キーの扱いだろうか (新下駄配列のテーブルを見ていて感じたことなのだが、おそらく我々は自分たちが考える以上に "ん" という文字を入力している)。

今後の展開なのだけれど、AZIK 配列を参考にしながら (技術的には同じ仕組みを利用して) 自分なりの配列を模索していこうと思う。ある程度客観的ななにかに基づいて配列を考えていきたいので、何らかのコーパスのようなものを用意して手元にある物理キーボードとにらめっこしながら新たな配列を考えていくことになると思う。

リンクなど: