オルタナティブ・ブログ > 「神奈河、神名川、上無川 。」 >

読めばベタに分かる、タイトルどおりのブログ

ATOK VS リッチクライアント?

»
昨日開かれたブロガーズ・ミーティング@ジャストシステムに参加してきました。

まずあらためて自分の立場、というものを明らかにしておく必要がある、と思いますので記述しておきます。

自分は一番小さい単位で言えばIT企画、というセクションに居るのですが、その上位組織は国内営業部門であるため、考えのベースとしては、「ITで何ができるか?」ではなく、「何をITにすべきか?」に置いています。企業の目的が利潤追求である、と学問にも謳われているとおり、個人の嗜好や興味でIT化を実現するのではなく、そのIT化にかかる費用が某かの利益貢献(やれば儲かるだけではなく、やらなければ儲けが減る、といったケースもあります。具体的な数値化はなかなか難しいのですが)ができないとすれば、そもそもやる意味は無い、と考える方に軸を置いています。したがって、新しいテクノロジーが出てきたから、と言って、ただ単純に早速それって使ってみるべきだよね!とか採用すると格好良さそうだしね!といった思考はしてはいけないし実際しようとも思わないし、まず、「今起きている問題で何か解決できそうなものあったっけ?」とか「いくらかかるんだろう?」とか「永続的に使えそうか?」とか言う批判的な目で見ることにしています。

ブロガーズミーティングではわざわざ言わなかったのですが(言う程の事でも無いので)、自分が初めて触ったパッケージソフトが「一太郎」と「Lotus 1-2-3」でした。もう15~6年前の話です。自分の家にはPCなんてものは無く、自分は特にPCに興味もなく、ただ偶然学校の授業で「履修してみようか」と思った講座がその2つをメインにしていた、それだけの理由でした。当時自分はCanonのワープロを愛用しており、自分比ですが、Canonのワープロの変換能力・効率が他社のワープロに比べダントツに良い、と思っていました(キーボード配列も良かったのですが)。そしてPCには全く無知だったので、「そんなPCのソフトが専用機と同じぐらいきちんと動くの?」ぐらいの認識だったように思います。今のご時世から言えばそんな考え方を持つこと自体が不思議でしょうけど(笑)
それで「一太郎」を初めて触った印象は、「Canonとは当然連文節変換の考え方が違うけど、これはこれでありかも」と極めて好印象を持ち、自分にとって”ワープロと言えば”の連想において、Canonの次に「一太郎」が位置付けられるようになりました(・・・正直、まだその時もCanonより超えているな、というイメージは無かったのですが。失礼!)

その後会社に入ったら、会社が使っているPCがFM-Rだったせいか、ワープロは「FM-OASYS」だったので、「一太郎」を覚えたことが役に立たないだけではなく「FM-OASYS」の操作性や変換能力にどうしても慣れずイライラし(→あくまで個人の主観です)、やっぱり、「やっぱPCソフトが皆凄いのではなく、「一太郎」が凄いんだ!」と実感した覚えがあります。会社に入って初めてそこそこまともにもらったボーナスでPCを買うことになった時、友人(→当時はまだプロミュージシャン指向。PCショップでバイトしてた。ちなみに、自分も音楽活動封印の上就職)に相談したら、「やっぱMacでしょう!」と言われ、自分の支払い能力と天秤で当時二個型落ちの30マシンを定価ベース80%OFFで購入しつつも「ATOKだけは入れとか無いとイライラするで!。(当時の)ことえりの変換はほんまひどいで!」とのアドバイスに前述のFM-OASYSの経験もあり素直にしたがって購入した、そんなこともありました。
その後、iMac(Rev.B)購入時も「ATOK」は購入し、自分の業務がよりCRMに近い所になった時、興味深く内容を追っていたのは「Concept Base」でしたし。
そういう意味で、自分の中では、ジャストシステム=極めて日本語処理の上手な会社、という印象がもの凄く強く、それ以外のイメージはほとんどありませんでした。

前置きが長くなってしまいましたが、その印象で臨んだブロガーズミーティングでしたので、まず冒頭に紹介を受けた、ジャストシステムのそれはもう数々の製品群について「へぇ~そんなものまで・・・」ということに単純に驚きました(自分が不勉強なだけですが・・・まぁ普通な人代表、ということで勘弁して下さい)。

