このページの本文へ

前へ 1 2 次へ

Windows 7対応の裏側に見た国内ISVの秘めた実力 第7回

エス・エス・ジェイ「SuperStream-NX」

日本生まれの会計ソフトがSilverlightでUXを手にした理由

2010年02月12日 09時00分更新

文● 塩田紳二

  • この記事をはてなブックマークに追加
  • 本文印刷

前例のないSilverlightの業務アプリ
開発に四苦八苦

―― 開発で苦労したところはどこですか?

尾花氏

尾花 一番苦労したのは、従来Silverlightがこうした業務用のアプリケーションで使われた事例がなく、参考になるものがほとんどなかったことでしょうか。1つでも事例があれば、それを参考に方向性を掴むこともできるのですが、われわれが開発を始めたときにはそういうものがありませんでした。当然Silverlight側にも、こうした業務向けの機能やフレームワークが用意されているわけではありません。

 そこで、われわれ自身で業務用アプリのフレームワークを作ることにしました。カレンダーやグリッド(表組み)、リスト表示などを自分たちで作り、それを部品として利用しました。

 もうひとつは、アプリケーションの基本構造というか、業務用途のフレームワークが必要でした。こうした業務用アプリでは、たとえば特定の画面でユーザーがクリックやボタンを押したといったときに、決まった画面への移動や、指定された処理が動きます。例外もありますが、同じ操作をしたら同じ動きを見せないとユーザーが混乱してしまいます。

 ところがSilverlightの場合、さまざまなアプリケーションに対応した汎用システムなので、そのあたりがまったく自由になっている。なので、同じ動きであっても逐一記述しておく必要がありました。

 そこで我々は、こうした一連の操作の流れをパターンとして定義し、それをフレームワークに作り込むことで、業務用アプリの「骨格」を作りました。この部分にかなりの時間を要しました。

 こうした大規模な業務アプリはチームで開発するため、プログラムにはある程度可読性が必要で、同じことをプログラマーがそれぞれのやり方でコーディングしていたのでは、他人が直すこともできなません。そういう意味では、Silverlightにおける開発標準が提供されるといいのですが。

―― つまり構造としては、サーバーから必要な情報を受け取って、それをクライアント側のWebアプリ=Silverlightである程度加工して表示する、というわけですか?

尾花 ええ、最初にデータと項目のリスト、個人設定情報などを受け取ってSilverlightで表示を行ないます。たとえば、グラフの拡大表示などは、サーバーに依存せず、Silverlight側のみで行なえます。

―― そもそも、クライアント側をWebアプリにしたのは、どういう判断からでしょうか?

尾花 従来、ERP(企業資産計画)や基幹業務パッケージはサーバー・クライアント型が標準でしたが、今はWebアプリケーションが主流になりつつあります。理由のひとつには、クライアント・サーバーでは、クライアントにソフトを配布してインストールするという作業が必須で、ほかの業務アプリとの関係で問題が出るケースもあり、それを防ぐにはクライアントマシンをきちんと管理しなければなりません。

 その点、Webアプリケーションであればクライアントマシンの状態をさほど気にする必要がなく、ソフトの配布やインストールの手間もありません。Silverlight(のランタイム)は、インターネット経由ですぐにダウンロードできます。これなら管理者はサーバー側のメンテナンスだけです。これは集中管理できるし、現場に点在するクライアントの管理が省ければ運用コストも低く抑えられます。

 さらにもうひとつ、セキュリティーの観点からいうと、サーバー側の情報をファイルで保存してクライアント側で運用するわけではないので、情報漏洩などの対策にもなります。とはいえ、こうしたソフトを使うユーザーの中には、データをExcelで分析する仕事も少なくないので、CSV形式でのダウンロード機能などは持っています。基本的には、データをクライアントに保存して動作することのない仕様にはなっています。

 WebアプリとしてSilverlightを使った最大のメリットは、サーバー側が単純になったことが挙げられます。クライアント側でさまざまな画面を作ることができ、サーバー側の処理と表示画面の生成が分離された結果、サーバーはクライアント側からの細かい要求に対応するさまざまなモジュールの集合体のようになりました。

経理担当者向け画面

SuperStream-NXの経理担当者向け画面。入力担当者によっては、上から順番に入力するのではなく、先に科目や商品を書き込むケースもあるとか

経営者向けの損益計算書

同じく経営者向けの「損益計算書」を表示したところ。同じソフトでも入力・閲覧担当者によって利用目的は大きく異なり、求められる画面も変わってくる

―― 画面デザインは外部に委託したのですか?

尾花 そうです。デザインを外部に発注するのは初めてだったのですが、まさに“未知との遭遇”という感じでした。Silverlightに業務用アプリの開発実績がなかったということは、Silverlightに対応できるデザイナーにも、業務用アプリの開発経験がなかったということです。ゲームアプリケーションなどの開発実績はあったのですが、業務用アプリの開発は初めてで、考え方の違いが大きいことに気がつきました。

 SuperStreamのような業務用アプリは、1つの画面を設計したら、これを10年間メンテナンスしていかねばなりません。その間に改良されることもあるでしょうし、不具合を修正する可能性もあります。しかし、Webのゲームアプリケーションなどは、そのような長期メンテナンスを前提には作られておらず、デザイナーも作ったものを10年間メンテナンスするとは思いもよらなかったようです。そのため最初のソースは、作った本人にしか理解できないものになっていました。われわれは、誰が見ても分かるようなソースコードでないと、メンテナンスができません。そういう部分をお互いに理解し合うのに、かなりの時間が必要でした。

 もうひとつは、Silverlightが提供するのは、静的な画面ではなく動きのあるもので、まさに“ユーザー経験”(UX)と言うべきものです。ところがこれは、紙に書くことができないのです。そのため、デザイナーとコミュニケーションをとること自体が大変な作業でした。

 例えば伝票の入力時に、会計などのルールである項目が入力されると、他の項目の選択肢が限定されるというケースがあります。こうしたルールは、会計についての知識が必要ですが、すべてのデザイナーが会計の知識を持っているわけでもありません。

 また、デザインを依頼する側としても、ユーザーがどこから入力を始めるのか予測ができないので、ルールを言葉で説明するには、すべての場合を列挙しなければならなくなります。かといって、デザインとロジックが分離できるのに、ロジックを開発する側がコードを書いて表現するというわけにもいきません。

 結局、我々の場合は、話し合いを重ねることでしか解決はできませんでした。これは、個々の製品がうんぬんというのではなく、業界全体の課題として、業務用アプリなどを分業で開発するときに、ユーザーエクスペリエンスをどのように表現して、デザイナーと開発者がコミュニケーションするのかという方法論の確立が、今後は必要になると感じています。

―― なるほど。開発現場ならではの意見ですね。本日はありがとうございました。


前へ 1 2 次へ

カテゴリートップへ

この連載の記事

アスキー・ビジネスセレクション

ASCII.jp ビジネスヘッドライン

ピックアップ