カナ系配列が持つ「設計上の魅力」は、「柔軟なスケーラビリティ」に集約される……のかもしれない。
(言及:Excite Bit コネタ「あいうえおかきくけこ……」一番使われているひらがなはどれ?)
(過去:効率的な「ケータイ入力法」の話。)
つい最近、効率的な「ケータイ入力法」の話。の中で、ムダに大きな表を掲載しました。
あの表を見ていてふと思ったのですが、かな系として配列を設計する魅力の一つに「柔軟なスケーラビリティ」が挙げられそうな気がしました。
ローマ字系配列では「JIS X4063」を基準にして、そこから【キー数が少なければ手順を圧縮する】なり、【キー数が多ければ手順を拡張する】なりするわけですが、どちらの手順をとるにしても「ローマ字綴りとは異なるつづりを必要とする=ローマ字入力ができるメリットを削って実現する」という都合が、どうしても生じしてしまうという問題点があります。
このデメリットを解消するためには「使いやすい運指を有効活用する」とか「わかりにくいルールを排除する」方法が有効に作用しますが、これを推し進めると「キー定義を余すところなく有効活用する」部分と衝突する場合があり、うまい具合に両者が共存する配列を設計するのは難しくなる……と、そう感じています。
かな系配列では、もともとローマ字ではなく「かな文字」を基礎とするので、ローマ字綴りには縛られることなく、自由に規則を作ることができます。
ローマ字つづりという既存知識に頼らないことで「習得コストは増える」というデメリットがあることは、逆に考えれば「ローマ字入力に縛られず、自由に打鍵効率を向上させることが出来る」というメリットにもなる……と。
そして、元記事やそのトラックバック先に示されているとおり、「ひらがなの使用頻度には大きな偏りがある」わけです。
この性質を利用すれば、かな系はローマ字系よりも「キー数の僅かな増減に対しても、効率の劣化が起こりにくく、配列の再設計がしやすい」といえるのかもしれません。
たとえば「かえで携帯配列」から「秋月かな配列」にいたるカナ配列系バリエーションは、この性質をそのまま現しているように思います。
入力法 | ボタンの数 | かな230文字あたりの打鍵数 |
---|---|---|
かえで携帯配列(W-ZERO3[es]で利用可能) | 10個 | 460回 |
Ask配列 | 12個 | 453.5回 |
かえで携帯配列(改)(かえで携帯配列の改造版) | 12個 | 425回 |
カシス配列(かえで携帯配列(改)の改造版) | 15個 | 401回 |
ローマ字入力(W-ZERO3などフルキーボード用) | 29個 | 400回 |
秋月かな配列(W-ZERO3などフルキーボード用) | 26個 | 約310回 |
ここに掲げた中で特に手抜きをしている配列が、「かえで携帯配列」を元に生成した、「かえで携帯配列(改)」と「カシス配列」です。
後2者の入力法は、ただ単純に「使用頻度の高いひらがなを、順に1打鍵で打てる位置に移動しただけ」で、それ以外のいかなる工夫も行っていません。
しかしながら、打鍵数ベースで考えれば「その鍵盤数向けに真剣に検討された拡張ローマ字入力法と、一方では単純な仕掛けで配字したかな系入力法が、机上計算ではほぼ同等の入力効率を実現できる」という結論を導き出すことができます。
これは何を意味しているのか……と考えてみたところ、一つの仮説を立てるほうが適切なのではないかと思いました。
それは、
任意のキーを持ち、任意の操作パターンを持つけん盤配列を【カナの出現頻度を考慮して】設計する場合、かな系の配列を基礎として設計するほうが【結果的には効率の良い】入力法を【作りやすい】のではないか。
というところ。
もちろん、「机上効率がよければ打ちやすい……とは限らない」というのは(配列屋ならば誰もが体感しているとおりに)真なのですが、これはローマ字入力・かな入力の分別とは全く無関係に発生する問題なので、ここで取り上げることは避けたいと思います。
それともうひとつ、かな系配列の歴史には、何らかの関連性があるのかもしれないですね……。
とりあえず、キー配列リンク集から「発生年度と配列名称がセットでわかるもの」を追記しつつ、かな系配列の年表を作ってみました。
年度 | けん盤配列 | 参照頁/注記**1 *2 *3 |
---|---|---|
1917年6月 | 電信局のカナタイプライター(かな専用) | ※pp.46-48★*電報10万字の単字出現頻度、人差し指優先 |
1922年4月 | 山下芳太郎のカナタイプライタ配列(かな専用) | ★*単字(?)出現頻度の高いものを2段目と3段目に。 |
1923年1月 | スチックネー・カナタイプライタ配列 | *4★*山下氏が賛同した配列、50音順に依存、現行JISかなの起源? |
1927年6月 | 電信局の和文印刷電信機(かな専用) | * |
1937年 | 黒澤商店の和欧文印刷電信機 | ※pp.61-62 |
1941年1月 | カナモジカイ・タイプライタ配列 | *スチックネー配列の記号類を固定 |
1951年 | 新興製作所の和欧文印刷電信機 | ※p.70 |
1956年10月 | 加入電信用印刷電信機のキー配列 | ※pp.71-73★* |
1961年11月1日 | 加入電信用印刷電信機用キー配列をベースとしたJIS配列(JIS C 0803-1961→JIS X 6001) | ※pp.82-86★*1994年6月1日に廃止JISへ。 |
1964年 | カナ符号用鑽孔キーボード案 | ※pp.96-97 |
1964年3月1日 | カナモジカイ・タイプライタ配列をベースとしたJIS配列(JIS B 9509-1964→JIS X 6002) | ※pp.82-87★*JISカナの前身、1999年2月20日に廃止JISへ。 |
1964年? | 上記配列をベースとしたIBM72カナ配列 | ★*「1」と「ヌ」がQの左上に移動。 |
1965年? | 上記配列をベースとしたIBM029型カタカナ穿孔機のキー配列 | ★*「ム」が「ケ」の右に、「ロ」が「チ」の左隣に移動 |
1970年1月 | 上記配列をベースとした電電公社データ通信標準のキー配列 | ★*「ロ」が「メ」の右隣に移動 |
1976年1月1日 | 上記配列をベースとしたJIS C 6220→JIS X 6002のキー配列 | ★*カナの配列は上のものとほぼ同等 |
1979年1月8日 | 親指シフト配列(NICOLA) | *JIS X 4064では「参考」扱い。 |
1986年2月1日 | 新JISキーボード(JIS C 6236→JIS X 6004:1986) | *1999年3月20日に廃止JISへ |
1986年07月09日 | TRON配列 | |
1989年09月13日 | 中指シフト仮名文字配列「花」 | |
2000年10月30日 | 零式(飛鳥カナ配列の前身) | |
2001年11月08日 | 姫踊子草(かな)配列六版六案 | |
2003年09月01日 | 月配列2-263 | |
2005年02月14日 | 月配列Ux | |
2005年06月20日 | 月配列3-285改(m3.00) | |
2005年06月22日 | 龍配列 | |
2005年06月23日 | 下駄配列 | |
2005年07月23日 | 星配列 | |
2006年03月10日 | 親指シフト日本語配列 小梅 | |
2006年04月08日 | 中指飛鳥「弥生配列」 | |
2006年05月05日 | 折鶴配列 | |
2006年06月13日 | 月配列Yx | |
2006年07月02日 | 叢雲配列 | |
2006年07月30日 | ○配列 | |
2006年07月31日 | 弓配列 | |
2006年08月19日 | さら配列 | |
2006年10月18日 | 虞美人草配列 | |
2007年01月21日 | 蜂鳥配列 | |
2007年03月18日 | 翡翠配列 |
2005年のバレンタインデーを境に、なにやらものすごいスピードでキー配列提案がなされてきた様が見て取れますね……。
もっとも、同時期からローマ字入力系でも同様のスピードで提案がなされたことは確かなので、これらは「入力法」にはよらず「時代」によるものだと見るほうが良さそうです。
……と、いくら「柔軟なスケーラビリティ」がメリットとして掲示できそうな「かな系配列」にも、いくつかの問題点は存在します。
設計上の最も大きな問題点は、先にもあげた
もともとローマ字ではなく「かな文字」を基礎とするので、ローマ字綴りには縛られることなく、自由に規則を作ることができます。
というところ……言い換えれば、これは
自由度が高すぎて、なかなか配列が完成しない。
ということになります。
ローマ字系の配列であれば、「行を指定してから段を指定する」という仕様上の制限があるので、「設計指針を作った時点で、配列の半分は完成している」状態になります。
そして鍵盤数と使い方が決まれば、「あとはそれにどうやって配列を圧縮/拡張するか」を決めるだけで、9割がたの配列は決まってしまう……と。
ローマ字系のキー配列が「配字指針は思想にしたがって千差万別でも、行段系のフレームワークから溢れることはほとんど無いので、仕掛け的には似たものが出来上がる」のは、その仕掛け上当然なわけです。
現実的な問題として、ローマ字入力系では「かなの出現頻度」ではなく「行段の出現頻度」しか考慮できませんし、「かなの連接頻度」は拡張入力でフォローするしかありません。そして、シフト方法を変えたとしても、基本的な配列に対して大きな影響を及ぼすことは無いわけで……。
もっとも、この話は「行段系かな配列(ポケベル入力、かえで携帯配列など)」でも同様の方針をとりがちなので、「ローマ字系」と括るよりは「行段系」と括るほうが、ことの性質をうまく現しているのかもしれません。
ところで、かな系の配列は「かなの単字出現頻度/かなの連接頻度」や「キーボードの使い方やシフトの仕掛け」などを元に配字指針を決定するので、頻度の取り方や測定のしかた、あるいはシフトの方法を細工するなどの手順を取ることで、全く性質の異なる入力法が多数存在できてしまうという、ある意味厄介な性質を持っています。
そして、その厄介さに何とか折り合いをつけた入力法だけが、「かな系の入力法として公開されている」というのが、今のところの現状……ということになりそうです。
いずれにせよ、ケータイの入力法だけではなく、パソコンにおける入力法についても「まだまだまだまだ改善の余地があるはず」だと感じています。
度々アンケートをとってきた感触としては、割と多くの方が「知ればなんとなく興味はあるけど、練習してまで習得する&使うための環境を構築するのは負担が大きいような……」と感じていらっしゃる、という印象を受けています。
練習法などについては、こんな感じで情報提供するべく模索しているところですが、まだカイゼンすべきところは山積みでして……こちらも何とかしていきたいところです。
いずれにせよ、今回のExcite Bit コネタ「あいうえおかきくけこ……」一番使われているひらがなはどれ?にあった話が元になって、(ケータイの入力法についても期待しつつ)パソコン用の日本語入力法に対しても、興味関心が広がることを期待したいところです。
*1:※については、全て
*2:★については、全て【キー配列の規格制定史 日本編― JISキー配列の制定に至るまで】を参照のこと。
*3:*については、すべて2007年6月3日23:12:27に追記or訂正しています。詳細はこの記事のコメントを参照のこと。
*4:これは、後のJISかな配列(JIS X6002)だけではなく、その他の色々な入力法に影響するコンセプトがあったように思うのですが、今のところはその謎が解けていません。