そして「ね」が残った。

1.3.2 版の時もそうでしたが、今回もまた収束感を強く抱いています。「完成した」みたいな手応えというよりも、むしろ「もはや打つ手なし」という手詰まりな感じ。投了と呼ぶのが似合いそうです。［Ｎ］に追いやられた「ね」がいまいち気に入っていませんが、かといって他に置き場所があるはずもなく。もしかしたら仕様と呼ぶしかないのかもしれません。

「ね」の 2-gram ベスト5

「ね」というカナは文末の、それも句点の直前にくるイメージが強いですが、最も多い連接は意外にも時節を表す「年」でした。「ネコ」がランクインしていたりするあたりに、10万字サンプルの素材選びのユニークさが現れています。

順位	「ね」が1文字目				「ね」が2文字目
	ね〜	運指	打鍵率		〜ね	運指	打鍵率
			絶対値	相対値			絶対値	相対値
1	ねん	NJ	0.08%	20.56%	すね	,N	0.04%	10.05%
2	ね。	NQ	0.08%	18.69%	んね	JN	0.04%	9.81%
3	ねが	ND	0.04%	9.58%	おね	UN	0.03%	7.24%
4	ねこ	NA	0.03%	6.78%	よね	CN	0.02%	5.37%
5	ねっ	NN	0.02%	5.84%	いね	KN	0.02%	5.37%

運指は 修正案2 のもの。強調は同指異鍵または同鍵連打 を示す。

1-gram の打鍵頻度は 0.41%（57位）とそれほど高くはないのですが、自己主張の強さは小粒でもぴりりと辛い山椒クラスと言えるでしょう。

流浪の「ね」

「ね」は左手側に置こうとあれこれ試行錯誤を重ねたにも関わらず、アクの強さが災いして、結局は諦めて右手側に戻したカナでした。ここしばらくは「，」に落ち着いていましたが、最後の最後で安住の地を「わ」に奪われてしまいました。いかに放浪してきたのか、節操のない遍歴ぶりをご覧ください。

日付	版	「ね」
2009-06-29	修正案2	N
2009-06-22	修正案1	，
2009-05-03	1.3.3	，
2008-10-04	1.3.2	，
2008-02-12	1.3.1	，
2008-01-17	1.3.1 RC	，
2007-12-24	1.3.1 beta1	，
2007-10-28	1.3.0	，
2007-10-17	1.3.0 beta23-2	，
2007-08-30	1.3.0 beta23	，
2007-07-14	1.3.0 beta22	，
2007-07-05	1.3.0 beta21	，
2007-07-04	1.3.0 beta21	，
2007-07-04	1.3.0 beta21	，
2007-07-03	1.3.0 beta20	，
2007-06-19	1.3.0 RC2	，
2007-06-14	1.3.0 beta19-5	，
2007-06-13	1.3.0 beta19-4	，
2007-06-12	1.3.0 beta19-3	，
2007-06-04	1.3.0 beta19-2	，
2007-06-01	1.3.0 beta19	，
2007-05-26	1.3.0 beta18	，
2007-05-23	1.3.0 beta17	，
2007-05-16	1.3.0 beta16-3	S
2007-05-08	1.3.0 beta16-2	S
2007-05-01	1.3.0 beta16-1	G
2007-04-28	1.3.0 beta16	S
2007-04-24	1.3.0 beta15	R
2007-04-21	1.3.0 beta14-1	R
2007-04-20	1.3.0 beta14	R
2007-03-30	1.3.0 beta13-7	C
2007-03-25	1.3.0 beta13-6	R
2007-03-21	1.3.0 beta13-5	G
2007-03-20	1.3.0 beta13-4	R
2007-03-17	1.3.0 beta13-3	R
2007-03-16	1.3.0 beta13-2	R
2007-03-08	1.3.0 beta13	R
2007-02-28	1.3.0 beta12-9	R
2007-02-16	1.3.0 beta12-8	R
2007-02-07	1.3.0 beta12-7	R
2007-01-28	1.3.0 beta12-6	R
2007-01-27	1.3.0 beta12-5	R
2007-01-26	1.3.0 beta12-4	S
2007-01-16	1.3.0 beta12-3	C
2007-01-14	1.3.0 beta12-2	C
2007-01-11	1.3.0 beta12	C
2007-01-09	1.3.0 beta11	C
2007-01-05	1.3.0 beta10	R
2006-12-30	1.3.0 beta9-2	R
2006-12-30	1.3.0 beta9	E
2006-12-27	1.3.0 beta8	E
2006-12-24	1.3.0 beta7	V
2006-12-17	1.3.0 beta6	V
2006-12-15	1.3.0 beta5	V
2006-12-14	1.3.0 beta4	V
2006-12-11	1.3.0 beta3	V
2006-12-07	1.3.0 beta2	V
2006-12-04	1.3.0 beta1	B
2006-12-04	1.3.0 #5	B
2006-12-02	1.3.0 #4	B
2006-12-01	1.3.0 #3	B
2006-11-30	1.3.0 #2	B
2006-11-29	1.3.0 #1	B
2006-11-25	1.23	，
2006-11-07	1.23 RC2	，
2006-11-03	1.23 RC	，
2006-11-01	1.23 beta3-2	，
2006-10-31	1.23 beta3	，
2006-10-29	1.23 beta2	，
2006-10-26	1.23 beta1	，
2006-09-17	1.22	，
2006-09-05	1.22 RC2	，
2006-09-03	1.22 RC1	．
2006-09-02	1.22 RC	．
2006-09-01	1.22 beta7	，
2006-08-31	1.22 beta6-2	，
2006-08-29	1.22 beta6	．
2006-08-28	1.22 beta5	U
2006-08-21	1.22 beta4	U
2006-08-19	1.22 beta3	．
2006-08-18	1.22 beta2	．
2006-06-11	1.21	．
2006-05-03	1.2	．
2006-03-26	1.11	．
2006-03-25	1.1	．
2006-03-14	1.01	C
2006-03-11	1.00	C

関連記事

さらに安全な論理配列を求めて（3）。

2009-07-05

さらに安全な論理配列を求めて（2）。

2009-06-29

さらに安全な論理配列を求めて（1）。

2009-06-22

さらに安全な論理配列を求めて（3）。

3種類のグラフを掲載します。［Ｒ］に注目してご覧ください。1.3.3 版では同手シフトに「わ」を置いていたのを、修正案2 では「ぬ」に差し替えています。

キー別打鍵頻度グラフ

等高線グラフ

同手シフト頻度グラフ

［Ｒ］の同手シフト。

連接がどうのこうのとか言う前に、［Ｒ］同手シフトの単独打鍵を繰り返すだけで、慢性腱鞘炎っぽい私の左手人差指第2関節が痛み出します。はっきりとは検証できませんが、もしかしたら［Ｔ］の同手シフトを繰り返すより痛いかも。1.3.1 〜 1.3.3 版では出現率0.82%（41位）の「わ」を置いてきましたが、さらに安全な論理配列を標榜するにはもっと減らさないとダメだと結論付けます。

関連記事

さらに安全な論理配列を求めて（2）。

2009-06-29

さらに安全な論理配列を求めて（1）。

2009-06-22

久しぶりに新しい親指シフト配列が生まれたけれど。

よろしければスレから転載します。

415 ：名無しさん：2009/06/29(月) 00:55:00 0
配列作った。(かな系親指シフト)
[シフト無]
ま、。てじ　ごがくにす
たんうしな　はといかの
つきでるげ　もょこっら
[同手シフト]
ろりさやぎ　ぢどよけほ
おちーせば　そだれあを
ふみわひぅ　ゃゅえめぶ
[逆手シフト]
ふぃ　ぽ　ざ　ぐ　　ふぉ　　ぃ　づ　ゆ　　へ　てぃ
ぷ　　ぼ　べ　ぜ　　ぱ　　　ぞ　ず　ね　　む　び
ふぇ　ぬ　ぺ　ふぁ　ぉ　　　ぁ　ぇ　うぇ　び　でぃ

