を組込みシステムに 実装す るための開発 プロセスに関す る提案

UserExperience

を組込みシステムに 実装す るための開発 プロセスに関す る提案

毅 哉 彦

尚 慎 晴

沢 形 原

平 尾 鱗

概 要

組込み システムが多機能化する傾向にあって, システムが提供す る機能を通 じて,ユーザーが どの ような体験

をす ることがで きるか を明 らかにする必要性が認識 されるようになっている｡ この

を導 くのが,システムのユーザ インタフェース

であ り, そのための UI設計の重要性 は高 まっている｡ しか しなが ら,従来か らの開発 プロセスでは,UI設計 は要求定義の後工程 で実施 されることが多 く,要求機 能の操作方法 を実現す る目的で実施 されて きた｡ この結果,多機能化 に伴 う操 作の多様化 を生 じさせ, システム全体の操作が一貫 しない問題等 を生 じさせて いる

本研 究では,製品企画の段 階で想定 した

を, システム全 体の操作体系のバ ランスをとった UIを実装す るための開発 プロセスを構想 し た｡

構想 したプロセスに基づいて,実際の開発者 に対 してワークシ ョップを実施 した結果,プロセスの有効性 は認識 された ものの,組織的な導入の困難 さが指 摘 された｡

〔73〕

/‑‑I

商 学 討 究 第60 巻 第

号

1. は じ め に

近年,組込み システム開発 では,ユーザ イ ンタフェース

設計 の重要 性 に対する認識が高 まっている｡ この傾向は,組込み システムの技術展等で,

Iに関す るセ ミナーな どは非常 に高い人気 であることな どか らも伺 える｡ ま た,組込み システムに関す る雑誌で も

Iの特集が組 まれることもある｡ こ の ような背景 には,現在の組込み システムの商品 としての訴求が

Iに強 く依 存す るようになったことを指摘で きる｡

本来,組込み システムの

Iは, システムの機能 を操作す るための手段 を実 現 した ものである｡機能が少 ない場合 は

Iも複雑ではな く,操作手順 も容 易 に理解す ることがで きた｡ ところが,技術基盤の急激な進歩によ り,多 くの 機能 を搭載す ることが可能 にな り, これに伴 い

Iも複雑 になって きた｡便 利 な機能が搭載 されて も,その操作が複雑 にな り,使いこなせな くなるとい う 矛盾 を抱 えるようになって きたわけである｡

一方,組込みシステムは通信技術 との連携 によって,システムが情報基盤や他 のシステムと連動することによって,システム単体の機能にとどまらず,様々な サービスを媒介する役割を担 うようになってきている｡電話単体か ら情報端末へ 進化 し,様々なサービスの媒介を担 うようになった携帯電話が典型的な例である｡

このような変化に応 じて,組込み システムの

Iは,システムが提供するサービス を通 じて,ユーザーが新たな体験

をするための導 き手

となっている｡ このことは

Iが商品の提供するサービスに関与する ようになってお り,商品としての訴求に直接影響 を与えるもの となっている｡ こ の結果

Iは,商品企画の段階で検討 されるべ きものとなっていることがわかる｡

以上の ように,組込み システムの

Iが担 う意味づ けが変化 して きているこ

とを踏 まえて,本研究では,企画の段 階で想定 した

を, シ

ステム全体の操作体系 のバ ランスをとりなが らシステムに実装す るための

設計プロセスを,従来の組込み開発 プロセスに統合 したプロセスモデル として

提案することを目的 としている｡

UserExperience

を組込みシステムに実装するための開発プロセスに関する提案

2. 組 込 み システム開発 にお け る U l設計

2

‑ l.組込みシステム開発 プロセス

組込み システムの特徴 として, システム全体の設計の後,ハー ドウェアお よ びソフ トウェアの実装設計 を行 うという構造的な開発 プロセスを辿 ることを挙 げることがで きる｡

情報処理推進機構の下 にある,ソフ トウェア ･エ ンジニアリング ･セ ンター では,組込み システム開発 プロセスモデル として,ESPR (

,図 1) を提案 している

｡ こ

図

ソフ トウエアエンジニア リングセンターによる

