SKK の入力方式は、
・通常はかな直、変換したいところだけ変換
→ 単語変換なので文節区切りの誤りがない。というか、そもそも変換したい部分の頭とお尻をユーザが指定してるので、変換エンジンは間違えようがない
→ 「変換不要な部分(ひらがなのままでいい部分)が変換されてしまう」ということがない
・送りありと送りなし(「活用語か否か」とほぼイコール)で変換操作が異なる
→ 「いた(居た)」と「板」のように連文節変換方式では同じ読みになって混同されるものを区別して変換し分けられる。
という 2つの点で高い変換精度を実現している。
反面、操作がその分面倒で細切れになり、入力に時間がかかる。
対して、連文節変換方式は、「どこが変換の必要な部分か」とか「どこで区切るべきか」とか「活用語か否か」といったことをユーザは一切気にせず、とにかくベタな読みだけを入力、変換エンジンが返してきた変換がおかしかったら後からそこだけ直す、という方式。
ユーザは、入力時は、とにかく読みを入力することだけ気にしていればいいので、入力は速い。変換時も、たとえ変換エンジンが返してきた結果が酷かったとしても、直すのにそれほど時間がかかるわけではない。
お題として与えられた同じ文章を入力する場合で考えると、自分がやった場合、SKK に不慣れな点を考慮しても、多分連文節変換方式での方が倍くらいのスピードで入力・変換できると思う。Anthy を使っても。
つまり、「入力・変換操作を複雑化させることで変換精度を上げる方式」より、「入力・変換操作は単純にして(その分初発の変換精度は前者より落ちる)、後から誤りを訂正する方式」の方がトータルでは早く入力できると思われる。
そういう意味では連文節変換方式の方が優れていると言えると思う。
(開発コストのことは、ここでは勘定に入れないことにする)。
にもかかわらず、連文節変換方式はユーザからは結構不評だったりする。「バカ」とか「イラつく」とか言われる。他方 SKK は、操作の面倒さに文句を言われることもあるが、それでも「操作に慣れてしまえば快適」と言われることが多いように思う。連文節変換から SKK に乗り換える人も結構見かける。
これは偏に、「連文節変換エンジンが返してくる変換結果がユーザにとってはストレスを感じさせるから」ということに起因すると思う。
ユーザには「期待する変換結果」がある。物事が期待通りに行かないと人はストレスを感じる。常に思い通りになるわけではないと分かっていても、頻繁に思い通りにならなかったり、期待からあまりにかけ離れた結果が返ってくると、やはり頭に来る。「なぜそういう結果になるのか」が理解できないとさらにストレスになる。そして、一般ユーザは変換エンジン内部のことなど当然知らないので「なぜそうなるのか」など理解できず、ストレスが溜まる一方ということになる。
そんなこんなで、連文節変換エンジンは往々にしてユーザにストレスを感じさせてしまい、心証を悪くしてしまうのだと思われる。変換精度が悪ければ悪いほどそうなる。
「速く入力できるかどうか」より「気持ちよく快適に入力できるかどうか」の方が大事なのだ、という考えは十分「あり」だと思うし、それが SKK を好む人の心理なのではないかという気がする。「速く入力できるかどうかという"結果"も大事だが、入力・変換時の"過程"も大事だ」ということだと思う。
ここまでが前置き。
じゃあ、連文節変換方式はどうしたらいいのか？
変換精度を上げればいい。元々入力速度は圧倒的に連文節変換方式の方が速いのだから、変換精度を上げてユーザのストレスさえ減らせれば最強のはず。
でも、「言うは易し、行うは難し」で、変換エンジン自体の改良は非常に難しい。できる人はごく限られてるし、できる人がいても即席には出来ない。そもそも Anthy は本体の開発は終わってしまっている。
なら、変換エンジン本体はいじらずに、もう少し容易な方法で変換精度を上げることは出来ないのか？例えば、SKK ほどではないにしても、何かもうちょっとだけユーザ側が負担する(変換エンジン側の負担を軽くする)ことで、変換精度を上げられないか？
誤変換には大きく分けて「文節区切りの誤り」と「候補選択の誤り」があると言われるが、文節の区切り位置をユーザが明示的に指定してやれば、「文節区切りの誤り」はなくなるから、その分変換精度が上り、ユーザのストレスも減るだろう。
で、以前考えたのがこれだったんですが、これだと「読み」の入力時に区切り位置の入力も行うので、せっかく「読みを一気にダーッと入力できて速い」という連文節変換方式の良さを損なってしまう。
SKK 風に自立語の先頭を大文字にする方式も、同じ理由で避けたい。
なので、別なのを考えた。
1. まず通常の連文節変換方式のように、区切りなしのベタ読みをダーッと入力する
例： このままこうかいされることはないとおもうけどI
※「I」はキャレットのつもり
2. 次に ctrl+a を押してキャレットを先頭に持ってくる
例： Iこのままこうかいされることはないとおもうけど
3. 左右矢印キーでキャレットを移動させながら、区切り位置指定文字を入力
例： このまま;こうかいされる;ことは;ないと;Iおもうけど
※区切り位置指定に「;」を使った場合
4. 変換キーを押して変換
例： [このまま|公開される|ことは|ないと|思うけど]
※区切り位置指定文字はいわばメタ文字で、文字として変換はされないものとする。ここでは「|」は区切り位置を示しているだけで文字ではない
これなら、読みの一気入力を損なわないので、少なくとも前のよりはかなりマシかなと。
入力のスピードは区切り位置入力の手間が増える分多少遅くなるが、変換精度は確実に上るはずなので、誤変換を修正する手間が減る分は取り戻せる。あとは「手間が増えるというデメリットより、おかしな変換を見なくて済むことによるストレス低減の方が嬉しい」と思えるかどうかだと思う。
ただ、「区切りを指定しなくても正しく区切ってくれる時も結構あるのに、毎回すべての区切りを入力するのはいかにもムダ」という気もする。
なので「一旦変換してみて、区切りを間違えていたら、変換キャンセル → 区切りを間違えていたところだけ区切り指定し、再度変換」という風にした方がいいのかもしれない。でも、そうすると「おかしな変換」を見ることになってしまうので、やはりストレスを感じてしまう気がする…。
あと、区切り位置を指定しても、変換エンジン側が更に細かく区切ってくるかもしれない、という懸念もある。例えば「ここだけ;へんこうできると」で変換しても「ここだけ|変更で|切ると」にされてしまうかもしれない。これは「事前の区切り位置指定」ではどうしようもないので、これまでのように文節を伸ばして直すしかない。「ユーザがすべての区切りを指定する」という縛りがあれば回避できそうだけど。「ユーザが明示的に指定した場合はそれを使い、あとは変換エンジンが判断して区切る」とかだと無理な気がする。
まぁ、どっち道自分では何も出来ないので、思ったことを書いただけです。何かのヒントにでもなればいいな、と。
-----
・連文節変換は 1〜2文節くらいでの変換が苦手とよく言われると思うが、他方で、ユーザは短い文節で変換することがよくある。自分もそう。特に考えながら入力している時は短くなりがち。この辺のギャップがまた心証を悪くしている原因のように思うが、これは区切り位置指定では対処できないと思う。かと言って、SKK のように活用語と非活用語を入力し分けるのも難しい。
・話は逸れますが、以前(去年の 10月) alt-cannadic から SKK 用辞書を生成するスクリプトを書いたのを思い出した。ただし、自立語部分だけで、接頭辞接尾辞は手を付けてなかったけど。元が alt-cannadic なので当然「送り仮名の開始位置」ではなく「活用語尾の位置」で大文字にする必要があるが、uim-skk で使ってみた感じでは、結構いけそうな感じだった。
【関連する記事】
Windowsではこの問題をうまく解決していると思います。
下記URLの"余談その 2 - テキストストアを活用した変換候補の選択"の項参照。
http://d.hatena.ne.jp/NyaRuRu/20070309/p1
なるほど、あれはそういう仕組みだったんですね。