これは10万字サンプルでは解析できません。10万字サンプルで計算できるのは、今までは「親指シフトだけ」と呼称してきましたが、正確には「打鍵と出力が1対1で呼応する論理配列だけ」です。

10万字サンプルで取り扱える打鍵と出力の組み合わせ

	同時打鍵を含む打鍵数	出力されるかなの数	取り扱いの可否
中指シフト系	1または多	1	否
一般的な親指シフト系	1	1	可
文字キー同時打鍵系	1	1または多	否
行段系	1または多	1または多	否

前にも書きましたが、多対多はおろか1対2や2対1の組み合わせでも Excel で計算できる方法を思い付かないので、現状では仕様とさせていただきます。悪しからず。

さらに安全な論理配列を求めて（2）。

Nicola 時代の経験 から避けてきた、「い」と「わ」が同指異鍵となるパターンを試します。左手側は修正案その1と全く同じです。

強調 は 1.3.3 版との差分です。

修正案その2

無シフト面

１ ２ ３ ４ ５ ６ ７ ８ ９ ０ − ＾ ￥
 。 な て せ そ ・ お の に ， 、 ：
  こ た か る は ー ん い し と BS ESC
   ． ゅ ょ ろ ゃ っ う す ら え ＿

左シフト面

？ ／ 〜 「  」 ＆ ’ ＜ ＞ ＋ ＝ ‘  ｜
ぺ つ も ぬ ぅ ゎ び ぎ げ  」 ゛ ゜
  め を ま さ や ぃ ぁ ぐ じ ど BS ESC
   ゆ ほ よ ふ ヴ ぉ ぇ ず ぢ べ ！

右シフト面

！ ” ＃ ＄ ％ ［ ］ （ ） ｛ ｝ 〓 〓
ぱ づ で ぜ ぞ 〓 ひ き け 「  ＊ ；
  ご だ が ざ ば む れ く り あ BS ESC
   ぽ ぼ ぷ ぶ ぴ ね み わ ち へ ？

〓 は未定義。

小指シフト面

！ ” ＃ ＄ ％ ＆ ’ ＜ ＞ ＾ ＝ ‘ ｜
 Ｑ Ｗ Ｅ Ｒ Ｔ Ｙ Ｕ Ｉ Ｏ Ｐ ＠ ［
  Ａ Ｓ Ｄ Ｆ Ｇ Ｈ Ｊ Ｋ Ｌ ； ： ］
   Ｚ Ｘ Ｃ Ｖ Ｂ Ｎ Ｍ ， ． ／ ＿

左手人差指 前後の打鍵を分解

絶対値での比較。

絶対値

全体で100打鍵した時、該当する打鍵がどれくらい発生したかを示す。

各レコードの合計は、左人差指の打鍵率に等しい。

前の打鍵は「どの指から左人差指に来たか」を、次の打鍵は「左人差指からどの指へ行くか」を分解したグラフです。

左手人差指の打鍵率が 1.33 版の 11.0% から 10.2% へと 0.8 ポイント下がり、指が楽になったのが実感できます。

相対値での比較。

相対値

左人差指を100打鍵した時、該当する打鍵がどれくらい発生したかを示す。

各レコードの合計は100％。

右手人差指 前後の打鍵を分解

絶対値での比較。

絶対値

全体で100打鍵した時、該当する打鍵がどれくらい発生したかを示す。

各レコードの合計は、右人差指の打鍵率に等しい。

前の打鍵は「どの指から右人差指に来たか」を、次の打鍵は「右人差指からどの指へ行くか」を分解したグラフです。

指別のバランスだけを見るなら、修正案1は右人差指の打鍵率の高さが気になります。Tron の22.0% に比べれば、まだまだ低い水準ですが。

1.3.3 版以前の 右手人差指の打鍵が連続することを最も嫌っているのが小梅配列 1.3.2 版でした というほどではなくなってしまいましたが、それでもまだ他配列比で右手人差指の連打が少ないと言えるでしょう。

相対値での比較。

相対値

右人差指を100打鍵した時、該当する打鍵がどれくらい発生したかを示す。

各レコードの合計は100％。

右人差指前後の打鍵と同手跳躍。

前回と同様に、右人差指の前後の打鍵が同手跳躍となる場合の数値を抽出しました。左手側は同手跳躍にはなりえませんから、この表では対象外となります。分子がかなり小さいので、比率ではなく発生数で示します。

	前の打鍵				次の打鍵
	右差	右中	右薬	右小	右差	右中	右薬	右小
修正案その2	272	277	170	110	272	586	458	145
修正案その1	265	311	173	162	267	610	558	126
小梅 1.3.3	233	259	159	85	233	590	453	124
小梅 1.23	131	158	194	96	131	213	149	37
Nicola	221	128	185	257	219	218	117	16
Tron 2005-1011	743	323	218	252	740	338	122	268
かえであすか	34	344	190	162	34	376	333	124
飛鳥 21C-372	27	266	233	102	27	302	290	51
飛鳥 21C-341	122	355	228	97	122	391	372	127
飛鳥 21C-290	27	343	188	120	27	376	334	87

10万字サンプルの分母は104,357で、104,357分の272は0.26%に相当します。前回の記事 には計算ミスが含まれていたようで、数値が若干異なります。おっと、よりによって Tron の数値が全然違いますね。

計算条件を変更するのに前回は 4 × 2 × 3 × 11 = 264 セルを手動で書き換えていたのを、今回はプルダウンメニュー1つの変更が 264 セルに反映されるように自動化しています。おそらくは今回の計算が正しいとは思うものの、前回どこで間違えたのかが再現できないので、説得力ありませんねぇ。「同じ式で計算すると、配列ごとに数値はこれだけ違う」と相対的に見てもらうしかないのかもしれません。

本日の配列

「いわ（ない）」は打ちにくくても「（おも）われ」が打ちにくいよりはマシなのかなとは思うものの、「おね（がい）」が同指跳躍なのはどうだろう、と。しばらくは評価打鍵に勤しみます。

関連記事

さらに安全な論理配列を求めて（1）。

2009-06-22

右人差指の前後の打鍵を分解する。

2009-02-12

さらに安全な論理配列を求めて（1）。

小梅配列の「左親指」キーが［スペース］キーな理由。に掲げたデータから、左人差指の打鍵率をさらに下げた方がいいのかなと。「ぬ」が［Ｂ］にあると、「せぬ」「わぬ」といった否定形を多用した場合に厳しい、というのも動機の一つです。

［Ｒ］のシフト側にあった「わ」をどこに持っていくかが、次版の焦点となりそうです。とりあえず［Ｍ］に置いて試してみますが、追い出されて［Ｎ］に移動した「み」と併せて、じっくり検討します。

強調 は 1.3.3 版との差分です。

修正案その1

無シフト面

１ ２ ３ ４ ５ ６ ７ ８ ９ ０ − ＾ ￥
 。 な て せ そ ・ お の に ， 、 ：
  こ た か る は ー ん い し と BS ESC
   ． ゅ ょ ろ ゃ っ う す ら え ＿

左シフト面

？ ／ 〜 「  」 ＆ ’ ＜ ＞ ＋ ＝ ‘  ｜
ぺ つ も ぬ ぅ ゎ び ぎ げ  」 ゛ ゜
  め を ま さ や ぃ ぁ ぐ じ ど BS ESC
   ゆ ほ よ ふ ヴ ぉ ぇ ず ぢ べ ！

