木を見て森を見ず。

一部分だけを採り上げて、どうしたいのやら＞ Nicola スレ。問題解決の方法もそこに3種類示してあります。お好きなものをご選択ください。

まだまだ目が離せません

小梅配列では

• まだまだめがはなせません
• DSDSADGWRDRJ

で、左手側の11連打 orz 。1.2 版からずっとこうなので、もはや仕様と言うしかありません。

1,000 時間の評価打鍵とは、はたして適正量なのか。

評価打鍵をどれくらい行えばいいのか、かえでさん は次のように述べています。

1000時間の評価打鍵って、たかが「8時間×4ヶ月」か「3時間×11ヶ月」で達成できる量だから……それぐらいの「訓練」で解決できる、と保証してあげられる状態になってから、完成品としてリリースするのがいいと思う。

1,000時間を分に換算すると、

• 1,000 × 60 ＝ 60,000 分

私の打鍵速度は遅いので、カナ換算で仮に 100字／分 とすると、

• 100 × 60,000 ＝ 6,000,000 字

1,000時間で 600万字が入力できます。そして、600万字ということは、

• 600万字 ÷ 10万字 ＝ 60

10万字サンプルを60サイクル繰り返すことができます。10万字 × 60 ともなると、出現頻度が最多の「い」は 41万回超も打鍵され、1.3.4 版で配置換えされたばかりの「あ」は7万回超、「わ」でも5万回超も打鍵できる計算です。頻度極小の「ぢ」や「ヴ」でさえ60回も打鍵されるとなれば、評価打鍵としてはたしかに十分と言えるでしょう。当然ながら、打鍵スピードが速い人ほど、さらに評価サイクルを重ねられます。

ただし、時間ベースで評価打鍵の量を語ることは、個人的にはピンと来ません。

毎日コンスタントに 1,000 字を打鍵し続けたとすると、10万字サンプルを1サイクルこなすには、

• 100,000 ÷ 1,000 ＝ 100

100日掛かります。上の例と同じように60サイクル繰り返すには、

• 100 × 60 ＝ 6,000

6千日ということは16年以上が必要です（汗）。逆に1年で60サイクル繰り返すことを目指すなら、16,000 字以上を毎日コンスタントに入力しなければなりません。これは大変だ！　仕事や執念（謎）で日本語配列をアレンジするならともかく、趣味で行っている私のような立場の人間には、いささか気が遠くなる数値です。

そもそも、かえでさんの言う評価打鍵の時間量って、

• 開発当初からの累積時間
• 最終候補が確定してからの評価量

どちらなのでしょうか。前者だとすれば小梅配列も基準を何とか満たせそうですが、後者だとすれば完成披露は16年後とかになりそうで怖いです。おっと、

配列を固定した状態で、1000時間以上の評価打鍵を行っているか、もしくは「1000時間評価打鍵をしても、配列を変更することがないと言い切れる」確証がある状態。

と書いてありますね。評価打鍵は「量より質」な側面も強いので、「単純に時間だけでは決められません」などと抵抗しないことには、完成したと永遠に宣言できなくなってしまいます（苦笑）。

左手は親指シフトの同時打鍵も下手みたいだ。

既に 対処済とした記事 が掲載されていますが、

DvorakJ で文字キー以外の同時打鍵をするときに不具合が生じることがわかった

blechmusik2の日記

2009-09-06

文字キーをまず打鍵し、続けて文字キーではないキーを打鍵すると、同時打鍵の判定時間が短縮されてしまうことがわかった*1。正しくは、文字キーではないキーを打鍵すると、同時打鍵の判定をする前に相当の時間を内部の処理に費やしてしまうのだ。処理時間を計測したところ、同時打鍵の判定前の時点で200ミリ秒ほどの時間が費やされていた。時間がこれほどかかってしまう処理なぞ何もしていないのだが……

という不具合がある DvorakJ 2009-09-06 版で小梅配列の試し打ちを重ねるうちに、