やはり一番気になったのは、現在の「ATOK」の可能性でしょうか?既に一緒に参加された吉川さんの記事でも記述されていましたが、ATOKの標準辞書として駅の情報や法人の情報が既に登録済、というところや、辞書登録の如何によっては入力結果に対する変換候補の中に具体的なWebのリンク先を指定することでGoogleの検索入力欄なのにYahoo!の検索結果が表示できる、とか。一方、辞書登録および辞書の利用制限の方法を利用ユーザーだけが登録を行うのではなく、集中して管理することのできるATOK Business Solution 辞書配信システムなるものが用意されているとのこと。これを利用すれば、業務用途において、各スタッフが入力した結果に対してどういった変換候補を表示するか?だけではなく、変換候補を選択させないことや前述のようなアクションも集中管理できるようだ。

ジャストシステムの担当の方がおっしゃったことを意訳すると、「アプリケーションが用意する入力フィールドに入力された結果をもって次の処理を行おうとする(もしくはユーザーが意志を持って次の処理を行おうとする)前に、「ATOK」自身が先に動いてしまえば(もしくは先に動かす必要があるならば)どうとでもできる」ということか、と。この概念は今まで全く持ち合わせていませんでした。目からウロコが落ちたようです。

として考えた時、前述で言う自分の担当業務で考えると、こういうこともできるのでは無いか?と考えました。
ここのところ、ずっとWebベースの業務系システムが担当なのですが、これが極めて標準的なHTMLおよびJSPおよびServletで構成されたシステムなので、入力フィールドにおけるFEP制御はほとんど無く、また多くの箇所で入力チェック等を構成していること、また、DB上に多くのマスターを保持し、また、各業務画面等に数々の区分処理を行うオプションボタンやラジオボタンを配していることにより、極めて複雑な、また肥大化したシステムとなっているのです(→そうなってしまった理由等はまたおいおいご紹介できる範囲で紹介させていただきます)。また、なかなか標準的なABC分析等には、FEPのON/OFF切替工数なんてものを上げる調査は少ないが、実際にはもの凄い工数になっているのでは無いか?このことは現在のこのシステムの位置付けおよび将来性から考えても非常に忌々しきことではあるので、そのソリューションの一つとしてずっと以前からリッチクライアントを注視しているのですが、別にFEP制御に頼らなくてもFEPとしての「ATOK」が起動してさえすればできることが逆に存在する時、今まで考えもしなかったのですが、「ATOK」がリッチクライアントの売り、と言われている部分の一部を担える、とすると、リッチクライアントが開発者に要求する新たな知識の習得、リッチクライアントにおける「どこが優位に立つか?」を見据えた将来性の考慮等が不要になるので、(ここから07/2/4 13:58追記→)業務システムにおいては(←ここまで)「ATOK」がリッチクライアントのライバルとなり得るのでは?と考えました。
(もちろん、リッチクライアントを自分が考えているようなある特定の用途で利用しようとした時、ということと、ジャストシステムがいつまでも「ATOK」を作り続けるであろう、ということが前提ですが、後者の方はもうそれは絶対で良さそうですよね!>ジャストシステム様)
例えば前述のマスターにおいても、区分情報や世間一般の情報等は頻繁に変わるものでも無いので、わざわざマスター構造として持たなくても辞書として保持しておけば済むものもあります。一つの入力欄において同じ入力内容でもその次のアクションが変わるようなケースがある場合、その次のアクション部分も含めて辞書化してしまえば済むものもあります。しかも、その欄におけるFEP制御云々を考えなくて良い(逆に起動させていれば良い)とすると、大文字小文字や全角半角、はたまた、ひらがなカタカナといったこの欄で入力させたい形式はこれ、まで辞書に任せてしまえる、それはもう全く考えもしなかったことなので、冒頭で言うところの「何をITにすべきか?」の所に非常に強く響きました。
そういった意味で、今自分の中では「「ATOK」ならどこまでできそうか?」をもうちょっと深堀りしてみよう、そういう気になっています。

ただあえて、(まぁこれは「ATOK」に限ったことでは無いのですが)こういったパッケージソフトが持つ機能そのもの、というのがユーザーにはもちろん、SIベンダーの方にまでどこまで認知されているのだろうか?ということを勝手ながら感じます。自分の場合、前述のような立場ですから、最終的な判断という意味でのIT開発におけるインフラや機構選定や購買折衝、維持管理の役割を担いません。したがって、そういった場合は、弊社で言えば、IT部門とSIベンダーとのやりとりになってきます。また、単発的な場合だと、うちの部門を通らず、国内営業部門の中でうちと並列に存在する業務部門が直接代理店等を通じてシステム構築を発注するケースも時にはあります。そんな時、これは「ATOK」の話では無いですが、「Excel」のVBAで十分なものを「Access」で構築したり、逆に「Access」で十分なものをわざわざ「Oracle」の一部領域まで使って、とかいう事例をもの凄くたくさん見てきたので、ユーザーはもちろんのこと、IT部門やSIベンダーにおいて、パッケージソフトそのものの知識・可能性に対して認知度が高い、とは必ずしも言えないのでは無いか、と感じています。

