「(習得時に)負担の少ないキー配列を！」という考え方。
(言及:負担の少ないキーボードを（下）)
(言及:負担の少ないキーボードを（上）)
(参考:シャドールーム、2006年10月21日（土）)
まずは、負担の少ないキーボードを（上）について苦言をひとつ……と思ったのですが、この記事を書いた記者さんはだいぶ丁寧に調べたようで、トンデモ説をきちんと避けているんですね*1。
ただし、（下）に述べられている
この配列は一説によるとQwerty配列の10〜40%も優れていて
(from http://news.livedoor.com/webapp/journal/cid__2601287/detail )
という部分については、きちんとソース(10〜40%という数字は、たぶん http://www7.plala.or.jp/dvorakjp/keyboad_h.htm から引用したものだと思う)を提示する形で「一説によると」という語句から置き換えるほうが自然かな……と思いました。この部分の数字は文献によってばらつきがあるようですので。
手持ちのキーボードを見てほしい。アルファベットも、仮名もバラバラに配列されているように思う。
(from http://news.livedoor.com/webapp/journal/cid__2596972/detail )
JISかな配列もQwerty配列も、もともとは覚えやすさを重視した規則的配列を出発点としている(JISかなの基礎はカナタイプの準50音配列、Qwerty配列の基礎は準ABC順配列)……という歴史はあるものの、現実の配列が「何が何でも覚えやすさ優先！」という状況ではないので、確かに「バラバラに配列」という指摘は外れてはいないところで。
タイプライタを製品化し、セールスマンがプレゼンテーションを行う際、より効率的に文字を入力できるようにと「TYPE WRITER」という文字を全て上段一行で打てるようにしたと言われている。
(from http://news.livedoor.com/webapp/journal/cid__2596972/detail )
「Type-Writer」という商標ではなくて、「TYPE WRITER」という語の説明に差し替えた……と。でも、たぶんこれの元ネタは「ジョーク」としての言及だと思います、はい。
「Qwerty配列の登場」よりも「全指タイピング技術の確立」のほうがあとに来ているので、Qwerty配列の製作者は1本指か2本指で「拾い打ちしやすい」入力法を研究していたと見るのが妥当かもしれません。交互打鍵率が高くも低くもないこと＆機械式タイプライタの打鍵にはある程度の力を要したことからすると、「2本指で拾い打ちしやすい」のほうが説得力があるのかも……。
やがてこの配列は、タイピストの養成学校で採用されるなどし、一般的に浸透。業界のデ・ファクト・スタンダード（de facto standard：事実上の標準）の座を勝ち取った、ということらしいが、この配列、打ちやすさであるとか、腱鞘炎対策にはならないようだ。実際、筆者も最近手首の痛みに悩まされはじめている。
(from http://news.livedoor.com/webapp/journal/cid__2596972/detail )
タイピスト養成学校は当初ほかの入力法──たとえばCaligraphとか──もサポートしていたはずで、「普及した理由」として提示するのであれば、ここはむしろ「タイプライタ・トラスト」を引き合いに出すほうが自然かな……と思いました。
ふつう、Qwertyを否定しDvorakを持ち上げようとすると「アームが絡むから云々……という話を持ち込んで、結果として時代検証忘れについて突っ込まれる」場合が多いのですが、ここでアームの話を持ち出さなかったのは賢明な判断だよなぁ、と。
……で、特に突っ込みどころのない記事であることに安心したところで、記事「負担の少ないキーボードを（下）」について。
あくまでもローマ字入力にこだわるとして、その範囲内で「(習得時に)負担の少ないキー配列」は無いのだろうか……と考えてみたのですが、Dvorakシリーズ(和文用の改善案を含む)よりも規則的で習得しやすい入力法が、きちんと存在していたりします。
その昔NECの森田博士が考案した「M式」がそれで、かつて各社が採用もしくは採用候補とした「五十音順ローマ字入力」という考え方を採用した入力方式の一つです。
M式のキーボード自体はNECが生産を中止してしまいました(富士通が親指シフト入力環境を生産し続けているのとは対照的)が、入力業務で飯を食う(株)Qプレスさんが「M式五十音ソフト」というエミュレータを販売することにより、近年になって事実上の復活を果たしました。エミュレータなので専用キーボードを必要とせず、普通の日本語/英語キーボードを使うことが出来ます。
M式の覚えやすさについては……うーん、ひとまず http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.pdf のp.10をご覧頂いた上で判断いただけますと幸いです。
M式の使いやすさ・高速入力適性については……M式だけでなく、似た理屈を採用した「タッチ16」を含めて、印刷業界(≒データインプット業界)で熱烈に支持されている(M式にいたっては、わざわざエミュレータを開発してしまうほどに)ことからして、その性能は「実務実績に裏づけされている」と考えてよいように思います。
Qwerty配列を基礎とした改善案も、下記のようにいくつか公開されています。
キーボードの打鍵に由来する手根管症候群(腱鞘炎など)の問題は、プロ・アマ・趣味の打鍵者を問わず重要な問題ですし……ということで、とりあえず「ぎりぎりまで習得コストを削りつつ、キー配列側で何とかする」方法があることについてご紹介させていただきました。
「キーボードを変更しただけではどーにもならないかも！」という、非常事態に至りそうになった場合に(出来れば非常事態へと至る前に)お試しいただければ幸いです。
……あっ、ひとつ忘れていました。
「打鍵数が多すぎること」が原因で腱鞘炎に至る場合は、打鍵数を少なく出来る入力方法を採用する以外には解決手段がなかったりします。
その場合は、まったく初めからの覚えなおしになってしまいますが「ひらがな入力」を採用することもご検討いただくと良いかもしれません。
一般的な「かな漢字変換システム(IME)」を使用する場合、かなの入力効率が良くなれば全体の入力効率が良くなるという特性があります。
ためしに私の日記を「漢字→かな変換」した文書で調査した限りでは、日記文で使われるかな文字の使用頻度は「いうんかしとてなのはたすにでき」のみで49%、「いうんかしとてなのはたすにでき、くまっがるもこつ。じれりーょ」のみで、全体の73%に達するという状況でして、ひらがなの使用頻度は驚くほどに偏っています。
この大きな偏りを利用した「よく使うひらがなを差別的に打ちやすくすれば、全体として打ちやすい入力法が作成できる」という方針は、1970年代以降に設計された入力法(かな・ローマ字などの入力種別を問わず)の設計方針として、幅広く採用されました。また、「かな文字の連接頻度を考慮する」考え方も同時に考慮され、これらはかな入力法であるNICOLA(親指シフト)・TRONキーボード・JISX6004(新JISかな配列)が採用しました。
文章入力を生業とするのであれば、おそらく日本語の言語感覚には鋭いはず……といことで、こういったことを頭の片隅においていただければ、入力法を変える場合にひとつの指針として役立つかもしれません。
もしも「ひらがな入力」に取り組まれるのでしたら、始めに触るべきは【中指前置シフト新JIS「月配列」】が良いかもしれません*2。生まれた場所が2chなだけに「忌憚なき意見」に揉まれつつ改良された成果物であり、致命的な欠陥は粗方除去されている*3というのが美点です。基礎となるキー配列がJISX6004(新JISかな配列)であることも含めて「新しい設計法」が持つべき原則をきちんと抑えているところもポイントです。
月配列の基本キー配列については、 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.pdf のp.8をご覧頂いた上で判断いただけますと幸いです。
ちなみに、1990年代以降に設計された「個人製作の」入力法(かな・ローマ字などの入力種別を問わず)では、ここからさらに一歩進んで「文字の連なり具合について、計算による仮想最適化のみではなく【自分の指で評価打鍵して、指が痛くならないように】徹底的なチューニングをしつつキー配列を設計する」手法も普及し始めました*4。前出の「月配列」をはじめとして近年発表されているキー配列はおおむねこの方針で設計・評価されており、最もとんでもない例としては「制作期間2002日の飛鳥カナ配列」のような例すらも存在しています。エルゴノミクス関連の技術をコンピュータで扱える関数へと変換するのは容易ではない(現在の技術では関数を作成するよりも実物を手作業で作成するほうが現実的)こともあり、この状況はしばらく(少なくとも四半世紀程度は)続きそうな予感はします。
参考までに……飛鳥カナ配列は、 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.pdf のp.7にある入力法です。濁音かななどの「低頻度文字」も(規則はあるものの)見た目がばらついて配置されていますので、普段の打鍵量が少ないのであれば覚えるのは難しいかもしれません。低頻度文字すら十分に使う……というほどに打鍵量が多ければ相対的に習得難易度は下がると思われます。
いずれにせよ、表現者の方が「手根管症候群の恐怖におびえることなく、自由に十二分な執筆活動を行うことが出来る」ような時代が来て欲しいところです。
そのためには、一番重要な入力環境(キー配列・キーボードやモニタ等のインターフェース・椅子や机などの環境)の整備が必要なわけで……。
いまだに王道、というか「誰にとっても満足できる環境」は見出せていない(というか統一すること自体が現実的ではない)ものの、いつの日にか「誰にとってもそれなりに満足できる環境」が発見されるといいですね。
誤記訂正欄。
かなり書いたので、色々間違いがあるかも……指摘いただくことがあれば、下記に随時訂正記録を記すことにします。
*1:該当記事には、Aki:zさんが記述された http://www7.plala.or.jp/dvorakjp/keyboad_h.htm からの孫引き時の転記ミス(?)に起因すると思われる「Dvorak配列に関する事実誤認」があります。詳しくはコメント頂いたとおりに記事「Dvorak配列の登場」をご覧ください。しかし、こうなると「記事記述時に使用した参考文献」の記述は必須ですね……。いちおう、Aki:zさんにもメールで本件についてお知らせさせていただくことにします。……いたのですが、思いっきり勘違いメールになってしまっていたので、直後にお詫びのメールも。何やってるんですか自分はorz
*2:今目の前にある「JISかな配列」を採用されていない方に、いきなりそれを提案するのは妙かも……と思いまして。JISX6002かなファンな皆様、すみません……今回は事情が事情ですので……orz
*3:コメントいただいたことに絡んで。カナ系共通の特徴として、「打ちやすいかなと打ちにくいカナが差別化されている＝打鍵コストが一様にならない」という癖があります。「行段系(ローマ字入力とか)」は打鍵コストが一様であり、「シフト系(かな入力とか)」は打鍵コストに波がある……という点は、入力法に関する「好き好み」にも関わってきますので、念のため追記させていただきます。しかもこれは運指条件にも依存するので、「打鍵コストに波がある行段系」「打鍵コストに波がないカナ系」というのも原理的には設計可能だったりするのがややこしいところで……。
*4:計算で求めた配列のなかから評価打鍵で配列を選択するという方法は、これ以前にJISX6004(新JISかな配列)が実践済みである点に注意。