右シフト面

！ ” ＃ ＄ ％ ［ ］ （ ） ｛ ｝ 〓 〓
ぱ づ で ぜ ぞ 〓 ひ き け 「  ＊ ；
  ご だ が ざ ば む れ く り あ BS ESC
   ぽ ぼ ぷ ぶ ぴ み わ ね ち へ ？

〓 は未定義。

小指シフト面

！ ” ＃ ＄ ％ ＆ ’ ＜ ＞ ＾ ＝ ‘ ｜
 Ｑ Ｗ Ｅ Ｒ Ｔ Ｙ Ｕ Ｉ Ｏ Ｐ ＠ ［
  Ａ Ｓ Ｄ Ｆ Ｇ Ｈ Ｊ Ｋ Ｌ ； ： ］
   Ｚ Ｘ Ｃ Ｖ Ｂ Ｎ Ｍ ， ． ／ ＿

本日の配列

カウントダウンはリセットです orz

小梅配列の「左親指」キーが［スペース］キーな理由。

実を言うと、理由はそんなに単純ではなかったりします。

まずは前提条件を一つ掲げます。

• ［Ｆ］キーや［Ｃ］キー直下の［無変換］キーを「左親指」キーとする。
• ［スペース］キーの［Ｇ］キー直下あたりを「左親指」キーとする。

左手の人差指伸領域（ＴＧＢ）は、後者の方が無シフトもシフト側も打ちやすくなります。この前提を踏まえたうえで、ここから先をお読みください。

次項は、かえでさんのところに私がコメントしたもの を丸ごと転載しています。

［スペース］キーを「左親指」キーにするメリット。

［スペース］キーを「左親指」キーにするメリットとして、以下の2点が掲げられます。

1. ［無変換］キーがどこに配置してあっても（論理配列としては）問わない。
2. 左手の人差指伸領域が打鍵しやすい。

前者は極端な話をすれば、［Ｚ］キー直下に［無変換］キーがあっても、私自身は［無変換］キーを多用するので困りますが、小梅配列としては関与しません。

【表1】10万字サンプルにおける左人差指の打鍵率

	RFV	TGB	左差指計
Nicola	6.70%	6.41%	13.11%
小梅 1.3.3	7.23%	4.58%	11.81%
かえであすか	8.74%	0.47%	9.21%

後者の左人差指伸領域が打ちにくいことに対して、［スペース］キーを「左親指」キーとすることで改善を図った小梅配列と、左人差指伸領域を使わないこととした飛鳥系と、アプローチは極端に分かれました。

Nicola でも［スペース］キーを「親指」キーとすることで人差指伸領域の打ちにくさを改善できるメリットは享受できるはずなんですが、［スペース］キーを左右どちらの「親指」キーとするかという問題が残ります。

【表2】10万字サンプルにおける右人差指の打鍵率

	YHN	UJM	右差指計
Nicola	6.13%	9.73%	15.86%
小梅 1.3.3	3.04%	12.86%	15.90%
かえであすか	2.21%	13.39%	15.60%

小梅配列では、［Ｙ］キーをカナの入力には使わないことも含めて、［スペース］キーを「左親指」キーにした方がメリットがより大きいと言えます。

以上のデータから、［無変換］キーを「左親指」キーとすることは、Nicola で OK だとするなら小梅配列で NG とする理由が見つかりませんが、［無変換］キーを「左親指」キーにした場合のメリットも同時に見つかりません。

繰り返しになりますが、［スペース］キーを「左親指」キーとすることで、

1. ［無変換］キーの配置は問わない
2. ［変換］キーは［Ｍ］直下にあればOK

なので、［無変換］［変換］キー両方の配置を考慮しなければならないケースよりも、若干ながらキーボード選択の余地が広がります。

［スペース］キーを「右親指」キーにしてもよかった？

Nicola で迷ってしまうのと同じ理由で、小梅配列でも［スペース］キーを「右親指」キーにしてもよかったはずです。［Ｎ］キー直下のあたりを「右親指」キーと決めて、［Ｙ］キーを含む右人差指伸領域を積極的に活用し、反対に左人差指伸領域は飛鳥系と同様に頻度の低いカナしか置かない。これによって、

• 最もデリケートな左人差指伸領域を極力使わないことで、左人差指を痛めてしまう確率を減らせる。
• 遅くて不器用な左手の使用頻度をさらに減らせる。

そのような設計にしてもよかったはずなのに、何故やらなかったのでしょうか。

右手を迷子にする右人差指伸領域。

小梅配列 1.2x 版の時代、［Ｎ］キーのシフト側に置いた「へべ」ペアが、右手を迷子にさせてしまう（＝ポジションを見失ってしまう）元凶となっていました。［Ｙ］［Ｈ］［Ｎ］キーに置くカナを吟味することで回避できるのかもしれませんが、清濁ペアの中で最も打鍵頻度が低い「へべ」でさえ迷子を生み出すとなると、ここに打鍵頻度の高いカナを配置することはためらわれます。

反対に左手側は、現在も［Ｇ］キーに「はば」という中〜高頻度の清濁ペアを置いていますが、これが原因で左手が迷子になることはありません。

結果として左人差指伸領域を多用した。

【表3】10万字サンプルにおける人差指伸領域の打鍵率

	TGB	左右差	YHN
Nicola	6.41%	≒	6.13%
小梅 1.3.3	4.58%	＞	3.04%
かえであすか	0.47%	＜	2.21%

結論として、小梅配列の「左親指」キーが［スペース］な理由を一言で説明すれば、「そのように作ってあるから」ということになります（笑）。

改めて、小梅配列は親指キーについて、

• ［スペース］キーを「左親指」キー
• ［変換］キーを「右親指」キー

とすることを前提としています。［スペース］キーを右手で操作して「変換／次候補」することが身体に染みついている方が小梅配列を試される時は、［スペース］キーと［変換］キーの機能を併せて入れ替えることを推奨します。

再チャレンジの価値あり？

「左人差指伸＜右人差指伸」は試してみる価値ありかも。時間と気力があれば、ですが orz

「親指シフト系新配列の作者」という立場。

まずは絶賛放置中で申し訳ない。忙しいとかいうのは大した理由ではなくて、とにかく書きたいと思わなかった。書きたいという衝動に駆られなかった。そういう時は無理をしないのが一番だと、私は信じています。

で、タイトルなんですが、これほど割に合わないポジションはないよなと、しみじみ思うわけで。肉体的には左手（＝非利き手）の人差指の関節を何度も痛めて、精神的にも Nicola オウムに何度も突かれ、飛鳥ワニからも執拗に噛み付かれ続けて、端から見てもホントに報われない。蜂鳥配列はともかくとしても、さら配列と翡翠配列は思い半ばにして鬼籍に入られてしまったのでしょうか。かえであすか配列と小梅配列は、これからも耐えていくしかないのでしょうね。

小梅配列の作者という立場も含めて、私ができること、私のやるべきことは、

1. 小梅配列を完成させること。
2. 小梅配列を含めて、親指シフト各配列の特徴を正しく説明すること。

この2点に尽きます。親指シフトの間口・裾野・理解を広げることで、親指シフトというシフト方式が使える環境が少しでも延命できるなら、私は努力を惜しみません。

ということで、本日の疑問です。

• スペースキーは利き手で打鍵する？それとも非利き手で？
• その理由は？

「親指」キーが独立した Nicola 専用キーボードを使っている方は右手と答えるでしょうが、親指シフトユーザーではない方も含めてどっちが多いんでしょうね。データがどこかに存在したりするんでしょうか。

小梅配列 1.3.3 版です。

