ソフトウェアにとって―― 特に業務で利用するソフトウェアにとって、人からシステムにデータを受け渡す「入力」は非常に重要な要素です。消費者向けECサイトでも、在庫や販売などの管理を行う基幹システムでも、情報共有のためのグループウェアでも「入力」は存在し、その良し悪しがデータ精度や業務の生産性、ひいては企業業績にまで影響を及ぼすことがあるからです。

17年間に渡り「入力」を支援するコンポーネント『InputMan』を提供し続けてきたグレープシティでは、Silverlight/WPFという新しい技術に合わせたInputManを開発するにあたり、より良い「入力」とはどういうものなのかを見つめ直し仕様を設計しました。この記事では、エバンジェリストの八巻雄哉がInputMan for Silverlight/WPFの仕様設計に携わった小野晃範(おの あきのり)と津留季子(つる としこ)の二人の開発者に、設計コンセプトなどのインタビューを行いました。

技術者の紹介

小野 晃範(おの あきのり) グレープシティツール事業部
写真「小野 晃範」

理系大学を卒業し木材会社に就職。その後、心機一転するためアメリカに渡る。帰国してからは、IT企業で米国向けストレージ管理ソフトの開発に従事。2006年グレープシティに入社。InputMan for Silverlightの仕様設計に携わる。


津留 季子(つる としこ) グレープシティツール事業部
写真「津留 季子」

大学でプログラミングを習得。外資系ベンダでJava開発ツールのテクニカルセールスに従事。結婚を機に仙台に居を移し、グレープシティに入社。ASP.NET製品のプロダクトマネージャを経た後、InputMan for Silverlightの仕様設計に参加。

インタビュアーの紹介

八巻 雄哉(やまき ゆうや) テクニカルエバンジェリスト
写真「八巻 雄哉」

小学生の時に買い与えられたMSXでプログラミングに入門するものの三角関数であえなく挫折。その後、忘れた頃に授業で経験するなどプログラミングとは付かず離れずの関係のまま、国内のSIerに入社。2003年よりグレープシティに入社し、プログラミングよりも自分に向いているものに気づかされる。現在はエバンジェリストとしてWPF/SilverlightとPowerTools製品を啓蒙中。


Silverlight版研究開始からリリースまで4年

八巻 : 本日はInputMan for Silverlightのコンポーネント設計に携わったお二人に、「入力」の概念などについても掘り下げてお話を聞いてみたいと思っていますので、よろしくお願いします。さて、InputMan for Silverlightのリリースは今年(2010年)の12月10日ですね。

小野 : そうですね。WPF/Silverlightの調査に着手してから4年とずいぶん長くかかりました。XAMLという新しい技術に対して、市場がどう動くか様子を見るというのもありましたが、Silverlightの進化のスピードが想像以上に速く、WPFとの共通化を検討したことなどが影響しました。

八巻 : そもそもSilverlight 1.0はJavaScriptで制御しなければならなかったので、.NET開発者には手を出しづらい状況でしたね。実際、業務アプリケーションとして導入を検討できるようになったのはSilverlight 2からですよね。

津留 : はい。でもグレープシティが提供してきた『InputMan』品質の入力支援機能をSilverlightで実現するには、2では大きな問題があったんです。

八巻 : 問題というのは、IME関係ですか?

小野 : 日本語の入力では、読みを入力したあと適切な漢字に変換して入力文字を確定するというステップが入ります。プラットフォーム側にこの確定のタイミングを知る手段が用意されていないと、InputManでは標準機能となっている文字種の限定などの制御が行えないんです。

写真「インタビュー風景(1)」

八巻 : そういえば、当時この機能について米国MicrosoftのSilverlight開発チームに直接問い合わせたことがありましたね。

小野 : はい。あのころは八巻さんにだいぶお世話になりました。結局Silverlight 3では実現されず、4になってようやく実装されたんです。当たり前の話ですが、英語圏の人はIME(Input Method Editor)を使用しませんから、どうしてもプラットフォームに実装する機能としては優先度が低くなってしまうのかもしれませんね。

