TOEIC800点RTAをした時の話

もう6月の話なんですが、TOEIC875点取りました。

対策期間は2か月、過去の最高点は数年前に5000円ガチャを回したときの705点だったので+170点になります。 そろそろ年も変わるので適当にまとめておきます。

  • 3行で
  • 以下駄文
    • 経緯
    • TOEIC800点てどれくらいなの
    • やったこと
      • ~705点 (数年前)
      • ~875点 (今回)

3行で

  • TOEIC800点はちゃんと勉強すれば取れるしコスパ/タイパもいいので資格的には意外とおすすめだよ
  • 会話が目的の人はTOEICはあんまりいらないかも
  • TOEICだけでいい人は、中高文法だけおさらいして、あとは金フレAbceedを無限に回そう
続きを読む

10FastFingers を劇的に快適にする方法

10FastFingers でまじめにスコア狙いをし始めると、

  • 途中経過が表示されない
  • リトライがめんどくさい (Tab → Enter に慣れない)

みたいなことが気になります。大丈夫です。解決できます。

やり方

このスクリプトをブラウザのデベロッパーコンソールに貼り付けるだけです。
(別に変な事してないんですが一応免責として自己責任でお願いします。)

$(function(){function e(){for(var e=0,t=document.getElementById("words").getElementsByClassName("correct"),n=0;n<t.length;n++){var o=t.item(n);e=Math.round(e+o.textContent.length+1)}var r=Math.round(e/5/((60.01-countdown)/60));(e<0||e>2e3)&&(e=0),(r<0||r>400)&&(r=0),$("#preview").html("<h2><b>Key Strokes: </b>"+e+" - <b>WPM: </b>"+r+"</h2>")}$("#words").before("<div id='preview'></div>"),e(),$(document).keydown(function(t){e()}),$(document).keyup(function(e){27==e.which&&restart()})});

そうすると、

  1. タイピング中に入力文字数と WPM が表示されます
  2. ESC でリトライできます

f:id:permil:20190303013326p:plain

べんり!!*1

これでだいぶタイプウェルと似た感覚でプレイできます。
Forefox/Chrome、Typing Test/Typing Test(advanced)、英語/日本語、あたりである程度使えそうなことを確認済です。
greasemonkey/tampermonkey あたりと組み合わせて使えばページ読み込み時に自動で適用もできます。

↑ で伝わらない人向けにもう少し細かく

ブラウザで 10FastFingers の Typing Test などのページを開いた状態で、

  1. 右クリックから開発者向けコンソールを開く
    • Firefox の場合、右クリック → 要素を調査 → コンソール
    • Chrome の場合、右クリック → 検証(I) → Console
  2. 上のスクリプトを入力欄に貼り付けて Enter
  3. 出題文字列の上に Key Strokes: 0 - WPM: 0 と表示されればたぶん成功
    • スクリプト貼付後はコンソールは消してしまって大丈夫です
    • ページを開くたびに貼り付ける必要があります
f:id:permil:20190303020706p:plain
Firefox の場合
f:id:permil:20190303021128p:plain
Chrome の場合

スクリプトについて

discord 上でいただいた2つのスクリプト*2を適当に混合しつつ、ESC でリトライ機能を足したものです。minify 書ける前はこんな感じです。

$(function() {
    $('#words').before("<div id='preview'></div>");
    update();

    $(document).keydown(function(k) { update() })
    $(document).keyup(function(k) { if (k.which == 27) { restart(); } })

    function update() {
        var realCPM = 0;
        var x = document.getElementById("words");
        var corrects = x.getElementsByClassName("correct");

        for(var i = 0; i < corrects.length; i++) {
            var correctword = corrects.item(i);
            realCPM = Math.round(realCPM + correctword.textContent.length + 1);
        }
        var realWPM = Math.round((realCPM / 5) / ((60.01 - countdown) / 60));

        if (realCPM < 0 || realCPM > 2000) { realCPM = 0; }
        if (realWPM < 0 || realWPM > 400) { realWPM = 0; }

        $('#preview').html("<h2><b>Key Strokes: </b>" + realCPM + " - " + "<b>WPM: </b>" + realWPM + "</h2>");
    }
})