同手シフトの判定が厳しすぎる。文字キーを先に打鍵して、親指キーの打鍵が遅れた場合の「同時打鍵」で、シフトが効かない。

という私の指摘が正しくないことに気付きました。たとえば「はいれつ」と入力すると、

はいれつ

GKJW

無シフト/無シフト/同手シフト/同手シフト

無シフト/無シフト/右シフト/左シフト

「はいれな（確定）」と出力されて、同じ同手シフトとはいえ右シフトはOKで、左シフトでシフトミスが多発していることが分かりました。

左手でのシフト操作がどれだけ下手なのか、すべてのカナを5回ずつ打鍵したものを一覧表にまとめました。

表1　小梅配列 を DvorakJ 2009-09-06 版で打鍵

入力	出力	配置		誤出力数
		シフト	段	シフト					段
				無	同手	他手	左	右	上段	ホーム段	下段
あ	あああああ	同手／右	下段
い	いいいいい	無シフト	ホーム段
う	ううううう	無シフト	下段
え	えええええ	無シフト	下段
お	おおおおお	無シフト	上段
ぁ	ぁんんんん	他手／左	ホーム段			1	1			1
ぃ	ーーーーー	他手／左	ホーム段			5	5			5
ぅ	・ぅ・ぅ・	他手／左	上段			3	3		3
ぇ	うぇぇぇぇ	他手／左	下段			4	4				4
ぉ	っぉぉぉっ	他手／左	下段			2	2				2
ヴ	ヴヴヴヴヴ	他手／右	下段
入力	出力	シフト	段	無	同手	他手	左	右	上段	ホーム段	下段
か	かかかかか	無シフト	ホーム段
き	ききききき	同手／右	上段
く	くくくくく	同手／右	ホーム段
け	けけけけけ	同手／右	上段
こ	こここここ	無シフト	ホーム段
が	ががががが	他手／右	ホーム段
ぎ	ののぎぎの	他手／左	上段			3	3		3
ぐ	いぐぐいぐ	他手／左	ホーム段			2	2			2
げ	にげげげげ	他手／左	上段			1	1		1
ご	ごごごごこ	他手／右	ホーム段			1		1		1
入力	出力	シフト	段	無	同手	他手	左	右	上段	ホーム段	下段
さ	るさるるる	同手／左	ホーム段		4		4			4
し	ししししし	無シフト	ホーム段
す	すすすすす	無シフト	下段
せ	せせせせせ	無シフト	上段
そ	そそそそそ	無シフト	上段
ざ	ざざざるざ	他手／右	ホーム段			1		1		1
じ	しじじじじ	他手／左	ホーム段			1	1			1
ず	すずずずず	他手／左	下段			1	1				1
ぜ	ぜぜぜぜぜ	他手／右	上段
ぞ	そぞそぞぞ	他手／右	上段			2		2	2
入力	出力	シフト	段	無	同手	他手	左	右	上段	ホーム段	下段
た	たたたたた	無シフト	ホーム段
ち	ちちちちち	同手／右	下段
つ	なつなつつ	同手／左	上段		2		2		2
て	ててててて	無シフト	上段
と	ととととと	無シフト	ホーム段
っ	っっっっっ	無シフト	下段
だ	だただただ	他手／右	ホーム段			2		2		2
ぢ	らぢぢらぢ	他手／左	下段			2	2				2
づ	なづづづづ	他手／右	上段			1		1	1
で	でででてで	他手／右	上段			1		1	1
ど	とどどどと	他手／左	ホーム段			1	1			1
入力	出力	シフト	段	無	同手	他手	左	右	上段	ホーム段	下段
な	ななななな	無シフト	上段
に	ににににに	無シフト	上段
ぬ	せぬせぬぬ	同手／左	上段		2		2		2
ね	ねねねねね	同手／右	下段
の	ののののの	無シフト	上段
入力	出力	シフト	段	無	同手	他手	左	右	上段	ホーム段	下段
は	ははははは	無シフト	ホーム段
ひ	ひひひひひ	同手／右	上段
ふ	ろふろろろ	同手／左	下段		4		4				4
へ	へへへへへ	同手／右	下段
ほ	ゅゅゅゅゅ	同手／左	下段		5		5				5
ば	ばばばばは	他手／右	ホーム段			1		1		1
び	おびびびお	他手／左	上段			2	2		2
ぶ	ぶぶぶぶろ	他手／右	下段			1		1			1
べ	べべべべべ	他手／左	下段
ぼ	ゅぼゅゅゅ	他手／右	下段			4		4			4
ぱ	。ぱぱ。ぱ	他手／右	上段			2		2	2
ぴ	ゃゃゃぴゃ	同手／左	下段		4		4				4
ぷ	ぷぷぷぷぷ	他手／右	下段
ぺ	。。ぺぺぺ	同手／左	上段		2		2		2
ぽ	．．．．ぽ	他手／右	下段			4		4			4
入力	出力	シフト	段	無	同手	他手	左	右	上段	ホーム段	下段
ま	まかかまか	同手／左	ホーム段		3		3			3
み	みみみみみ	同手／右	下段
む	むむむむむ	同手／右	ホーム段
め	こめこめこ	同手／左	ホーム段		3		3			3
も	ててもても	同手／左	上段		3		3		3
入力	出力	シフト	段	無	同手	他手	左	右	上段	ホーム段	下段
や	はややはや	同手／左	ホーム段		2		2			2
ゆ	．ゆゆ．．	同手／左	下段		3		3				3
よ	ょよよょよ	同手／左	下段		2		2				2
ゃ	ゃゃゃゃゃ	無シフト	下段
ゅ	ゅゅゅゅゅ	無シフト	下段
ょ	ょょょょょ	無シフト	下段
入力	出力	シフト	段	無	同手	他手	左	右	上段	ホーム段	下段
ら	ららららら	無シフト	下段
り	りりりりり	同手／右	ホーム段
る	るるるるる	無シフト	ホーム段
れ	れれれれれ	同手／右	ホーム段
ろ	ろろろろろ	無シフト	下段
入力	出力	シフト	段	無	同手	他手	左	右	上段	ホーム段	下段
わ	わわわわわ	同手／右	ホーム段
ん	んんんんん	無シフト	ホーム段
を	たたたたを	同手／左	ホーム段		4		4			4
合計（全打鍵数 81*5=405）				無	同手	他手	左	右	上段	ホーム段	下段
誤打鍵数計 91				0	43	48	71	20	24	27	40
誤打鍵率 22%				0%	11%	12%	18%	5%	6%	7%	10%

