タイプウェルを10年ぶりに更新した話、または完全固定運指からの脱却の道程 (前編)

タイプウェルを10年ぶりに更新した話、または完全固定運指からの脱却の道程 (導入編) - permilの日記

前の記事の続きです。

前置き: 前提知識

以下の文章中で、左手小指から右手小指までの指10本に 1～9, 0 の番号を割り当てる表記を使用します。

　　　小薬中人親　親人中薬小
左手　１２３４５　６７８９０　右手

ということです。

RTC2017 予選前にやったこと

正直この段階ではまだ予選通過できるとは思っておらず、賑やかしとして上位の争いを演出できたらいいなくらいのことを考えていました。 そのためまだ本格的に最適化には振っておらず、一般的な、出現頻度の高い最適化をいくつか試すに留めていました。

ca, cu, co の導入

予選課題の e-typing は初速の速い私に有利な種目ではあるものの、得意な種目ではありません。 主には私がローマ字、しかも小文字しかまともに認識ができないせいです。 そのため私が e-typing で高スコアを狙う場合、「全てのワードを暗記して、最初数文字を見て続きを全部思い出せる状態にする」というのが前提条件になります。

が、裏を返せばこれは「文字を見ずに入力をしている」ということでもあり、 文字列と一緒に最適化箇所も覚えてしまうことで前の記事の「見えている文字と違う文字を入力することへの抵抗」を気にせず cacuco などの文字単位での最適化を適用できる、と前向きにとらえることにしました。

結果的には、この期間に e-typing で「画面の文字ではなく脳内の音節から打鍵を組み立てる」という練習を続けたことで、

• ローマ字の kakuko を見ながら cacuco を打つこともできるようになり、
• また日本語読みの実力も向上 (TWR 常用 32秒 → 29秒)

するという副次的な効果も得られたような気がしています。 また懸念していた英文の文字認識時の混乱も、今のところは起きていません。*1

yu47, yu78

また y についてもこのタイミングで最適化を導入し始めました。

ちゃんと数えてないですが、慣用句などの実用文は「○ゅ」という文字列が頻出の印象があります。 そのため、普段 77 で連打している yu をばらすことは費用対効果が高いと判断しました。

yu の最適化については 47, 78 の両方が考えられますが、 「最適化部分を打ち終わった時点で指が勝手に元の位置に戻る方がその後をスムーズに打てる」と判断したため

• 基本的には 47 で打つ
  • kyu, nyu, myu, pyu, oyu
  • hyu も 747 でいいはずだが、指が狭いせいか無意識に避けていた(る)ような気がする
  • syu, dyu なども 47 で良いはずだが、指を準備する期間が短いので無理しない
• ryu, tyu, byu といった直前の文字も 4 で打つケースは、語末などの無理のない範囲で 78 を検討する
  • 語末、特に e-typing では、打ち終わったあとに指を戻す時間が十分にあるため積極的に導入する
  • また語末では syuu, tyuu といった u の連続で終わるものも yu の延長とみなし yuu788 で耐えきる

というところに落ち着きました。 これは意識してそうしたというよりは、導入しやすいところから yu47 を導入していった結果こうなったというのが正しい気がします。 おそらくこの先 hyu, syu, dyu などに yu47 を導入しようとした場合は、意識的にこれらを練習する必要があると思われます。

RTC2017 本選前にやったこと

予選課題の練習で 650 を越え始め、「あれこれもしかして予選通過あるんじゃね？」と思ったあたりから本格的に最適化を検討し始めました。 その時点ではまだ課題ワードが発表されておらず、また最適化の練習方法もよく分からなかったため、 典型的な最適化ワードを集めて TypeLighter の長文モードでひたすら打ち、 慣れてきたら少しワードを増やしてまた打ちこむということをやっていました。 実際のファイルがこれです。

この練習方法はたじさくそうまごウェルの影響を強く受けています。 元々、少ない種類のワードで練習してもそのワードに慣れるだけであまり意味がないと思い込んでいたのですが、 たじさくそうまごウェルは想像よりもタイプウェルのエッセンスが凝縮されていてトップスピードを取り戻すのにかなり有用であったため、 最適化でも似たような練習方法を採ることにしました。

練習期間中はこのファイルで指を起こし、ある程度指が温まったら TW や WT をしばらく打ち、 その特定のワードが出た時に自然にその最適化が使えたかどうか、 ダメだったら TypeLighter に戻ってまたしばらく打つ、ということを日課にしていました。