76

商 学 討 究 第60 巻 第

号

の中では

I設計 はシステム要求定義 において行 われ, ソフ トウェア詳細設 計で実装 されることが示 されている｡ このモデルでは

I設計のイ ンプ ッ ト を提供するユーザーに関す る分析 プロセスには触れていない｡

一方, システム ライフサ イクルプロセス を規 定 した規格 であ る

(

]では,利害関係者要求定義 プロセス を明示 してい る ( 図

) ｡

S

押t O mEl e me n t l mp l e me n t a t J O n

q

r " ‑Ha‑A ‑,.‑F

‑ a 品

I tI

Sof^Reftweratro^BClSrO/^Bat^tE^lOnC ^llll

｢‥一己&‑r&to; ir;i;in‑g""1

I l

図

におけるエンジニアリングプロセス

U

I設計 プロセス を明示 したプロセスモデルを構築す るには

のみで は不十分であ り,他のプロセスモデルを参照に して再構成する必要があると考 えられる｡

2‑ 2.U l設計 プロセス

U

I設計 プロセスを考 えた場合, これを支 える枠組み として人間中心設計 プ

ロセスがある｡この基本的な考 え方は,

:人間工学 ‑インタラクティ

ブ システムの人間中心設計 プロセス

] にまとめ られている｡具体

的には,企画か ら実装 において ,( 1) 利用状況の把握 と明示 ,( 2) ユーザー と組織

の要求事項の明示 ,( 3) 設計による解決案の作成 ,( 4) 要求事項 に対す る設計の評

UserExperience

を組込みシステムに実装するための開発プロセスに関する提案

価 とい う

つ プロセスを繰 り返 し実施す ることによって,ユ ーザー要求 を実現 す ることを 目指 している｡

この規格 は,人間中心設計の基本概念 をまとめた ものであるが,実際 には, い くつかの手法や方法論が提案 され利用 されている｡その中で も

t tら に よる

] は最 も有名 な方法論 であ り,国内で も紹介 されている [ 黒須1

] [ 奥 出2

]｡ この方法 は, システムの利用状況 をい くつかの観点か らモデル化 し,要求事項 を導 くことか ら始 め ,U I基本仕 様 を作成す るまでのプロセスを体系化 した ものである｡近年では,モデルの数 を縮約 し, プ ロセス を簡略 した

が提 案 されてい る

エ ンタープライズ系 の システム開発 に適 した方法論であ り,組込み システムの 場合 は,手続 きが簡素化 された

の方が応用 しやす い

と考 え られる｡

同様 に,ユーザ ビリテ ィエ ンジニア として著名 な

は,要求分析 の後, 設計/テス ト/開発 を 3 つの段 階 ( 概念モデル,プロ トタイプ,詳細設計) に 分 けて,抽象度の高いモ ックア ップか ら具体 的な U I‑落 とし込 んでい くプロ セスを定義 している

]｡ また,Cogne

が提案す る

] では,企画 プロセスにおいて構想 した ビ ジ ョンを開発 関係者で共有 しなが ら,詳細設計 まで詳細化 してい く開発 フ レー ムワークを提供 している｡ この他,I

の

山 崎2

] な ど,様 々な設計方法論が提案 されている｡

これ らの方法論 に共通 していることは,ユーザー要求分析 お よび定義の活動 を明示 していることと,プロ トタイプ作成 と評価 のプロセスを繰 り返 しなが ら, U I設計 を詳細化 してゆ くことである｡プロ トタイプ作成 については,ペーパー プ ロ トタイ プ法

], ペ ル ソナ法

], シナ リオ法

[Car

r

] [ 大西2

]等の手法が提案 されるな ど充実 しつつある｡

78

商 学 討 究 第

巻 第

号

2‑3.

組込みシステム開発おける

l設計の課題

ここで,実際の組込み システム開発 プロセスにおける,U I設計 プロセスの 位置づけを確認 してみる｡

一般的には,要件定義活動の成果物 として生成 された機能要求お よび非機能 要求が

I設計のインプ ッ トとな り

I設計が実施 され,最終的にソフ トウェ ア詳細設計 において

