異分野と異文化

秋分の日も過ぎて朝晩は肌寒く感じることも多くなりました。 皆さま、風邪などひかれてはいらっしゃらないでしょうか。 さて、ここ最近は、皆さまへ、より良いサービスや開発体験への理解を深めようと思い、そういった系統の資料を入手して読んだり、社内のチームから話を聞いたりといったことをしています。もちろん、これまで様々なお客さまからお聞かせいただいた、ご要望やご苦労といったものを、どのように体系化して、さらに製品を改善していくのかという日頃の活動の一環なのですが、私どもの場合は国際化の観点から、文化や言葉の違いを乗り越えて情報や目的を共有する必要性があります。 そういったなかで、偶然の成り行きだったのですが、昨年、弊社でユーザビリティの調査をしているSteven Clarkと会う機会がありました。Stevenは、元々はレドモンドのCLRチームに在籍し、基本クラス ライブラリのAPIのユーザビリティを指導していたのですが、いまは開発者や開発ツール全般の使用体験を考慮するチームのメンバーとなり英国のケンブリッジに在住しています。すでにいくつかの社内の成果をDr. Dobb’sやACMの学会誌などに発表している、その道の人ですので、私は入門者に近い形でOffice Communicator使っていろいろとアドバイスを受けています。先日、帳票に対する要件のような、いわゆる「日本での特殊事情」と考えられていることを話すと、意外にも共感してくれ、どのように調査をしていけば上手く説明できる可能性があるかといったガイダンスをくれたりします。国際化の範疇に括られていては上手く解決や説明ができなかった問題に対して、少し別な方向性が見えてきたりするので面白いものです。 彼に会うまでは、ユーザビリティやユーザー エクスペリエンスというと、なにかビジュアルなUIのことであったり、画面のデザインであったりといった固定観念が私にはありましたが、彼のリサーチの成果は、認知心理学や認知工学の要素をAPI設計に応用して評価するといったアプローチです。当人はコンピューター科学の博士号を持っていますが、自分自身でもこのキャリアは意外だったと私に話します。「日本やアジアの文化や、そこでのソフトウェア開発は私にはまったく分からないけれど」と話すなかで、こういった別な分野での応用や情報の共有が面白い成果を生み出すのかもしれません。

5

Microsoft Visual Studio International Pack 1.0 製品版リリース!!

Microsoft Visual Studio International Pack 1.0 製品版を本日正式にリリースしました。 Microsoft Visual Studio International Pack 1.0 はVisual Studio や.NET Framework の標準機能だけでは不十分だった、カナ文字の変換や「よみがな」への対応など、日本語の処理や日本文化に即した機能に対応した新しい製品です。 Microsoft Visual Studio International Pack は、Visual Studio のすべてのエディションのユーザーが無償にてダウンロードセンターからダウンロードして利用することができます。また、コンポーネント毎にセットアップが用意されているため、必要なコンポーントのみインストールすることができます。ぜひ一度お試しください。 日本向けには、以下の4つのコンポーネントが提供されています。 East Asia Numeric Formatting Library数値データを日本語、繁体字中国語、簡体字中国語および韓国語における漢数字の文字列に変換します。  Japanese Kana Conversion Libraryひらがな、カタカナ、半角カタカナの相互変換、およびローマ字からかなへのの変換をするためのライブラリです。 ベータ版からの変更点:変換が正常に行われていていない文字を修正しました。 Japanese Text Alignment Library決められた範囲に文字間の空白が均等になるように文字を割りつけて描画するためのライブラリです。ディスプレイ、プリンタの両方に使用することができます。 ベータ版からの変更点:ベータ版では既定の動作が、英文字の間には空白を置かないようになっていましたが、製品版では、すべての文字の間の空白を均等にするようになりました。割り付け単位が1つの際に中央に表示されない問題を修正しました。環境によってインストールが失敗する問題を修正しました。 Japanese Yomi Auto-Completion Library入力された読みに一致する候補を表示するオートコンプリート機能を実現するためのライブラリです。この機能を使用することで、まず読みを入力してから漢字に変換する日本語IME の入力プロセスと、途中までの入力に応じて入力候補を表示するオートコンプリート機能の相性の悪さを解消し、日本語の入寮効率を高めることができます。ベータ版からの変更点:環境によってインストールが失敗する問題を修正しました。 上記の4つのコンポーネントに加え、中国、韓国、台湾向けの3つのコンポーネントあわせて提供しています。   Korean Auto Complete TextBox Control韓国語入力に対応したオートコンプリート機能を持つTextBox コントロールを提供します。 …