2, 3週間ほど練習した結果、

• 期間中に使えるようになったもの
• 特定のワードのときしか使えなかったもの
• TypeLighter 以外ではまったく使えるようにならなかったもの

などさまざまでしたが、私の場合

• mu67
• ko78
• io89

の三つが非常に効果的でした。

mu67

TypeLighter で本番課題を練習していた際、「この空の下、一人たたずむ」というワードが異常に遅かったため、 「たたずむ」の最適化をいくつか検討した結果

• umu878 は空間把握が難しくてむり *2
• umu787 はあり
  • が、本選課題に含まれていた「ゲーム」も遅かったので共通で使える最適化を導入したかった
• umu767 ？？？

という流れで m6 を検討したところ、意外と打てたので本格的に練習を始めました。*3

練習し始めてまず驚いたのは、 TypeLighter で特定ワード (「たたずむ」 と 「ゲーム」) でしか練習していなかったのに、 TypeWell の「リズム」「フィルム」などでも勝手に m6 が出るようになっていったことです。*4

また、練習していく中で umu という特定文字列を含むワードの遭遇率が思った以上に高いということに気付きました。 正確には「なんか親指が出る頻度がやけに高いな？」という違和感が発端で、 体感としては「途中 ESC のトライアルも含めて 10 回くらい常用を打つと 2, 3 回程度親指が出てる」という感覚でした。*5

これを多いと捉えるか少ないと捉えるかは人によると思いますが、私は

• m6 を覚えただけでこんなに使えるのか！　お得！
• これで 0.1 秒伸びるなら、10 個覚えたら 1 秒伸びるじゃん！
• というかこれまで umu777 で打ってた私はどんだけ無駄してたの...

と思い、この辺りから俄然最適化のモチベが高まり始めます。

さらに驚くことに、練習を続けていくといつの間にか m だけでなく n についても勝手に親指が出てくるようになってきました。*6
n については unu は少ないものの

• un で終わるワードはかなり多い
  • 語末なので認識しやすい ＆ 多少崩れても戻しやすい
• 後々 unyu7647 にも派生

と適用範囲が広く、右手親指の導入は総じてかなりお得感がありました。

ko78

これはあまり一般的でない最適化だと思います。 というのも、標準運指では ko89 なので最適化の必要性が薄いからです。 私の場合基本運指が o8 だったため、ko が 88 となり最適化の余地がありました。

再掲: 私の運指 (最適化前)

最適化初心者の私が自然にこれを思い付くはずもなく、元々は de43 を練習していて

de43の人はdecはどうするのだろ 434?
和文だとkに逃げられるけど英文だと回避できない上に頻出なので悩まし

— permil＠休職中 (@permil) 2017年9月25日

と思い試しに「デコレーション」を追加してみたのがきっかけでした。 これもいくつか運指を検討した結果、

• dec はむり、っていうか遅い
• ko89 は (私の場合) 直後の - が 9 なので繋げづらい
• ko78 かな...

という流れで deko(re-syon)4378 で練習していました。

するとしばらく経って、oko878 が自然に使えるようになっていることに気付きました。 当初は oko のときだけ最適化できていた*7のですが、 徐々に ko78 や ok87 でも使えるようになっていきました。

また k7 の感覚を覚えたことで、ki78 も導入してみようという気持ちになり、「できる」も追加しました。*8
こちらは指の形が辛く最初は慣れなかったものの、oko878 の感覚でまず iki878 が、追って ik87, ki78 も徐々に反応できるようになりました。

io89

標準運指にしか見えませんが、私の基本運指は o8 なのでこれは「私にとっては」最適化となります。

これについては特段個別の練習をした記憶はないのですが、umu, oko などと同様にまず ioi898 (nioi) で自然に指が出るようになり、 そこから徐々に io89, oi98 単体でも使えるようになっていったと記憶しています。

io, oi ともに語末に多く(sutajio, hitosio, hiroi, omoi など) 、また母音連続のためかこの部分をパターンとして認識しやすく、慣れるまでの時間は比較的短かったです。 また英文にも適用箇所が多く (station, national, coin など) これもかなり費用対効果が高かったです。

ただ、個別練習を行っていないためか一部の文字列中ではまだ最適化を適用できていません。たとえば