I仕様が決定 される手順が とられる｡ユーザ ビリテ ィガ イ ドラインが,エ ンジニアか ら高い関心 を向け られ,エ ンジニア リング系の雑 誌 において特集が組 まれているのは [日経エ レク トロニクス

等], この よ

うなプロセスを前提 に していると考 えられる｡

システムの要求仕様定義後 に

I設計がある場合, ソフ トウェア設計 までの 時間的な制約 を強 く受けなが ら,サ ンプルやポ ンチ絵 を描 くものの,ユーザー 視点での評価 を行わないまま実装 されることが多 くなる

設計がアウ トソー シングされる場合 も,実装す る機能が定義 された状態か らU I仕様 を設計す る ケースが多い [ 尾形

] ｡

組込み システム開発 プロセスにおける

I設計の位置づけを, この状況 にお いた場合,次の ような課題 を兄いだす ことがで きる｡

i)企画 プロセス で憩足 された

Xが;必 ず

UIに反顔 されをいす彪任が あ るo

企画 プロセスで

を想定 して も,それ をシステム要求仕様定義 プロセス に連動 されることがなければ,U I仕様 に反映 される保証 はない｡実際に,企 画担当が想定 した仕様 と,ソフ トウェア詳細設計後の仕様 とが異 なる場合 は少 な くない｡

単純 にこの間題 を解決するには,企画段 階で

概要仕様 を決めれば良いこ

とになるが,U I仕様 はシステムの技術面か らの制約 を強 く受 けるために,企

画段 階での

I仕様 を作成す ることが難 しい と言える｡

UserExperience

を組込みシステムに実装するための開発プロセスに関する提案

シス テムの多戯 彪 化に伴 い,操作系が 鎗鍵化する.

ユーザーの声 を反映 させ,技術的な性能の向上 を反映 させ, さらに競合 との 競争優位 に立つ仕様 を検討 してゆけば,必然的に多機能化 となることは避け ら れない｡ しか しなが ら,ユーザーの身体的,認知的能力 には限界があるので, すべての機能 を受け入れることがで きない｡利便性 を考慮 して機能を追加 した にも関わ らず,逆 にユーザーが使 えない,あるいは必要でない機能を開発 して しまうとい う矛盾 を強めることになる｡

3) t I I在席 の妥当性確認が囲潜 にをる.

2

)の多機能化 に伴 う問題 は, システム要素の

の最適化 だけでな く, シ ステム全体か ら見た操作系全体の最適化, さらには,通信 などで外部 と接続 さ れる場合,異 なる操作系 との連動性 について も最適化 を求めなければならな く なる｡ したが って,今後,U I仕様の妥 当性 を確認す ることが更 に困難 になっ てゆ くことになる｡

4)

t I I在席密度管犀が囲瀞 に7 ?る0

2

)の多機能化 の問題 は,部分的な

Iの仕様変更による仕様全体への影響 を推定す ることを困難 にさせ る可能性がある｡個 々の

I仕様 は関連 している ものであるため,ある部分の

I仕様 を変更 した場合,全体 に与 える影響 を予 測す ることが難 しくなる｡

5)避i

nを t I I各様を甜 するためには,再度,二 要求各様定義 を 行 う必劇 ミ あ る0

で レビュー した

I設計方法の全ては,そのプロセスの中で,要求仕

様定義 を実施 している｡組込み システム開発 において,要求仕様定義プロセス

後に ,U I設計プロセスを取 り込むのであれば ,U I設計のために,再度,要求仕

様定義を実施することになる｡すなわち, システムのための要求仕様定義 とUI

のための要求仕様定義 を

つ実施す ることにな り,場合 によっては同様の活動

を繰 り返す可能性がある｡無駄 な開発 コス ト,工数をかけていることになる

80

商 学 討 究 第60 巻 第

号

以上のような組込み システムおける

I設計に関する課題は,既 に,い くつか の企業では顕在化 してお り,急務の課題 として対策が求め られている [ 伊藤

3.

組込 み システム開発 プロセスへの

Ⅰ設計 プロセスの統合

3‑1.U

l設計プロセスを統合するための要件

前述の

で考察 した組込み システム開発における

I設計の問題 を整理 すると

I設計プロセスについて次のような基本要件 を兄いだす ことがで き る｡

i)企画 と t J I任牒 とを遵guできるようにするo

