(メモ)親指シフトの「かえであすか」、再考。
(過去:［あしゅかはいれちゅ］［かえであすか配列］「あしゅかはいれちゅ」の名称を「かえであすか配列」に変えます。)
(過去:鍵盤配列は「繰り返し頻度の高低」に注視して設計するべき、という仮説。)
(過去:［あしゅかはいれちゅ］改0訂0案9版を正式に【あしゅかはいれちゅ改0訂0版】とすることに。)
延々と日記を逆めくりしていくと、かえであすかは「清濁隣置」というキーワードに向かって収束していったのかも……。
世の中には、ケータイに代表されるような｢簡単入力」から、速記系＆漢直系入力法に代表されるような「超多手順入力法」まで、さまざまな利用シーンや利用頻度に応じたインターフェースがある。
そのなかで、今後「鍵盤」が使われる利用シーンにおいて、どの程度の利用頻度で鍵盤が使われるか……によって、どういうコンセプトの配列が「なるべく多くの利用者がもつニーズを満たせる」のか、という点は、自動的に決まってくるのかもしれない。
Rayさんがたびたび指摘していた「人間の能力を過小評価するな」という話については、至極まっとうな指摘だと思う。
実際、飛鳥を2年半も使っていて「カナ90個程度を覚える労力は、そう重い負担ではない」ことは理解できてはいる……と。
ただ、どこまで「過小評価するべきではない」のか、という度合いについては、正直言ってまったく見当がついていないというのが私にとっての現状で。
拡張行段系のような配列では？漢字直接入力では？速記系入力法では？と、いずれも「どこまでならいけるのか＆どういう方法ならいけるのか」というあたりの話がより多く聞こえてくるようにならないと、このあたりの判断は難しいのかもしれない。
一方で「かえであすか」では、そこに「(習熟初期に限っては)人間の能力を過大評価するな」というリミットを設定してみた。
ここには、Rayさんの後追いをしても追いつけるはずがないから、別の方向で攻めてみよう……という意味のほかにも、いくつか細かな点が作用している。
個人的にはここ10年ほど、ケータイ配列検討から始まって「ユーザビリティ」「アフォーダンス」「作業手順改善」「動作記憶」あたりをぐるぐると回り続けているのだけれど、結局インターフェースをいじるにあたっては
(一部の人を除く)大衆は常に「それまでの常識」に近く、なおかつ「より楽が出来る」インターフェースがもっとも優れていると感じる。既存の概念を始めから全否定してはならない…と思う。
(from http://d.hatena.ne.jp/maple_magician/20040815/p2 )
を考慮する必要が、どうしても出てくると思う。
ここで重要なのが、「それまでの常識」にあがる入力法が【カナめくり入力(ケータイ)】【ポケベル入力(ケータイ)】【Qwerty/JISX4063ローマ字入力】【JISX6002かな入力】【NICOLA(親指シフト)】あたりにある……というところで。
誰にとっても間違いなく「今使っている入力法を使い続けるのが一番楽であって、よほどの不満を抱いた場合に限って移行を検討する」というのが現状であろうことからすると、ただ単に優劣の比較をしたところで、移行に対する興味関心をひくことはできないのかもしれない。
話は変わって、親指シフト系の配列は(漢触こーどのような拡張実装さえしなければ)極端な断崖絶壁があるわけでもないし、昇るための階段も、きちんとついている……と。
ところが、世間には(すでに上った階段をわざわざ下りてまで)新たな階段を上ろう……と決意してくださる方はなかなかいないことは、今までの経緯からして明らかなのかも。
そうすると、階段を安全に上れるように手すりを付けてみたり*1、そもそも段差をなくしてor階段の傾斜を緩やかにしてみたり*2……といった工夫が、初期段階においてはどうしても必要になってしまうように思う。
はじめから「飛鳥カナ配列」を試してもらえる人が多いのならば、そもそも(わざわざ飛鳥の美点を失うことを覚悟してまで)「かえであすか」を作る必要はまったくなかったはず。
でも、もう「テキストの整備」などの方面でできそうなことは、正直言ってほとんどないような……質についてはまだまだ向上の余地があるにせよ、方向性についてはもう手詰まり感が強いというか。
今、とりあえずできることは、とにかく「あらゆる方向性から検討したうえで、あらゆる物事についての【導入時コストの削減】をする」というところなはずで……結局、配列にも手を加えて【見かけ上の記憶＆運用コストを減らしたもの】を作るしかなかった、というのが現状。
いずれにせよ、かえであすかは
【アンシフト】 １２３４５６７８９０−＾￥ 「ーじぶ％─・とはば」［ D3〜D4は【じぶ】、D6は【──】、D12は【［】 きしうてぎゆんいかたけ］ C11〜C12は【け］】 ぴちみにぢゃっょゅめ… B1〜B5は【ぴちみにぢ】、B11は【……】 【左シフト】最上段は片手クロス＝飛鳥方式近似、その他＝小指シフト等価に。 ！”＃＄％＆’（）＋＝〜｜ D1〜D6は【！”＃＄％＆】、D10は【＋】 ぜせえぁぅぇぃよふ！）｛ D1〜D3は【ぜせえ】、D12は【｛】 ださありぉずるすまでげ｝ C2は【さ】、C12は【｝】 ざひねびヴやが、。？未 B1は【ざ】、B3は【ね】、B11は【未】 【右シフト】最上段は片手＝飛鳥方式、両手＝小指シフト等価に。 ！”＃＄％＆゛＜＞゜却却却 E7〜E13は【゛＜＞゜却却却】 （ぷれぱ＆〜ぞそこごぽ「 D2は【ぷ】、D4は【ぱ】、D6〜D11は【〜ぞそこごぽ】 わおならづぬくのつほろ」 C5は【づ】、C10は【ほ】 ぺべへぐ＊むをどもぼ未 B1〜B4は【ぺべへぐ】、B10〜B11は【ぼ未】 【小指シフト】 ！”＃＄％＆’（）却＝〜｜ 全て英字シフト側 ＱＷＥＲＴＹＵＩＯＰ＠｛ ほぼ英字シフト、【＠】は英字アンシフト側。 ＡＳＤＦＧＨＪＫＬ；：｝ ほぼ英字シフト、【；：】は英字アンシフト側。 ＺＸＣＶＢＮＭ，．／未 【，．／】はアンシフト、ほかは英字シフト側。
から永遠に変えようがない*3ので、とりあえずはこれをベースにして「導入時コストの削減」「運用時コストの削減」に必要なものについての検討を重ねていきたいところ。
それと、「エミュレータが必要です」＋「エミュレータが導入できない環境では使えません」→「ロマかなが使える人の追加学習用途にしかお勧めできません」が現状であることを考えると、練習云々以前に環境面での「移行するために相当重いコスト負担が強いられる」ことも無視できないわけで……。
この点をまるっきり無視してしまうわけにはいかないので、結局は英字入力のタッチタイプに関するフォローも必要になりそう。
最後に……なぜにかえであすかが「清濁隣置」近似配列を採用したのか……というところについて。
これは、結局「普通に飛鳥で打っていて、時として半濁音や低頻度濁音の位置を度忘れしてしまう」ことがあったことに起因していたり(たいていは「眠いとき」や「疲れているとき」などに限定して発生するタイプのもの)。
一般的には、こういうことがあれば「その場で練習しておぽえ直すべき！」なのだけれど、個人的には、それを必要するかどうかについてコスト対ベネフィット比を検討した結果が「配列側で対策するべき」だった……と。
ゆえにかえであすかは、低頻度文字について「清濁隣置」に近い緩々なルールを採用しました。
「マクロ的には若干打ちづらくなる」というデメリットを背負ってでも、「ミクロ的な忘れにくさを確保できる」というメリットを採用することを選んだ……と。
実際、かえであすかを使うようになってからは、低頻度濁音や半濁音が原因で「引っかかる」ことがなくなりました。以前はたまにそういうことがあって、そのたびに「どこにあのカナがあったかな……」と探し回っていた(これがとても気になっていた)のですが^^;。
私は「個々人が練習しまくることにより威力を発揮するシステム」よりも、「設計時点で設計者がどーにかして威力を発揮するシステム」のほうが好きなんですよね……。
で、「設計時点で設計者が、何に対して威力を発揮するように設計するか」が設計者によって異なるから、最終的な成果物たる配列の仕上がりは多種多様になる……と、そういう理解をしています。
Rayさんは「極力多くの人にとって有用なように」と設計されているはず……それに対して、かえであすかは「なるべく短い期間で習得しやすいように＆なるべく学習曲線の悪影響を受けないように」あたりを目指していたり。
どういうシーンで「かえであすか」が使えるのかは、まだまるで見当もついていないのですが、そのあたりは考えても仕方がない気もするので、今日のところは保留……と。
とりあえず。
親指シフトの「かえであすか」まとめWiki (仮)について、とりあえず即時製作できる部分については作成してみた。
ここから何をするべきかは考え中。