公言した通り、1.3.3 #c をそのまま採用します。

強調 は 1.3.2 版との差分です。

小梅配列 1.3.3 版 シフト面別の文字配置

無シフト面

１ ２ ３ ４ ５ ６ ７ ８ ９ ０ − ＾ ￥
 。 な て せ そ ・ お の に ， 、 ：
  こ た か る は ー ん い し と BS ESC
   ． ゅ ょ ろ ゃ っ う す ら え ＿

左シフト面

？ ／ 〜 「  」 ＆ ’ ＜ ＞ ＋ ＝ ‘  ｜
ぺ つ も わ ぅ ゎ び ぎ げ  」 ゛ ゜
  め を ま さ や ぃ ぁ ぐ じ ど BS ESC
   ゆ ほ よ ふ ぬ ぉ ぇ ず ぢ べ ！

右シフト面

！ ” ＃ ＄ ％ ［ ］ （ ） ｛ ｝ 〓 〓
ぱ づ で ぜ ぞ 〓 ひ き け 「  ＊ ；
  ご だ が ざ ば む れ く り あ BS ESC
   ぽ ぼ ぷ ぶ ぴ ヴ み ね ち へ ？

〓 は未定義。

小指シフト面

！ ” ＃ ＄ ％ ＆ ’ ＜ ＞ ＾ ＝ ‘ ｜
 Ｑ Ｗ Ｅ Ｒ Ｔ Ｙ Ｕ Ｉ Ｏ Ｐ ＠ ［
  Ａ Ｓ Ｄ Ｆ Ｇ Ｈ Ｊ Ｋ Ｌ ； ： ］
   Ｚ Ｘ Ｃ Ｖ Ｂ Ｎ Ｍ ， ． ／ ＿

小梅配列 1.3.3 版の解説

特に異論がないようなので、利き手の強さを活かしているから、

1. 一般的な JIS キーボードで使える
2. 正確で素早い打鍵ができる

と訴求することを中心に加筆の予定です。

カウントダウン開始！

本日から1年間を猶予期間と定めて、期間内に改版要求が生じなかったら、それ以降は改版を行いません。

悲喜こもごも

• おめでとう！＞モジャイズミさん。
• ありがとう。そして、さようなら！＞キヨシロー。

行段系の作成に挑戦した。

今年も新作発表の日がやってまいりました。どうせならいつもと全く違うことを試してみようと、行段系に初挑戦です。

まずは、複数の文字キーの同時打鍵でカナが入力される、すなわち行段系なのに1アクションでカナが入力できる、ありそうでなかった新感覚の日本語配列を掲載します。しかも、促音や拗音も専用キーや文字キーの同時打鍵で入力できて、今どきの行段系配列として恥ずかしくない高機能さも自慢です。同時打鍵を1打鍵として数えるならば、カナ入力以上に省打鍵な日本語配列に仕上がりました。

げたならべv2

 〓 〓 〓 〓 〓 〓 〓 〓 〓 〓 〓 〓
  〓 〓 〓 〓 〓 〓 〓 〓 〓 〓 〓 〓
   〓 〓 〓 〓 〓 〓 〓 〓 〓 〓 〓

文字化けではありません。

〓（げた）を無秩序に並べただけと思われるかもしれませんが、評価打鍵の結果を踏まえて、打ちやすさと覚えやすさのバランスが保てる範囲内で、当初の配置に改変を加えてあります。げたならべv2としてリリースします。

話題の「ぬりげたならべ」化も、定義ファイルを差し替えるだけで対応できる予定です。

せっかくですから、配字方針のベースとなった配列も紹介しておきます。

とまとならべ

こちらも文字化けではありません。

見たまんま、実に単純明解。トマト言葉の効率的な入力に特化した行段系配列です。ただし、トマト言葉だけが日本語ではありませんから、一般的な日本語の入力に用いた場合の性能は担保しかねます。

残念ながら「げたならべv2」「とまとならべ」いずれも、ローマ字カスタマイズでは実装できません。現状では Windows 環境専用ですが、Microsoft IME では入力が全くできない可能性もあります。ご注意ください。

本日の配列 ♪

文字通り、並べただけ〜（を。

飛鳥配列の最新版 21C-374 を紐解く。（1）

これは是非とも解析しなければ！と思える配列に、久しぶりに出会いました。飛鳥配列の最新版 21C-374 は、

左手の同手シフト（裏）の発生を押さえ、手の移動を伴ったとしても左のアンシフト（表）の使用を増やす。

ことをテーマに据えて、左手側の「Ｄ」キー以外の同手シフトを徹底的に減らしたとうたっています。この狙いが正しいかどうかは評価打鍵するより他に方法はありませんが、狙い通りに実装されているかどうかは、計算でも確かめることができます。例によって10万字サンプルで紐解きます。

飛鳥 21C-374

左手側の同手シフトは、ＤとＥを例外として、徹底的に抑え込んでいることがよく分かります。

飛鳥 21C-368

「遠くの無シフトよりも近くの同手シフト」な飛鳥配列の最終版です。

かえであすか

こうやって分解すると、大同小異という言葉が浮かんできますね。

小梅 1.3.3 #c

小梅配列の場合は、「遠いキーほどシフトを減らす」ルールを採用しています。同手シフト・他手シフトともに適用されているのが、グラフからもお分かりいただけるかと。

Nicola

Nicola のメリットは親指シフトを採用したことだけ、と言いたくなるくらいの惨状です。

本日のまとめ。

	無シフト率	同手シフト率	他手シフト率	小指シフト率
飛鳥配列 21C-374	52.9%	20.8%	25.8%	0.5%
飛鳥配列 21C-368	49.4%	25.6%	24.4%	0.5%
飛鳥配列 21C-341	49.6%	24.6%	25.2%	0.5%
飛鳥配列 21C-290	48.1%	26.2%	25.3%	0.5%

飛鳥配列 21C-374 は狙い通りに実装されていることが、よく分かりました。ただし、グラフを眺める限りにおいては、改版の余地がまだあるように思えます。

また、かえであすか配列が「近くの同手シフトよりも遠くの無シフト」ルールを採用するかどうかにも、注目したいところです。

最後になりますが、

ところが、親指シフトでは「全て」でこの「指の力と掌の重さ」の両方で打つことが出来ないのです。

というのは、「逐次シフトの親指シフト」の同手シフトにおいても真だと思います。本来であれば、

• 指の力
• 掌の重さ
• 手首の力や勢い

が渾然一体となって文字キーの打鍵に使われるのに対して、「親指シフトの同手シフト」時は上記の掛かる力が文字キーと親指キーとに分散してしまいます。だから親指シフトで使うキーボードは、打鍵荷重の軽いものが適しているとされるのです。

あるいは今回の飛鳥配列の新ルールで、Tron や「さら配列」のようなアプローチが親指シフトとして成立しうると説明できることに、今さらながら驚いています。

KDF と DKJ を試してみた。

ホントにホントなんだな？　と、自分に突っ込みを入れるエントリーです（笑）。

不器用な「利かない手」の連打を避けて、速くて気持ちがいい「利き手」の連打を優先するのは、配列設計として大いに意味があります。KDF と DKJ をそれぞれ数十回ずつ素早く打鍵してどちらがミスが少ないか、試してみるのも面白いかと。どちらも交互打鍵と（左または右の）片手連打が1回ずつの組み合わせで、交互打鍵率が67%となる打鍵です。KDF は Nicola を、DKJ は小梅を模した打鍵例と言えるかもしれません。

こんな条件で試してみます。