これは,課題 1) を受けた要件である｡ この要求をプロセスに組み込むこと によって,商品の訴求性の高い製品開発 につな ぐことができる｡

2) t I I在席の窟 超 を道産 できるようにするo

これは,課題

を受けた要件である

I仕様 を決定 した理由が要 求分析の過程で明確化 されるようにすることである｡

3) t J Z任腰全体 を席題蕗に理解 できるようにするo

これ も,課題

を受けた要件である

I仕様 を決定 した背景 を構 造的に理解で きるようにすることである｡

4) U

ZB n 一 計のための要求it 牒定義 を亜送み シス テムの要求任牒定義 と遵励 さ せる｡

課題

) を受けた要件である

I設計 における

I要求仕様 を導 くプロセ

ス とシステムの要求仕様 を導 くプロセス とを連動 させることである

UserExperience

を組込みシステムに実装するための開発プロセスに関する提案

基本的なプロセスモデル

3‑

1.の要件 を受けて, まず,プロセスの基本的な構成 を決定 した｡ これ を図

に示す｡プロセスの構成 は, 企画プロセス とシステム要求定義の間にユー ザー要求定義 プロセスを導入 した もの となっている｡従来のプロセスモデルと の関係 は,表

の ように対応す ることがで きる｡企画 プロセスは,現段階では, 明示的なプロセスモデルがな く,属人的な側面が多いため,企画の構想 とその 確証 という

つのプラクテ ィスに集約 している

プ ロセ ス 企宵I■愚 ユーザ ー7E*J:暮 システム手水分析 アーキテクチャ牧11システム ‑ 7‑キテクチャ牧■トソフトウエア

プラクティス

l

事東■4の分析 分析 +l当て の分析 インタフェースp

t f

∈≡≡

∃

=

匡

匝 璽 ヨ 〔 ≡ ≡ 三 ≡ ヨ

図3 プロセス全体構成

プロセス間の連携

このプロセスモデルの基本構造は,従来のプロセスモデルを再編集 した もの となっているが,実際の

I設計 プロセス を統合 させ るための工夫 は,プラク ティスに設定 している｡

1) 『 利用特性』 とい う考 え方の導入

株式会社

にお ける過去

年 にわたる

I設計の実績 に よれ

ば

I設計 は画面デザ インな どか ら始め るのではな く, システムを利用す る

ユーザー活動 を定義す ることによって

I設計 を円滑 に進めることがで きる

表 1 プロセスモデル対応表

プロセスカテゴリ プロセス プラクティス

企 画 企 画

1 企画の構想

‑

BP2

企画案の確証

ユーザー要求定義 ユーザー要求定義

1 利用状況の明確化 ^{要求事項の分析}

BP3

ユーザー要求定義

BP4

ユーザー要求定義の確証

システム開発 システム要求分析

1 システム要求事項の特定

BP2

システム要求事項の分析

BP3

運用環境の分析

BP4

システム要求事項の重み付け

BP5

システム要求事項の評価 .改善

BP

6 システム妥当性確認テス トのための評価計 画作成

システム

アーキテクチ ャ設計

l システムア‑キティクチ ャの設計

BP2

システム要求事項の割当て

BP3

システムインタフェースの定義

BP4

システムアーキテクチ ャの評価卜 改善

ソフ トウェア開発 ソフ トウエア要求分析

1 ソフ トウエア要求事項の特定

BP2

ソフ トウエア要求事項の分析

BP3

運用環境の分析

BP4

ソフ トウエア要求事項の分類 と重み付け

BP5

ソフ トウエア要求事項の評価 .改善

BP6

価計画作成 ソフ トウエア安当件確認テス トのための評

ソフ トウエア

アーキテクチ ャ設計

1 ソフ トウエアア‑キティクチ ャ設計 ^{インタフェース設計}

謝 焼

2:R 瀬 6 0 醇 瀕

･J3g

