イータイピングやタイプウェルを使っていて不満に思うこと

月配列や新下駄配列、その他のマイ配列でイータイピングやタイプウェル等のタイピングソフト (サイト) を使用して練習を行う場合 DvorakJ 等のキーボードエミュレータを使用してキーコードを変換する必要がある事は月配列 2-263 式で述べた。 私もこの方法でタイピング練習を行っているわけだが、マイナー配列を使っているので仕方がないこととはいえ幾つかの小さな不満はあった。

1. 中指シフトの押下状態が分からない

月配列はローマ字互換性があると言われている。 月配列は 1 打で打てない文字は D か K を押下してから目的のキーを押下するという事なので、例えば以下のようになる:

ローマ字: 「は」は "HA",  「あ」は "A", 「ふぇ」は "FE", "HUXE" 等
月 2-263: 「は」は "A", 「あ」は "DF" 若しくは "KF", 「ふぇ」は "KRDP" 等

この場合のローマ字の「は」は H を前置シフトし A を押下している、と読み解ける。 同様に月配列の「あ」は D を前置シフトし F を押下している。 「ふぇ」の例を出したのは、個々のかなと見て入力しようとすると HUXE なのだが FE というショートカットが用意されているというところがローマ字の一つの優位性になっているという一例を示す為である。 このローマ字の優位性に近づこうとしたのが新下駄配列や月配列の私家版の拗音にあたるキーを用意したものだろう。 「ふぇ」等が 1 打で打てるようになるのは確かに凄いが、キーの数がかなり増えて学習コストが跳ね上がるのは一長一短と言える。

このように挙動上は似ているローマ字と月配列だが、タイピングソフトにおいてローマ字は前置シフトにあたる文字が解釈されるが月配列側は解釈されないというのが大きな差となる。 つまり先程の例で言うと以下のようなユースケースが考えられる:

ミス回復の例: ローマ字

  1. A さんはローマ字でタイピングしている。
  2. 「ふ」を打とうとして HEE と打った (A さんは HE と打ったつもりだった)。
  3. H は正しいが E は誤りの為ミスであることが表示され、次の E も誤りの為同様にミス表示された。
  4. A さんはミス表示に気づいたが H の方は正しく入力されているので U を押下した。
  5. HU が解釈され「ふ」という文字が正しく打てたと認識された。

上記の例で前置シフトにあたる H は解釈されているので打ち直す必要がない事と、H が解釈されてしまっているので「ふ」は FU でも打てるからと F から打ち直す事は出来ない事に注意 (U を打とうとして F を押下してしまったと解釈される)。

同様のミスで回復できない例: 月配列 2-263 式

  1. B さんは月 2-263 でタイピングしている。
  2. 「も」を打とうとして KDD と打った (B さんは KD と打ったつもりだった)。
  3. K は正しいが D は誤り (KD は「ら」である) の為ミスである事が表示されたが最後の D がシフトとして解釈された。
  4. B さんはミス表示に気づいたが 2 回目の D がシフトとして解釈されている事を知らずに DK (正しい「も」のキー) と押下した。
  5. まず DD (ら) として解釈されミス表示され K の部分はシフトとして解釈される。
  6. B さんはまたミスだと思い DK を押下。
  7. 再度 KD (ら) として解釈されミス表示され K の部分はシフトとして解釈される。
  8. 以下 B さんが「シフトがずれている」と認識するまでこの間違いは続く。

ちなみにタイピングソフトでなく実際に入力している場合は KDD の次の D を打った時点で「ら」が出力されているので間違いにすぐ気がつくのだが、タイピングソフトの場合画面に間違った文字も表示されないし中指シフトの状態も表示されないので「シフトがずれている」のに気づくまでに連続して間違え続けてしまう場合がある。

2. 打鍵数や秒速が分からない

タイプウェル国語 K やイータイピングかなで打ったかなの数が表示されるが、あくまで JIS かなとして数えた打鍵数 (濁点も 1 文字と数える) が表示されるのみで月配列で「シフトを含めて何打し、秒あたり平均何打したのか」を簡単に知ることは出来ない (計測用のソフトを併用することになるのだろう)。

