FACILITATOR@Sɉ΂‚lCl

2000N̉Ă̍ƎvBVے̖{i{ɌāCwZwZuIȊwK̎ԁvǂĂ̂CK̖͍𑱂ĂB
ȒCL}ق̊JˏɂȂ߂ĂƂɁCэłB
uSɉ΂‚lClv
Vے̃L[[húvCIȊwK̎Ԃ𒆐SɎqǂɐgɕt́|úv
̂߂ɋtɋ߂Ă̂́C܂ɁuSɉ΂‚lvƂĂ̎ł͂ȂƍlẮCȐołB

---

FACILITATOR@Sɉ΂‚lCl

ԒrwEJNWEYKisaru^jJj

z180x]Ă݂

IBM UCDとは - Japan

メッセージの単純化

UCDアプローチの最初の対話は単純で力強くなければなりません。メッセージが単純であれば、組織が「肯定はするが、受け入れない状態」(つまり、「そのとおりであるが、複雑すぎる」とか、「そうではあるが、時間、資金、人手がかかりすぎる」と思う状態) になりにくくなります。UCDというアプローチは単純で手が届くものなので、このアプローチの対話では、「単純で手が届く」印象を与える必要があります。

聴取者の関心事に合わせたメッセージ作り

組織の構成員によって、UCDの採用についての関心事はそれぞれ異なります。開発者は開発サイクルの遅れが気にかかるでしょうし、管理職なら予算の超過を心配するでしょう。聴取者それぞれの関心事を扱うことによって、UCDを採り入れると組織にとって利点があることを納得してもらうことができます。

使いやすさが不充分であるために組織に発生する問題点の指摘

ユーザー中心の設計を実践していない組織では、たいていの場合、顧客が満足できない、ユーザーの生産性が悪い、トレーニングやサポートのコストが膨大である、マーケット・シェアが下降しているか停滞している、開発スケジュールや開発コストが超過している、などの何らかのサインが表われています。問題の程度を示すデータが見つかれば見つかるほど、組織が変化を受け入れる必要があることになります

UCDの意義を証明する証拠の提出

UCDを採用することの正当性を示す必要があります。最も説得力のある証拠は、それぞれの組織の UCDプロジェクトから得られます。各組織からのデータを持っていない場合は、コストに見合った使いやすさに関する外部の調査データを使います。「コストに見合った価値」の記事を読むと、UCDを始めるのに役立ちます。UCDプロジェクトを開始するときには、組織にとって重要な目標に焦点を置き、その目標の達成における UCDの意義を証明する量的および質的な証拠を集めます。量的な測定データには、ユーザーの生産性、ユーザーの満足度、開発時間、開発コスト、売り上げ高と収益、トレーニングとヘルプ・デスクのコストや保守コストなどがあります。質的な証拠としては、第三者の製品評価者からの証明書や批評などがあります。

再度述べるならば、測定データや証明書類として何を選択するかは、UCDによって達成したいと思う目標によって大きく違ってきます。たとえば、UCDによってトレーニング・コストの削減を望む場合は、UCDを使って設計し直す前と設計変更後のトレーニング・コストを比較します。

有効性の意義を証明することの難しさは、目標の達成と UCDの成果 とのつながりの中にあります。IBMの経験によれば、UCDの成果をたった 1つ挙げるだけでは、UCDの有効性の証拠として十分ではありません。むしろ、何が効果的と思われるかというと、UCDが組織に浸透するにつれて、ユーザーの要望やニーズへの対応という点に関して製品の全体的な質が向上することを示すことです。このためには、UCDプロセスが活発化するために要する時間と、UCDの作業とその成果とを注意深く追いかけることが必要です。

UCDの基本方針の設定

UCDの基本方針とは、UCDプロセスの骨子を簡潔に規定し、これを伝えるものです。基本方針の数は、覚えやすいように5つか 6つに限定します。基本方針の良い例を以下に示します。