UserExperience

を組込みシステムに実装するための開発プロセスに関する提案

ことを経験的に理解 していた｡ユーザー活動 を定義するには,その活動 を特徴 づ けるための観点が必要 になる｡

例 えば

Sシステムの売 り上げ実績 を表示す る UIを考 える場合, まず, 売 り上 げ実績 を確認す る とい うシステムの利用 目的か ら設計す ることがで き る｡ また, この システムをどこで利用す るか という観点か らも設計することが で きる し, また, どの ようなユーザーの特性か らも設計することがで きる｡重 要 なことは, これ らの観点 によって, システムを利用 した際の

Xが方 向づ け られることである｡すなわち, これ らの観点 を明確 にすることは, システム のユーザー‑の訴求点 を明確 にす ることにもつながる｡

Cooper

の提唱す る手法

]では,ユーザー特性 を分析す ること で

X を定 義 して い る と見 る こ とが で きる｡ また

[Beyer&Holtzblatt1997

]では,ワーク ( 作業) とい う観点か ら

X を定義 しているとみなす ことがで きる｡

いずれに して も,これ らの観点 を定義することは,システムを利用する意味 づ けを明確 にす る ものであるため,企画 において

X を定義す ることを補完 するもの となっている｡筆者 らは, この観点 をシステム利用の特性 を規定する

もの として,｢ 利用特性｣ と名付 けている

2

) システム要求 に関連す る概念の統合

組込み システムにおける UI設計 は,一般的には,要求定義 において決め ら れた機能 を基 に,UI仕様 を設計 している｡ この場合 の UI設計 プロセスは属 人的であ り,明確 なプロセスはない｡ む しろ,従来の UIや,競合 の UIを参 考 に しなが ら設計 されることが多 い｡ 開発費にゆ と りがあれば,UI設計 コン サルタン ト会社 にアウ トソーシングされるものである

筆者 らは, この背景 には,UI設計 プロセスの基盤 となる基本的な概念が共

有 されていないため と考 えた｡す なわち,UIとは,何 を背景 に設計 されてゆ

くのかが唆味 になっているため と考 えている｡そ こで,次の ような,UIとシ

ステム要求 との関係性の基本的な概念 を明 らかに した｡

84

商 学 討 究 第60 巻 第

号

●ユーザー タスクを実施す るために, システムに備 えなければな らない機 能 がある

●システムの機能 は,ユーザーの システム操作 を通 じて利用 され る

●ユーザーの操作 を実現す る手段が U Iである｡

図

は, これ らの考 え方 を図示 した ものである｡

この図に基づ くと,① の課程 を実施す ることによって,ユ ーザー要求定義 プ ロセス とシステム要求定義 プロセスを連動 させ ることがで きる｡② ,③ の課程 は,システム開発 プロセスの段 階か ら U I設計 を実施す ることを意図 している｡

ユーザー側 システム側

要求定義レベル

設計レベル

一 一 日一 一 一 ■ 一般的なul 設計プロセス

= 提案するul 設計プロセス 図 4 U l 設計プロセスのための基本的な考え方

以上の ように,

利用特性』 の考 え方 と,ユーザー タス ク とシス テム機能 と

の考 え方 を統合 すれば,企画 における商品 と しての訴求点 を U Iに取 り込 む こ

とが可能 にな り,結果 として,企画段 階か ら U I設計 を開始す ることがで きる

ようになる｡今 回,提案 したプロセスモデルのプラクテ ィスを実施す ることに

よって,理論的には,企画か ら U I詳細設計 まで を連動す ることが可能 になる｡

UserExperience

を組込みシステムに実装するための開発プロセスに関する提案

4.

統合 開発 プ ロセ スの妥 当性

提案 したプロセスモデルの妥当性 を確認す るために,国内の製造業の開発 関 係者にワークショップを実施 し,可能性 と問題点 を調査 した｡ ワークショップ を実施 した企業は,次の

社である｡

A

社 ( 製造機器 メーカー)の場合

A 社 は,特定の製造業 における製造機器 メーカー として,世界で も トップク ラスのメーカーである｡社員数 ( 連結)