どうすればこれらの問題が解決出来るのか

もし自分でタイピングサイトを作るとした時のアプローチを 2 つ考えてみた。

1. DvorakJ のようなリマップ使用前提とする

この場合前述 2. の「打鍵数」「秒速」に関しては文字に対する重み付けを行うことで解決出来る。 例えば「は」なら 1 ストローク、「あ」なら 2 ストロークなので、問題を解き進める際に 2 ストローク対象のかなを押下した場合は 2 打として計算する。

準備としては、かなに対する重み付けのハッシュ (対応表) を持っておけばいいので比較的容易に見える。 「新下駄配列」「月配列 U9」等の別の配列に対応する場合でも同様に重み付けのハッシュを定義してやればいい。

ただ、この方法だと「ち」は ti とも打てるし chi とも打てる、といった場合に適切な判定が出来ない。 あくまでユーザが最短の手順で打鍵するものとして重み付けを定義するしかない。

また、この方法だと前述の「中指シフトの押下状態が分からない」が解決できない。 DvorakJ 等を介している場合 D 若しくは K を押下してもキーコードは何も発行されないので JavaScript 側で中指シフトの押下状態を伺い知ることはできない。

2. JavaScript 側で月配列のリマップ定義を実装する

例えば月 2-263 の場合「は」は A を押下するので JavaScript 側には A のキーコードが送られるが JavaScript 側で「A のキーコードは「は」である」といった定義を全てのキーコードに対して行っていく (ちなみに JIS かなの場合「は」は F であり DvorakJ などのソフトはこの変換を受け持ってくれる)。 この方法の良い所は中指シフトの状態まで JavaScript 側で取得・制御できるというところである。 つまり前述の問題を 2 つともクリアしている。

但し「新しい配列を追加したい」時に労力が高めな方法と思われる (文字の配置の違いだけならまだ良いが中指・薬指シフトや新下駄配列のような同時押し等。そもそも同時押しが正しく判定できるのかも不明)。

Typing of Eningrad

Enin 様が作成された Typing of Eningrad という JavaScript タイピングサイトがあり、私も JIS かな打ちの時から利用させて頂いてきた。 恐らく作者様はプログラミングの専門家というわけではなさそうだが、かなりよく出来ていて驚いた。

この Typing of Eningrad では前述の 2. のアプローチをとっており、ローマ字、JIS かなの他に月配列 2-263 と月配列 E が選択できるようになっている。 月配列 2-263 を選ぶと CPM と KCPM という単位で「キーストローク数」「かな入力数」が表示された。 素晴らしい。

ただ、これは思った通り正直に書くので「参考程度に」受け取って頂きたいのだが、押下すべきキーの表示が英字で表示されているのは直感的ではない気がした (単に対応しきれていないだけかもしれない)。 一応中指シフトに当たるキーは色付きで表示されてはいる。

「あ」を入力する際に DF と打つところを DD と打ってしまって間違えても DF の D の部分は既に解釈されているので次は F と打てば良い (DF と最初から打つとミスがもう 1 打増えてしまう)。 この挙動を最初見た時「動きがおかしいのでは (他のタイピングソフトを操作している時と違うのでは)」と思ったが、前述の考察からしてこの挙動の方が正しい (ローマ字と同様に前置シフトの D が解釈された状態から始まる)。 但しタイプウェルやイータイピングを行ってからこの挙動に触れると間違いなく最初から DF と打ち直してしまうだろう。 どちらがいいかというところだが、前述の「連続シフト押し間違い」が無い所は優れている (ミスが 1 打増えるだけ)。

無いなら作ってしまえの精神

幸いにも私はプログラマの為タイピングサイトを作ろうと思えば作ることは出来る。 JIS かなの時は既存のサイトで満足していたので全くそんな気は起きなかったが、月配列を使い始めて前述の不満も出てきたりしてタイピングに関する考えが変わってきたように思う。 ただ JavaScript に加えてまともに集計やランキングなども作るとなるとやはり大変である。 やるかやらないかは別にしても、もう少しいろいろなタイピングサイトを見て情報収集したいところだ。