無意識が選択する (1)

[↑一覧] [新着] [ホームページ]

昨年末、FKBOARDというフォーラムがオープンした。ちなみに、鍵盤楽器のフォー ラムではない。文字入力装置のキーボードがテーマである。

　フォーラム名称はNICORA・キーボードフォーラム。これから分かるように、 NICORA配列が中心で、その他のキーボードについても語ろう、といった趣旨の感 じのフォーラムだと思ったのだが、実際参加してみると、直接入力方式(*1)を 使っている皆さんが、想像以上に積極的なのが面白い。NICORA配列に関する資料 やインタビュー録の発言量は多いのだが、あえて辛口に批評するなら、単に製品 の宣伝活動をしているような雰囲気がどうしても感じられてしまう。

FKBOARDで議論するうちに、かな漢字変換の思考モデルを考えることになってし まった。気楽に書くわけにもいかず、暫く時間をいただいて推敲しているうちに、 会議室では話が勝手に進み、雰囲気が怪しくなり、私がコメントする予定の方が 「かな漢字変換については一切コメントしない」と宣言するに至っては、もはや 今更発言できる雰囲気ではなくなってしまった。が、折角の成果を捨てるのも勿 体ないから、ここに書いてしまうことにした。

　なお、割と根拠のない空想的な意見が多いので、科学的な裏付けが欲しいなら、 ご自分で追試・検証していただきたいと、あらかじめお断わりしておく。

    *

  (1) 読みの入力。
  (2) 変換開始操作。
  (3) 候補の選択。
  (4) 確定操作。

(注) 所謂「自動変換」のような方式は考えない。また、読みを無変換で確定したい 場合の操作も変換確定操作の一種と考えることにした。

　この中には省略できる操作があるので、これについて検討する。まず、読みは 必ずしも全て入力する必要はない。短縮した読みを辞書登録する手法は一般的に 行なわれている。例えばこの文章には「かな漢字変換」という言葉が頻出するが、 「かなかんじへんかん」という読みを入力するのは煩わしいので、「んか」とい う読みで「かな漢字変換」と変換されるように辞書に追加登録して使っている。

(3)の操作は、変換された最初の候補が目的の漢字なら不要だが、変換結果が正 しいことの判断が必要なら、(3)の操作の一部と考えるべきである。これに対して 変換結果を全く見ないで次の入力ができるときには(3)を省略したと考えてよい。

　次の読みを入力することによって、その時点での候補が自動的に確定する場合 は、(4)の操作は不要である。

　今回は、このうち(1)(2)と(4)については、熟練者は無意識に処理できるのが明 らかであると仮定する。

　残る(3)の操作が今回の議論の最も大きなポイントである。かな漢字変換に否定 的な最も代表的な意見は、(3)の処理には意識的な操作が必要だから文章創作の思 考に邪魔になる、というものだ。これに対して、FKBOARDで私は「かな漢字変換に 熟練すれば、(3)も含めて無意識下に操作可能」と主張した。

(注) 「意識的」「無意識」という言葉の解釈も難しい。検討は後に述べる。

    *

　例えば「漢字」という字を書く時に、どのような思考が行なわれているか考え てみよう。まず、これが「漢字」という漢字であるだけでなく、「かんじ」とい う読みを持ったものと認識していることに注目する。経験的に、読めない漢字を 文章中に平然と書くことはまず不可能だ。故に、日本語で文章を書く時には、必 ず読みの情報が頭のどこかにあると考えてよい。「漢字」という字を書こうとし た瞬間に、それが「かんじ」という読みであることも頭のどこかで同時に認識し ているのである。

　また、「漢字」という字を書くためには、どこかに表記に関する情報があり、 それをアクセスしているはずだと考える。従って、少なくとも、意味・読み・表 記の3つが密接に関係していることは間違いない。そこで、次のようなモデルを想 定した。頭の中には、これら3つのデータが不可分な単位として格納されていると 考える。

    (意味・読み・表記)

　ただし、この中の「表記」には漢字の正しい書き方が直接対応するのではない。 これは後で検討する。

    *

　頭の中に浮かんだイメージから、読みを連想し、発声する…という逐次的な考 え方にはかなり無理がある。「思わず言ってしまった」という慣用句からも分か るように、思わなくても口には出せる程、思考と発声は同時に実行することがで きる。普段、まず意味を考えて、読みを対応させ…といちいち考えていないこと は、会話できる人なら異論もないだろう。今回考えたモデルでは、イメージの時 点で意味も読みも表記もごちゃまぜの状態で既に発生していると考えているから、 会話の場合には、ここから読みを導出すると解釈すれば、自然なモデルが完成す る。

    (意味・読み・表記)→読み

    *

    (意味・読み・表記)→表記

