雑記とするつもりではなかったのであるが、結果的に雑記になってしまっているのである。様々、色々書いたものをひとまとまりにして公開するという形である。
こういう公開の仕方だと中身がわかりにくくなるだろうかという危惧もある。
AOUR頭脳
AOURを使っていると、打鍵の時の和文解析がAOURになる。
どういうことかというと、例えばローマ字入力の場合であれば、「共同文書」という文字を入力する際には「きょ・う・ど・う・ぶ・ん・しょ」という音節に分けてそれぞれ「kyo/u/do/u/bu/nn/syo」と入力する指の動きを指令する（完全に習得している場合は無意識に）のに対し、AOURの場合は「きょう・どう・ぶん・しょ」という4音節になり、入力も「io/hw/nv/bs」になるということである。
おそらくこれは、JISかな入力なら「き・ょ・う・と・濁・う・ふ・濁・ん・し・ょ」とそれぞれ区分しているのではないか。習得して無意識であるとしても、音韻と入力単位としては必ずそうなる。
AOURは拡張入力のために二重母音や撥音節などが定型化されてそれに打鍵が割り当てられているので、必然的にそういう音韻を含む単語や文章の場合は入力音節数が少なくなり、もちろん打鍵数も少なくなるのである。これはAOURでなくても、同種の拡張入力を持つ入力方式なら同じである。
自分が当初、かな入力からローマ字入力を選んだのは、様々な理由はあるが、その一つとしてはルールとして覚えられるからである。かな入力は、すべてのかなの位置を機械的に覚えていく必要があるが、ローマ字入力は基本的に子音と母音の組み合わせなので、その子音と母音のルールを考えれば良いわけであって、既にその時点でローマ字のルールは完全に把握していたので、そのほうが習得しやすかったのである。
AOURなどの拡張入力は、そういうローマ字のような行と段の組み合わせのルールの上に成り立っているが、さらには拡張入力の音韻毎のルールを習得する必要はある。
これもAZIKのように通常のローマ字入力の拡張であれば、母音の位置に規則性がないので習得には少し時間が必要になるものだが、AOURなどDvorakベースの場合は母音の配置に定則性があるので、ローマ字入力の拡張よりは確実に習得しやすいのである。
Dvorak配列は、母音五つが左手ホームに都合よく並んでいて、これは最初から和文の入力のことまで考えて配置されている配列なのではないかと思えるほどである。
US配列の行方
我が国で流通しているキーボードにはJIS配列の他にUS配列があって、一定のシェアを持っている。もちろん圧倒的にJIS配列ユーザのほうが多いものの、中級者以上にUS配列派は一定の割合で存在する。自分もUS配列を使っている。
かな文字の刻印の有無ということで言えば、JISかな入力をする人には必須であるが、そのJISかな入力をする人は1割以下になっているという。すなわち、それ以外の9割の人はかな刻印を必要としていない。
もちろん、世界的な視点ではUS配列型のキーボードのほうが標準・主流であることは誰もが想像が付く。
JIS配列とUS配列は当面は今のような状態で共存していくが、長期的な視点では、US配列に収斂していくのではないかと思っている。
例えば、国内メーカーの撤退が続いてることがその理由の一つである。海外メーカーの製品が主流になれば、世界的にシェアの低いJIS配列ユーザ向けの製品をいつまで作ってくれるかは怪しい。US配列で和文入力ができないというのならともかく、何の遜色もなくローマ字入力が使えるのであるから、それならUS配列で良いのではないかと、合理的な考えに基づけばそういう結論に至るからである。
もちろんこれは長期的な視点での考えなので、今すぐJIS配列からUS配列に改宗する必要はないと思うが、US配列は利点が大きいと思うので、理解できる人はUS配列も使えるようになっておいた方が良い。
自分がUS配列を使うようになった時にはそこまで考えていたわけでもないが、そういう選択肢もあって、それなりに使える人はUS配列を選んでいると知ったので、自分も使ってみればその使い方のほうが自分に合っていた。
ユーザ数では少数派であるが、天邪鬼なのでその点においても自分に適合していると思った。US配列を使ったからといってJIS配列が使えなくなったわけでもなく、両方選択して使えるというのは寧ろ便利になったとも言える。実際、会社PCはJIS配列なので、今後もそれを使わざるを得ない。
HHKBとRealforce
静電容量無接点のキーボードとして、東プレのRealforceは有名で、その東プレのスイッチを使っているキーボードとしてHHKBももちろん有名である。HHKBは海外での人気も高く、それはUS配列のモデルのほうが標準であるというような扱いをしている点が大きい。無刻印モデルが定番商品としてあるのもUS配列だけで、当初はJIS配列の製品はなくUS配列をベースにしたモデルだけだった。
HHKBのユーザミートアップ動画を見ていると、製品のシェアについてのレポートがあり、最も売れているのがHybrid Type-Sの最高級モデルであって、その割合は8割を超えて85％前後であるようだ。配色の割合では、墨色モデルが2/3のシェアを占めている様子。
US配列とJIS配列の割合はほぼ拮抗しているように思えるが、これにはUS配列の無刻印を含んでいない。US配列は1割には満たないがそれに近いシェが有り、これを含めると実はHHKBはUS配列のほうがシェアが高いということになるのである。
一方のRealforceは、おそらく海外でも販売されているが国内の流通量のほうが多く、それでJIS配列のほうが優先されて商品化されているのではないかと想像する。こちらはHHKBとは逆に、JIS配列製品が先行して、US配列製品は後発のような状況のイメージがある。
最新のR3モデルも、これを書いている時点ではJIS配列の製品しか発売されていない。おそらくUS配列製品は動向を見て少し先になり、R2の時の状況から想定するとJIS配列製品よりはラインアップが少ないのではないかと思っている。
ただし、HHKBもそうだがRealforceは耐久性が高く長期に亘って使える物なので、仮に今自分の好みのモデルが将来その製品の後継製品も発売されなくなるということがあっても、通常は購入後10年以上の期間は安泰であると言える。
実際、自分もUS配列の変荷重・静音のタイプを使っているが、このモデルの生産は終了して、その同等性能の後継製品は発売されていない。
そもそもRealforceは製品のバリエーションも多すぎるくらいにある。好みで選べるのは重要なことではあるが、合理化の波が押し寄せた場合には標準的な製品群に絞った取り扱いになっていくとか、開発形態が変わったりするのは仕方のないことである。
長文の基準
RealforceやHHKBなど、良いキーボードは長文書きには必須などと言っているが、その長文とはどのくらいの長さを言うのか。
一説には、Twitterの140文字を超えるような文章が長文だというのもあるし、読むのが嫌になるような長さなら長文だとかの意見もあり、具体的・数値的な長さとしての基準はないようである。
自分としての基準で言えば、原稿用紙２枚分、800字からそれ以上くらいが長文と言えると思っている。すなわち、これくらい以上の文章を書くことがあるようならば、キーボードにはこだわりを持って、疲労防止のためや快適な入力をきちんと考えるべきだと思っている。
それ以下ならば、とりあえず入力できれば問題はないくらいのキーボードでも、これは仕方がないような思いである。
今のブログ
何か個人の見解だとか、製品の情報を検索して個人のブログなどを探そうとすると、検索上位に来るようなのはだいたい、WordPressで作成されていて収益を目的としたブログ記事ばかりが目立つ。尤も、そうなるようにSEOなどの対策をしているのだからそうなる。そういう記事は、もちろん役には立つのだが、オリジナリティ・独自性には乏しいものが多く、皆同じようなもので、どれか一つだけそれに関して見れば、他に幾つも見る必要がなく、ほとんど面白みはない。多くは真っ当な見解しかない。
以前のブログはもっと、そういう収益だとかは関係なしに好き勝手に作られていて、必要な情報として不足していたり、考えもよらないような見解があったりして、色々と見て回るのはそれなりに面白い物だったのだが、最近の検索上位は、そういうものに行き当たらない。しかも、そういうのがほとんどになったので検索下位には、なかなか行き着けないし、実際そういうブログは淘汰されてきているか、あるいは少なくなってきている可能性もある。ブログサービスの終了もあるし、そういう情報は皆TwitterなどのSNSに遷った可能性が高い。Twitterで検索すると、そういうのが比較的沢山出てくる。
原稿用紙設定
入稿するような原稿を書く場合はもちろんだが、そういう場合がなくても、書いた文章の分量を把握することは多くの場合重要である。だいたい、400字詰め原稿用紙に換算して何枚とか、そういうのが分量の目安になってくる。
高機能なテキストエディタでは、原稿用紙を模した書式で表示できるような設定ができる。もちろんWZもそれができる。通常は文字数などを気にすることのない表示書式を使っているが、マス目を表示させた原稿用紙設定に切り替えるとまさに原稿を書いているという雰囲気で、入稿原稿を書かない場合でも書く気分が乗ってくる。
秀丸もできるが、秀丸では行間罫線・文字罫線は単純な格子状になるだけなので、マス目にはなるものの、原稿用紙のような雰囲気とは少し異なっている。また、秀丸はおそらく同じ拡張子ではタイプ毎の設定は一つで、それを任意に切り替えるような仕組みにはなっていないので、毎回設定を変更する必要がある。あるいは、別の拡張子のテキストファイルを作る必要があるが、それではやや運用は不便になる。