ぶっちゃけ中味が気になる人が読めないほど複雑なことやってないんですが

  1. ページ読み込み時に Key Strokes と WPM の行を差し込む
  2. キー押下時にそれまでの打鍵数と速度を計測して更新
  3. ESC が押されたら reload (Tab → Enter を押したときと同じ挙動)

をしてるだけです。
$(document).keydown(function(k) { update() })setInterval(function() { update() }, 100} あたりで置き換えてもいいと思います。よしなに。

*1:使って問題ないことは、10FF関係者のAyasuさんにdiscord上のDMで確認済です。「ああそういうのみんな使ってるから大丈夫だよhaha」的な回答をいただきました。

*2:出自不明、10ff の discord に誰かが貼ったものっぽい

Macで本気でRealforceを使う

タイピングをガチってた割に打鍵感にそこまでこだわりのない方なので、 macbook では設定もめんどいし内蔵キーボードでいいか、Control と Command と Caps くらい入れ替えときゃいいだろ、 くらいの気持ちで雑に過ごしてきたのですが、

  • 首肩痛めたのでノートパソコンスタンド(こういうやつ)を導入した
  • → らキーボードの位置も高くなって打ちづらいので余ってた Realforce を繋いだ
  • → ら Windows 用のショートカットが身に染み込みすぎてて発狂した *1

のでなんとかして MacWindows 用外付けキーボードを繋いで Windowsキーバインドで使ってやろう*2 という記事です。

結論

お金と時間と空間に余裕のあって Mac しか使わない人

東プレ,第2世代「REALFORCE」のMac向けフルキーボード4製品を2019年3月に発売 - 4Gamer.net

REALFORCE for Macが出るらしいんでそれを待ちましょう。

別に 変換/無変換 とか使わなくね? むしろ Mac の 英数/かな の方がいいでしょという人

Windows の方の挙動を変えてしまいましょう。GoogleIME ならこの辺でいけそうです。

Windowsで英数/かな入力切替は無変換/変換キーでしよう | Techs Life

また将来的には Windows の 無変換/変換 の挙動が Mac の 英数/かな 準拠に変わるという話もあるらしいです。

[半角/全角]キー不要に? WindowsのIME切り替えがMac方式に - ITmedia NEWS

私の場合

KarabinerHyperSwitch 入れたらそこそこ苦痛なく使える状態になりました。

やったこと

とはいえ Windows はそこまでキーボードショートカットに頼る文化でもないので(多分)、 無意識で使おうとしてストレスになるようなショートカットはそこまで多くありませんでした。 のでその辺だけ上書きして、Mac でもそれっぽい挙動になるようにしました。

具体的には (Windows における)

  • Ctrl+A, C, V, Z, F, T, ...
  • 半角/全角
  • 変換, 無変換
  • Alt+Tab

あたりです。

Karabiner

Windows の Ctrl+英字キー 辺りのショートカットは Mac では大体 Cmd+英字キー あたりで違和感なく使えるので、 それだけなら Mac の標準機能でできます。(システム環境設定 → キーボード → キーボード → 修飾キー)

f:id:permil:20190124101707p:plain:w300

が、他の入れ替えは標準機能ではできないので Karabiner を入れます。 いわゆるキーリマッピングツールで Windows における窓使いの憂鬱とか DvorakJ みたいやつです。たぶん。

Karabiner を入れると認証を求められるので適当に許可します。 Karabiner-Elements.app が設定用アプリ、Karabiner-EventViewer.app は実際に発生しているキーコードのビューワーです。

f:id:permil:20190124102329p:plain

Karabiner を入れると別のキーボードデバイスとして認識されます。 ので修飾キーの入れ替えが戻ったり、内臓キーボードと Windows キーボードで Control の位置が違ったりして一瞬焦るんですが、 Karabiner 側でキーボードごとの設定を持てるので、Cmd/Control/Caps あたりシステムの設定を使わず Karabiner 側で個別に設定することにします。(既にシステム側で設定済の人は戻した方が混乱しないかもしれません。)

