「○○入力法は、速く入力できる日本語入力法だ。」は恒真か?

 「小難しく書こうとしてしまった上に、意味が間違っていた」という、ひどい間違いをしていました……。
 その点についてご指摘を頂いていますので、「恒真」ということばに「???」とお感じになった方は、ぜひとも「この記事のコメント欄」をお読みください。


 #「なるべく平易に、かつ正しく書く」という基本から、思いっきり外れてました……その点すみません>皆様。


 ……○○のなかには、 http://www4.atwiki.jp/japanese_keyboard_layout/ に載ってる入力法でも、そうではない入力法でも、何でも好きな名前を入れてください。何を入れても答えは同じです。
 ……で、答えは「恒真ではない!」。*1
 #ちなみに、この「恒真ではない!」という答えすらも、「恒真ではない!」わけで……アアヤヤコシイ。


 日本語入力を含む文字入力法に関して、根本的に考え違いをしてる人がいる……と思うので、一応書いておくけど。
 日本語入力法が腐るほどあるのは、「圧縮する方法がそれぞれに違う」=「人それぞれに、圧縮しやすい&展開しやすいルールが違う」から……なのですが、これらのうちどれが「当人の能力を最大限に発揮できるか」ってのは、まさに「実際に使ってみて、始めて解る」セカイなわけで、いまのところ実験的に「どの配列が向いているか」を調べる方法すら確立していない状態です。
 ついでに言うと、「世間様にとって良いもの」を見つけたところで、「ワタシと世間様は違うだろ……」ってなるだけなので、「世間様にとって良いもの」を探そうとするのはあまり意味がない気も。


 この圧縮具合いが一番解りやすいのは「ステノワード」かな。
 ステノワードはむちゃくちゃ圧縮率が高いので「圧縮した定義を使いこなせれば、とても高速に文字入力できる」わけです。
 ところが、ステノワードの高速入力性を生かすためには「圧縮した定義を、高速に使いこなす必要がある」と。
 これは今でも「デカいデータを(通信速度の遅い)Internet経由で転送するなら、非圧縮で転送するよりも【圧縮して転送して展開】のほうが早い」とか、そういう現象でおなじみかも。
 打鍵速度が速くなくても「高圧縮記述ができるなら」高速に入力できます!ってのが、ステノワードの肝。
 で、ロマかなとかはまるっきり逆だよね……「高圧縮記述が出来なくても」打鍵速度が速ければ高速に入力できます!だし。


 その人にとって「最も効率よく快適に入力できる入力法」は何か?を定義するとなると、たぶん

  • 【その人にとって】許容できうる範囲で圧縮定義された入力法を用いて、【その人にとって】許容できうる打鍵速度で入力したときに、最もすばやく入力できる入力方法。

……ってゆー定義にならざるを得ないと思う。
 インチキグラフで描くと、↓みたいになる……と。

  • 低い圧縮率しか扱えないけど、高い打鍵速度を出せる人。
  • 高い圧縮率を扱えるけど、低い打鍵速度しか出せない人。
  • 中庸な圧縮率を扱い、中庸な打鍵速度をだす人。

 ……こういう三者三様の人々に対して「ただ一つの○○配列こそ、あなたにとって最も速く入力できる方法だ!」って言い切れるのは、「あたりまえのことを、さっぱり理解してない人」だけです。
 ……で、日本語入力のセカイでは、ながらく「あたりまえのことすら通用しないと勘違いしてる人が居た」らしく……こういうのって、ほんとに「運が悪かった」としか言いようがないのかも。

 
 あと、「恒真ではない!」という答えすらも、「恒真ではない!」となる理由は……たとえば、

  • 「い」という文字を打つために、100回キーを連打しなきゃいけない。

みたいな、無意味に冗長なけん盤配列がありえるから、ということで。
 ただ、一般に公開されてる配列というのは、大抵こういう冗長さはない*2から、まずこういうところでリジェクトされるものは無いと思うけど。

打鍵速度の評価方法について。

 ひとまず、

  • 「もと使っていたけん盤配列」が異なる人を複数人集めて、それらの打鍵速度データをとる。
  • 運指距離演算処理について、せめて「飛鳥の【とは】みたいな運指」くらいは、真面目に処理している。

……とか、そういう心遣いは必要になってくると思う。
 けん盤配列を「作る」うえでは、これらは必須ではない……けど、「平等に評価する」なら、こういうのは必要だな、と。

ムダの無い配列を作るための、鉄則。

 ぶっちゃけると、ルールはすごく単純で、

  • 3-gramサンプルを打鍵するときに、「この動きはムダじゃない?」って、24時間365日、延々と悩むこと。

くらいしかない、と。
 ……もっとも、以前に「評価打鍵は1000時間で」って書いたくらいなので、さすがに「24時間365日(=8760時間)」は必要だと思ってはいないけど。


 前にもチラッと書いたけど、「(価値を生まない)動き」と「(価値を生む)働き」のくべつは、きちんとやるほうがいいと思う。

 「働き」=「キートップに指が触れてから、スイッチがonするまでの間」。
 飛鳥とか連続シフトを使うモノは、「押している間のうち、修飾される側のキーが打たれた瞬間」と「離し始めてからoffになるまでの間」も「働き」。


 あとの動きは、全て「働き」ではなく「ムダ」。
 キーに触れずに指が動いてるところは「ムダ」。
 スイッチがOnしてるのに、さらに押し込む操作も「ムダ」。
 Offタイミングが関係ない配列なら、On期間もTurnOff期間も全部「ムダ」。


(from 打鍵効率原則。 - 雑記/えもじならべあそび )

 打鍵時間を基準にするときには、こういう「働きの時間と、動きの時間を分離して考える」ってゆー考え方を持っていると、測定した時間を「どう切り分けるべきか」ってゆールールを組むときに、役に立つんじゃないかな……という気がする。

それでも「××入力法は、すばやく入力できない入力法だ!」「○○入力法のように効率をよくするべきだ!」と言いたい人へ捧げることば。

 正直、あんたの働いてる「職場」よりも、「××入力法」のほうがはるかに効率的だと思うよ。
 「××入力法」がもつ、わずか「数十g・mm/Action」とは比べ物にならないような「働きになってない、単なる動き」が、たぶんあなたの職場には「数ton・m/Actionの単位で」溢れてる*3から……そっちを優先して直すべきじゃないの?と、ワタシはそう思うわけで。

*1:こういうことは、「みんなの耳にたこができてもなお(?)」言わなきゃいけない気がする。言うのを止めたとたんに「嘘によってかき消される」らしいことは、ほぼ確かだと思うから……。

*2:一見冗長に見えて、その理由が「定義をカンタン化するための仕掛け」だったりするものがある、と。たとえば「濁点キー」「半濁点キー」「小指シフトによる小書き文字化」とか。

*3:というか、最近、職場のムダを「数十g・mm/Action」単位にまで圧縮できたら、どんなにすごいだろうか……ってゆー妄想をしてます。今目の前に「そういう現実」がないけど、なんとなく「出来そう」な気がするので……。