やはり「左シフトで誤シフトが多い」ことと、さらに「下段で誤シフトが多い」ことが分かりました。なるほど。

表2 は10万字サンプルでシフト率を上下段別・左右シフト別に分解したものです。

表2　上下段別・左右シフト別に分解したシフト率

		無シフト	左シフト	右シフト	計
小梅 1.3.4	上段	18.64%	4.56%	6.83%	30.2%
	ホーム段	30.52%	7.39%	10.42%	48.5%
	下段	13.52%	2.36%	4.02%	20.0%
	計	62.68%	14.31%	21.27%	98.27%
Nicola	上段	20.09%	4.39%	10.72%	35.4%
	ホーム段	30.57%	8.85%	12.37%	51.4%
	下段	5.48%	2.15%	2.41%	10.1%
	計	56.14%	15.39%	25.50%	97.02%
Tron 2005-1011	上段	18.91%	3.33%	4.76%	27.1%
	ホーム段	34.76%	3.50%	10.41%	49.0%
	下段	19.07%	1.69%	1.76%	22.6%
	計	72.75%	8.52%	16.93%	98.21%
かえであすか	上段	8.91%	3.40%	5.33%	17.8%
	ホーム段	31.52%	12.96%	14.07%	58.7%
	下段	8.70%	8.94%	4.89%	22.6%
	計	49.12%	25.29%	24.28%	98.70%