Control, Caps, Cmd

内蔵キーボードと外付けキーボードで修飾キーの配置が違うので個別に設定します。

内蔵キーボードでは Windows ユーザーが如何にも押しそうな位置に Caps があるので、Caps を押したら Cmd になるようにしてしまいます。 Simple Modifications から

  1. Target Device に Apple Internal Keyboard を選択し、
  2. Add Item → From key: caps_lock, To key: left_command

を設定します。

f:id:permil:20190124104732p:plain

同様に外付けの方では、caps_lock → control、left_control → left_command を設定します。

半角/全角

Complex Modifications → Add rule → Import more rules from the Internet (open a web browser)
の一番下の other examples から、
input_source_if,input_source_unless example
を Import し、Karabiner の方で Enable にすれば完了です。 この辺の下の方見ました。

変換, 無変換

まじめにシミュレートしようとすると面倒そうなんですが、 私は単に日本語入力後「カタカナに変換」「普通に変換」の用途でしか使ってなかったので、単に

Simple Modifications → Target Devices: For all devices から

  • From key: PCキーボードの無変換キー → To key: F7
  • From key: PCキーボードの変換キー → To key: spaceber

を設定するだけでごまかしてます。

入力してないときは無変換キーで入力モード切り替えるとかも Complex Modifications 使えばできんのかな、どうだろ...

(おまけ) PrintScreen, Alt+PrintScreen

頻繁に使うわけでもないし元のショートカットでも困ってないんですが Complex Modifications でできそうだったので試しに設定してみました。

  • PrintScreen → Cmd+Shift+3
  • Alt+PrintScreen → Cmd+Shift+4, 50ms後 Space

Windows のような最前面にあるウィンドウを自動でキャプチャする機能はないっぽいので、 Cmd+Shift+4 → Space でキャプチャするウィンドウの選択までを Alt+PrintScreen で行うようにしてみました。

実際の設定内容はこんな感じ*3 Complex Modifications の設定は設定ファイル(~/.config/karabiner/karabiner.json)を手動でゴリゴリいじるしかなさそうなので分かる人の参考になれば。complex_modifications → rules の下の配列に追加してけば良いです。 公式ドキュメント日本語の解説記事が大変参考になりました。

HyperSwitch

Windows の Alt+Tab に相当する機能は Mac には存在しないようなので、*4 それっぽい挙動を実現してる HyperSwitch を入れました。

手順はこの辺り。 ざっくり書くと

  1. インストール後起動すると認証を求められるので許可する
  2. 再度起動しライセンスに同意
  3. Preference → General から Run HyperSwitch in the background にチェック

で Option+Tab (Windows 用キーボードでは Alt+Tab) でウィンドウを切り替えられるようになると思います。 複数の操作スペース (マルチデスクトップ) を使っている人は Include Windows from other spaces にチェックを複数スペースをまたいだウィンドウの切り替えができるようになります。お好みで。

*1:どうやらこれまでは「macbook の場合はこのキーで 英字/かな 変換」みたいな理解をしてたのでそんなに不都合なく使えてたみたいです。Realforce 繋いだら完全に脳が Windows モードになって頭おかしくなった。

*2:コード書くときは7割方 mac になってしまったけれど、PC はゲーム機だと思ってるので心はいつも Windows ユーザーです

*3:本当は複数打鍵も設定できるみたいなのだけど GUI が絡むせいか delay 入れないと動かなかった。この辺の人もハマってるっぽい。

*4:同じアプリのウィンドウ同士を切り替える Command+F1 と、アプリ間を切り替える Command+Tab はあるが、アプリをまたがってウィンドウを切り替えるショートカットはないっぽい。たぶん。

改めて

なんかテンション上げすぎてタイピングのガチ記事ばっか書いてたら既に他のこと書きづらくなってるんですが改めて指針を表明しておくと