八巻 : それはそうでしょうね。4が発表されたのは、2009年のPDC(Professional Developers Conference:開発者を対象としてMicrosoft社が開催しているカンファレンス)でした。

津留 : そのころには、SilverlightとWPFでコードを共有できるといった互換性にも注目が集まっていて。だったらInputManもSilverlight版とWPF版で同じコードベースで開発しようということになりました。

八巻 : なるほど。WPFで開発したアプリケーションをSilverlightに移植したり、実装したコードの一部を両方のプラットフォームで使いまわしたりできれば、生産性やコスト削減、保守性につながる要素がありますね。とまあ、こういった経緯を経て現在のInputMan for Silverlight/WPFが生まれたと。

津留 : 長い道のりでしたね(笑)

「入力」インタフェースの役割とは

八巻 : InputManはActiveX、Windowsフォーム、ASP.NET、Java EE、それにSilverlight、WPFとさまざまなプラットフォーム向けに一貫した入力支援機能を提供していますよね。日本語環境のシステムを開発するうえで、どのプラットフォームでも求められる普遍的な入力の機能とはどのようなものだとお考えですか?

小野 : そうですねぇ、どのプラットフォームでも入力は人が行うものですから、速さと正確さの両方を支援してあげることが重要だと思っています。そのために必要な機能が操作性とデータ検証ですね。少ないキー入力で目的が達成できるような高い操作性は速さと正確さの両方につながりますし、データ検証機能は取り扱うデータの整合性を保つことができます。

八巻 : 具体的にどのような入力インタフェースを実装するとよいのでしょうか?

小野 : まず、データ検証についてですがこれには「制御」と「通知」の2種類の方法があると思っています。

八巻 : 検証のタイミングで言えば、事前検証と事後検証に分けることができますね。

小野 : はい、そうです。まず事後検証というのは、テキストボックスなどのコントロールに値が入力された後のタイミング(フォーカス遷移時や確定処理実行時など)で入力値と条件を照合し、その結果を基に入力者にメッセージやアイコンで通知する検証方法です。これは、InputManのような専用コントロールを使わなくても比較的簡単に実装できます。
一方、事前検証はコントロールに文字が入力された(IME入力の場合、確定された)タイミングで入力値と条件を照合し、コントロール内に保持したくない値については入力そのものを取り消したり、有効な値に変換したりします。さらに、保持できる値の場合はコントロール内に格納し、次の文字入力を待つというように状況に応じて入力を制御する方法です。

津留 : 入力制御はユーザーにとっては手戻りが少ないですし、データ精度という観点から見ても、無効な値は入力させないというロジックの方が優れています。

八巻 : でも、開発者にしてみると入力制御を実装するのはかなりの負担になりますよね?

津留 : そうなんです。入力制御は入力の方法がキーボード、マウス、クリップボードなど複数ありますし、1つ値が入力されるたびに設定値と照合して、値を取り消すのか、文字種を変換するのか、次の入力を待つのかなど広範な処理を組み込まなければなりません。なので、これこそが「入力コンポーネント」に求められている機能の本質といえますね。事後検証は入力し終わった値を確認するだけなので比較的かんたんなのですが。

八巻 : Silverlight/WPF版のInputManの仕様策定では入力制御のほうに重点が置かれたということでしょうか?

津留 : はい。Silverlight/WPFは新しい技術ならではのたくさんの特長がありますが、入力インタフェースとは何か、入力コンポーネントに求められる機能は何か?という原点に立ち返えるところから仕様策定を始めた結果、入力制御の重要性を改めて認識しました。ActiveX、Java、Windowsフォーム、ASP.NET、Silverlight、WPFとプラットフォームが違っても「InputManの入力制御」を提供しようと。

写真「インタビュー風景(2)」