• KDF の10秒間連打と DKJ の10秒間連打を3セット。
• ついでに KSDF の10秒間連打と DLKJ の10秒間連打を3セット。
• 打鍵速度は目いっぱい速く！
• アナログ時計の秒針を見ながらの打鍵なので、誤差はそれなりに。
• 結果は無修正で掲載。

言わずもがなですが、DLKJ は飛鳥配列を模したつもりです。

打鍵速度を変えて何回か試してみましたが、「脳内発声あり」にしたり、正確性を重視した打鍵を心がけたりすると、速度を恣意的にコントロールできてしまう（≒速度が一定しない）ことが分かりました。そこで、とにかく目いっぱいのトップスピードで入力しました。

では早速参りましょう。

10秒間でどれだけ入力できるか。

はみ出した部分も含めて、等幅フォントで表示します。フレーズを正確に打鍵できた部分は、123 または 1234 と数字に置換して掲載しています。強調は正確に打鍵できなかった部分 です。

KDF

	
123123123kf123kdkf123123123123123123123123123123123123123123kf123123123123123123123123123123123123dkfdkf123123dkf123dkfdkf
	
123123123kf123123dkf123123123123123123123kf123123123123123123123123123123123123123123123123123123123123123123dkf123dkf123
	
123123123123kdkfdkfdkfdkf123123123123123123dkf123123dkfdkf123123dkfdkf123123123dkf123123123123123dkfdkfdkfkf123123dkf123

DKJ

	
kdj123123123123123123123123123123123123123123123123123123dkdjkj123123123123123123123123123123dkdjkjdkdjkjdkdjkdjkdj123123123123123123ddjk
	
kdjkj123123123123123123123123123dk123123123djk123123123123123123123123123123123123dkdjkj123123123123123123123123123123123123dkdjkjdk123123dj
	
123dkdjkj123123123123123123123123123123123123123123123123123dj123123123123123123123123dkdjkjdkdjkdjkj123123123123123123123123123dkdjkdjkdjkdjkdjkjd

KSDF

	
12341234123412341234ksdkf123412341234123412341234ksf12341234123412341234123412341234123412341234ksdkf1234123412341234123412341234kskdfskdfskdfkdfskdfsk
	
123412341234k123412341234ksf123412341234kskdf1234123412341234123412341234123412341234123412341234ksdkf123412341234123412341234ksdkfskdfskdf1234
	
123412341234123412341234k12341234123412341234123412341234ksdkfsdkfsdkfkf12341234123412341234kskfksfskdf12341234123412341234kdf1234skdfskdf

DLKJ

	
ldkjldkj1234ldkjldkjldkjlkdjlkdjlkdjldkjldkjlkdjlkj12341234dlkdjlkdjlkdjlkj12341234dlkdjlkdjlkdlkdjlkdjlkdjlkdjlkdjldkjldkj12341234123412341234123412341234d
	
ldkjdkjl1234123412341234dlkdjlkj12341234123412341234123412341234123412341234123412341234123412341234123412341234dlkdjlkj123412341234123412341234123412341234djkld
	
dlkdklj1234123412341234123412341234dlkdjlkdjlkj123412341234123412341234123412341234123412341234123412341234123412341234123412341234123412341234dlkdjlkdj

試打結果。

数えるのが大変 orz

フレーズ	No	打鍵フレーズ数	成功フレーズ数
			発生数	比率
KDF	1	41	33	80%
	2	41	36	88%
	3	40	25	63%
	計	122	94	77%
DKJ	1	45	34	76%
	2	48	38	79%
	3	49	35	71%
	計	142	107	75%
KSDF	1	38	29	76%
	2	35	29	83%
	3	34	25	74%
	計	107	83	78%
DLKJ	1	39	13	33%
	2	40	33	83%
	3	38	31	82%
	計	117	77	66%

DLKJ の1回目で失敗を多発させてしまいましたが、これを除外すると成功率は左右でだいたい同じぐらいでしょうか。打鍵数は DKJ と DLKJ の右手のアルペジオを活用したフレーズの方が、明らかに多くなっています。

皆さんの追試を希望します！

利き手の強さを論理配列に活かす。

残念ながら、利き手である右手を活用した方が「ミスが少ない」ことを、このエントリーで証明することはできませんでした。しかし、打鍵速度の伸び代は利き手を活用した論理配列に分があることが、はっきりと分かりました。

積極的な理由

利き手の強さを打鍵の素早さとして活かせる。

消極的な理由

利かない手の限界を超えた負担を肩代わりさせる。

一般的なキーボードを使った親指シフトに必須の条件。

さらに言えば、打鍵速度の伸び代は Nicola ＜ 小梅配列 ＜ 飛鳥配列 の順で大きいことを、この試打結果は示しています。ただし、親指シフト動作や連続シフトが発生した時はどうなるのか、親指シフトはまだまだ分からないことだらけです。

蛇足ながら、Ray さんの言及には因果が逆転しているケースが少なからずあるので、慎重に見極めていかないと遠回りを強いられます。そこいらを少しずつ紐解いていくことも、かえでさんや私に残された仕事なのでしょうね。

関連記事

素材はいろいろあるけど、まとまらない。

2009-03-17

打鍵数＝負担度ではないと主張してみる。（2）

2009-02-26

打鍵数＝負担度ではないと主張してみる。

2009-02-24

小梅配列は右利き専用の日本語配列です。（補足）

2009-02-20

小梅配列は右利き専用の親指シフト配列です。

2009-02-19

素材はいろいろあるけど、まとまらない。

なにやら料理に失敗したみたいなタイトルですが（苦笑）。ぎっちょんさんのコメント に対する回答だったり、そうとも限らなかったり。

一番強い指は中指です。

マウスの左クリックと右クリックを入れ替えて、少なくとも3カ月以上が経ちました。余計な戸惑いが生じないよう、自宅と会社で同じ日に入れ替えています。たったそれだけのことで、あれほど悩まされた右手人差指の第2関節の痛みから解放されて、しかし中指が痛みに悩まされるということはなく、右手はペインフリーとなりました。

ただ最近は、右肩の肩こりに悩まされるようになりました。マウスの左右クリック交換が関係するかどうかも含めて、原因は不明ですが。

左手と右手の強さは、はっきりと違う。

私は右利きです。だから電話する時は受話器を左手に持って左耳に当てて、右手でメモを取りながら通話します。ケータイも同じように左手で持って通話したり、左手でメールを打ったりしていました、かつては。そして、左肩から左の二の腕に掛けての痛みと痺れに、長いこと悩まされていました。

ケータイでのメールを利き手の右手で打つように変えたら、痛みや痺れからまるで魔法のように解放されました。利き手とはこんなにも強いものかと、はっきりと実感できた出来事でした。

他にも、小梅 SD を試して左手の親指がボトルネックになる現象が体感できたことも、左手と右手の特性が違うことの証拠となるでしょう。

脳の負担。

ローマ字入力は頭が疲れる。

「ん」専用キーを設けると頭が楽になる。

「っ」専用キーを設けると頭が楽になる。

省力打鍵を採用すると頭が疲れる。

次の打鍵が省力打鍵の対象となるか否か、常に判定が求められるのは頭が疲れる。

そもそも省力打鍵を覚えられない。

清濁分置は頭が疲れる。

てゆーか、私は覚えられる自信がない。

漢直系とか多段シフト系とか。

上に同じ。

変換コスト。

特に同音異義語の選択コストは、脳の負担になる。

上に掲げた項目のどれが真でどれが偽かは、人によって異なるのかもしれません。また、いずれのコストも定量化できていないのが現状です。

無シフト率が高いということ。

これはつまり、打鍵頻度の高いキーが散らばって配置されていることを意味します。無シフト率が高いほど指の移動距離が多くなりがちだ、と言えるはずです。

