IPA


IPAトップ





平成15年度未踏ソフトウェア創造事業(未踏ユース)  採択案件評価書


 




1.採択者氏名


代表者

古市  悠(慶應義塾大学大学院)

共同開発者

なし



2.担当プロジェクト管理組織


 (株)創夢



3.委託支払金額


 3,000,000円



4.テーマ名


 実世界指向協調動作定義アプリケーションの開発



.関連Webサイトへのリンク


 なし



6.テーマ概要


 近年,情報家電,ネットワークMDなどの通信機能を持つ電子機器が市場に出回るようになった.電子機器がネットワーク接続機能を持つ事により従来はCDプレーヤーとアンプなどの同一機種間だけで行なわれていた協調動作が椅子とテレビなどの異機種間においても行なえるようになった.

 しかし,現在構築されている機器間協調動作アプリケーションでは,ユーザは自分の要求をアプリケーション特有の手法に変えて表現しなくてはならない.

 たとえば,実世界においてユーザは,自分が存在する空間内の機器を視覚的に把握することが可能であるが,アプリケーション上では機器をコマンドリスト,リストボックス,チェックリストなどのPC上の情報としてしか把握できない.

 このため,実世界の視覚的な情報とアプリケーション上の情報を照らし合わせなければならず,また,定義手法も機器間に線を描く方法やドラッグアンドドロップする方法などアプリケーション独自の手法を使用するためユーザに負荷がかかってしまう.

 本プロジェクトではこれらの問題を解決する方法として実世界行動に基づいた動作定義アプリケーションSticky Editorの開発を行なう.本アプリケーションを使用することによりユーザは実世界の情報と同様の情報をPC上で取得することが可能になる.また,付箋を貼るという実世界行動を用いた定義手法を採用することにより,容易に機器間の協調動作定義を行なうことができる.



7.採択理由


 前年度の門田君と同じ研究室からのよく似た提案であった.書類審査の段階では,付箋紙というシンプルなアイデアに筋の良さを感じたが,プレゼンでは,どこか印象が薄かった.しかし.概念やシステム構成の言葉はスムーズに展開しており,いま流行りのこのテーマになんらかの貢献ができる可能性も感じた.また,プロ管候補からの期待も比較的大きく,まずは蓋を開けてみるのもありとPMは考えた.なお,本人自身の能力は十分に高いと思われる.

 

 
8.成果概要(中間報告時)
 

 
 このシステムのアイデアが具体的にどういうことなのかを少し説明しておく.

 このシステムでは制御を行なう機器の状態変化をイベントと呼ぶ.ユーザが機器の協調動作を定義するときは,まず被制御機器の制御するコマンドを付箋に書き込み,イベントを発する制御機器の変化後の状態に付箋を貼る (古市 図1).たとえば,

 

ビデオの状態Runningに付箋LightOnを貼るイメージ図

 

古市 図1 ビデオの状態Runningに付箋LightOnを貼るイメージ図

 

・「TV,ON」と記述した付箋を,椅子の,人がいるという状態に貼ると,椅子に座ればTVがつくようになる.
・「CD Player,Play」と記述した付箋をボタンが押されたという状態に貼ると,ボタンを押したときの動作が変わるマルチボタンが構築できる.
・「ライト,ON」と記述した付箋を時計の時間に貼れば,タイマー機能を提供するタイマー時計が構築できる.

 実際に定義を操作するには

(1) ユーザが,小型端末上で制御機器のイベントと被制御機器の制御コマンドを選択すると付箋が生成される.
(2) 小型端末を機器に向け,画面上の「Post」ボタンを押して機器に付箋を貼る.赤外線を介して小型端末上から機器へ定義情報が通知される.

 なお,本システムが動作するには,各機器が計算機能を持ち,またネットワークを介した操作や状態の通知が可能であることが必要である.

 上記の機能を実現するために,実装形態の詳細設計を行ない,それに従って各種の機能の実装を進めた.UIを除いた部分は概ね完成したが,統合試験は未了である.

 

 
9.PMコメント(中間報告時)
 

 
 日程が合わず現場訪問をし損ねてしまって,どの程度までシステムが立ち上がってきたのかの確認が未了である.だから,中間報告時(11月末時点)ではちゃんと評価できない.というのも,報告書を読んでも詳細がよくわからなかったからである.以前から気になっているのだが,古市君の文章はかなり読みにくい.比較的細かく書かれた報告をもらっているのだが,読み通すのが困難で,結局なにがどうなっているのかよくわからない.上の「中間成果」も10ページ程度の報告から私に理解できたところだけを短く抜粋したものである.

 現場でデモを見れば,実現された機能は,上に示された簡単な例のわかりやすさからいっても一目瞭然に違いないのであるが,その機能を実現をするための内部構造や実装技術がきちんとした形で提示されていないので,どうも不安になる.これは,たとえば,この仕事を論文化する際にも大いに問題になるだろう.プログラムだけでなく,せっかくよく整理されているはずの概念を,やはり整理された言葉で語る文章技術をもってほしい.それはそのままソフトウェア作成にもフィードバックして役立つ.

 このことも含めて,なるべく早く現場を訪れたい.


10.成果概要(終了時)


 中間成果で記述したものと様子が違ってきているので,少し詳しく説明する.開発されたのは,単なるStick Editorではなく,Sticky Editor System (のプロトタイプ) である.

 Sticky Editor Systemは,ユーザに対して実世界指向ユーザインターフェイスと「付箋」という実世界メタファを用いた定義手法を提供する.これらを提供することにより,協調動作定義の際の「デバイス,定義等の把握」,「定義手法の習得」におけるユーザの負担を軽減し,一般ユーザ自身による協調動作の定義と利用を実現する.古市 図2にSticky Editor Systemの構成図を示す.

 