ここはタイピングブログではありません。雑にいろんなことを書きます。

よしこれで他のこと書けるぞ

WeatherTyping用月配列プラグインを作りました (v3.3, v3.4対応)

正確には作ったのは去年なんですが、バージョン3.3.0, 3.4.0で動作する形式に修正しました。
中指シフト系で最もメジャーと思われる月配列 2-263式用のkeymapも付属させておきます。

月配列プラグインと銘打っているものの、WTEditor.exe での配列作成に対応しているため 花配列中指NICOLA配列TWW配列 といった前置シフト系の配列であれば流用可能です。

バージョン3.2.1から公式にサポートされるようになった入力方式プラグインとして作られているため、 結果画面やロビーでもちゃんと配列名が表示されます。

f:id:permil:20181223221402p:plain f:id:permil:20181223221235p:plain

ただし、実装方針の都合上以下の制限があります。

  • シフトキーが2つまでしか使えない
    • そのため、薬指にもシフトを置くUx版や、多段シフトの必要な3-285改などには対応不可*1
  • D/K 以外にシフトを置く配列では、初回の配列選択時にシフトキーを設定する必要がある

使い方 (月2-263配列)

Windows デスクトップ版(WeatherTyping340.zip)をダウンロードします。解凍後WTを一度起動すると、本体と同じ階層に InputMethod ディレクトリができます。 f:id:permil:20181223181805p:plain:w320

次にプラグインページから WeatherTypingPluginTsuki.dll, Tsuki_2_263_v1.keymap の 2 つのファイルをダウンロードし、 InputMethod ディレクトリに両方とも配置してください。

問題なければこれだけで WT で 月配列 2-263 が選択できるようになっているはずです。

f:id:permil:20181223182335p:plain:w320

その他の配列での使い方

月2-263以外の配列で利用したい場合は WTEditor.exe で配列を作成してください。

f:id:permil:20181223190110p:plain

注意点は

  • 名前・著作者・バージョンを入力する
  • KeyFilter は permil:月配列 v1、InputFilter は Denasu System:かな v1 を選択する
  • 必要に応じてシフトキー1, シフトキー2 の双方に文字を割り当てる
  • 配列保存時にエラーが出る場合は、割り当て忘れている文字がないか確認する (特に、。・「」など)

あたりです。

保存に成功すれば、作成した配列が WT で選択可能になっているはずです。
ギャルメロンパン配列のような D/K 以外にシフトキーを置く配列の場合は、忘れずにシフトキーを変更しましょう。

f:id:permil:20181223191144p:plain

*1:WTEditorでの配列編集を諦めればコード側で対応は可能だと思います。コードは公開しておくので参考になれば。

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

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

続きです。主に今年やった英文への最適化導入の話です。

2018 年 9 月中旬頃

去年の TWR 常用 ZH で完全に燃え尽きておりサミット中も特にモチベは上昇しなかったのですが、 なぜかサミット翌日から謎のモチベが生まれたため今年もタイピングをすることになりました。

RTC に向けてさらに和文の向上を目指すという選択肢もあったのですが、

  • 正直 TWR 常用があと 1 秒伸びたとしてもまだ今のトップ層とはまともに戦えない
  • 去年和文で好感触を得た最適化を、主戦場の英文でも試してみたかった

という理由で、今年は英文の最適化をメインで練習してみることにしました。

方針

去年の練習の中でいくつか実感したことがあります。それは

  • ワードを絞った練習は思いのほか効果が高い (たじさくそうまごウェル・TypeLighter)
  • 最適化の定着率は、該当文字列の出現頻度と強い相関がある
    • 頻度の高い最適化 (例: umu, oko) はあまり特別な練習をしなくても定着・派生が進む
    • 頻度の低い最適化は普通に練習をしているだけでは定着しない

ということです。