• otioti (oti x 2 と認識してしまうため真ん中の io をかたまりとして認識できない)
• iou (これまで使ってなかった指の形なので窮屈に感じる)
• oil, lion (o ⇔ l の移動が狭く無意識に避けている)

あたりです。これらの最適化を習得するには y 同様個別の練習が必要になると思われます。

その他の最適化

deredere4343、burabura78417841、hurahura78417841 については、これら特定の文字列に対しては稀に適用できるようになったものの、 d4, bu78, hu78 の習得にはそれぞれ至りませんでした。*9

また tanjican41789417 については完全に TypeLighter でしか打てないままに終わりました。

おそらくこれらは um/mu, ok/ko などと異なり、普通に TypeWell などを打っているだけでは出現頻度が低く学習に至らなかったのだと思われます。

最終的に (2017 年終了時点)

これらの最適化導入の結果、2005 年が最終更新だった TWR 常用を何度か更新し 最終的に 26.857 ZI 05.02.19 → 25.914 ZH 17.10.29 と約 1 秒の更新につながりました。

倒した・・・ pic.twitter.com/oIsfcLq08M

— permil＠休職中 (@permil) 2017年10月29日

また、ワーストスピードに関しては更新こそなかったものの平均的に向上したように思います。 逆にトップスピードについては特に変化を感じませんでした。 これは最適化が指の動きを速める技術ではなく「打ちづらい文字列を打ちやすくする技術」であることからも納得ができる結果です。

英文に関しては最適化は全く練習しなかったため最適化の影響はほぼありませんでした、が、 逆に言うと懸念していた悪影響もありませんでした。*10
io89, oi98 については和文英文ともに頻出なためたまに使えるようになったのと、 ook (book, cook, took...) に関しては中指の三連打を避けようという意識からか ook888 から ook887 に変化しました。

続きます

次回、2018 年編。

*1:推測ですが、文字列認識の単位がそもそも違うような気がします。和文ではローマ字読みでも脳内で音節ごとに分割しているが、英文は tri, any, ter, teen, ple みたいな頻出文字列を頼りに単語を分割して認識している気がする。

*2:当時は。後編で書く予定ですが、最近はありかなとも思い始めてます。

*3:親指とか昔は冗談だとしか思ってなかったんですが、どうやら打鍵姿勢が昔は両手首ベタっと派だったのが、10年の歳月の間にいつのまにか右手首浮かす派にシフトしていたことが功を奏したようです。また、スペースが左手なので右手親指が空いていたのも最適化に活用しやすかった一因であると思います。

*4:私がローマ字読みなので、umu という文字列の形がパターンとして認識しやすかったというのもあるかもしれません。他の最適化勢の人にも聞いてみたいところ。

*5:今真面目に調べたところ、TWR 常用の 2157 ワードの中に umu を含むワードが 15 ワード (約 0.7% ≒ 1/144) あるようです。1 トライアルがだいたい 55 ワード程度のようなので、3 トライアルに 1 回くらいは見る計算になります、えめっちゃ多いな。umu だけでこれなので、um, mu 単体で数えるともっと増えるはずです。

*6:munmun あたりで、mu67 のあと n を自然に打てる指が n6 だったのがきっかけで、そこから tuntun, runrun あたりに派生していった気がします。こうして考えると、常用特有の繰り返しワードは1ワードで2度おいしいため、最適化の例示として使われやすいのも分かる。ただ最近は munmun は親指による速度低下を防ぐため個別最適化で 674674 で打っています。

*7:推測ですが、ローマ字読みの場合 umu や oko のような行って戻る文字列は認識がしやすく、また umu で間に他の指をねじ込む感覚を練習していたため応用が利いたのではないかと思っています。

*8:これだけやっても結局 de43 は身についてません。未だ練習中。つらい...

*9:ただ burabura, hurahura に関しては練習の中で、1 文字目で反応し損ねても繰り返しの 2 回目は b7, h7 が間に合う、というケースは段々増えていきました。r ⇔ f, r ⇔ b の移動は意外と時間がかかっていたためこれだけでも一定の効果は実感できました。

*10:TWE 常用についても 26.362 ZG 06.11.27 → 26.303 ZG 17.09.06 と 0.059 秒の更新はあったのですが、これは最適化の影響というよりは、リハビリによるトップスピードの回復と、TWR で更新できたことによる自信の回復が主な要因だったと考えています。