距離か、または時間か、いずれかの指標を10万字サンプルに採り入れる時期が来ているのかもしれませんね。距離と時間のどちらを採用すべきか、違いを分かりやすく解説してくれる人がいると助かります。

論理配列を何かに例えたい。

ベクトルが全く違うのに驚きました。

論理配列を日本酒に例えるならば、淡麗辛口が好きな人がいたり、芳醇甘口が好きな人がいたりするように、人によってお気に入りの論理配列は違います。項目別に点数を付けていくとどの配列にも得手不得手があって、高得点を獲得する項目もあれば、低得点に沈む項目もある。そして、項目別の得点を合計すると、どの配列も似たような点数に集約していくよね、と。美味い酒は、一つ一つはっきりと味が違うけれども、どれも美味くて甲乙付けがたい。そんな主旨で何かに例えたいのです。

日本酒でもいいのかもしれませんが、パラメータがいっぱいあることを、私は日本酒では説明できません（汗）。

左人差指の前後の打鍵を再び分解する。

リリース候補の 1.3.3 #c とボツにした 1.3.3 #v について、最も気になる左人差指の前後の打鍵を分解してみました。

絶対値での比較。

絶対値

全体で100打鍵した時、該当する打鍵がどれくらい発生したかを示す。

各レコードの合計は、左人差指の打鍵率に等しい。

相対値での比較。

相対値

左人差指を100打鍵した時、該当する打鍵がどれくらい発生したかを示す。

各レコードの合計は100％。

左人差指前後の打鍵と同手跳躍。

さらに、左人差指の前後の打鍵が同手跳躍となる場合の数値を抽出しました。右手側は同手跳躍にはなりえませんから、この表では対象外となります。分子がかなり小さいので、比率ではなく発生数で示します。参考までに10万字サンプルの分母は104,357で、104,357分の25は0.024％に相当します。

	前の打鍵				次の打鍵
	左小	左薬	左中	左差	左小	左薬	左中	左差
小梅 1.3.3 #v	42	44	77	46	25	163	67	46
小梅 1.3.3 #c	46	52	82	64	36	175	94	64
小梅 1.3.2	46	56	78	64	36	175	94	64
小梅 1.3.1	58	60	90	72	48	178	104	72
小梅 1.3.0	61	68	81	78	42	179	113	78
小梅 1.23	79	62	151	124	49	198	216	123
小梅 1.22	73	204	76	140	62	183	160	137
小梅 1.21
小梅 1.11	112	188	571	367	664	165	234	364

分解しても［分｜解］からないことだらけ。

左人差指同士の連接も、同指跳躍も、狙い通り #v が最も少なくなっていました。だがしかし、#c は痛くなく、#v は痛い。左人差指の負担がトータルで 0.8 ポイントほど増えたのが効いたのか、それともかえでさんが言う通り 「V表」を多用するためには「G」の打鍵頻度を、「N表」を多用するためには「H」の打鍵頻度を、それぞれ十分に落としておく必要がある のか、あるいはまだまだ未知の指標があるのか、親指シフトは本当に難しいです。

#c は痛くないので、おそらくこのまま小梅配列 1.3.3 版としてリリースできるものと思われますが、左人差指の関節をいったん痛めてしまうと、仕事で使う qwerty ローマ字が辛い。3日連続でデスクワークばかりやっていたら、まるで突き指をしたみたいにズキズキと痛むところまで悪化してしまいました。痛みから解放されて妥当な判断が下せるようになるまで、しばらく保留となります。

関連記事

「でしょうが、」を考える。

2009-03-08

小梅配列 1.33 版候補 − 定石か、奇策か。

2009-03-01

「でしょうが、」を考える。

「でしょうが、」を入力する時、どの指をどの順番で使うかを表にまとめました。例えば qwerty ローマ字では［desyouga,］で9打鍵となります。

「でしょうが、」の運指表

	左手側				右手側
	小指	薬指	中指	差指	差指	中指	薬指	小指
小梅 1.3.3 #c			1 3 5		4		2	6
小梅 1.3.2		3	1 5		4		2	6
小梅 1.23			1 3 5		4		2	6
Nicola	4	2 5	1				3	6
Tron 2005-1011			5	1 3		4 6	2
かえであすか		2	4		5	3 6		1
飛鳥 21C-372		2	4 5			3 6		1
飛鳥 21C-290		2	4		5	3 6		1
さら 20070501			2	1	6		4	3 5
蜂鳥 X-001			3 5		4	6	1 2
翡翠 A003			3	5 6	2		4	1
翡翠 S009		3 5		1		6	4	2
月 2-263		6	3	1 4	5	8	2 7
新 JIS		6	3	1 4	5	8	2 7
JIS		1	3	5 6		8	4	2 7
qwerty ローマ字	8	3	1 2	7	4 6	9	5

「で」「し」「ょ」「う」「が」「、」は高〜中頻度のカナ・記号が使われていますが、配列によって見事にバラバラです。

「でしょうが、」はどれぐらい使われている？

思い立って調べてみたら、10万字サンプルでは1度たりとも使われていませんでした。なんてこった。「でしょう」というフレーズも、「〜で紹介した」というパターンも含めて17回で、頻繁に使われているとは呼べないようです。うーむ。

「でしょうが、」問題の解決を目指すとするなら、かなりの困難が予想されるにもかかわらず、期待される成果≒成功報酬があまりにも小さい点が気になります。また、頻度分布がいびつになる下段を、ホーム段と上段の逆相のいびつさで補正するのは、なんだか本末転倒というか性質の悪い対処療法のように思えます。付け加えるなら、Nicola では「でしょう」の打ち間違いに悩まされましたが、小梅で「でしょうが、」を打鍵ミスしたことは 1.2x 時代にもなかったはずです。

本日の結論。

「でしょうが、」の打鍵でミスが目立つようであれば、改めて対策を考えます。それまでは放置！　「そろそろ」と同様、現時点では「でしょうが、」も仕様とします。

関連記事

小梅配列 1.33 版候補 − 定石か、奇策か。

2009-03-01

「親指シフト」3つの失敗。

• 日本語配列のメリットとデメリットは表裏一体です。例外はありません。
• よくできた日本語配列には、好き嫌いはあっても、良し悪しはありません。
• 「全ての人にとって最適な単一のけん盤配列」なんて存在しない！

ラストは かえでさんの毎度毎度の主張 をお借りしてきたものですが、この3つはおそらく、同じ事柄を別な言葉で表現したものです。

出っ張りを叩いて引っ込めれば、お約束のように別なところが出っ張る。あるいは大きく開いた穴を埋めるためには、別なところに穴を掘らなければならない。こうした出っ張りや穴を数値化していくことができたら、配列作りや配列選びは今よりもずっと手軽に行えるはずです。まあ、永遠の課題だという気もしますが。

これらを踏まえて今にして思えばという話をすれば、富士通や日本語入力コンソーシアム（Nicola）は、3つの失敗を犯してしまったんですね。

1. 普及に失敗した。
2. JIS化に失敗した。
3. コミュニティ作りに失敗した。

こういうのは下野すると、はっきりと見えてきますね。昭和に製造されたテープレコーダたちは、どうして平成21年になっても現状を正しく把握しようとしないんでしょうか。そこを変えていかないと何の変化も生まれてこないのに、役者が入れ替わっても呆れるほど同じ台詞を繰り返すばかり。失敗の一つ一つには何がしかのきっかけが各々あるはすですが、今さら修正は効かないんでしょうね、きっと。

それとまた、2 はともかくとしても、1 と 3 は飛鳥配列も結果として同じ轍を踏んでしまっているのが、何とも歯痒い限りです。