そのため今年の練習では、去年のように乱雑に最適化ワードを集めるのではなく

  • とにかく特定の連続打鍵を含んだワードをかき集め、TypeLighter でひたすら打ちこむ
  • その際「最適化の効果が実感しやすいもの」を意図的に集める
    • 最適化すると空間把握が難しくなるようなワードは抜いておき、慣れてきてから追加する
    • ただし、最終的にそのようなワードをどう処理するかはあらかじめ考えておく

といった方針で最適化の個別練習を始めました。

f:id:permil:20181111164721p:plain:w300

やったこと

去年の最適化導入後の私の運指がこんな感じです。 *1

f:id:permil:20181113023240p:plain:w350
私の運指 (2017 年終了時)

これを見ると、明らかに左手人差し指の担当範囲が広いことが気付きます。 幸い子音ばかりなので和文では頻度が低めかつ連続するケースもなくあまり問題にならないのですが、 英文では和文に比べると頻度が高く、さらに tr, rt, gr, fr, br など r 絡みの子音同士の連続が多いため、 標準運指では同指連続打鍵が多発することになります。
加えて私の場合 c も左手人差し指の担当のためさらに忙しく、 これらのキーを他の指で肩代わりする最適化は速度面でも疲労面でも効果が高そうにみえます。

そのため、まずは一番移動距離の長い br, ct について最適化を検討し、 次いで頻出である r 絡みと、その他いくつかの最適化を考えていくことにしました。

br74

b ⇔ r と c ⇔ t では後者の方がロスしている自覚があったのですが、 ct はどう最適化すべきか決めかねていたので先に br から取り掛かることにしました。

br の最適化としては br43 と br74 が考えられますが、

  • br43 としてしまうと bre432 の習得が必須である
    • 特に brew, break などでは小指まで導入する必要があり難易度が高そう
  • 去年和文では定着させられなかった b7 の感覚を習得したい

という理由から br74 を選択しました。

TypeLighter にはプリセットとして TypeWell のワード一覧が入っています。 そのため、基本英単語にあたる 1-基本英単語 (1500).tpl 内を br で検索し、それだけを詰め込んだファイルを作って最適化の練習をすることにしました。

f:id:permil:20181113050045p:plain:w300

当初 b7 以外は基本運指のままでよいと思っていたのですが、練習を始めてみるといきなり問題が発覚しました。 右手人差し指が b にある状態ではいくつかのキーの位置把握が思った以上に難しく、 その中でも致命的だったのは bro で、先述の通り私の基本運指は o8 なのですが、b7 からだと o8 が遠すぎて全く安定しなかったのです。

慣れるまでひたすら打ち込むという選択肢もありましたが、 私は「右手人差し指が b にある状態での運指を新たに覚え、b7 のときだけそちらにシフトする感覚で打つ」ことにしました。
具体的には以下のような運指です。

f:id:permil:20181114092026p:plain:w350
右手人差し指が b にあるときの運指

私の基本運指から比較すると、右手が一列弱左にずれているイメージです。*2
当初は新しい配列を覚えて切り替えるくらいの気持ちで臨んだのですが、実際はそこまで大げさではなく 1 週間程度で慣れ始めたと思います。*3

gr43, tr43, fr43

去年 doragu さんから

という助言をいただいていたので、r3 を練習することにしました。 が、語頭で頻出の gr に対し gra, gro には gr43 を適用するが gre には適用しないという打ち分けをするのはかなりの先読み力が必要と感じたため、 語頭 gr (, tr, fr) を見た時点で 43 を適用し、直後に e が来た場合は e2 で切り抜ける、という想定で練習することにしました。*4

練習にあたっては先述のように、「最適化の効果が実感しやすいもの」として gr の直後に e が来ないもの (group, angry, ...) のみで練習を行い、 後から gre が入る単語 (great, agree, ...) を追加するといった順序で練習を行いました。

hu78

和文では定着させられなかった hu78 ですが、 gr43 の練習中についでに hungry787437 を練習してところ徐々に thus, husband などでも適用できるようになってきました。