2

開発者共通の悩み?Yomi-Autocompletion の動作に関して

皆様、もう Microsoft Visual Studio International Pack ベータ1 はご覧になりましたでしょうか? けっして、規模の大きなものではありませんが、もし、まだという方がいらしhたら是非一度ドキュメントだけでも目を通していただけると幸いです。専用フォーラム(http://forums.microsoft.com/MSDN-JA/ShowForum.aspx?ForumID=1989&SiteID=7)では、現在提供しているコンポーネントに関するフィードバックはもちろん、「こんなものが欲しい」というご意見も是非お伺いたいと思っています。さて、今回は、その Microsoft Visual Studio International Pack より、Japanese Yomi-Autocompletion Library を簡単に紹介させていただきだいと思います。 このライブラリは、一言でいえば、読みに対応した自動補完機能をコントロールに追加するための拡張ライブラリです。読みに対応した自動補完とは、そのままですが、IMEによる入力時に、変換前の読みを入力した段階で、入力された読みに対応する候補を表示するという機能です。たとえば、都道府県名の一覧が候補になっている場合には、「お」と入力すると、「大阪」「大分」「沖縄」など「お」から始まる名前が候補として表示されます。 説明するまでもありませんが、日本語を入力する場合には直接文字を入力するかわりに、「読み」を入力した後変換することが必要になります。さらに、入力が長ければ長いほど文脈に適した変換候補を提供する日本語IMEの特性も加わり、日本語システムに関しては自動補完やインクリメンタルサーチが期待したように動作しないのが現状です。これを解決するために、「読み」への対応をご自分で実装されている方もいらっしゃると思います。より良いユーザーインターフェースの探究も皆様、開発者の方の工夫の部分ではあると思いますが、一方で、基本的な機能の作りこみに時間をとられたくないというご意見もあると思います。そこで、このライブラリでは、基本的な動作を実現するためのライブラリを提供しています。 Japanese Yomi-Autocompletion ライブラリでは、自動補完機能を持つ複数のコントロールを提供する代わりに、既存のコントロールに自動補完を追加するために必要な機能をライブラリという形で提供しています。ライブラリは、2つの中心的なクラスとデータ型や状態を表す列挙型などの周辺のクラスより構成されています。はじめに、一番中心になるのが、YomiAutoCompletionContextManager クラスで、候補の一覧や自動補完機能の状態など、ほとんどすべての情報がこのクラスによって一括管理されています。次に、機能をコントロールに組み込む際にコンテキストマネージャとコントロールの橋渡しをするのが YomiAutoCompletionListener です。 詳細はドキュメントを見ていただく方が良いと思いますので、紹介はこれくらいにしておきましょう。 さて、実はこのライブラリを設計するにあたって、いくつかの問題がありました。特に大きな問題は、どのように読み仮名を提供するかということです。都道府県名のように読みが決まっているものや、ユーザー登録の名前のように登録時に「ふりがな」があらかじめ提供されている場合には、話は簡単です。しかし、自動補完機能を付加したい項目に必ずしも読みが与えられているとは限りませんし、読みがない項目への対応も考慮しないといけません。特定のアプリケーション向けに設計するのであれば、活用できる読みのデータがどこにあるのかが分かっていますし、「読みがなデータのある項目さえ表示されれば良い」というようにアプリケーションのシナリオに沿ってルールを決めれば解決できる場合も多くあると思います。しかし、これを汎用にするとなると、いろいろな方法や考えがあります。例えば、すべての項目は事前に読みが与えれられていることを前提にすると、割り切ってしまうのもの一つの方法だと思いますが、それだと使用できる場面がかなり限定されてしまうなど、バランスが難しい。この点を決めるまで(決意するまで?)にはずいぶんと悩みました。 結局、このライブラリでは、インターフェースが多少複雑になるのを覚悟して、以下のような、どちらかというと柔軟を重視したアプローチをとってみました。 1) 読みが分かっているものに関しては、項目の追加の際にアプリケーションが読みを提供する。2) 読みが与えられていない項目に関しては、自動的に読みが与えられるようにする。3) 自動の場合には、IYomiProvider インターフェースを介して、読みを取得するようにし、開発者がIYomiProvider の独自実装を提供することで、読み仮名のソースを自由に選択できるようにする。4) IYomiProvider の一実装として、IMEの辞書から読み仮名を取得するクラスを提供する。5) IME の辞書が対応する読みがなを複数持っている場合には、先頭の候補のみを使用する。6) 入力補完はベストエフォートする。つまり、入力された読みが項目に与えられた読みと違う場合には、候補として表示されない。7) ユーザーが入力した読みが項目に関連付けられた読みと一致せず、候補がでない場合を考慮し、変換後の文字列に対しては、通常の自動補完のように動作するようにする。 最後の3点は、ちょっとわかりづらいと思いますので、例をあげると、たとえば、「大和~~~」という名前の会社があったとします(現存する会社名とは一切関係ありません)。これだけでは「だいわ」と読むのか「やまと」と読むのか分かりません。この場合には、残念ながらIME から取得した読み仮名が正しいとは限りません。仮にIMEから取得した読みがなが「だいわ」の場合、ユーザーが「や」と入力してもヒットしません。したがって、ベストエフォートということになります。辛いところですが、ここは諦めるしかありませんでした。ひとつの項目に複数の読み仮名を関連づけることも検討はしましたが、5~6個の読みの候補が示されるものはざらで、もっと多くの読みをもつ単語も非常に多いうえ、それでさえ必ずしも完全に網羅しているとはいえません。結局、パフォーマンスの観点から見送りました。話は戻りますが、上の例のような場合に、読みがな自動補完だけですと、ユーザーは結局会社名をすべて入力する必要があり非常に不便です。そのため、ライブラリでは、「やまと」と入力して変換しても「大和」に変換された際には、読み仮名ではなく(7)のように項目自体の文字列にヒットするようにしました。 柔軟で拡張性に富んだものを作ろうとすると複雑で分かりづらいものになってしまうし、反対に、簡単で分かりやすいものにした場合、一歩間違えると、かゆいところに手の届かないものになってしまいます。「7割から8割の人のニーズを満たすようにして、あとは思い切って諦める。諦めるとはいいつつ、技術力のある人なら実現不可能というわけではなく、情報も提供されている。」というあたりが良いのはないかな、という漠然とした想像はできなくはないのですが、どこまでが7割の人にニーズを満たすかということは分からないというわけです。特別なことではなく、設計過程では常に悩みのたねとなる部分ですが。やはり今回も悩みに悩んでしまいました。公式で答えの出るようなものではないですね。データ解析で線引きできれば理想ですが、十分なバイアスされていないデータを集めるというのも一朝一夕にできることではありません。結局のところ、皆様、お客様のニーズに対して、地道に、そしてもっともっと勉強する以外に答えに近づく方法はないのでしょう。 というわけで、フィードバックお待ちしております。      

0

KanaConverterの使い方

前回は、KanaConverterと、その基盤になっているTransliteralConverterの作成のいきさつに関して紹介をさせていただきました。抽象的な話でしたので、難しく感られた方も多いのではないかと思いますが、実際の機能は、手間を省いていただくことが目的ですので、簡単に使っていただけるようになっています。しかし、なにぶんbetaでもありますから行き届かないところがあるのではないかと思いますので、今回は具体的に使い方を書いてみようと思います。 作業をはじめる前に、Visual Studio International Pack Beta 1 (vsipk1betaというZipファイルになっています)をダウンロード後に展開し、JPNKanaConv というインストーラ パッケージのインストールを行ってください。実行の結果はUnicode固有の文字を含みますので、コンソール アプリケーションでは、上手く扱うことができません。今回はUTF-8が既定値であるWeb のプロジェクトを使います。Windowsフォームを使っていただいてもかまいません。今回は、Visual Basic言語を使います。 JpnKanaConvHelper.dllへの参照をソリューション エクスプローラから追加してください。このDLLはインストール先のフォルダにありますが、私の場合は既定のフォルダにインストールしていますので、Program Files以下の “Microsoft Visual Studio International Pack(Beta)\Japanese Kana Conversion Library” というところにあります。JpnKanConvHelperが依存しているJpnKanaConversion.dllや日本語用のリソース、IntelliSense用のXMLファイルなどもbinフォルダにコピーされます。 簡単にレイアウトのために2X3のテーブルをひとつ作成したあと、Labelを3つ置き、以下のImport文を vb側のコードに書きます。 Imports Microsoft.International.ConvertersImports Microsoft.VisualBasic ハンドラを追加したあと、コードは下のようになるものを書いてください。Label などは適当ですが、フォームに添ったものにします。 ひらがなをカタカナに変換するものですが、Charの型にある、ConvertFromUtf32を使っていくつかの文字をStringに変換しています。 13行目にある&H309B は独立の濁点である、 KATAKANA-HIRAGANA VOICED SOUND MARK、&H3099は複合のために濁点である COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK です。また、15行目のStrConv関数に渡されている &H411 は日本のロケールIDを表す 1041 の16進数です。ひらがなをカタカナに変換するコードの比較です。   上はIE7を使った表示です。   今回は、Visual Basicを使って、簡単にVisual Studio…

0

Visual Studio 2008 Team Foundation Server 用言語変更パッケージに関するアンケートについてのおしらせ

Visual Studio 2008 Team Foundation Server に対応した言語変更パッケージに関する記事が弊社 Brian Harry のブログ (英語) に記載されています。 このツールは既存の英語版Visual Studio Team Foundation Server を日本語を含む各言語に対応したエディションに変更するための追加パッケージで、MSDN Download Center で現在 Visual Studio 2005 Team Foundation Server 対応のもの(http://go.microsoft.com/fwlink/?LinkId=70500) が公開されております。以下は Brian Harry の記事の前半部分のご紹介です。 TFS 2005 を出荷した後、私たちはお客様のお使いの TFS サーバを英語版から他の言語エディションに変更するための補助ツールセットをリリースいたしました。このツールセットは、お客様ご自身が手動で行わないといけない手順に対する解説とそれを補助するためのツールで構成されています。正確な数字は今思い出せませんが、かなり多く、おそらく2000名程度のお客様にこのツールセットをご利用いただいております。TFS 2005 は最初の TFS のリリースであったこともあり、英語版のベータしか提供されていない時期がありました。このツールはその時期から英語版をお使いになっていたお客様がローカライズされた製品版のリリース後に、お使いになりたい言語エディションに移行するのをお手伝いするために作成されました。 現状私たちは、このツールは TFS 2008 にはもしかしたら必要ないのではないかと考えています。前回の状況とは異なり、お客様は TFS 2008 の英語版のリリース後、ローカライズ版がリリースされるまでの間、あえて英語版に移行しないでも既存のローカライズ版 TFS 2005 を使い続けていただくことができると思われるからです。この仮定は正しくないかもしれません。私たちは実際に TFS 2008 対応の言語変更パッケージの開発に着手する前にお客様からのリクエストがあるのかどうかの調査を始めました。また、同時にどの位のお客様がこのツールを必要としているかを理解するためのアンケートを行っています。 アンケートにご協力いただける場合には、Brian…

1

Visual Studio International Pack 1.0 ベータ1のリリース

11月30日にVisual Studio International Pack 1.0 ベータ1をリリースしました。   Visual Studio のリリースは数年に1回です。これでは、フィードバックに素早く対応できないので、ご存知のように、Visual Studio のリリースの間にも、様々な技術がリリースされています。私たちは、このような流れの中で、日本の開発者の皆様に向けても、長く待たせることなく日本の慣習や日本語の処理に係る機能を提供したいと考えました。これに加え、いままでVisual Studio や .NET Framework では、各国固有の部分に対しては、かゆいところに手の届くようなサービスを提供できていなかったという反省も踏まえて、これらを同時に解決してしまおうという、ちょっと欲張りな気持ちで企画したのが International Pack です。もちろん、Visual Studio や.NET Framework本体に組み込まないと意味のない機能も多いのですが、それは仕方がないものとして、International Pack では、独立したライブラリとして提供可能なもののうち、要望の多いもの、日本固有の機能という条件で絞り込んだ結果、以下の4つの機能を.NET Framework 用の拡張ライブラリとして提供することにしました。 かな相互変換ライブラリ 日本語均等割り付け よみがな認識自動補完 漢数字変換ライブラリ 詳しくは、Visual Studio International Pack ベータ1は、ダウンロードサイトを見てください。大きなものではないので、ダウンロードにさほど時間は掛りません。ぜひダウンロードして試してみていただけると嬉しく思います。 ベータ版のリリースに合わせて、MSDNフォーラム上にVisual Studio International Pack 専用のフォーラムを開設いたしました。早い対応が一つの目的ですから、ベータ版に対するフィードバックも可能な限り積極的に製品版に反映していきたいと思いますので、ささいなことでも、どんどんフィードバックをお寄せください。 また、専用フォーラムはベータ専用のフォーラムというわけではありません。今回リリースしたベータ版のバグの報告、ご要望等はもちろん、将来に期待する機能に関してのご意見もお待ちしております。

3

String.Normalizeとカタカナの複合文字

.NET Frameworkの2.0からですがStringクラスにNormalize というメソッドが付いたことをご存知の方も多いかと思います。Unicodeの文字列を正規化するものですが、日本語にも若干影響があるので、確認の意味を含めてカタカナでの半濁点の動作を検証してみようと思います。コードは簡単に以下のようなものだとお考えください。string[] sa = { “ポ”, “ホ゜”, “ホ\u309a”, “ポ”, “\u333d” }; foreach(string source in sa) { string normalized = source.Normalize(); Console.Write(“{0}\t”, normalized); foreach(ch in normalized) { Console.Write(“U+{0:x4} “, Convert.ToUInt16(ch)); } Console.WriteLine(); } いろいろと問題はあるかと思いますが、とりあえず、簡略するために仮想的に上のようなコードだとお考えいただくことにします。 ここで、一般的な表記として、カタカナにはいわゆる全角と半角があるのは、ご理解いただけると思いますが、ほかにも複合文字用の半濁点(U+309A: COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK) や独立した半濁点(U+309C: KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK)などを組み合わせると上記のような配列で良いかと思います。引数をもたないNormalize() メソッドはFormCという正規化を行い以下のような出力が得られます。 ポ U+30dd ホ゜ U+30db U+309c ポ U+30dd ポ U+ff8e U+ff9f…

0

Silverlight 1.1の基本クラス ライブラリにおける非ジェネリック系のCollectionについて

Alpha版で調査をなされていらっしゃるお客さまも多いのではと思いますが、Silverlightのランタイムにおいて非ジェネリック系のコレクション クラスを取り除く予定でございます。また、ジェネリックのコレクション クラスでもList を使っての追加実装が可能な、Queue, Stack, LinkedListも取り除くことになります。ジェネリック コレクション クラスと非ジェネリック コレクション クラスのマップはMSDN ライブラリにございますが、非ジェネリック系のコレクションでビジネス ロジックなどを組み上げられてしまわれSilverlightとの共有をなされるご予定であられた方にはご迷惑をおかけすることになると思います。この変更は、サイズの制限、ジェネリックによるコードの読みやすさ、ボックス化のない高パフォーマンスでタイプ セーフなライブラリといった点を考慮し、機能的な相似性などを考えた結果でございます。しかし、このあたりのことを考えるにあたっては、日本語になっている情報や、お客さまの違いからくる日本のシナリオにおいて上手くいくかどうかということが気になりました。非ジェネリック固有の機能をロジックの判定にお使いになられている場合、まだ、ジェネリックまで手がまわらない方々の場合、また、コレクションのクラス ライブラリの使用や拡張をするまでにいたっていらっしゃらない場合など、クラスの独自実装はやはり困難になるかと思います。書店やWebを見ても、このあたりのガイダンスをする情報がなかなか日本語では見当たりませんし、私どもも製品のドキュメントでは網羅しきれない部分であり悩ましいところではあります。このような懸念があることを担当のInbar Gazitにフィードバックとして返したところ、最近になっていくつかblogにて情報を公開しております。こちらの変更に加えて、Stack クラスのジェネリックを使った変換のサンプルや、ジェネリックによるコレクション クラスの動作の違いの注意点、スレッドの同期の懸念などを取り上げた内容もございます。残念ながら英語なのですが、有用なサンプル コードがいくつか紹介されておりますので、ご参考にしていただければと思います。

1

ユーザー インターフェイスを考える

2007年も始まってひと月がまもなくすぎようとしています。私もベータの頃からWindows Vista、Office 2007など試用し、正式リリース後からは製品版を使っていますが、まだ十分に操作に慣れていないせいか、「これを使うにはどうしたら・・・」といった感じです。そんな中で、お客さまのお問い合わせを検証するために、過去のOSや製品を使ったりすると、やはり隔世の感があります。 Vistaなどは、最初は、角がさらに少なくなったことや3Dの透明感の表現などビジュアルな側面に気が付かれることが多いと思いますが、操作をしていると、ふと不思議に思える点や、そこに目に見えない共通のルールやテーマのようなものが見え隠れします。コンピュータ科学やリサーチの世界だとHuman Computer Interaction (HCI) といった分野で、人間とコンピュータの対話の観点から様々な研究が行なわれていますが、弊社などは世界中のお客さまからのフィードバックなどにより、実製品として多くの方々に使われるところへ応用されていきます。使っていると「以前と違うので違和感が・・・」と最初は思うのですが、「これは何をしたいのだろう」、「これは誰に使ってもらうためのものだろう」といったことをやはり調査していくと、それなりに資料が見つかります。 2001年の秋ですのでXPの時代のものですが、Win32やCOMのユーザー インターフェイスの技術文書として “Inductive User Interface Guidelines (英語)” (日本語にすれば「誘導的ユーザー インターフェイスのガイドライン」といったところでしょうか)が出されています。技術文書といってもリサーチ向けの文書ではなく、開発者のみなさんにお読みいただくために文書として書かれているようで、その分野の用語はそれほどありません。Inductive UI (IUI) と呼ばれるこのUIとは対極に近いものが、Deductive UI(日本語にすれば「推定的 UI」といった感じでしょうか)として紹介されていますが、これは今日使われている、ダイアログ上にコントロールを貼ったものです。こちらの文書では前者のIUIは、「ソフトウェアは使いづらい」という問題を解決し、後者のDUIは、「これを提示されてもユーザーは何をして良いのかよく分からないだろう」といった論調で書かれています。    リンク先の文書は英語ですが、図も何点かあるので見ると、「ウィザードで作ること」に結論付けられる方も多いのではと思われます。しかし、最初のステップに書かれているようにユーザーの作業(task)に着目することから解析を行なう必要性があり、ウィザードのようなものは表現の手段にすぎないようです。ちょうどこの時期の前後にWebのユーザビリティでも、ある方が「ユーザー中心の考え方ではなく、ユーザーの行動に着目すべき」といったことを書かれていたと思いますが、これはそれなりに話題になっていたことを覚えています。この文書でも「WebのUIはこちらに近い」といったことが最後に書かれているので、着目する点に相似するものがあるのでしょう。 2003年の秋ですが、弊社のUser Experience GroupがAeroのガイドラインのなかで “Picking the Right Degree of Control for User Interfaces (英語)” として「日常の作業の度合い」と「ソフトウェアとユーザーのどちらが主導的に操作すべきか」を比較し、IUIとDUIの双方を肯定しています。IUIが非Web系の今日のクライアントのUIだとすると、これは辻褄が合います。よくWebの開発に携わっていらっしゃるお客さまが、「いままでWindows クライアント向けで作ったものをWebに書き換えて欲しい」という依頼で、お困りであるという話を聞きます。これは、このUIや通信が含まれる操作の特性をご理解いただけないまま、同じものをWebで再現するような要求が発生してしまったためではないかと察します。 2004年の初夏 には、”IUIs and Web-Style Navigation in Windows Forms (英語)” としてWindows フォームでIUIをどのように実現するかという内容が2つに分けられて投稿されています。これらはUIへの投資回収といった観点から始まり、実際に弊社のサンプルでおなじみのNorthwindのデータベースを実装していますが、現行のWindows フォームでの実際の動作を見るには良いでしょう。 ここから先の資料があまりないので、これ以上ご紹介することができないのですが、最近のWPFのショーケースやガイドラインなどを見ていると、IUI、DUI双方の要素を取り入れつつ、表現力豊かで創造性の高いアプリケーションが、これまでソフトウェア開発に関わっていらっしゃらなかったような方々も含めて開発なされていて、ますます楽しみです。さて、私たちも今年はWPFや ASP.NET AJAXといったユーザー インターフェイスを改良する技術や、それを開発するツールなどをみなさまのお手元にお届けさせていただく作業に携わることになります。これまでも、ソフトウェア開発にデザインという要素はございましたが、今後、ますます多様なお客さまからのご意見を取り入れて、さらにより良いものを作っていかなくてはいけないと思います。日本ではこういった機能が必要だ、こういったところに手が届くようになってくれないと、といったご意見やご要望をぜひ今年もお聞かせ下さい。

0