2003年04月04日
製品GUIバーチャルモデルの賢い使い方とは
GAIO CLUB 特集
GAIO CLUB【2003/4月号】
製品GUIバーチャルモデルの賢い利用方法とは
組み込み機器のGUI
最近の組み込み機器では、LCDパネルへの文字表示、ビットマップ表示など、当たり前になってきました。組み込み機器の操作性を考える上では、この表示デバイスを有効に利用して、ユーザーが使いやすい機器を提供することが必須となっています。
一昔前の組み込み機器の4ビット、8ビットマイコンは、周辺にぶら下がったハードウエアをコントロールするする事が主な目的で、簡単なLEDのみを表示物として搭載しているものがほとんどでした。現在では、ネットワーク接続機能など、機能そのものをソフトウエアで実装するケースが多くなり、組み込み機器の機能そのものが巨大化しています。複雑な機能を分かり易くするためには、GUIの実装が不可欠となっています。
GUIの設計は技術の仕事?
GUIをもつ機器の開発で、最初に問題となるのが誰がこの仕様を作成するかです。5年ほど前、LEDだけだった製品からLCDによる文字表示に発展した段階では、製品の表示物の設計はほとんどが技術サイドで行われていたようです。
-
表示物、文字と言っても、「Play」とか「Stop」とか、「使用中」、「●●を押して下さい」とか簡単なメッセージですから、問題なく製品に実装してきたと思います。
今では携帯電話を筆頭に、あらゆる機器に、「アイコン」なるビッマップが採用されるようになっています。この表示物は「絵」ですから、もはやエンジニアがシコシコ作成するようなものではなく、工業デザイナー側のデザインスキルを必要としています。
-
このビットマップの作成については、「お絵かき屋」であるデザイナーの仕事であることははっきりしているのですが、その機器の操作性、HMI(ヒューマン・マシン・インタフェース)の部分については、技術サイドなのかデザイナーサイドなのかはっきりしません。というより、両者にまたがる内容を含んでいます。
エンジニアはその機器のハードウエア仕様を良く知っていますから、その操作についての設計も出来ると思われがちです。操作性については、エンジニアも「一般のユーザーに優しい」とか「使いやすい」とかを考えて設計しているのでしょうけれど、そのシステムに慣れてしまっているエンジニアが設計した場合の多くは、一般ユーザの考える使いやすさとは、確実なギャップを生じさせるようです。
このような問題を克服するために、最近の会社の開発体制では、「デザイナー」の役割の中に、従来の「意匠デザイン」のみでなく、「操作性」、「GUI表示デザイン」などを含めて、総合的にHMIを担当させ、技術サイドの仕事から切り離すケースが多くなっているようです。
デザイン部署も競争の時代
大手メーカーでは、従来から、そのほとんどに「デザインセンター」なる部署が存在し、社内製品のデザインを一手に手がける体制をもっています。しかしながら、最近ではここでも分社化の流れが進み、一般のデザイン会社と同じ立場に立たされるケースもでてきました。要は、社内の仕事は必ずデザイン部に回ってくるとは限らず、特に競争の激しい携帯電話の分野では、デザイン専門の会社がその意匠デザイン、HMI設計を行う例も多くあります。
デザイナーは、社内の重要な製品のデザインを手がけるためには、同じカンパニーであるメリットを生かして、一般のデザイン会社にはできない内容を打ち出していかなければ、外部のデザイン会社に勝てないと言うわけです。
動きを伴うデザイン・使いやすさ
表示デバイスへのグラフィカルな表現は、アイコンの様なスタティックな表現から、アニメーションを多用した動きのあるダイナミックなものに変化しています。 また、「使いやすさ」についての考慮は、特に買い換え需要に集中している携帯電話では、ユーザーの満足度を上げてリピート購入をねらうことが必須事項となっており、分かり易いグラフィック、文言の整備を、通常の短い開発期間のなかで実現していかなければなりません。
ワープロでのGUI仕様の作成の問題点
一昔前の、機能が簡単であったころのGUI開発は、ソフトウエア仕様作成と一緒に扱われており、エンジニアが書く内部動作を含めた仕様書に含められて、GUI表示内容が記載されていました。その歴史から、機能が比べものにならないほど複雑になった今でも、ほとんどがワープロによる手書き書類で作成されています。
ワープロでの製品仕様作成は、デザイナーから届けられたGUIデザイン画を前に、仕様作成者が頭の中で動きを組み立てながら、順次ワープロで書き起こして行く作業です。頭の中で動きを想像しながら、操作の流れを組み立てている分けですから、よほどの天才でない限りは、必ず間違いや仕様の書き忘れなどを起こしてしまいます。また、全体の操作の整合性の確認や、間違いの確認は、仕様情報が大きくなればなるほど、工数が膨れ上がってきます。
つまりは、人間が管理しながらワープロで間違いのない完全な仕様書を作りあげることは、物理的にも不可能となっており、より効率的で確実な手法が必要となっています。
試作前に「バーチャルモデル」で仕様検討・確認
GUIの動きや、その操作性を確かめるためには、実際に動く「モノ」が必要です。現状の多くは、ソフトエンジニアが仕様通りにプログラムするのを待って、製品サンプルができあがった後に、作った仕様を確認・修正してゆくという方法が採られています。これでは、仕様に間違いがあった場合や仕様変更を行いたい場合などには、時間がかかるばかりか、大きなコストを強いることになります。
そこで、実際の製品を作る代わりに、PCの画面で動作するバーチャルな製品を作って検討しようと誰もが考えるはずです。
バーチャルモデルを作るツール
特に組み込み製品開発の分野では、GUI仕様作成に特化したツールは数える程しかありません。進んだデザイナーは、流行のWEB系のアニメーションツールやオーサリングツールを駆使して、製品そっくりのモデルを作成し、仕様検討に役立てています。実際の製品イメージ通りのモデルで、その操作を体験できるため、仕様自体の問題点が具合的な形で発見できます。
また、製品の使いやすさに関しては、紙に書かれた仕様情報をいくら睨んで見ても、その操作性を体験できなければ、その評価は絶対にできません。このように、動くシミュレーションモデルを体験することは、複雑な動きをする製品の仕様検討には、非常に有効です。
肝心の仕様情報は…
しかしながら、WEB系のツールは、時間軸に沿ったアニメーションを作るツールであり、組み込み機器の状態遷移の考え方とは異なっています。そのため、成果物として得られるものが、PCで動くシミュレーションモデルだけであり、これでは、せっかく工数をかけて作っても、仕様情報を伝えるには、このモデルを使って見る以外に方法がありません。
仕様情報を渡される側のソフトエンジニアにとっては、動くモデルだけ渡されても、全体の仕様構成の把握に時間がかかり、このシミュレーションモデルは歓迎されないかも知れません。
シミュレーションと仕様書をセットで考える
一部の組み込み製品仕様作成用ツールには、シミュレーションモデルの作成からその仕様書、果てはGUI情報のソースコード出力が可能なものまであります。
ガイオの「プロトビルダー」もその一つで、作成したバーチャルな製品モデルの状態遷移情報から、状態遷移図、チャート、リストなど様々な形式の仕様書を作成できるようになっています。
このように、シミュレーションで実際の動きを体験しながら仕様情報の検討を重ね、できあがったモデルから、設計に必要な仕様情報を出力すると言う一連の機能が、ますます複雑化する組み込み製品のHMI開発には不可欠となって行くでしょう。