　頭の中に(意味・読み)だけの不完全なデータが記憶されることがある、という 解釈はどうか。確かに漢字が書けないという現象は説明できるが、読めても書け ないような漢字の存在をうまく説明できないようである。

　従って、やはり(表記)はあるのだが、正確な情報ではなく、漠然としたイメー ジ、例えば正確な二次記憶へのヒントの情報に過ぎないと考えてみる。例えば 「仮説」と書く場合、頭の中には次のような情報の組が記憶されているのではな いか。

    (「仮説」の意味・「かせつ」・↑仮+↑説)

　「仮定」と書く場合には、同様に「↑仮」と「↑定」というポインタが記憶さ れているが、この仮説の特徴は、「仮説」という表現中の「↑仮」の指す先が、 「仮説」の情報中に現われる「↑仮」の指す先とに等しいと考えていることであ る。

　実際に漢字を書く時に、へんやつくりだけ思い出せる場合があるが、これは表 記の情報として、何へんである、といった具体的なデータが格納されていること を意味する。

　筆記の手順に対して、既に書かれた文字を読む場合には、視覚から得た情報を パターン認識するデータベースへの参照が必要である。読めるが書けない漢字が ある以上、このデータは筆記のためのデータとは別でなければならない。

    (意味・読み・表記)→<フォント情報>→表記 

　　表記→<パターン認識情報>→(意味・読み・表記)

(注) 漢字は書けるが読みは全く分からない、という例は殆どないが、経験的に、皆 無でもない。しかし、もし読めないとしても、誤読によってとりあえず読みを 当てるという場合が圧倒的に多いのではないか。

    *

　しかし、他の方法が繁雑でないかというと、必ずしもそうではないのである。 最終的に文字の状態を得るためにどのような操作が必要であるかを比較してみる。

　手書き:       筆順に従ってペンを動かす
　直接入力方式: 覚えているキーストロークの組に従ってキーを打つ
　かな漢字変換: 読みに従ってキーを打ち、変換結果に従って候補を選択する

　直接入力方式は、キーを押す順序が固有の漢字に直接対応しているのであり、 漢字とは無関係な「キーを押す順序」を経由するという点では直接的ではない。 もっとも、キーボードを使う限り、キーの位置を覚えるという訓練からは逃れら れないのであるが。しかしキーの押す順序が固定化されていることは、反射的に 操作する上で大きなメリットになっていると思われる。

　ワープロの熟練者の中には、候補の並びを固定するモードで入力することを好 む人がいる。常に固定した位置に候補を出すことによって、反射的に操作しやす くなる。変換キーを押してから何番目の候補という所まで反射的に操作できるよ うに覚えるのだ。

　直接入力方式の場合には、今までのモデルの3つ組の中に、さらに打鍵手順とい う知識を追加すると考える。熟練者の頭の中に作られる構造は次のようになる。

    (意味・読み・(表記・打鍵手順))

    (意味・読み・(表記・打鍵手順))→打鍵手順

　表記と打鍵手順を括弧でくくったのは、両者の関係が特に密接ではないかと思 ったからである。打鍵手順は、実際は漢字毎の知識として持ち、モデル中ではポ インタ情報のみを格納するとも考えられる。

　直接入力方式を実際に経験したことはないのだが、個人的な独断的感想を書か せていただく。とりあえずでも感想が書けるのは、ネットで自称「直接入力を使 っている」という数名の方の文章を、何度か拝見したことがあるからだ。これら の方々の表現に共通して気掛かりなことがある。私なら漢字で書きたいような文 字を仮名書きしている場合を結構見掛けるのである。もしその理由が、漢字に対 応するキーを押す手順を覚えていないのでとりあえず仮名で書いた、というので あれば、これは直接入力方式の明白なデメリットである。すなわち、

　自分が文章中に使いたい漢字に対応するキー手順を全て覚えるまでは、直接入 力方式は自由な表現の妨げになるだろう。もちろん「漢字が書けないから仮名で 書く」というのも一つの選択であることは否定しない。また、逆に「つい漢字に してしまう」のは、かな漢字変換の欠点でもある。必要以上に漢字が使われてい る文章は、かえって読む時の妨げになるからだ。ただし、偶然私が見た文章を書 いた人が入力慣れしていなかった、ということも十分考えられる。また、特に使 い始めた人の発言を見ていると「アルジャーノンに花束を」を読んでいるようで 楽しいものである。

(つづく)

補足

    COMPUTING AT CHAOS RUINS -210-
    1994-01-12, NIFTY-Serve FPROG mes(6)-073
    FPROG SYSOP / SDI00344   フィンローダ
    (C) Phinloda 1994, 1996