おそらくですが

  • 「ふ」は fu で表示しているため、fu → hu → 78 の二段階の思考が必要で定着しづらかった
    • 英文では hu で表示され、回避もできないため強制的に練習できた
  • br74 の練習の中で u8 の感覚が養われてきていた

などが影響していたのではないかと思われます。

pl98

私の基本運指は p9 であり pl は薬指の連打だったため、pl98 の導入はかなり効果がありました。

当初は単語中の pl をひとかたまりとして認識できず語末の ple でしか適用できませんでしたが、 徐々に pl を一つの子音であるかのように知覚できるようになり、player, complete といった語頭や語中の pl にも 98 を適用できるようになりました。

ny74, ny67, my74

y7, ny67 は和文で導入済でしたが、 直後に母音がくるケース(「ゆ」または「にゃにゅにょ」) でしか適用できていなかったため、 英文についても意識的に練習を行いました。

ct47

ct の最適化はかなり長いこと悩んでいました。 選択肢としては ct34, ct43, ct54, ct47 などがありえると思いますが、

  • ct34 は標準運指だが、私の基本運指 c3 とは相性が悪く、指の形も苦しく感じる
  • ct43 も流れの中ではありかもしれないが、基本的には指の形が苦しい
  • ct54 はスペースを 5 で押しているため親指がかなり忙しくなる
    • その付近だけスペースを 6 でフォローすることも考えたが、しっくり来ず断念
  • ct47 は t7 がかなり遠く、ction, ctor などと続く場合の空間把握が難しい

とどれも何かしら問題があります。 悩んだ末現状は語末の ct に限り ct47 で打つという部分的な導入を試みており、 将来的に ctor4704, ction47907 なども導入していこうと考えています。*5

おまけ: 和文

和文は今年は余り力を入れる予定はなかったのですが、 去年と比べると c/k の打ち分けが自然にできるようになってきていたため、 RTC 予選の e-typing 向けに申し訳程度の対策をしました。具体的には

  • 文末の「ん」を xn で打つ
  • 右手に偏った文字列中の j/z の打ち分け
  • 他のソフトに悪影響が出ない範囲での水増し
    • shi, tsu, chi など、ヘボン式で見慣れているものを、反応できた範囲でねじ込む
    • 文頭は文章の識別に必死なので諦める

ということをしました。

xn については以前 TypeWell で導入しようとして n の個数が分からなくなって断念したのですが、 文末は認識しやすく n もかならず 1 つのため、 文末の「ん」に nn が必要な e-typing や WeatherTyping に限って導入することにしました。

おまけ2: n4

munmun674674 と autumn174764 に限り n4 を導入しました。

~現在: 最近考えていること

最適化を導入し始めてから 1 年経ち、色々考え方も変わってきたので現状の考えをまとめておきます。 あくまで現状の考えであり、今後も変化していく可能性は高いですが、何かの参考になれば幸いです。

考え方の変化

最適化の導入当初は、最適化とは「普段はこう打つが特定の文字列が連続したときだけこう打つ」という例外パターンを増やしていくことだと思っていました。 つまり、「y は普段は y4 で打つ、但し直後に u が続いた時のみ yu47 で打つ、といった例外パターンを追加していく」ことが最適化だと思っていました。

が、実際には「nu67 と yu47 しか練習していないのに nyu647 が」「try437 しか練習していなかったのに tory4837 が」咄嗟に適用されるなど、 練習していないはずの文字列に最適化が勝手に適用されるケースが散見されました。 このことからすると、私にとっての最適化は

  1. 各指のポジションがずれた状態での固定運指を複数覚え、
  2. 打鍵中忙しい指をサポートする形で複数の固定運指を適宜切り替える

という感覚に近いのではないかと思い始めています。

また最適化適用のタイミングについても、当初は「最適化箇所には必ずその運指を適用しなければならない」と思い込んでいました。 おそらくこれはそれまでの固定運指の考え方を引きずっていたのだと思います(あくまで「一つの固定運指における例外適用」という感覚を持っていた)。

