鍵盤配列の『乗り換え』が必要になったとき、どういう考え方で「ステップ先(経由地)」と「ジャンプ先(目的地)」を探せば良いのだろうか……。
……ってのが気になったので、ちょっと「(私が認識しているところの)親指シフト相関図」ってのを描いてみた。
「ホップ(現在使用中の配列)」から「ステップ(経由地)・ジャンプ(目的地)」の2段階乗換えだけで【各ユーザーさん自身にとって、確かに合うと考えられる配列へと到達できる】ようにするためには、こーゆー「配列関係図*1」が必要なのかも……って考えのテストをしてみたところです。
図上に「月配列Ux」が必要となる関係で、むりやり他の月配列系についても押し込んでる……のですが、月配列系の相関図についてはアヤシサ満開なので、詳しい方に再整理していただかないとダメっぽい感じです。
それから、親指シフト系配列の相関図本体についても、けっこういい加減に矢印で結んでるところがある……ので、ヘンなところ・違うところがあったらご指摘ください。
この図上でのポイントは、まんなかあたりにある「QWERTY」と「Dvorak」のふたつ。これらは「拡張QWERTYローマ字入力」とか「拡張Dvorakローマ字入力」って意味を含んでいるのと同時に、「QWERTY英字配列的な運指」とか「Dvorak英字配列的な運指」って意味も含んでいます。
……で、これを使って何が出来るか？ってゆーと、これをきちんと作れば「ホップ配列(Qwerty/Dvorak)」から「ステップ配列」へと移るときに、何を選べば良いか……ってのと、そこから「ジャンプ配列」にいたる必要があるかどうか……ってのを、大まかに推測できそうだ、ってこと。
以下の「推測パターン」は、あくまでも『上の相関図』と『私の独断と偏見』に基づくもの……なので、なんか変だよ？ッてところはたくさんあると思います……が、まずはたたき台として作ってみました(ので、ご意見についてはコメントorトラバ頂きたく)。
推測パターン１：かえでライティあすか経由の場合。
たとえば……「かえでライティあすか」ってのは、周辺配列に対してこういう特徴があります。
| 配列名 | 引き継いだor持っているもの | 置いてきたor持ってないもの |
|---|---|---|
| 小梅 | 覚えやすさ・忘れにくさ | 同置特有のテンポ感 |
| Qwerty | 運指範囲・運指の癖 | 過剰な打鍵数 |
| 飛鳥カナ配列 | 配列骨格・運指動作の主特性 | 過剰な最適化配列 |
| かえでレフティあすか | かえで＊＊＊＊あすかの主特性 | 右手への負荷寄せ |
このとき、「ホップ配列(Qwerty)」を使ってた人が、ステップ配列として「かえでライティあすか」を選んだとき、そこで得た感触を元に「たどり着くべきジャンプ配列」が、ある程度明確に選出できるはずです。
| 「かえでライティあすか」で気になったところ | 乗り継ぎ先提案 |
|---|---|
| 清濁同置のテンポ感が欲しい・覚えにくい | 小梅配列 |
| 甘すぎる・もっと最適化してるほうが良い | 飛鳥カナ配列 |
| 鍵盤をもう少し広く使いたい | 鶯配列 |
| 左右負荷が逆じゃないとヤだ | かえでレフティあすか |
推測パターン２：親指シフト(NICOLA)経由の場合。
たとえば……「NICOLA」ってのは、周辺配列に対してこういう特徴があります。
| 配列名 | 引き継いだor持っているもの | 置いてきたor持ってないもの |
|---|---|---|
| 新JISかな | 清濁同置のテンポ感 | 配列設計に掛ける人的・時間的コスト |
| Dvorak | 運指範囲・運指の癖 | 過剰な打鍵数 |
| 小梅 | より厳格なシフト規則 | 調停頻度文字の覚えやすさ |
| 月配列Ux | 同時打鍵操作 | 1本指操作への対応意思 |
このとき、「ホップ配列(Dvorak)」を使ってた人が、ステップ配列として「親指シフト(NICOLA)」を選んだとき、そこで得た感触を元に「たどり着くべきジャンプ配列」が、ある程度明確に選出できるはずです。
| 「親指シフト(NICOLA)」で気になったところ | 乗り継ぎ先提案 |
|---|---|
| すばやい運指で高い効率を出したい | 新JISかな |
| 高頻度かなより、低頻度かなのわかりやすさを！ | 小梅配列 |
| キーボードを選ばず、似た操作感が欲しい | 月配列Ux |
| Dvorakッぽさを残しつつ、シフト率を下げたい | TRONかな |
この図からわかる、たった一つのこと。
それは、親指シフト系の配列が「NICOLA」「TRONかな」「飛鳥カナ配列」の3つしかなかった時代は、相当に「乗り継ぎしづらい・合うかどうかわかりづらい」状態だった……ってこと。
特に、昔私がやってひどい思いをした「Qwerty→NICOLA→飛鳥カナ配列」って乗り継ぎ手順が、どんだけメチャクチャだったのか……ってのを、この図で表そうとしています。
「ホップ(現在地)」から「ステップ(経由地)」を経由するのは最大1箇所で、あとはそのまま「ジャンプ(目的地)」へとたどり着ける……ってゆー、そーゆーのを目指したいところで。
この状態だと、まだまだ難しいところはある……ので、そのうち「(マルチシフト対応の)楓配列」をまともに整備するなどして、「ハブとしての、一つのステップ(経由地)配列」から、色んな配列へと一発で「ジャンプ(目的地)」へとたどり着ける方が良いのかな……とか考えてみたり。
あるいは、「ハブとしての、一つのステップ(経由地)配列」を、最大2つまで許容する代わりに、実用配列を乗り継ぐだけでいけるようにするとか、そーゆー方向に持っていくという手もあるかも。
いずれにせよ、色んな配列へとたどり着くための「ハブ配列」をいくつか見つけ出さないと、この計画は上手く行かない……ので、そのあたりでアレコレ実践しつつ検討してみるつもりです。
……で、こーゆーときにこそ『かえで＊＊＊＊あすか』みたいなのが活きないと、作った意味がないというか……これがハブ配列足りえるのか否か……ってのも含めて、チェックしてみるつもりです。
ちなみに、ハブ配列ってのはこーゆー使い方をする以上、ハブ配列であるがゆえに「ありとあらゆる方向からボロクソに評価される」事が、はじめから確定してる……ので、私としては「評価が下がるとまずい配列」をハブ配列に指定するのはマズいと考えてます(ので、Qwertyサークルからの1次乗り換え配列を『かえでライティあすか』にしました)。Dvorakから移るときのハブ配列として、ひとまず距離的な問題で「NICOLA」を指定してる……のですが、正直『NICOLAがボロクソに評価される』ってことがあると作戦遂行上マズいので、なんか別の(ボロクソに評価される覚悟を持ってる人が作った)配列をハブ配列にしなきゃダメッぽいところが難しいです。
『ハブ配列』に必要な要素。
……これは2つしかない。
- 『○○というハブ配列はクソだ！』といわれても、顔を赤くして論破しようとしたりする『作者＆ユーザー』が皆無な配列であること──これは絶対条件。文句や不満点を【使い手から具体的に引き出して、次の乗り換え先についての見地を得る】ための環境を提供するのが『ハブ配列』に求められる「周辺環境」であって、それが実現できなきゃ無意味になってしまうから、引止め工作をしたりするユーザーとかがいる配列は(この目的に限っては)まったく使い物にならない。
- QwertyもしくはDvorakの運指動作から遠すぎず、かつジャンプ先の特性から遠すぎない「中途半端な特性」であること──これは十分条件。『ハブ配列』を2段階のパスで構成するときには、この距離感についてもよく検討する必要があると思う(近すぎると『2段ハブ』としての意味がなくて、乗り換えコストをムダに押し上げる原因になる……それは絶対に避けたい)。
……ってことで、この条件を満たすものを探す(なければ作る)必要がある、と。
あとは、全体が固まり次第『全てのハブ配列』と『主要なジャンプ(目的地)』を収容可能なエミュレータ向けに、配列定義を各人が提供すれば、乗り換えのための基本的な環境は整う……ってことになる、はず。
そこまでどれくらいの期間が掛かるかは、まだ読めてない……けど、可能な限り早いところ「初版リリース」を行いたいと思う。
#それにあわせて『鍵盤配列wiki』とかも構造を変える必要があるかも。
*1:そのまんま、ある配列の○○と、ある配列の○○を基に作った……ってゆー『関係』を描いた図。これは「作者がそれを目指して作った」ものなので、そのまんま「乗り換えを希望する人にとってのヒント」として十分に使える。