Sticky Editor(左)とSticky Board(右)の図

 

古市 図2 Sticky Editor(左)とSticky Board(右)

 

 Sticky Editor Systemは,Sticky EditorとSticky Boardの2つの動作定義アプリケーションと,多数のサービスコンポーネントにより構成されている.Sticky Editorは,付箋の実世界メタファを用いた定義手法を使い図・古市2 (左) のGUI: Sticky Editor内で付箋をサービスコンポーネント (機器) に貼り付けるという実世界行動を用いた定義手法を採用する.ユーザの「定義手法の習得」を軽減しながら,サービスコンポーネント間の協調動作定義を実現する.Sticky Boardは,付箋の実世界メタファを用いた定義の操作手法を使い,図・古市2 (右) のGUI: Sticky Board内で付箋をBoardに貼り付けたり剥したりすることで,ユーザの「デバイス,定義等の把握」の負担を軽減しながら,複雑な協調動作定義を実現する.

 サービスコンポーネントとは,デバイスやソフトウェアなどのネットワークコンポーネントを抽象化した概念である.サービスコンポーネントは本システムが提供するミドルウェアのAPIを使ってデバイス開発者やソフトウェア開発者により構築される.構築されたサービスコンポーネントはID (名前,位置情報,認証情報など) と機器が持つ状態を保持することができる.サービスコンポーネントはお互いにメッセージを送りあうことで関係を持つことができる.サービスコンポーネント構築者は「どのような時に,だれにどのようなメッセージを送るか」,「どのメッセージを受信したときにどのような処理を行うか」を定義することでサービスコンポーネントを構築する.

 サービスコンポーネントは,ビデオカメラ,TV,メールシステム,時計など,制御される機器やソフトを表すものと,それらの間をつなぎ,状態変化による制御メッセージを送信する付箋を表すものの2種類に分類される (古市 図3).

 Sticky Editorでは,古市 図4のようなGUIを使って,画面上の機器に古市 図1のような付箋を貼っていく (赤外線は使わない).

 

サービスコンポーネント概念図

 

古市 図3 サービスコンポーネント概念図

 

Sticky Editor使用時のスクリーンショット

 

古市 図4  Sticky Editor使用時のスクリーンショット

 

 Sticky Boardは付箋を機器に直接貼るのではなく,ボード上に並べていく.こうすることにより複数枚の付箋を関係づけることができ,もう少し複雑な制御シーケンスを書けるようになる.また位置を同定しにくい対象の制御も可能になる.

 これらのGUIや (公開できる) ミドルウェアを実装した上で,マルチボタン (叩く回数に応じて定義可能な多用途に使えるボタン) やマルチタイマー (いろいろな機器を制御できる) によって実証実験を行なった.



11.PM評価とコメント(終了時)


 中間報告までに現場を訪問できなかったプロジェクトであったが,1月上旬に訪問していろいろ話をした結果,その後展開が進んでほっとしたというのが正直な感想である.中間コメントで古市君の文章が読みにくいということを書いた.これについても面談で個別の文章作法について少しコメントした結果,最終報告書では文章の質も大幅に改善されており (あとほんの少しのテニヲハや打ち間違いのみ),なによりも全体のアーキテクチャ概念がきれいに整理されていたことに感心した.やはり,文章やプログラム書法は若いうちに鍛えると効果が抜群ということか.

 中間報告ではシステムの中にいろいろなレベルの多種類のコンポーネントがぐちゃぐちゃとしていて,それもあって読み辛かったのだが,最終報告では,制御対象と付箋の2種類というサービスコンポーネント概念にきれいに整理された.これならわかりやすい.同じものでも,概念整理するとずっとわかりよくなる好例だ.

 Sticky Boardも訪問したあとで出てきた新しいアプリケーションだ.これは大学内部でいろいろ議論をした結果生まれたものらしい.これも大いに結構.

 さて,このシステムは,シロウトにも容易に使える情報家電制御の仕組みを提唱している.付箋には「書く」,「貼る」,「剥す」の動作しかなく,しかも,ここでは「書く」はすべて,メニューからの選択だけなので,たしかに初心者にも容易に使えそうだ.ただ,作成されたGUIにはシロウト向けの改良がもっと必要だろう.しかし,付箋メタファでなにができるかを示したプロトタイプとしては評価できる.

 

慶応義塾大学湘南藤沢キャンパスSSLABの写真

 

古市 図5 慶応義塾大学湘南藤沢キャンパスSSLABの写真

 

 最終報告会でも質問したが,それにしてもネットワークで機器を制御するハードウェアがまだまだ日常的な価格では買えない.これが早くブレークしてくれないと,マニア層がちょっと遊んでみようかというところまでにもなかなかいかない.終了時(3月時点),古市君の所属している徳田研のSSLAB (古市 図5) のような大がかりな装備のある部屋での実験が主だ.技術的にはいつブレークしてもおかしくないところまで来ていると思うのだが,やはり一般家庭にまず入るためのキラーアプリがまだないということなのだろう.キラーアプリというのは,ひょんなことから生まれたりするので,せっかくいい環境で研究をエンジョイできる古市君には,その「ひょんなこと」のアイデアの創出をぜひ期待したい.





  ページトップへ   






  Copyright(c) Information-technology Promotion Agency, Japan. All rights reserved 2004