ジャストシステム様にはその「ATOK」の魅力、能力をもっと存分に出し切れるように(これまでもされて来られたとは思いますが)更なるSIベンダーへの波及、インフルエンスを期待したい、と思います。

追記1:ブロガーズミーティングには、ジャストシステムの多くのスタッフの方々とお話できただけではなく、浮川社長や浮川専務とお話することもできました。皆様、お世話になりました。ありがとうございました。経営陣の方が自分達の行っている商品やサービスに自信を持って熱意を持って話している姿を目の当たりにすると、より一層、その会社の商品に対する信頼度や安心感って増すよなぁ、と感じました。昨今不二家の話が取り沙汰されているだけにそれはもう本当に。。。

追記2:ブロガーズミーティングで「ATOKご利用されている方?」とジャストシステムの方に質問されて、一応手を上げたのですが、家に帰って確認すると、自分のiMacで利用しているATOKはバージョン13でした。。。って古過ぎます?

このページは xfy Blog Editor を利用して作成されました。

Comment(2)

コメント

Bar

>ユーザーが意志を持って次の処理を行おうとする前
>に、「ATOK」自身が先に動いてしまえば
 
こういうユーザーインターフェイスって、実装されたものを使ってみればわかるけどすごく不便。たとえば、入力フィールドが
A. [_____________]
B. [_____________]
   [送信ボタン]
とならんでいて、Aに入力し終わるとBに自動的にジャンプしたほうが便利だろう…と思うとさにあらず。ユーザーはAの入力後、Bのフィールドに移ろうと思ってアクションを起こしてしまうので間違ってBの入力モードをキャンセルして送信ボタンに進んでしまうことがある。「機械は機械以上のことをしてはならない」という例。
 
全角・半角などのモード管理も、このあたりのことを配慮していないと「余計なお世話」になってしまう可能性が高い。特に入力業務オペレータのように馴度の高い作業員は、自分でモードを管理することに慣れていてそれで作業効率を高めていることが多い(日本語入力業者が漢字の高度な変換機能を切って使うのと同じ)ので、強制的に漢字入力モードにされるだけだったりすると混乱が起きる。
 
>わざわざマスター構造として持たなくても辞書として
>保持しておけば
古いATOK13をそのまま使っているような人もいるので、どこに「更新すべき辞書」をもっている人がいるかわからない。そうすると、その更新管理のためのコストがばかにならなくなってしまう。
 
インプットメソッドはインプットメソッドとして洗練されることを目指すべきで、守備範囲を広げすぎるべきではないでしょう。ジャストがそういう業務展開を志向しているのだとすれば、先行きはあまり明るそうな気がしません。

>Barさま

早々のコメントありがとうございました。
コメントいただいたことはごもっともだ、と感じます。

自分の記事で若干言葉足らずなところ、長過ぎてわかりにくいな、とあらためて思った所について補足させて下さい。

リッチクライアント、という存在はユーザーに対する表現を豊かにする側面と、ユーザー自身が利用するUIの改善する側面と両方があり、またそのユーザーも、Web上での不特定多数を対象にする場合と、業務システムのようなある閉じられた世界における特定の利用者を対象にする場合の双方がある、と認識しています。

そういう意味で、上記「ATOK」の件で自分が感じたのは、業務システムにおけるUIの改善において、になります(ここはご理解いただいていることか、と存じますが)。業務システムにおいては動作保証およびサポート等の観点からその動作環境をある程度固定せざるを得ません。この時、ATOKに頼るなら頼るで、バージョン統一および辞書の統一ができる環境は必須となるか、と思います。

そうなった場合、果たして費用面(ライセンス、ランニング)云々も含めて見合うのかどうか、は十分検討すべきでしょうし、ご指摘のとおり、FEPに頼りたくないところでも余計なお世話をされることによる作業効率低下が発生するのは望むことではありません。

ただリッチクライアント界そのものでも各種のソリューションが出てきて競い合っている中、入力制御関連でリッチクライアントとは全く違うアプローチを取るには、で自分が思い付いていたのは、CitrixやWBT等を利用してVB等で開発されたアプリケーションを利用するようなイメージしか無かったのですが、また全く異なる見方ができたことについて述べさせていただきました。

今後ともご意見・ご感想をいただけましたら幸いです。
何卒よろしくお願い申し上げます。

コメントを投稿する