小野 : InputManでは入力させたい文字種を制限するときに使うキーワードはどのプラットフォームでも基本的に同じです。ひらがなだけで入力させたいなら「J」、全角カタカナだけで入力させたいなら「K(全角)」と、文字種を指定するプロパティに設定します。キーワードはほかにも全角/半角や数字、記号、サロゲートペアなどいろいろあって、文字種の多い日本語での入力に柔軟に対応できるようになっています。

津留 : それから、入力制御は厳しく設定しすぎるとかえって操作性が悪くなりますので、インテリジェンスも求められます。たとえば、半角数値以外の入力を受け付けないという設定よりも、全角数値で入力されたとしても半角に変換してあげるほうがユーザービリティとしては優秀ですよね。InputManではこういった柔軟性を提供することも目指していますので、これをSilverlight/WPF版にも取り入れています。

八巻 : 事後検証の機能については、どうなんですか?

小野 : 事後検証についてはプラットフォーム側で複数の方法が提供されていることもあり、今回のバージョンでは通知機能に絞りました。

新技術を取り入れることについて

八巻 : プラットフォームが違っても入力に求められる部分は同じという考え方はよくわかりました。では、Silverlight/WPFという新しい技術ならではの部分についてはどのようにコンポーネントに取り入れたのでしょうか?

小野 : XAMLの特長でもあるデザインのカスタマイズ性をどう取り入れるかは、ずいぶん議論しましたよ。たとえば、Silverlight/WPFでは、コントロールの外観はすべてXAMLで記述されたテンプレートで定義されています。このテンプレートは非常に柔軟にカスタマイズできます。たとえば、ボタンの外形を手書きした線のようなグニャグニャにすることも簡単です。でも、その反面、罫線の色を変えるだけの変更であってもテンプレートを編集しなければならない。従来コンポーネントはカスタマイズできる部分は少ないですが、変更はプロパティで簡単にできますから、その落としどころに苦労しました。

八巻 : どのような方法を取られたのか、ちょっと具体的なところを教えてください。

写真「インタビュー風景(3)」

津留 : そうですね。カレンダーの祝日設定は悩みました。テンプレートの概念を導入すると休日の外観をかなり自由に変更できるんですが、業務アプリケーションでどこまでカスタマイズの自由度が要求されるんだろう、むしろ、変更頻度の高い文字の色の設定を簡単に行えるほうが良いのではないかとか。

小野 : あの時はなんか、いっぱい悩みましたよね。業務アプリケーションのデザイン要素ってどこまで踏み込んだらいいのか…。

津留 : そうなんですよ。本当に難しい。でも、最終的にStyleSelectorという仕組みを導入しました。スタイルと、そのスタイルが設定される条件をセットで設定する手法です。これまでのInputManシリーズにはない仕組みですが、WPFやSilverlightでは便利に使っていただけると思います。

八巻 : 設定の簡便さを残しつつ、デザインのカスタマイズ性も提供したということですね。本日は、いろいろなお話をありがとうございました。

インタビューを振り返って

最近、日本国内で独自の進化を遂げた製品のことを「ガラパゴス」と呼びますが、業務アプリのUIは昔からガラパゴス化していると言えるかもしれません。そう言えるほど日本の業務アプリのUIは日本独自の仕様と機能を満載し、優れたエクスペリエンスを提供しています。その中でも“入力”はそのような要素が特段顕著な領域です。開発者は汎用UIにガラパゴスを実装することに多くの工数を割いています。「Galapagos」 GrapeCity InputMan for Silverlight 1.0Jにぜひご期待ください。


InputMan for Silverlight 1.0Jについて

今回取材した開発者が仕様策定に携わった入力支援コンポーネント。2010年12月10日発売。これまでのInputManの入力制御をSilverlight 4で実現できます。
画像「InputMan for Silverlight 1.0J」

製品の詳細はこちら

撮影協力 GrapeCity ワインスタジオス

ワインスタジオスは、杜の都仙台の豊かな自然を生かした屋外施設と最先端の撮影技術でトータルな映像クリエイティブを提供する東北最大級のスタジオです。
写真「GrapeCity ワインスタジオス」

GrapeCity ワインスタジオス