万名 を超 える大企業であ り,機器の 高い品質 ときめ細かいサー ビスでブラン ドを形成 している｡当初,顧客 に対 し て,使いやす さを訴求で きる

Iについての評価 を依頼 されたが,調査 を進め る中で

I設計 プロセス以前の システム要求定義 プロセスに問題があること を指摘 した｡

A 社 は製造機器の提供か ら製造 システムのソリューシ ョン提供へ と事業 を転 換す ることを目指 していたこともあ り,筆者 らの構想 したプロセスモデルの導 入 について関心 をもっていただいた｡その結果,ある既存 システムについて, 提案 されたプロセスモデルに基づ く設計活動 をワークショップ形式で再度実施 し,従来 と比較 して何 が違 うのか を実証 的に精査す ることになった｡ ワー ク ショップは,半年間, 4回実施 した｡

ワークシ ョップの結果,企画か ら構想 を可視化 し,下位のプロセスまで情報 共有で きることの可能性が指摘 された｡ また, システム開発の上流 を僻撤で き ることか ら,教育研修 に直接応用で きるとい う感想 を得 られた｡

一方,機能要求 を中心 に設計で きるが,設計 に必要 となる情報の設計 につい

ては,不十分であると指摘 された｡そ して, ワークシ ョップの修了後,事業 レ

ベルでの開発 プロセスの改善へす ぐに着手で きることは難 しい とい う感触 を得

た｡

86

商 学 討 究 第60 巻 第

号

B 社 ( 家電機器 メーカー)の場合

B 社 は歴史ある家電メーカーであ り,社員数 ( 連結) 1 万名 を超 える大企業 である｡特定の技術領域 に先端技術 を持 ってお り,そのためのブラン ドも確立 している｡ しか しなが ら,提供す る商品市場 も成熟 してお り,競合 との差別化 が難 しくなっている｡今後, この差別化 について,商品の

Iを訴求ある もの

と考 えてお り,そのための新たな

I設計 プロセスを模索 していた｡

今 回は ,U I技術基盤が大 きく変化す るのに対 して,新製品開発 に対する UI 設計 プロセスを見直す機会 と考 え,開発 関係者の

I設計 ワー クシ ョップを依 頼 された｡その結果

ケ月間に実際の開発活動 を並行 して,4回のワークショッ プを実施 した｡

ワー クシ ョップは ,U I設計 に対す る問題意識が明確 であったために,概 ね 好評であった｡特 に,企画段 階か ら

Iを意識す ること,ユーザー要求 を可視 化す ること,機能要求の論拠が明 らかにされることは好評であった｡

一方,作業量が増 えることか ら,組織的な導入は困難であると指摘 された｡

開発者個人 レベル向けのスキルに分解す ることがで きれば,受け入れが容易 に なるだろうとい う感想 を得ている｡

A

社

社 ともに,構想 したプロセスの有効性 は認識 された

社の場合 は, 企画構想 とシステム要求定義 との連動 について ,B 社 については,企画 と UI 設計の連動 に関心が向け られていた｡対象 となるシステムの特性 によって,プ ロセスの関心が異 なることが理解で きる｡ したがって,基本 プロセスは汎用的 なもの として,事業 によって,プラクテ ィスをカス タマイズす る必要性がある ことが理解で きた｡

また, どち らのケース もプロセスの有効性 を実感 しつつ も,組織的な展開に

ついては大 きな壁 を認識 していた｡新たな開発 プロセスの変更は,組織変更 を

伴 うことを考 えると,社会技術

l ) アプローチの研究の必要性

を認識することになった｡

UserExperience

を組込みシステムに実装するための開発プロセスに関する提案

5.ま と め

組込み システムが多機能化す る傾向にあって, システムの

Iは様 々な課題 を抱 える と同時 に,商品の訴求の点か ら期待が寄せ られ

I設計の重要性 は 高 まっている｡ しか しなが ら,従来か らの開発 プロセスでは

I設計 は要求 定義の後工程で実施 されることが多 く,要求機能の操作方法 を実現する流れで 実施 されて きた｡ この結果,機能 を満載す る製品仕様 となった り

