親指シフト(NICOLA)単独のJIS化を目指すためには、いったい何が必要なのか。

(過去:【4月1日終了直前】JIS X 4064について、2009年度改定に向けての公式レビューが開始されたようです。 - 雑記/えもじならべあそび)

　(2008年7月28日0:21:30追記)この記事？は、左記時間までこまごまとした追記訂正を行いました。
　日付をまたぐ記述変更を行ったため、ひとまずその点をメモとして書いておきます。
　(2008年7月28日1:05:44追記)「100倍近くいるJISかなユーザ」ではなくて「100倍近くいるQwertyロマかなユーザ」でした……ここは取り消し線訂正を行いました。


　……一番単純なこととしては、

  • 「利用者の意見を中心に、ユーザ数を【割合ではなく絶対数で】アピールすること」
  • 「1980年(!)以降の資料について、可能な限りネタとして使われないようにすること」

のあたりは必須とだ思います……が、正直言って

  • どちらも、今現在とる手段としては「時代遅れ過ぎる」。

という結論に至りつつあります。
　ダラダラと考えた経過は以下のとおり。


　入力速度比較については、(既にRayさんがバラしてしまっているとおりに)同時打鍵方式はもともと「速度重視」でいくには負担が重い方式です。
　ネット上で公開されているあたりでは、

  • 小梅配列(TRONのようにシフトキーへの依存度を減らすことが有効)という方針。
  • 飛鳥カナ配列(シフト状態の変移度を減らすことが有効)という方針。

という、２つの方針である程度表現できたりするので、このあたりが「見つからないように振舞う」必要があります。
　また、過去文献としても、

  • TRONかな配列(NICOLA/JIS X 6004/TRONかなの3種比較がバッチリ載っている)の資料。
  • JIS X 6004(JISかなとの比較があるので、NICOLAの速度に関する文献にかぶせることができてしまう可能性がある)の資料。

の2つが普通に引き出せる状態にあります*1。
　ネット上のそれらを見つける可能性があるかどうか……という点については不明ですが、さすがに紙文献は見つかってしまうでしょうから、それに対してどう言い訳をするのか……というところは、今からそれぞれの文献を引っ張ってきて検討する必要があると思います*2。
　また、従来行われてきた「JIS X 6004に対する批判」について、その解決案が既に提示されてしまっているところについても注意する必要があります。特に「JIS X 6004」と「花」に絡んで「月配列」が生まれたあたりを詮索されると、中指シフトを通してセンターシフト方式のことが出てきて、結果として「JIS X 6004はダメです理論」が崩れてしまうところが厄介でして。
　こういった事情から、「NICOLAを性能面で有意だと位置づける」というのは、とても危険が伴うことなのではないかと感じています。
　正直、いままで「計算で配列の優劣を決めるなんてムリムリ〜」といい続けてきた私*3ですが、真面目に現行の高性能コンピュータを使って物理演算によるシミュレートをすれば、少なくとも「機構が極めて近い入力法同士の比較」は十分にできてしまうのではないかと危惧しています。現状では

  • 「NICOLA vs 飛鳥」──移動距離が数割違うけど、ぎりぎりごまかせるかも(飛鳥の打鍵動画が見つからなければごまかせると思う)。
  • 「NICOLA vs 月配列」──理論武装で測定値を弄らないと厳しい。
  • 「NICOLA vs 小梅」──(比較条件が揃い過ぎていることもあり)かなりヤバい。小梅の使用経験があれば、この「ヤバさ」は誰もが気づくと思う。

という感じですね……真面目に性能面で比較するのは「あまりにも危険すぎる」と、私はそう思います。

　「訓練によって速くなった実績を持つ人が多い」ことは、測定方面においては何の役にも立たないところがポイント。
　標準時間法で測定されたら一巻の終わりです。


　……ではどうするか？といわれれば、性能面については隠蔽して、「有名人も使ってます＆使っている方の意見はこうです」方面でいく……と。
　ただしこれについても、「それを意識していないから、ロマかな方面＆JISかな方面に関する推薦テキストが少ない」だけの話だと、私はそう感じています。
　そのため、あまりやりすぎると

  • 10倍近くいるJISかなユーザさんによる推薦文が溢れかえる。
  • 100倍近くいるJISかなユーザ100倍近くいるQwertyロマかなユーザさんによる推薦文が溢れかえる。

という現象を生みかねない(まさに泥沼)ので、その点について対処する方法を考えなければ……ってイヤ無理だろソレ*4。


　私が「NICOLAの単独推進」をとる立場だったら、もう正直言って八方塞ですよ、これでは……。
　私だったら、「色々な入力法を扱えるエミュレータ(もしくはエミュレータとして振舞うライブラリ)」を規格の核にしてしまって、それに付属させる配列データについて、

  • NICOLAは規格本体に含める。
  • NICOLA以外は規格の解説とかに追い出す。

という方向で攻めるかもしれません。
　もっとも、そのあたりまで見透かされて、

  • (イネーブラ向けに必要な工夫を乗せた)特殊な50音配列を規格本体に含める。
  • それ以外は規格の解説とかに追い出す。