傍から見れば私も同じ穴の狢、五十歩百歩なのかもしれませんが、せめてもの抵抗として、寝言は寝てから言おうと思います（爆）。

小梅配列 1.33 版候補 − 定石か、奇策か。

先日記した 小梅配列に残っている課題 を紐解きながら、具体的な解決策を考えていきます。まずは指別の打鍵頻度グラフをご覧ください。問題点を強調するため、掲載する配列数を絞り込んでいます。

採用したばかりの 1.23 版を早々に諦めて 1.3.0 版の作成に着手した のは、左手薬指の負担率がどうしても下げられなかったから、でした。ところが、現行の 1.3.2 版で長文を入力すると真っ先に左手薬指の腹が痛み出します。こと左手薬指だけを見れば、1.23 版からの改善効果は微々たるものだと言わざるを得ません orz

原因は奇策にあり。

左手薬指の負担をそれほど下げられなかった主因は下段にあります。「でしょうが」の問題 を解決するために、［Ｘ］と［Ｃ］で「ゅ」と「ょ」を入れ替えた影響で、キー別の打鍵頻度グラフを見ても左手下段が歪んでいるのがよく分かります。

小梅配列 1.3.3 #c 無シフト面

ということで、「ゅ」と「ょ」を元に戻します。［Ｃ］に「ょ」を置いたので、便宜的に 1.33 #c と呼ぶこととします。これぞ定石、グラフもまさに王道の美しさです。

強調 は 1.3.2 版との差分です。

１ ２ ３ ４ ５ ６ ７ ８ ９ ０ − ＾ ￥
 。 な て せ そ ・ お の に ， 、 ：
  こ た か る は ー ん い し と BS ESC
   ． ゅ ょ ろ ゃ っ う す ら え ＿

	左手薬指の 打鍵負担	小梅 1.23 との比	Nicola との比
小梅 1.3.3 #c	10.85%	86%	78%
小梅 1.3.2	11.82%	94%	85%
小梅 1.23	12.63%	100%	91%
小梅 1.11	11.74%	93%	84%
Nicola	13.93%	110%	100%
Tron 2005-1011	8.82%	70%	63%
かえであすか	9.37%	74%	67%
飛鳥 21C-372	9.71%	77%	70%
飛鳥 21C-290	8.94%	71%	64%

左手薬指の打鍵頻度は 1.3.2 版から1ポイントほど下がりました。1週間ほど試用していますが、左手薬指が楽になったのが実感できます。

再び奇策を求めて。

しかし、1.3.3 #c では「でしょうが」の問題が再び浮かび上がってきます。困った時は他の配列からアイディアをパクってくるのが一番です（笑）。最新版（2009年2月時点）の飛鳥配列 21C-372 を眺めると、

［Ｖ］に「り」が置いてあるのが目を引きます。そう言えば、かえであすか配列も［Ｖ］に「に」を置いていますね。グラフにはっきりと映し出された強引さを、奇策と呼ばずに何と呼びましょうか。

小梅配列 1.3.3 #v 無シフト面

同様に［Ｖ］に「ょ」を置いてみます。便宜的に 1.3.3 #v と呼びます。

１ ２ ３ ４ ５ ６ ７ ８ ９ ０ − ＾ ￥
 。 な て せ そ ・ お の に ， 、 ：
  こ た か る は ー ん い し と BS ESC
   ． ゅ ろ ょ ゃ っ う す ら え ＿

「ろ」は［Ｘ］に置きたくないので［Ｃ］へ。件の「そろそろ」は打ちやすくなる半面、「ところが」「ところで」が打ちにくくなりますが、「だろう」優先で我慢するしかありません。

今後のポイント。

1. 左手薬指の打鍵頻度は 1.3.3 #c や 1.3.3 #v の水準で大丈夫なのか。
2. ［Ｖ］の「ょ」は通用するのか。

（１）がＮＧならカナを左右で入れ替えるより他に術はなく、1.4.0 版への道程はまた長期戦となりそうな悪寒がします。

（１）がＯＫで（２）がＮＧだったら、「でしょうが」問題を諦めて 1.3.3 #c を採用するか、それとも長期戦覚悟の 1.4.0 版でオールクリアを狙っていくかが焦点となります。

（１）も（２）もＯＫであれば、1.3.3 #v を 1.3.3 版として採用します。

2009-03-02 追記。

1.3.3 #v は NG です。こちらも久しぶりに左人差指の関節がしくしくと（泣）。しばらく 1.3.3 #c の評価打鍵を続けます。

打鍵数＝負担度ではないと主張してみる。（2）

具体的な数字を代入して負担係数がどんな感じなのか探ってみましたが、そう簡単には問屋が卸してくれません。

1万字のかなを入力する場合の打鍵数

10万字サンプルについて

数値のベースは上記 kouy さんとこの記事と、いつもの10万字サンプルをミックスしたものです。厳密には正確な数値ではありませんが、アバウトな比較を行うには十分でしょう。

	打鍵数	打鍵率		負担係数	左手の 倍率	1万字を打鍵した時の負担度
		左	右			左	右	計
	s	fL	fR	k	m	s*fL*k*m	s*fR*k
小梅配列	10,000	44%	56%	1.3	2.0	11,440	7,280	18,720
Nicola	10,000	51%	49%	1.3	2.0	13,260	6,370	19,630
飛鳥配列	10,000	38%	62%	1.4	2.0	10,640	8,680	19,320
月 2-263	13,726	47%	53%	1.0	2.0	12,479	7,036	19,516
下駄配列	9,672	48%	52%	1.3	2.0	12,071	6,538	18,609

1. 「利き手ではない手＝左手の打鍵負担」が各配列でほぼ等しくなる。
2. 「打鍵負担の左右計」が各配列でほぼ等しくなる。

上記二つの両立を目標に「負担係数 k」と「左手の倍率 m」にいろいろな数値を代入してみましたが、現状では未達成です。数式を見直さないとダメだろうとは思うものの、今のところは解決策が浮かんできません。

関連記事

打鍵数＝負担度ではないと主張してみる。

2009-02-24

小梅配列は右利き専用の日本語配列です。（補足）

2009-02-20

小梅配列は右利き専用の親指シフト配列です。

2009-02-19

打鍵数＝負担度ではないと主張してみる。

コメントと補足、ありがとうございます＞ kouy さん。論旨を発展させるため、別発言にします。

実際の数値がこれだけ違えば、左手負担の程度が同じだとは、わたしには思えません。「程度の差こそありますが」と書かれていますが、程度の差が重要だと思います。

私の違和感を表現すると、こんな感じです。

• 負担が軽いから、痛くなる。
• 負担が軽いから、疲れる。
• 負担が軽いから、これ以上の負担は掛けられない。

これらの文章は、自然文として因果が呼応していませんよね。飛鳥配列の左手の打鍵回数が少ないことは、飛鳥配列の左手の負担度が低いことを意味しません。打鍵数だけが負担の軽重を決定する唯一の数値であると考えるのは、間違いであると主張します。指や手の疲れや痛みを左右するパラメータが打鍵数以外にもいろいろあることは、皆さんよくご存知ですよね？

これを数式で表現すると、指や手への負担度 L は次のようになります。

• 負担度 L ＝ 打鍵数 S × 係数 K

K を負担係数と呼ぶとすると、K は論理配列によって固有の値を持っていて、

• 非親指シフト ＜ 逐次シフトの親指シフト ＜ 連続シフトの親指シフト
• 非同時打鍵 ＜ 同時打鍵
• シフトが少ない ＜ シフトが多い
• 跳躍が少ない ＜ 跳躍が多い

などと、様々なパラメータによって多寡が決まってきます。

そして、この負担度 L は、よくできた論理配列であれば、例えば飛鳥や下駄や月2-263 などでは、おそらくは似たような数値になっているのではないでしょうか。

