けん盤配列スレッドメモ。
そういえば、なぜにRayさんは「有料の英語学習メール講座」とかいう方法をとって生計を立てる試みなどをしないのだろうか……。
1対1でやるような「商業翻訳・工業翻訳」はデータ入力業務に近く「能力＆時間給」的な要素がある＆結構資料などへの投資が必要らしいけれども、1対nでやるような「有料の英語学習メール講座」の場合はそういった事情があまり絡まないような……と、最近不思議に思っているのだけれど。
……で、以下は飛鳥カナ配列スレッドより。
694 名前：名無しさん[sage] 投稿日：2008/09/07(日) 06:19:17 0
飛鳥を実用してる人っているんだなあ・・・
695 名前：河豚 ◆8VRySYATiY [] 投稿日：2008/09/07(日) 07:44:32 0
俺も使ってるよ。
いま、Linux環境でもなんとならないか模索してるよ。
Windowだと、確実に飛鳥使うよ。他人のマシンにだっていれちゃうよ。
ローマ字入力には瞬間的に戻れるから、どんなときでも対応できるよ。
696 名前：名無しさん[sage] 投稿日：2008/09/07(日) 09:56:07 0
LinuxならAnthy+SCIMで親指シフトあるからIMEバーから設定クリックしてその配列パターンを変更するだけでできるでしょ
(from http://pc11.2ch.net/test/read.cgi/pc/1174639472/694-696 )
そういえば、「作者以外の方が、業務系のために新配列系入力法を使う」という事例は、いままでほとんど報告されていなかったような……。
そういった事実が「配列変更をするべきかどうか」についての質問というかたちで表れたところは、いかにも「けん盤配列系スレッド」らしいですね。
できれば、(シェア争いに引きずられるかたちで泥沼化しがちな)利用者の多い入力法が絡む同種の質問についても(シェア争いに引きずられる必要なしに)より適切さがある回答が可能となるように、「同化圧力を感じることなく、どこのコンピュータでも永遠に、様々な入力法が使えることが保証される」時代が来て欲しいところです。
同化圧力のせいで回答が歪められてしまうというしょーもない現状を作った原因は「シェア争いに負けると利用可能な機種が減る」というシステム側の都合なので、今後はそれらが「変な同化圧力を生まない、柔軟なシステムへ変化していく」ことを期待したいところです。
SCIMAnthyについては、いわゆる「連続シフトロジック」が存在しないので、親指シフト(NICOLA)専用ロジックのままでしか使えないと記憶しています。現状では「飛鳥系にとっては適しているけど、NICOLA系にとっては適していない」超漢字などのBTRON環境とは、まるっきり逆の状況という感じで……最新版では出来るようになっているのかなぁ。BTRONネイティブ環境をテストするためにLinux環境をつぶしてしまったところ(いまはブランクに戻している)なので、最近の状況については掴みかねています。
ロジックについては、シフトの打ち切りに関する部分を無効にして、かわりに「シフトキーを放した時点or反対側のシフトキーを押した時点で、該当シフト側のシフト修飾を打ち切るようにする」とかいう挙動を作りこむ必要があると思うのですが、(SCIMAnthyロジックの元となった)親指ひゅんQのロジックをどうやって弄ればその挙動を再現できるのかというところからして解決できなかったので、結局プログラムを弄るより以前の状態で頓挫した経験があります。もっとも、うまい切り替えロジックを考え付いたとしても、私には実装能力もないのですが……orz。
もしもロジック弄り＆実装が出来る方がいらっしゃるようでしたら、「IMの設定画面でロジックを切り替えできるように」プログラムを記述したうえで、次回以降の更新時に「機能として取り込んでもらえるように」統合依頼をしていただけると非常に助かります(仮にさらに「プレフィックスシフト」の機能追加まで含まれれば、結果として「論文方式の理想的な新JISかな入力」と「アクセシビリティ対応NICOLA」の両方についても実現できることになるんですよね……ッて、贅沢をいってる場合じゃないよorz)。
697 名前：名無しさん[sage] 投稿日：2008/09/07(日) 11:33:48 0
>>584の予想が当たったようだ、無料端末が存在する限り更新は止まらないってことか。
決定版（と自分で言うのも恥かしい。。）飛鳥21世紀-366 公開｜飛鳥カナ配列 ☆未来の子供たちへの贈り物☆
http://asuka-layout.ameblo.jp/asuka-layout/entry-10136060425.html
698 名前：名無しさん[sage] 投稿日：2008/09/07(日) 11:58:47 0
最終版じゃなくて決定版？
こりゃ死ぬまでに400いけるね、老骨に鞭打ってがんばれ。
(from http://pc11.2ch.net/test/read.cgi/pc/1174639472/697-698 )
Rayさんが「どこのどういう共有施設に」いっているのかは解らない……のだけれど、私が調べて予測したところ(いままでの記事をさらってみると、完全に合致するところは一箇所だけ？かも)の場合ですと、「市民活動目的では利用できないが、そうではない目的で使う場合は【予約が出来ない】だけであって【利用は可能】という感じ」なんですよね……。
ゆえに、「利用目的を「(市民活動ではなく)趣味」として利用申請すれば」順番待ちは必要でも、たぶん使えるのではないかな、と……向こうの状況はわからないものの、そんな予測をしていたり。
699 名前：名無しさん[sage] 投稿日：2008/09/07(日) 13:03:33 0
＞使えば使うほど入力速度が上がり思考がそのまま文字になる
＞打鍵範囲の狭さでも右に出るものがない
さて、入力速度の最速をそろそろ競うべきだと思うんだ。
打鍵範囲の狭さ自体はどの版を使っても変わらないから
本当に366の良し悪しを比べるなら入力速度しかない。
スタンダードなところだとやっぱ日本国憲法前文かね？
700 名前：名無しさん[sage] 投稿日：2008/09/07(日) 13:35:14 0
タイピング厨のカナ配列の速度を破るのは難しいだろ。
701 名前：名無しさん[sage] 投稿日：2008/09/07(日) 13:52:35 0
新版おもいついたらネカフェの金を工面してでも更新するでしょ、
どこまでいってもRayは飛鳥を手放せないんだから。
すでに367が出来上がってて、無料で使える端末を探してウロウロしてるかもしれないんだぜ？
702 名前：名無しさん[sage] 投稿日：2008/09/07(日) 14:46:37 0
作者本人がスピードテストもやれば良いと思うんですよ
各版ごとに同じ例文を同スピードで打ってみて打鍵感をコメントする
これでかなり客観性が増します
703 名前：名無しさん[sage] 投稿日：2008/09/07(日) 23:38:05 0
そりゃ客観性じゃなくてデータで納得したいだけじゃないかなー
速度評価を重視してるならとっくにやってたと思うわ
Rayというゆらぎまくってるフィルターを通した時点で主客転倒してるだろうし、
俺の各版スピードテスト結果をあなたが客観的に見れるのかしら？
704 名前：名無しさん[sage] 投稿日：2008/09/07(日) 23:52:55 0
小説用、法律文書用、ビジネス文書用にわけてテストしてみてほしいな
705 名前：名無しさん[sage] 投稿日：2008/09/07(日) 23:58:38 0
今のRayには酷なこと言うね
(from http://pc11.2ch.net/test/read.cgi/pc/1174639472/699-705 )
そういえば、141Fさんが記事として「カナの打鍵範囲の狭さ」について書いていらしたことを考えると、飛鳥カナ配列における狭さについて、もうすこし厳密な解釈を提示する必要がありそうですね……。
モールス符号送信用の電鍵よろしく「1キーor2キーですべてをまかなう」わけでもなく、スピードワープロのように「ホームポジション＋人指伸＋2親指シフトキーのみで(以下略)」というわけでもなく、かつコンパクトさを重視した特殊な行段系配列としての配列構成とも違う……ということを考えると、単純に「打鍵範囲の狭さ」と表現するのはちょっと違うような感じも。
なにか、飛鳥の配列について「嘘偽りなく*1、しかもピタリと直感的に解る表現」が欲しいところです。
飛鳥の打鍵速度測定についてですが、このための評価用ドキュメントとして「漢音への偏り方が強い文章」を選ぶことは、あまりお勧めできないかも……という感じがしています。
一応飛鳥は「漢音の多い文章」について、交互打鍵で処理する構造ではあるものの、それ「だけ」が飛鳥のおいしいところではないですから、漢音偏重の文章では「飛鳥の中の飛鳥らしさを評価する」には、ちょっと問題があるのかも。
それと、私事ですが……私はその昔「日本国憲法前文」をロマかなで打って336打鍵/分をようやく出した……のですが、実際に自然文でかな漢字変換をするとなると70文字/分も出せないような状況でして、打鍵数と入力文字数の乖離具合が酷かったという印象があります。漢音は特に打鍵パターンが単純になりがちなので、実力以上の打鍵速度が出てしまったりするなどして、評価基準を狂わせる原因になる可能性すらありそうだな……と。
いま日本語入力がどういう風に使われているか……というところについては把握しようがないのですが、ある程度くだけた表現がそれなりの割合を占めていると考えるほうが自然だと思われますので、そういうところについてもうまく取り込まれている評価用ドキュメントが必要になると考えています。
現実的には大量に行われているであろうコミュニケーションの場面では、文語体(書面体)のような構造よりも、口語体(会話体)のほうがより使われやすい*2という事情も加味すると、「そもそもどういう文章を速度測定の基礎とするか」という点についての議論が必要になるかもしれません*3。
そういえば、改定版は基本的に「Rayさんにとっては、過去版よりも良い配列」であるはずなので、Rayさん本人による測定を依頼すれば「(常に)最新版を使ってください！」と返されるのがオチだと思います。
そして、少し離れるのですが「タイパーさんが徹底的に訓練すると仮定した場合の最速配列」について……は、ダラダラと長くなったので隠してます。
Typewellでの現時点の最速記録を拝見する限りでは、
- Qwertyロマかな──1037.3/400*230=596.4475かな/分=9.94079かな/秒(→100.5956ミリ秒/かな、57.842ミリ秒/打鍵)
- JISかな──863.2/280*230=709.057かな/分=11.8176かな/秒(→84.61941ミリ秒/かな、69.5088ミリ秒/打鍵)
というようになっているらしく。
1打鍵ごとに数百ミリ秒程度の間隔があいているようであれば、同時打鍵によるシフトコストを考慮しなくてもいけそうなのですが、tomoemonさんによる分析の延長線上には、おそらく「同時打鍵用シフトの1打鍵が、文字キーの2打鍵に相当するくらいに重いコスト負担となる世界」が待っているのではないかと想像しています。
データ通信の世界では「パラレル伝送でスキューズレなどが問題になるとシリアル伝送へと移行し、シリアル伝送で足りなくなるとシリアル伝送を何本も束ねてパラレル伝送にして……」とかいう感じで行ったり来たりしているようなのですが、入力法に関しても同じように、同時打鍵やシフト機構に絡んだスキューズレが問題になって、その影響で入力速度が上げられなくなる地点がどこかにある*4だろうと考えています。
また、シフト機構が「マニュアル方式(JIS系)」ではない「オートマチック方式(同時打鍵系)」の場合、パソコン側のタイマーがもつ時間軸方向のズレ(過負荷などによる大きなジッターなど)にも影響を受ける可能性があり、このあたりは人間側の訓練ではどうにも解消できない問題として立ちはだかるでしょう。
新JISかなの論文などから考えるに、現実的には「ロマかなのようにシフトケースを考慮する必要がなく、表に高頻度文字を並べて省打鍵化を図り、かつ3段組配列(＋親指キーによるプレフィックス専用シフトのみを許容)であること」あたりが、【タイパーさん自身の技量のみによって、機械的な揺らぎに左右されず、超高速打鍵に最も適したけん盤配列】の本来目指すべき世界なのかもしれません。
「パターンを多くすることによって省打鍵を図る」という方向もアリかと思うのですが、そういう方向では「訓練による極度の習熟」を阻害する要素となる可能性もありますから……うーん、個人的な感触としては
- 親指2シフト方式(濁点ではなく濁音＆半濁点ではなく半濁音として入力、前者によって1割打鍵数を削減)。
- 親指プレフィックスシフト方式または親指キーを使った普通のシフト方式(同時打鍵ロジックなどによる揺らぎを排除)。
- 掌の移動量を減らすために、「Q・T・G・B・C・Y・H・P・＠・：」あたりの使用頻度を減らして、極限まで「指先だけ打鍵」を志向する*5。
- 句読点や記号類はシフトケースや↑領域に収容する(句読点処理は月配列Ux版の考え方をそのまま(もしくは同じ考え)で扱うべき)。
- 手指に対する安全性をきちんと考慮すること(やりこみによって安全性への不安が発生するのは心理的にまずい)。
というあたりがどうしても必要になってくると思います。
飛鳥の場合、シフトロジックからタイマー要素を排除することによって「結構いける部分がある」様に思うのですが、それと同時に「強い指は相応に使い切る」という感じの性質がある気がしていて、あるいは「C・，・P・＠・：」の打鍵量が(速度至上主義を想像しつつ見る限りは)多すぎるという判定を受ける可能性があるのかもしれません。
こういった超高速打鍵への対応をしようとすると、
- 2親指プレフィックスシフト方式──親指化月配列Ux版、小梅配列、TRONかな配列などのなかから基礎版を選んで、場合によっては部分的な清濁分離配列化もする。
- 2親指ノーマルシフト方式──飛鳥から「流れを阻害する配字」を弄る。
というかたちが有効なのかもしれません。
タイパーさん自身の手によって「配列を打ちながら改定していく」というのはどう考えても無理がある*6ので、実際にやるなら
- タイパーさんから「掌が動いてしまう3-gramのパターン」に関する情報を徹底的に収集する。
- 上記パターンを元に「掌が動いてしまう3-gramのパターンについて、その中間打鍵部で打たれるキーが「なるべく中指の曲げ＆小指と人差し指の伸ばしを使わずに打てるように」配列換えした」けん盤配列を作成する。
というあたりを基本方針にして、「プレフィックスシフト方式で左利き用＆右利き用が各一つ・ノーマルシフト方式で左利き用＆右利き用が各一つ」を作り上げるべきなのかも。
相当な量のやりこみによって徹底的に打鍵パターンに対する習熟度を上げていく……というプロセスを経て練習することからすると、「【速度寄り】と【安全寄り】の間で悩むような配字候補がある場合は、悩むことなく【安全寄り】に配字する」ほうが、やりこみ中の練習者を妨害せずにすむので、結果として高速打鍵性を引き出しやすくなるのかもしれません。キーボードなどは壊れても買いなおせば済みますが、人間の体は「壊れると直りにくいうえに、取替えが効くわけでもなく、しかも元通りに直る保証なんてどこにもない」わけですから、結局は【安全は全ての基礎であり、絶対にそれを崩してはいけない】という基本を守ることが、特に配列設計者にとって必ず守るべきルールになると思います。
「コンピュータのタイマー精度ぶれによってシフトの判定ミスが起きてしまうという可能性すら考慮しなければならない」ような超高速打鍵をする場合に限っては、同時打鍵法が持つ限界について、きちんとした説明およびロジック面での対策が必要になってくるのかもしれません。
タイパーさんの世界では、(配列の中に組み込まれた省打鍵規則は許容される可能性はあるものの)ワープロ速記時代の「IME頼りの辞書引き技術」は何の役にも立たないはずであるだけに、基本的にはけん盤配列側でムリ・ムダ・ムラを可能な限り吸収しておく必要があるんですよね……。
打鍵速度に応じて入力法やシフトロジックを調整もしくは変更する必要が出てくるかもしれない……というところは厄介なのですが、いまのところは「そういう要求がいずれは出てくるであろうと覚悟しておくこと」さえ満たせばよいのかもしれません。
幸いなことに？手指に関しては「(腱鞘炎にならない限りは、という条件がつくものの、楽器がらみで聞く話としては)訓練によって強く出来るという要素がある」らしいので、そういった部分に助けられつつ、うまく落としどころを探していくのがよいのかな……と。
「一般の方ではとうてい到達できないようなレベルまで、極限まで習熟すること」を前提とした場合、最速入力法かどうかという問題については答えが出ないにしても、「JISかな/Qwertyローマ字入力よりは速い入力速度(≠打鍵速度)で打てること」を目指すとなると、最終的には次の条件を満たすことが必要になるのかなぁ……と、なんとなく考えたことをメモしておきます。
- その入力法が「タイマー依存の同時打鍵系」である場合については、シフトモードを「プレフィックスシフト方式」か「ノーマルシフト方式」か「全キーOff時確定方式」へと変更すること。
- 少なくとも、なんらかの仕掛けによる漢音対応がなされていること(漢音適性が悪くはない「ローマ字入力法」と比較した場合にキーポイントになると思う)。
- 総運指距離──3次元的に見た場合に、JISかなおよびQwertyローマ字入力と比べて、少なくとも3割程度は少ないこと。
速度の問題というのは、極端なことをいえば「打鍵数には関係なく、(きちんと3次元的に測定された)総運指距離によって決まる」ところがあるのかもしれません。
打鍵数というのは、むしろ安全性のみに関わる問題として別個に捉えてしまうほうが、この手の問題をスッキリまとめることが出来るのかも。
こういう乱暴なまとめ方がどの程度機能するのかは、まだ予測も出来ません……が、打鍵ミスが増える可能性があるとすれば、それこそ「打鍵数が多いかどうか」よりも「運指距離が長いかどうか」のほうが、習熟という観点から見れば重要そうな気がしています。
*1:ここ、とっても重要です……正直、四半世紀と経たずに「それはさすがに嘘だろｗ」とか笑われてしまうような失態は犯したくないですし、そういうのはたいてい「見透かされてしまう」はずでもあるわけで。
*2:これは、かつての「ホームページ・閉じた掲示板」時代から比べて、いまの「開かれた掲示板・ブログ・ＳＮＳ」時代へとシフトすることによって、さらにその傾向が強くなったように思います。
*3:ただし、電脳日本語論においてATOKの辞書について似たようなことが書かれているのですが、本質的には既に「一つの文章・ひとりのペルソナを想定した測定をすること」自体に無理がある……という地点に差し掛かっている可能性はあるのかもしれません。
*4:現行のタイマー依存な同時打鍵ロジックは、打鍵間隔が短い場合に「文字キー同士の間に打たれたシフトキーについて、そのシフトキーがどの文字を修飾するかを判断するために、タイマーを使って【より近いほう】が選ばれる」ように動作するという仕掛けを主に採用しています……ので、たとえば文字キーの打鍵間隔が84ミリ秒(JISかな記録の親指シフト換算値)だとすると、シフトキーの打鍵時間ズレは絶対に41ミリ秒未満(タイマーの揺らぎを考慮すると、現実的にはもっと余裕時間が少ないはず)に抑えなければならないことになります。しかも、親指キーを他の機能との共用にしている場合には、さらに半分の精度(20.5ミリ秒未満)で打鍵する必要があるという事情まで絡んでくる可能性がある上に、打鍵速度自体にもある程度のブレが出る＆指の長さの違いによる打鍵タイミングズレも深刻な影響を及ぼし始める領域でしょうから、特にトップスピード部分ではさらに厳しいスキューズレ防止打鍵法を必要とするはずです。文字キーの打鍵速度に対して倍精度でシフトキーの同時打鍵タイミングを制御しなければならないというのは「タイマー依存の同時打鍵ロジックを使う全ての入力法に共通の問題」なんですよね……。この点を完全に解消するには、そもそもタイマーへの依存を止めて「普通のシフト方式」か「プレフィックスorポストフィックスシフト」方式より他に、方法はないだろうと感じています。「一般的な数百ミリ秒単位打鍵の世界では」マトモに機能するタイマー依存な同時打鍵ロジックも、さすがに「超高速な数十ミリ秒単位打鍵の世界では」相当に重い負荷になるはずです。
*5:難解(というかとらえ所がない)な飛鳥理論を持ち出すまでもなく、動作解析などでは「100ミリ秒単位で付加価値のない動きを削っていくこと」が「より付加価値のみの動きへと近づくため」に実際に行われてきたわけで……打鍵に関しては、そこからさらに一桁〜二桁程度細かな単位で「動作のムリ＆ムダ＆ムラ取り」をすることが有効なのかもしれません。ここで重要なのは「静止時点では無理をすれば指が届くかどうか」などという話ではなくて、「流れに乗って打鍵したときに掌が動いてしまわないかどうか」という視点で観察する必要があるということかと。
*6:改定するたびに運指パターンがリセットされてしまうので、速度の追求と配列効率の追求を同時に行うのは無理がある。