最上段を加えて合計が 100% となる。

小梅配列は Nicola に比べて下段の打鍵率が倍増していますが、下段の左シフトは Nicola と同程度に収まっています。というか、小梅配列が Nicola より無シフト率が高いのは、下段の無シフト率が高いからだと分かります。また飛鳥系は、左シフトの 1/3 ほどを連続シフトで吸収できるようです。

表2 を見る限り、Nicola も利き手が右手な人に向けた日本語配列であると言えます。そして「かえであすか」は、同時打鍵の判定が厳しいほど下段のシフト動作がシビアになると伺えますが、いかがでしょうか？

小梅配列のカナと句読点の打鍵範囲は30キーに。

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

580 ：名無しさん：2009/09/05(土) 21:24:32 0
>>579
小梅と飛鳥のどちらが打鍵範囲が狭いかについては
両配列の作者間ですさまじい舌戦が繰り広げられた経緯があって
大変デリケートな問題なので、そう簡単に言い切ってしまうのは危険だ。

581 ：名無しさん：2009/09/05(土) 21:30:28 0
>>580
知らなかった。
どのあたりのエントリー？

582 ：名無しさん：2009/09/05(土) 22:12:07 0
>>581
http://61degc.seesaa.net/article/103966389.html
「上に示したカナと句読点が1文字でも乗っているキーの数を、配列ごとに数えてみました。」
「打鍵範囲の狭さでも右に出るもののない小梅配列を是非お試しください(笑)。」

このエントリに対して飛鳥作者は猛反発。
！（　）？％−などは一部のかなよりも使用頻度が高く、
これらを無視して配列の打鍵範囲を評価するやつは救いがたいバカ、
というような反論をした。

583 ：名無しさん：2009/09/05(土) 22:26:27 0
つかそのエントリーだけ取り上げて「すさまじい舌戦」とかいっても意味ねぇよ
議論をやりあえる仲ってだけだし。

もともと前フリがあってRayの反応を期待したエントリーだったし、その期待どおりになっただけ
デリケートな問題でもなんでもないわ

あはは。

関連記事

カナの打鍵範囲を確認しておく。

2008-08-01

小梅配列 1.3.4 版は［Ｙ］キーに「ぅ」を置いたため、上の記事と同じ条件で数えると 30 キーに増えてしまいました。しまった（笑）。

カナ「だけ」の打鍵範囲。

蛇足ながら、句読点も除外して文字通りに「カナの打鍵範囲」だけを問うならば、

小梅配列 1.3.4

qwertyuio (9)

asdfghjkl; (10)

zxcvbnm,./ (10)

計 29 キー

飛鳥配列 21C-383

qwertyuiop@ (11)

asdfghjkl;: (11)

zxcvbnm,./ (10)

計 32 キー

Nicola

qwertyuiop (10)

asdfghjkl; (10)

zxcvbnm,./ (10)

計 30 キー

Tron 2005-1011

qwertyuiop (10)

asdfghjkl; (10)

zxcvbnm, / (9)

計 29 キー

と、［Ｐ＠］を使わない小梅配列と、［＠．］を使わない Tron 2005-1011 が目立ちます。

どんなに使用頻度が低いカナでも、カナはカナです。「はなぢ」や「ちぢむ」を差別的に打ちづらくはしたくない、というのが小梅配列のスタンスです。清濁同置なので、特定のカナだけ差別しようとしても無理だというのもあります。

そして、頻度データを重視して「使用頻度の高い記号」を「使用頻度の低いカナ」より優先的に配置する、という飛鳥配列のアプローチを私は否定しません。彼我の「違い」は主張しますが、相手を「否定」したことはなかったはずです。はたして、こういうのも 舌戦 と呼ぶのでしょうか。

生物の多様性が重要なのと同様に、日本語配列も多様な方がいい。かな配列にもいろいろな DNA があった方が、幸せな人が増えると私は信じています。

関連記事

指を差した向こうにあるもの。