が、最近はそこまで厳格に考えておらず、

  • 同じ文字列であっても常に同じ運指で打つ必要はない (前後の文字列で最適な運指が異なる)
    • yu は直前の文字によって 47, 78 の両方があり得る
      • 最悪 77 でも良い fyu-4779 とか
    • oko878 はかなり速いが、「もこもこ」などでは oco とした方が速い
      • 逆に「ぼこぼこ」などでは oko の方が速い *6
  • また最適化可能な文字列についても「反応できたらラッキー」くらいに思っていて十分効果があり、ストレスも少ない
    • furahura47417841 とか中途半端になってもやらないより大分得
    • また cacuco などもローマ字読みのため、先読みが間に合わないこともある その時は諦める

くらいのユルい気持ちで、「あくまで基本運指をベースに、最適化可能箇所はボーナス」と考えるようになってきました。*7
感覚としては「自分の最適化無しでの理論値が常用26秒、そこから最適化1回ねじ込むごとに0.1秒、10ヶ所入れば1秒縮んで25秒」くらいのつもりで打っています。*8

最適化による影響

当初最適化による恩恵は、当初「該当文字の入力速度の向上」に留まると思っていました。 がそれはあくまで見た目上の効果であり、実際はそれだけでなく「同指連続打鍵の排除によって打鍵・先読みリズムが一定になることで得られる安定性への寄与が大きい」ということが分かりました。*9

また、最近日本語読みが以前よりできるようになったのですが、 これはどうやら単語認識速度が上がったことによる結果であり、 もしかしたら最適化の導入が関節的に影響したのではないかと思っています。
すなわち、これまでは打鍵速度に対して認識速度が十分であったためそれ以上鍛えられる機会がなかったのですが、 認識 → 打鍵 の間に「最適化により運指構築」というステップが加わったためこれまでの認識速度では足りず、 結果的に認識力が鍛えられたのではないかと思っています。

最適化によるデメリットですが、疲れているときには最適化の成功率が下がるため、脳への負担は明らかに増えていると思います。 しかし、今のところは「最適化を意図的に使わないで打つ」ということは問題なくできているため、 懸念していた「最適化導入前より遅くなる」ということは起きていないようです。

練習方法について

今年採った方法は、「特定の連続打鍵を含む練習ファイルを作ってひたすら打ち込む」でした。 が、実際にやってみると特定の連続打鍵であっても別の最適化を導入した方が打ちやすいケースもあり、*10 これらは「同じ最適化を使う文字列同士でまとめたファイルを作って」練習するのが効果的なのではないかと思い始めています。

また今回の方法は、「特定の指が特定の位置にある状態での他のキーの位置把握を定着させる」のには有効でしたが、 「基本運指からその状態にシフトする/戻す」という練習ができておらず、そのためたとえば 「既に右手人差し指が t の上にあれば t7 で最適化された打鍵ができるが、通常のタイピング中に t7 の場面が出てきても反応が遅れたり移動に失敗したりする」 ということが起きてしまっていたように思います。 ある程度頻度の高い最適化については日常の中で徐々に慣れていくことも可能だと思いますが、 頻度の少ない最適化については「該当の最適化ワードを 2~3 割だけ入れた練習ファイル」を使った練習を併用するのが良いのではないかと思い始めています。

n6, m6

去年あれほど有用と感じた右手親指 (n6, m6) の導入ですが、最近は去年ほど多用していません。 それは以下のような理由です。

  • かなり余裕を持った先読みが必要
    • 親指を n, m に持って行くのも戻すのも時間がかかる
  • 単発では効果的だが前後の文字列次第ではずっと親指で耐えることになり遅い
    • rizumuninorenuyatu などで rizum48176... と打ち始めてしまうと、以降の n, m のラッシュで親指を抜くタイミングが難しい
  • 練習している他の最適化とあまり相性がよくない
    • k7, b7, t7 など右手人差し指の可動範囲が増えてきたため、親指の空間把握が難しい
    • bu78, hu78 の習熟に伴って u8 の感覚が分かってきたため、nu78, mu78 の可能性が出てきた
  • 日常使いにあまり適さない
    • 腕ごと前に出すような感覚のため疲労が大きい
    • キーボードを選ぶ