とかいう方向でつぶされてしまう可能性もある(イネーブラを作る方々の説得力ってゆーのは、快適さ方面を根拠にする人たちのそれとは段違いだろうから……)ので、危険な勝負であることには変わりないかもしれませんけれども。
　最終的には、

  • (イネーブラ向けに必要な工夫を乗せた)特殊な50音配列を規格本体に含める。
  • 標準時間法を使った打鍵時間シミュレーションをしてみて、よさそうなものを2〜3個規格本体に含める。
  • それ以外は規格の解説とかに追い出す。

という方向に落ち着くのではないかな……と感じていたり。

打鍵時間シミュレーションの結果を悪くしないために必要なこと。

　……これはとにかく、

  • BuffaloのB下割れキーボードを、標準時間測定用のサンプルキーボードとして使わせること(理由は一切告げない)。

くらいしか、解決策がないと思います*5。
　仮にここで

  • PCの普及率にあわせて、大手メーカーのキーボードを(ノート機を含めて)複数種使い、普及率に合わせて結果を調整する

という方向でやられたら、もう打つ手はないと思います。
　このあたり、もう少し考えてみるほうがよいのかなぁ……。

(2008年7月28日0:06:32追記)……そういえば、こういう方法ならアリかもしれない。

  • JIS X 6002の内容を取り込む(か、取り込めるような仕掛けにするだけでもよい)。
    • そのうえで、JIS X 4063の内容を取り込めるような仕掛けにする。
  • JIS X 4064側に、この新規格について対応するように指示を盛り込む。
  • 規格の仕組みは「キー配列定義を解釈する翻訳層」と「翻訳層が解釈可能なキー配列定義を記した接触層」の2階層方式にする。
    • 「キー配列定義を解釈する翻訳層」には、いくつかのキー配列入れ替えソフトが採用しているキー配列定義を解釈できる、キー入力翻訳エンジンを組み込むor接続できるようにする(時間があれば独自方式を検討してもかまわないが、作者さんからの許可があれば実績のある方法を採用するのが好ましい)。
    • 「翻訳層が解釈可能なキー配列定義を記した接触層」のためのキー配列定義としては、「Qwerty/JIS X 4063ローマ字」「JIS X 6002かな」「(NICOLAのうち共通部分としての)NICOLA-JR」「(イネーブラ向けに必要な工夫を乗せた、完全逐次打鍵操作が可能な)特殊な50音配列」を標準として定義する。
      • 「NICOLA-JR」を標準へと含める根拠としては、「NICOLA-JR」で規定する部分に限っては、版の差異に影響されず数十万人規模(署名法を用いた調査を要す)の利用者がいることを掲げる。ほかのことは根拠として持ち出さない。
        • 「NICOLA-JR」は市販キーボードのうち「JISかなキープリントなしのJISキーボード」によって基礎部分をまかなうことができるので、市場が混乱せずに済む。
      • 「(イネーブラ向けに必要な工夫を乗せた、完全逐次打鍵操作が可能な)特殊な50音配列」を標準へと含める根拠としては、「Qwerty/JIS X 4063ローマ字」「JIS X 6002かな」「(NICOLAのうち共通部分としての)NICOLA-JR」のいずれもが「イネーブラ用途向けのデバイスにとって最適とは言えない」ことを示せば十分だと思う。トグルキー操作と同時押下操作を完全に排除して「完全逐次打鍵シーケンスのみによって」すべての文字入力をまかなえる必要があるので*6。

　……と、こんな感じなら大丈夫かなぁ。
　まだ穴があるかもしれないけど、実現性が多少は上がるのではないかと思う。

*1:特に、JIS X 6004に関するドキュメントを「真面目にすべて」見れば、たいていの人は性能面に関して「これのどこがダメダメ配列なの？20年も前の話なのに、よく検討してまとめてるじゃん！」と思うはず……少なくとも、こき下ろすに足る根拠は見つからないですよ、アレでは。

*2:もっとも、検討のために使われた基礎データの量が「一桁か二桁違う」ことに気づかれたら、その時点でヤバイと思いますけど……。

*3:これにしても、実際は「こなとけろ　むるいのれめ」にクラッと来たくらいですから^^;、適切な条件さえ整えばかなりいけるのではないかと感じています。

*4:今の「インターネットが広く普及した」現状において、こういう方法をとるのはとても危険だと思います。

*5:とはいえ、NICOLAに慣れていない方をサンプルに使った場合、「親指キーに関するホームポジションズレ」＆「手のひらの移動距離(指先移動よりも負担があることは、MODAPTSをやった人間ならすぐにわかる話)」問題が出てくるので、まだ微妙かもしれませんが……。

*6:……ってゆーか、今気づいたのだが「JIS X 6004かな」はイネーブラ向けの要件をほぼ満たせるじゃないかorz。50音配列である必要性がない「機械経由入力のためのイネーブラ向け配列」としては、既に必要十分なものがあった、ということか。