あるいは、負担がこれ以上きつくなると痛くなったり疲れたりする、先のエントリーで閾値と呼んだ上限の値＝飽和負担度 L_MAX は、論理配列とは関係なく一定だと推測されます。

何はともあれ、打鍵数だけが「負担の程度」を決定する唯一の係数ではないと、改めて主張しておきます。

とは言うものの。

具体的な数値を代入して配列毎の負担係数を探ってみましたが、近似値がなかなか得られません orz

関連記事

小梅配列は右利き専用の日本語配列です。（補足）

2009-02-20

小梅配列は右利き専用の親指シフト配列です。

2009-02-19

4度目の梅の季節に。

ユーザの反応とは、ありがたくもあり、怖くもあり。

572 ：563=508：2009/02/20(金) 13:14:10 0
>>564
あ、ごめん書き方悪かった。

自分が小梅(1.3.2)を実際に使っててなんとなく
Nicolaの時より右手が忙しくなったように感じたから…。
※利用者の感想です。

>>567
うん、もうこの話やめるよ(；＾ω＾)

利き手の話は、いつもすっきりとした結論が得られないんですよね。

右手が忙しくなったと感じられたのは、事実そうなのだと思います。それが不快に思えるのならば、Nicola に戻られるのもありだと思います。自分の手や指に合った配列を使うことが、何よりも優先されるべきです。

563氏の率直な感想を発端とした、古くて永遠な課題について考察していく渦中で、私は小梅配列に課題が残っていることに、ようやく気付くことができました。これを克服するのはまた大変なことになりそうな悪寒で、正直ブルー入っていたりもしますが、気付きのためのヒントをいただけたことには、とても感謝しています。ありがとうございました。

ということで、（心の）準備が整い次第、小梅配列 1.4.0 版（仮名）の開発に着手します。

小梅配列は右利き専用の日本語配列です。（補足）

本日は下駄配列作者 kouy さんのエントリー 利き手なんて関係ない？ に言及します。seesaa 発のトラックバックは大方無視されるので、一方的にリンクだけ貼っておきます。まずは 小梅配列の解説ページ から、左右の打鍵頻度に関係するグラフ2つを転載します。

左右別の打鍵頻度グラフ

左右指別の打鍵頻度グラフ

利き手ではない手が、先に泣き言を言い出すから。

昨日の記事でもそれとなく書いたんですが、結論をはっきりと述べます。

× 間違った計算式

左手の打鍵負担率(%)＋右手の打鍵負担率(%)＝100%

○ 正しい計算式

右手の打鍵負担率(%)＝100%−左手の（人差指の負担率＋中指の負担率＋薬指の負担率＋小指の負担率）

小梅配列の左右の打鍵負担が左手：右手＝44：56になっているのは、左手の打鍵負担率は44%でMaxだと判断しているからです。「右手は利き手だから、いっぱい働いてもらおう」というのは結果であって原因ではありません。利き手ではない左手は人差指が11%、中指15%、薬指12%、小指6%の合計44%でいっぱいいっぱいだから、残りの56%は利き手の右手に頑張ってもらおう。これが真実です。

左手：右手＝48：52の小梅配列 1.2x 版でも左手の痛みから逃げられなかったんですから、50：50に設定した小梅配列なんて、とてもじゃないけど痛くて打てません。

かつては Nicola ユーザだった私。

こんなょゎょゎな左手を抱えた私でも、Nicola を10年以上も使ってこれたのには、ちゃんと理由があります。

• 打ち方が違う。
• キーボードが違う。

Nicola 時代の私は、手首をアームレスト（パームレスト）から浮かせて、指の力ではなく手首や腕の力で、キーボードをバタバタと騒々しく打っていました。だから反発力の強いメンブレン式やメカニカル式のキーボードでも、左手小指の腹が痛くなるぐらいで、あとは特に問題なく親指シフトしていました。小梅配列の歴史が始まるのと前後して、指の力でキーを押し下げる静かなタイピングをするように変えたら、メンブレン式のキーボードは指の関節が痛くて痛くて痛くて、とてもじゃないけど使えないと判断するしかありませんでした。

利き手ではない手が、泣き言を言い出す臨界点。

違いを生み出す要素として、次の3点が考えられます。

1. 論理配列の違い。
2. 物理配列の違い。
3. 加齢による違い。

論理配列の違い。

飛鳥配列と小梅配列の違いは、そのまま「連続シフトの親指シフト」と「逐次シフトの親指シフト」の違いでしょう。「連続シフトの親指シフト」が生み出した「弱い人差し指」は、6〜8%の打鍵負担率で限界となっています。人差指だけで小梅配列とは3〜5ポイントも差がついてしまう計算です。

また、指や手首に負担が掛かりがちな親指シフトは、中指シフトや行段系などに比べて、指別の打鍵負担に関してよりシビア（弱い箇所の閾値が低い）なのではないかと考えます。

物理配列の違い。

小梅配列を私は、ノートPCで一般的なパンタグラフ式のキーボードを用いて開発しています。現在はギアドライブ式のものに変えていますが、性能的にはパンタグラフ式と同一と考えてよろしいかと。

飛鳥配列の作者 Ray さんは、メーカー製デスクトップPCで一般的なメンブレン式のキーボードで開発していると公言しています。

Nicola ユーザの大多数は、タッチが軽くストロークが深い専用キーボードを使っています。

下駄配列の作者 kouy さんは、タッチがとても軽い Realforce ユーザであることを公言されています。

私が Realforce ユーザだったら、左手が痛くなる閾値が高くなるはずですから、左手の負担率をもう少し上げていたかもしれません。Realforce や Libertouch はいつか使ってみたいキーボードではありますが、「一般の JIS キーボードでも快適に打てる」を標榜する限りにおいて、小梅配列の開発が終わるまでは高級キーボードへの乗り換えは自重しておきます。

加齢による違い。

私はアラフォーど真ん中です。Ray さんの正確な年齢は存じ上げませんが、私より少なくとも一回りは上ではないかと。kouy さんの年齢は全く知りません。

加齢は弱いところから順番に、容赦なく自らを攻撃してきます。

ということで。

少し気になるのが、冒頭で「飛鳥とか小梅で〜」と書かれている部分。ここでは単に右手を多く使う配列の例として2つを挙げただけだと思いますが、左右使用率は、飛鳥と小梅では大きく異なります（参考：「1万字のかなを入力する場合の打鍵数」）。

配列について考えるときは、具体的な数字やその配列の他の部分との関連などを考え、個別に判断していただきたいと思います。「左手より右手の使用率が高い」という理由だけで「右手重視」という枠でひとくくりにするようなことをすると、実態を見誤ります。

飛鳥配列と小梅配列の左手の打鍵負担率は、程度の差こそありますが、今まで述べてきたように同じ理由でひとくくりにして説明できます。小梅配列と同様に、左右の打鍵負担が50：50の飛鳥配列なんて、作らないのではなく、作れないのです。因果を見誤ってはいけません。

また、飛鳥配列とかえであすか配列の差は、メンブレンとパンタグラフの差であったり、年齢の差であったりするのかもしれませんね。

「連続シフトの親指シフト」であるにも関わらず、［Ｆ］にあっと驚く「い」を置いて、左：右＝48：52に設定した蜂鳥配列は、「最上のネタ配列」と呼んでいいと思います。作られたご本人もこのまま実用に耐えられるとは考えていないはずですが、［Ｆ］の「い」が本当に使い物になるのか、誰か試してくれないかな〜という思いは未だに抱いています（他力本願）。

関連記事

小梅配列は右利き専用の親指シフト配列です。

2009-02-19