I仕様変 更が困難になるな どの問題 を抱 えたままの開発 プロセスが少 な くない｡

本研 究では,製品企画の段 階で想定 した

を, システム全 体の操作体系 のバ ランスをと りなが ら, システムに

Iを実装す るための開発 プロセスを構想 した｡ このプロセスの特徴 は,利用特性 とい う考 え方 と,ユー ザータスクと機能 との関係性 に基づいたプロセスを指向 していることにある｡

開発者に対す るワークショップを実施することによって,提案 したプロセス モデルの妥当性 を確認 した結果,プラクテ ィスの有効性 は確認で きたが,実際 に事業 として取 り組 むことの困難 さが指摘 されている

今後,組織的な導入 をはかる際の事業モデルのあ り方 も精査 してゆきたい と 考 えている｡ また,今 回はプロセスモデルによる議論 を中心 に展 開 したが,開 発基盤環境 をもとにユーザ インタフェースアーキテクチ ャの構想 も検討 してゆ

く必要性があると考えている

謝 辞

本研 究 を進 めるにあた り, ビジネス創造 セ ンター

研 究部 門の桶谷研 究

負,葛西研究員,山田 ( 河合)研究員,黒 田研究員か ら多 くの示唆 と協力 を得

た｡ ここに,改めて謝意 を表 したい｡

ββ

商 学 討 究 第

巻 第

号

参 考 文 献

[SEC200

7]独立行政法人情報処理推進機構 ソフ トウェア ･エ ンジニア リング ･セ ンター

:組込み ソフ トウェア向け開発 プロセス ガイ ド,朔泳社

lifecycleprocesses

[ISO13407] ISO13407:1999Human‑centreddesignprocessesforinteractivesys‑ tems

[ 尾形

]尾形憤哉,鱗原晴彦,青 島寛大 :

I( ユーザ イ ンタフェース)設計 と システム設計 を結ぶモデ リング技術 の可能性 について, ヒューマ ンイ ンタフェース シンポ ジウム

論文集抜粋

[Beyer&Holtzblatt1997]Beyer,H.,Holtzblat

t ,K

[ 黒 須

]黒 須正 明,時津倫 子,伊 東 昌子 :ユーザ工学 入 門 一 使 い勝 手 を考 え る

への具体 的アプローチ,共立 出版

[ 奥 出

7]奥 出直人 :デザ イ ン思考の道具箱 ‑ イノベー シ ョンを生 む会社 のつ く り方,早川書房

lBeyer,Holtzblatt&Wood2004]Beyer,IL,Holtzbla

t

textualDesign:AHow‑toGuidetoKeyTechniquesforUser‑CenteredDesign.

MorganKaufmann,2004

[Mayhew1999]Mayhew,D.J∴TheUsabilityEngineeringLifecycle:A Practi‑ tioner'sHandbookforUserInterfaceDesign,MorganKaufmann,1999

[Cognetics]CogneticsCorporation:LUCIDFramework,http://1eadersintheknow, biz/Default.aspx

[Carolyn2003]Carolyn,S.:PaperPrototyping:TheFastandSimpleTechniques forDesigningandRefiningtheUserInterface,MorganKaufmann,2003

[Cooper2004]Cooper,AJTheInmatesAreRunningtheAsylum:WhyHighTech ProductsDriveUsCrazyandHowtoRestoretheSanity,Sams,2004

[Carro112000]Carroll, J.M.:Making Use:Scenario‑Based Design of Human‑ComputerInteractions,TheMITPress,2000

[ 大西

]大西淳, 郷健太郎 :要求工学‑ プロセス と環境 トラック,共立出版

[日経エ レク トロニクス

] 日経エ レク トロニ クス ( 編) :モデルに基づ く開発方

法論のすべ て 一 組み込み ソフ トウェア

), 日経

社

[ 山崎

] 山 崎和彦,吉武良治,松 田美奈子, 日本

使 いやす さのためのデ ザ イ ンー ユーザーセ ンター ド ･デザイ ン,丸善

[ 伊藤

]伊藤潤,組み込み システム開発 とユーザ ビリテ ィ工学,人間中心設計,

l