バーチャルモデルの使い方事例 こんな使い方で効果を上げています

最近の組み込み機器はますますパソコンに近づいており、一昔前の家電製品に比べれば、実装される機能は比べものになりません。「多機能な組み込み機器」と言えば、直ぐに「ケータイ」が取り立たされていましたが、ケータイ以外の製品でも非常に複雑な操作仕様を持つ製品が多くなってきました。

筆者が最近購入した家電製品では、「HDD内蔵DVDビデオデッキ」が上げられます。妻などは最初「VHSテープがHDDに変わっただけ?」と思っていたようですが、HDDを利用したビデオ録画には、テープ録画では考えられない機能性が多くあります。

・録画した内容がすぐにサムネイルで一覧できる
・どこでも自由に消去できる
・「巻き戻し」の必要がない
・放送時間に遅れても、追っかけ再生できる
・そのままのクオリティでDVDにコピーできる

などなど、数え切れません。また、テープをセットする必要がないので、VHSにあった「予約録画モード」の概念がなく、VHSビデオデッキの仕様とは大きく異なっています。

このように、組み込み機器は短期間でドラスティックに変化しており、新しい機能性を活かした「使いやすい」製品を作るための皆様のご苦労は、並大抵の事でないと想像しています。

製品を開発するには、製品仕様作成の過程では、「製品企画」→「仕様決定」→「仕様のドキュメント化」→「仕様のレビュー」と進み、完成した仕様書が開発へ渡されます。一昔前の様に機能が単純であった時代では、明確な仕様提示なしに、前に開発した製品をたたき台に、担当者間の「暗黙の了解」で開発される事も少なくありませんでした。

前述のHDDビデオデッキのような新しいジャンルの製品、あるいは、機能性が桁違いに複雑な製品では、「暗黙の了解」など通用するはずはなく、製品仕様をドキュメントとして、正しく作成することが必須になっています。製品仕様には、機能を整理して正しく使えるようにすることの他に、「ユニバーサルデザイン」など、様々なユーザーに対しての「使いやすさ」を考慮することも必要です。

開発スタート時点での製品仕様の完成度が、製品そのものの価値を決めていると言っても過言ではないでしょう。

ガイオでは、PC上に構築する仮想的な「プロトモデル」を使用して、より確実な製品仕様を作成する手法を提案してきました。

製品の方向性が決定されれば、製品の操作仕様やGUIのデザインなど、具体的な製品仕様決定に進んでゆきますが、このフェーズでも、「プロトモデル」は非常に有効です。

一般的な製品仕様作成の方法は、仕様デザイナーが頭の中で組み立てたGUI、操作方法を、ワープロで書き上げていくと言うものです。仕様デザイナーは、機能の分割・階層化、操作モードの構築、操作メニューの階層化などを考慮して、「首尾一貫した」「使いやすい」製品仕様作成を目指していると思います。

しかしながら、頭の中で組み立てるだけでは、その結果を確認する方法、ソフト開発で言えば「デバッグ」する方法が無いため、機能が複雑であればあるほど、作成した製品仕様の中に「矛盾点」や「ミス」「バグ」と言った不具合を多く抱えてしまいます。このままの仕様書が開発に渡ってしまうと、仕様そのもののミスから来る不具合が製品に実装されてしまう可能性もあり、これは、どうしても避けたい事の1つです。

「プロトビルダー」を導入された多くの皆様の目的と言えば、開発プロセスを効率化し確実な製品リリースを行うためであることは明確です。

作成した「プロトモデル」を早期のプレゼンテーションに使い、このツールで仕様そのものを設計・確認し、最終的には「機能仕様書」をプロトモデルから自動出力することで、開発の効率化が計れると考えています。これは、ガイオが「プロトビルダー」で提案している利用方法です。

欲張りなユーザーの中には、プロトビルダーに「ソースコード機能モジュール」を追加して、作成したプロトモデルからGUIのソースコードを出力して、製品にそのまま使ってしまおうと考える方もいらっしゃいます。これらは、実際の製品のリファレンスとして作成する「プロトモデル」から、取り出せるものはすべて利用しようと言う、無駄のない活用方法なのかも知れません。

しかしながら、「プロトビルダー」を最近導入されたユーザーから、意外な事を耳にしました。

「プロトモデルは成果物ではないんです。あくまでワープロの仕様書作成の過程のもので、仕様書が出来たときには捨ててしまいます。各担当者が自分の作成した仕様を確認して、間違いを無くすためだけに使用しています。この方法で、はっきりとした効果が上がっています。」

これは、ガイオが想像していた利用方法と少し違っていました。このユーザーは「プロトビルダー」を、ワープロで作成する仕様書の「デバッガ」として利用することに徹底しており、最終的な成果物はプロトモデルやプロトモデルから自動作成する仕様書ではなく、あくまで「ワープロ書きの仕様書」なのです。

このユーザは、プロトモデルを成果物として、完全に仕上げることにはフォーカスしておらず、短時間で確実な仕様書を作成するためには、プロトビルダーを単にデバッグツールとして使用する方が、はるかに利用価値が高い様です。

このユーザのチームでは、製品仕様書として3000ページ越えのワープロ文書を作成しており、この作業自体は、長年培ったノウハウで、分業体制を確立しています。しかしながら、分量が分量なだけに、各担当者が集まってワープロ文書の読み合わせを行っただけでは、作成した仕様のどこに間違いがあるのかが判らないことが多くあるようです。

平たく言えば、各担当が数百ページの仕様書を赤ペンでチェックするのは退屈な作業であり、機能が複雑になってしまうと、机上でのレビューには限界があるのです。

各担当者はいくら考えても、仕様の間違いを見つけだせない、気が付かないと言う袋小路に入ってしまっており、ここから抜け出すには、仕様をデバッグする手法やツールが必須です。

しかし、短時間でワープロ仕様書を作成することが目的であれば、「プロトビルダー」でプロトモデルを作って動作確認する工程は、通常のワープロ作業の上の余計なものとなります。

このユーザのチームにとっては、この余計さを考慮しても、バグの取れた正しい仕様書が作成できることが、より大きな効果となっています。