2008-09-17

追記

前提条件を何ら示さずに 打鍵範囲の狭さでも右に出るもののない と書くのは、読者に対してフェアじゃないと思います。そういった部分への批判は、相手が誰であろうと遠慮なく行います。

小梅配列 1.3.4 版です。

修正案その4 を採用します。

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

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

無シフト面

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

左シフト面

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

右シフト面

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

〓 は未定義。

小指シフト面

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

再びカウントダウン開始！

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

関連記事

小梅配列＜その先の親指シフト＞

普通のキーボードで親指シフト「小梅配列」

1.3.4 版

サイトも久しぶりに更新しました。

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

［Ｂ］のシフト側のカナ「ヴ」「ぴ」を左右で入れ替えます。

［Ｖ］の他手シフトが「ぶ」で、すぐ隣［Ｂ］の他手シフトが「ヴ」というのは、qwerty ローマ字とは逆配置ですが、覚えやすくて忘れにくいかなと。

半濁音のカナを一覧表にすると、「ぴ」が同手シフトに変わったことで、

	キー	シフト
ぱ	Q	他手シフト
ぴ	B	同手シフト
ぷ	C	他手シフト
ぺ	Q	同手シフト
ぽ	Z	他手シフト

「ぱぴぷぺぽ」のシフトが「他同他同他」と並びます。これはこれで規則正しい？

修正案その4

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

無シフト面

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

左シフト面

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

右シフト面

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

〓 は未定義。

小指シフト面

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

本日の配列。

残暑お見舞い申し上げます。

関連記事

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

2009-07-17

そして「ね」が残った。

2009-07-10

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

2009-07-05

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

2009-06-29

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

2009-06-22

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

「わ」を左手側に戻せる手がないか、改めて検討しています。しばらくお待ちください。

左手側には戻せなかったものの、

• くみあわせ
• うちあわせ
• あらわれる

うん、これなら大丈夫でしょう！

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

修正案その3

無シフト面

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

左シフト面

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

右シフト面

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

〓 は未定義。

小指シフト面

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

本日の配列

もしかしてもしかしたらの話ですが、「あります」「ありえない」なんかの「あり」も、慣れたらこっちの方が打ちやすいかも。そんな素性の良さを感じます。

ついでに、分かりやすさ優先で「ぅ」と「ゎ」を左右で交換します。

上段

ぅ

ホーム段

ぃ ぁ

下段

ぉ ぇ

と左向きに規則的に並べることで、覚えやすく忘れにくいことを狙います。

関連記事

そして「ね」が残った。

2009-07-10

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

2009-07-05

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

2009-06-29

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

2009-06-22

そして「ね」が残った。

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

2009-07-14 追記

「ね」が右手人差指にあることにまだ慣れていないせいか、「ね」が文末以外に現れた時のペナルティが大きいような気がするんですよね。例えば、

ねむる

NHF

ねれる

NJF

ねむれる

NHJF

ねんれい

NJJK

ねーむ

NHH

ねーみんぐ

NHMJK

しんねん

LJNJ

ねおん

NUJ

むねん

HNJ

みねうち

MNM．

えみねむ

/MNH

うねうね

MNMN

おうねん

UMNJ

強調は同指跳躍や同指異鍵、同鍵連打を含む同指連打 を示す。

上の 2-gram の表によると、最も多い「ねん」で絶対値 0.08% 、相対値 20.56% と、私の実感を裏付けるかのような数値になっていますが、ここいらも含めて慣れるしかないんでしょうね。

他にも「わ」が右手側に来たことで、

くみあわせ

KM；，R

あらわれる

；．，JF

等が久しぶりに打ちづらくなっていますが、総じて「仕様です」と言うしかなさそうです。

関連記事

さらに安全な論理配列を求めて（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万字サンプルに採り入れる時期が来ているのかもしれませんね。距離と時間のどちらを採用すべきか、違いを分かりやすく解説してくれる人がいると助かります。

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

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

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

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