n6, m6 自体は今も有用だとは感じていますが、 いつも適用するというよりは「他の最適化ができなかったときの緊急避難先」くらいに思っておくと良いのではないかと最近は思っています。

最後に

一応現状の運指を載せておきます。

f:id:permil:20181114013801p:plain:w350
2018 年現在の私の運指 (練習中のものも含む)

また今後導入する可能性のある最適化の候補としては以下のようなものを考えています。

  • 英文和文共通
    • nu78, mu78
    • ju78
  • 主に和文向け
    • nm78
    • za21
    • nki798, kin897
  • 主に英文向け
    • de32
    • sw32
    • cr43
    • hy78
    • I'm876

ただ、これはあくまで私の基本運指に対して優先度の高そうな最適化であることにご留意ください。 私は c4 や o8 ですが、これがもし標準運指の c3 や o9 だった場合、 英文の最適化としては上に挙げたものよりも ce43 や lo98 などを優先度高く検討すべきではないかと思います。

そのため、最適化の導入を検討する場合、一般的に知られる最適化をただ導入するのではなく、 自分の基本運指に対して優先度が高く相性の良いものを選択し、 また必要に応じて自分の基本運指に適切な最適化を考えていくことが重要なのではないかと思います。*11

*1:b7, h7 はそれぞれ特定の文字列で稀に使える程度だったため除いてあります。

*2:最終的にこの形になるまでは紆余曲折がありましたが、ざっくり書くと ①o8 は遠いので o9 ②和文と揃えたいので u8 ③brim7498 を考慮して i9 ④brilliant で指が足りなくなったので仕方なく l0、という流れでこのようになりました。

*3:音ゲーで例えると、IIDX で皿が多いときに別運指に切り替える感覚に近かったのではないかと思います。

*4:この判断が正しかったどうかはまだよく分かりません。というのは e の直後にさらに a や w が来るケースも多く(great, grew, ...)、小指の精密動作を要求されるからです。また e が連続した場合 (green, free, ...) の薬指の連打速度もさほど高くありません。そういった意味では gr74, tr74 あたりと併用できるのが理想かもしれません。

*5:後から気づいたことですが、和文では u, i, o, k あたりの頻度が高く右手が忙しい (だから c や z の導入が有効) のと比較すると、英文では k, u あたりの頻度はあまり高くなく、e, r, t, s, d, c あたりの頻度が高いためむしろ左手の方が忙しい印象があり、英文で右手の担当範囲を増やすのは妥当な判断であったように思います。

*6:この辺り、特に c/k の打ち分けについては練習の中で徐々に「この辺は右手忙しいから c に逃げよう」といった感覚が身についていった気がします。

*7:賛否あると思いますが、私の最適化精度は現状まだ理論値を目指せるような段階ではないため、最初から100%を目指すのではなく少しずつ精度を高めていこうと考えています。

*8:これは、ベースに固定運指が染みついていて、最適化に失敗したとしても基本運指で打てば良いという安心感があればこその考え方かもしれません。

*9:たとえば、最適化導入前は br を打つ際 b の後は先読みと他の指を一瞬緩めるということを無意識に行っていましたが、br74 導入によってこれが必要なくなり、たじさくそうまごウェルのように一定の速度で打鍵・先読みができるようになりました。

*10:同じ tr でも try では tr43 が有効だが attract では t7 が有効、同じ ny でも company では ny74 が有効だが anything では ny67 が有効といったように

*11:もちろん、一般的に有効とされる最適化を知ることは「どのような最適化があり得るのかを知る」という意味で重要です。たとえば ki98 などは私の発想にはない最適化でした。が、ki98 と ki89 のどちらが有効か (または両方か) というのは、個々人の基本運指や打鍵姿勢、指の長さなどに依るところも大きく、その辺りも最適化が「人による」と言われる所以なのではないかと思います。