...

How do you attain interactivity

by user

on
Category: Documents
6

views

Report

Comments

Transcript

How do you attain interactivity
e-Learning Forum Winter2004 トラック D「発注者のためのeラーニング要求仕様の作り方と導入マネジメント」
セッション1「有能なベンダーを選ぶための e ラーニング要求仕様の書き方」
1
・約 8 割の企業がシステム開発をベンダに依頼、その満足度は25%と高くない
・ユーザー企業側が RFP をほとんど作成しているのは、全体の 16%
システム開発における、システムベンダへの仕事の依頼があるかどうか質問を行ったところ、78%の企業がシス
テムベンダと何らかの取引があることがわかった。仕事を依頼しているベンダの数は 1 社だけが、30%で、残りの
70%は 2 社以上の複数の会社に依頼しており、6 社以上に依頼している企業も7%存在する。
その満足度をみてみると、残念ながら、満足していると回答した企業は全体の 25%のみで、残りの 75%は、全く
不満の 6%を加えて、何らかの不満を抱いている。前年度は、調査文言が「概ね満足」「一部不満」「全く不満」という
今年度と少し違う聞き方をしているので、比較が難しいが、概ね満足している企業は、全体の 40%あったことを見れ
ば、厳しい数字と言うことができる。
次に、システム開発における要求仕様書(RFP)についてその状況を率直に聞いてみたところ、ユーザー企業で
RFP のほとんどを作っているところは、全体の 16%しかなく、従業員が 1000 人以上の大企業でも 22%しかないこと
がわかった。
さらに、「システムベンダへの満足度」別に、要求仕様書(RFP)における役割分担を見てみたところ、「全く不満」と
回答している企業では、ユーザー企業で RFP のほとんどを作っている企業が 5%しかなく、ユーザーはラフ案のみと
いう企業が 54%、全てベンダにまかせている企業が 16%と、ベンダ任せの傾向が顕著である。この結果より、仕様決
定におけるユーザー企業のコミットは、満足のいく結果を得るために、非常に重要であると言えるだろう。
図表 システム開発におけるベンダへの仕事の依頼
図表 システムベンダの満足度
図表 要求仕様書(RFP)における役割分担
図表 システムベンダへの満足度別要求仕様書(RFP)における役割分担
出典:社団法人日本情報システム・ユーザー協会ホームページ 「企業 IT 動向調査2004」(2003 年実施)
記者発表内容 URL:http://www.juas.or.jp/project/survey/it04/press4.html
©2004 Junko Nemoto, Shirou Kitamura & Katsuaki Suzuki, Ph.D
e-Learning Forum Winter2004 トラック D「発注者のためのeラーニング要求仕様の作り方と導入マネジメント」
セッション1「有能なベンダーを選ぶための e ラーニング要求仕様の書き方」
2
メッセージ
□ 抑えるところを抑えて、残りはベンダーに任せられるまでの力を、まずはつけよう!
□ フツーのユーザーは RFP を書けない? RFP はコンサルに書いてもらうのがよい?
―であれば コンサル力を身につけよ。
□ ユーザーにどんなソリューションが欲しいかを聞いてくるベンダーとは付き合うな。
―どんな問題を解決したいかを聞いてくれて、複数のソリューションを提案してくれるベンダーと付き
合うのが、自分にとっても会社にとってもハッピーだ。
□ ユーザーは技術面に口を出すな。
―「今回の案件では、今うちで使っている○○システムを使ってください。」これでは、自分でソリュ
ーションを限定している。
評価
分析
コンサル
企業
設計
RFP
ユーザー
企業
分析
分析
プロ
ポーザ
評価
設計
実施
ベンダー
企業
開発
契約書
プロト
タイプ
設計
評価
開発
実施
納品・
納品書
自社
開発
経験
ユーザ
サポート
各プロセスでの
アウトプット
自社利
用によ
るユー
ザ経験
テスト
ベッド
プロセスの流れ
企業間のやり取り
©2004 Junko Nemoto, Shirou Kitamura & Katsuaki Suzuki, Ph.D
e-Learning Forum Winter2004 トラック D「発注者のためのeラーニング要求仕様の作り方と導入マネジメント」
セッション1「有能なベンダーを選ぶための e ラーニング要求仕様の書き方」
3
参考資料1
RFP を利用する場合の条件
†
†
†
†
†
†
†
†
ニーズに合うソリューションが複数ある。
同じソリューションを提供できる供給者注1が複数いる。
購買者注2は、供給者のソリューションの中から「最良のもの」を決定したいと望んでいる。
プロジェクトで使う製品を明確に指定することができない。
供給者にさまざまなスキル、専門知識、技術的能力を要求するプロジェクトである。
供給者が製品とサービスを組み合わせて請負契約を結ぶ必要がある。
最低価格が契約を決める決定基準ではない。
最終的な価格は供給者と交渉して決める。
注1
「供給者」という用語は、装置、ハードウェア、ソフトウェア、サービス、その他なんであれ購入しようとしている
もののベンダーの意味で利用する。 注2 「購買者」は、RFPを書く企業または政府機関を指す。
出典:Bud Porter-Roth(2004)『RFP 入門
はじめての提案依頼書』日経 BP プレス 第 1 章
p.1
参考資料2
RFP の構造分析:基本的な RFP は大まかに言って、次の文章から構成される。
1. 事務要求の章
要求のエグゼクティブサマリー(形成軍向けの要約)と同様に、課題の概要または要約を記述する。
そして、RFP に関する事務的な情報を記述する。
2. 技術要求の章
技術的な要求を記述し、供給者が問題を理解してしっかりした提案を書けるだけの情報を影響する。
3. 管理要求の章
プロジェクトを実行し管理するための条件を記述する。
4. 供給者の参加資格と照会先の章
供給者の参加資格について説明し、自社の資格と照会先を記載するように供給者に依頼する。
5. 供給者の章
RFP では求められていなくても、供給者が関連すると思う情報を入れるように勧める。
6. 価格の章
供給者が提案の中でどうやって価格情報を伝えればいいかを説明する。
7. 契約書とライセンス契約の章
購入契約、機密保持契約、その他法律関係の文書を入れる。
8. 付録
ネットワーク図や技術要求の検討の結果、プロジェクト計画の概要など、量の多い関連情報を入れる。
―――――――――――――――――――――――――――――――――――――――――――――
出典:Bud Porter-Roth(2004)『RFP 入門 はじめての提案依頼書』日経 BP プレス 第 1 章 p.18
©2004 Junko Nemoto, Shirou Kitamura & Katsuaki Suzuki, Ph.D
e-Learning Forum Winter2004 トラック D「発注者のためのeラーニング要求仕様の作り方と導入マネジメント」
セッション1「有能なベンダーを選ぶための e ラーニング要求仕様の書き方」
4
参考資料3
技術要求−優れた要求の特性
「要求は、実際の製品やソリューションを反映していなければならず、あいまいであってはならず、意
味を持たなければならず、完全でなければならない。そして、ソリューションも不必要な特性も含んで
はならない。
」
1.要求は実際の製品やソリューションを反映していなければならない
要求は達成可能でなければなりません。つまり既成の製品であれ、注文製品であれ、供給者は要
求中にあるものを購入したり、統合したり、作成したりできなければなりません。
教訓:
「RFP チームが実現可能な要求を書くためには、既存の製品やサービスについての知識を持
たなければならない」
2.要求はあいまいであってはならない
「技術要求」の章 「あいまいな要求」の例
提供されるハードウェアコンポーネントのいずれにおいても、雑音レベルが 70dB を超えてはならない。
具体的な測定値(70dB)を提供していますが、その測定がどうやってなされるかについての記述
がありません。
「技術要求」の章 「あいまいでない要求」の例
提供されるハードウェアコンポーネントのいずれにおいても、計器を机上の高さ(30 インチ)に置き、
5 フィートの距離から標準デシベルメーターで測定したときの雑音レベルが 70dB を超えてはならない。
3.要求に主観的な言葉を用いてはならない
「技術要求」の章 「主観的な要求」の例
■供給者は、適切なユーザ教育を提供しなければならない。
■アプリケーションレベルのソフトウェアの機能は、直接的に明らかで、ユーザー教育を必要としないも
のでなければならない。
最初の分の「適切な」という言葉を供給者はどう定義し、購買者はどう測定するのでしょうか。
「技術要求」の章 「主観的な要求」の例
供給者は適切なリソースを持ち、このプロジェクトの開始から完了まで続けるために必要な資金確保が
できるだけの財務的安定性がなければならない。
「適切なリソース」、「必要な資金確保」、「できるだけの財務的安定性」はどう測定するのでしょ
う。
©2004 Junko Nemoto, Shirou Kitamura & Katsuaki Suzuki, Ph.D
e-Learning Forum Winter2004 トラック D「発注者のためのeラーニング要求仕様の作り方と導入マネジメント」
セッション1「有能なベンダーを選ぶための e ラーニング要求仕様の書き方」
5
4.要求は測定でなければいけない
「技術要求」の章 「測定可能ではない要求」の例
応答時間は次のように測定すべきです。
「1,000 人のユーザーがログインし活発にシステムを使用している状態で、サーバーにリクエストしてから
ファイルを受け取るまでの遅延時間は、Enter キーを押してからファイルが画面に表示されるまでの時間
で測定して、1秒を超えてはいけない」
「活発にシステムを使用している」とは何を意味するのでしょうか。鋭い供給者は、このような
詳細をやかましく要求し続けるので、購買者は「RFP は書いては直し」を続けなければなりませ
ん。
5.要求は意味を持たなければならない
「技術要求」の章 「意味を持たない要求」の例
提供されるハードウェアコンポーネントのいずれにおいても、雑音レベルが 70dB を超えてはならない。
この雑音レベル要求は、実際にはデータシートからコピーされたものであって、RFP チームの誰
が求めたものでもなく、実際に機器の測定をすることもない、ということも考えられます。この
ままではテストと遮音のために供給者が追加費用を上乗せする原因となるかも知れません。
6.要求は完全でなければならない
「技術要求」の章 「不完全な要求」の例
供給者は、初期の開発で大量データをインポートする取り組みを記述しなければならない。
「大量データ」とは何を意味するのでしょうか。また、「取り組み」や「大量」といった言葉は、
そもそも主観的でこの要求を無意味なものにしてしまいます。
7.要求はソリューションを含んではならない
「100 テラバイトを光ディスクに格納できること」と要求を言葉にすると、それはソリューショ
ンを提供していることであり、結局のところ、供給者の提案を制限するばかりか供給者の数も制
限することになります。
8.要求は不完全な特性を含んではならない
要求の書き方がまずいと、供給者が RFP を読むのに余分な時間がかかります
要求の書き方がまずいと、供給者と付き合い続けるのが難しくなるという問題も出てきます
要求の書き方がまずいと、その結果は必然的に供給者の提案に現れてきます
出典:Bud Porter-Roth(2004)『RFP 入門
はじめての提案依頼書』日経 BP プレス 第 1 章
©2004 Junko Nemoto, Shirou Kitamura & Katsuaki Suzuki, Ph.D
p.120-
e-Learning Forum Winter2004 トラック D「発注者のためのeラーニング要求仕様の作り方と導入マネジメント」
セッション1「有能なベンダーを選ぶための e ラーニング要求仕様の書き方」
6
参考資料4
■e-ラーニング・コンサルタントのコンピテンシー(CeLP)
□e-ラーニング・コンサルタントの性質,要素およびプロセス(過程)を説明する
コンサルタントの役割を定義する
内部および外部のコンサルタントの長所および欠点の一覧を作る
それぞれの例を伴うコンサルタント・スキル(技能)の要素の一覧を作る
トレーナーとコンサルタントの移り変わりの関係を説明できる
クライアントを中心においたコンサルタント(client centered consultancy)の性質の一覧を作る
―評価手段:オンラインのテストおよび演習
□コンサルタント・プロセスを説明する
コンサルタント・プロセスの段階の一覧を作る
プロジェクトの初期からコンサルタント実施までのレベルを明らかにする
成功するコンサルタントのルールの一覧を作る
―評価手段:オンラインのテストおよび演習
□参加者(entry)を獲得し、目的(purpose)と結果を確立する
クライアントを定義する
クライアントを明らかにするためのルールを説明する
いかにプロジェクトの参加者(entry)を獲得するかを説明する
―評価手段:オンラインのテストおよび演習
□効果的な企画書を書く
契約プロセスの段階の一覧を作成する
個人としてあるいはチームとして企画書を提示するための基準を明らかにする
交渉のモデルを説明する
―評価手段:オンラインのテストおよび演習 ― 事例または自身のプロジェクトについての提案書を書く
□系統立てられたe-ラーニング戦略を準備する
e-ラーニング導入を指揮するものとして,危険性と可能性を分析する。
目的を達成するために,ほかの選択肢を見直す。その選択肢には,e-ラーニングと伝統的な手法との異なる
組合せも含まれる。
その選択肢を列挙すると:
・課題,技能,あるいはコンピテンシーを提示
・e-ラーニングの対象者
・解決策(ソリューション)としての e-ラーニング本質とスタイル
・e ラーニングが伝統的な学習法とどのように組み合わせるか
・その解決策を支援するためのハードウェアおよびソフトウェアのインフラ(基盤)
・e-ラーニングの内容がどのような資産となるか
役割,期限,責任およびコストを含む実行計画を策定する。
―評価手段:学習者は自身の組織のための e-ラーニング戦略を提出する
©2004 Junko Nemoto, Shirou Kitamura & Katsuaki Suzuki, Ph.D
e-Learning Forum Winter2004 トラック D「発注者のためのeラーニング要求仕様の作り方と導入マネジメント」
セッション1「有能なベンダーを選ぶための e ラーニング要求仕様の書き方」
7
□e-ラーニング戦略を支援する技術基盤を確立する
バンド幅,セキュリティーおよび配信するプラットフォームの性能を含む組織的なネットワークの改善の
必要性を決定する。
学習管理ソフトウェアに必要な要件を決定し,適当なシステムと供給元を選定する。
協調ソフトウェア・ツール(疑似教室など)に必要な要件を決定し,適切なシステムと供給元を選定する。
コンテンツ開発おおびコンテンツ管理ソフトウェに必要な要件を決定し,適切なシステムと供給元を選定
する。
技術専門家と共に,新たに導入されたハードウェアとソフトウェアの設置と試験の監督をする。
―評価手段:学習者は,彼らの組織に必要とされる技術基盤の分析し提出する。
□e-ラーニング・コンテンツの制作および習得過程を確立する
必要とされる e-ラーニング・コンテンツの情報源となるための最適な手法,あるいは手法の組合せ(既製
品の購入,自製品,外注,1対1など)を決定する。
既製品あるいは外注を利用する場合,最適な供給元を選定し,契約交渉を行う。
自製品を開発する場合は,必要とされる専門技術,経験の有る人員の登用や,すでに雇っている職員の訓
練などを検討する。
―評価手段:学習者は,彼らの組織のために提案されたコンテンツ制作過程の分析を提出する
□e-ラーニングを成功に導くために組織の方針と慣行を策定する
全てのステークホルダー(管理職,学習専門家,IT スタッフ,エンド・ユーザなど)に e-ラーニング実施
計画に参加することを奨励する。
それぞれのステークホルダーにとって e-ラーニング導入による利益になることを保証する。
実施に移す前にテスト(test)および試験(pilot)を実施しソリューション(解決策)の質を高める。
導入前後に e-ラーニングのマーケットと促進を行う。
―評価手段:学習者は,彼らの組織のための実行方針と慣行の分析を提出する。
□e-ラーニング戦略の効果を見直し,適当に改訂する
(一定の手順(報告の慣行,ドロップアウトおよび終了者の分析,反応調査,など)を確立することで,
e-ラーニング戦略の進捗を検査することができる。
e-ラーニング戦略の弱点を特定し,適当に改訂する。
―評価手段:学習者は,彼らの組織に必要とされる検査課程を分析し提出する。
□業務分析を実施する
実行されるべき業務をおよび,それに付随する業務や要素を特定する。
効果的かつ効率的に業務を完了させるための知識,技能,態度およびコンピテンシーを特定する。
―評価手段:サンプル・プロジェクトの業務分析を提出する。
□学習ニーズ分析の実施
対象者(数)を特定する。
対象者が,効果的かつ効率的に業務を遂行するために必要であり,現在不足している知識,技能,態度お
よびコンピテンシーを決定する。
これら不足分の内,他の戦略を必要とする学習形態によって取り組むべき内容について分類する。
その不足している知識,技能,態度およびコンピテンシーを補う企画を,測定可能な学習目標を含む形で
準備する。
―評価手段:サンプル・プロジェクトの学習ニーズ分析を提出する。
©2004 Junko Nemoto, Shirou Kitamura & Katsuaki Suzuki, Ph.D
e-Learning Forum Winter2004 トラック D「発注者のためのeラーニング要求仕様の作り方と導入マネジメント」
セッション1「有能なベンダーを選ぶための e ラーニング要求仕様の書き方」
8
□適当な学習メディアを選択する
メディアの選択決定に必要な状況を分析する,例えば:
・課題の本質および必要とされる学習内容
・対象者の数,性向
・資源(リソース)の入手可能性
効果的かつ効率的な解決策を提供するための最適なメディア,またはメディアの組合せを選択する。
メディアの選択において,メディア固有の性質を考慮し,その性質が解決策の効果と効率にインパクトを
与えるかどうかを考慮する。
―評価手段:学習者は,サンプル・プロジェクトのメディア選択の分析結果を提出する。
□学習を仲介(learning intervention)するビジネス事例を準備する
プロジェクトを実施するに当たり,直接あるいは間接的に掛かる費用を予測する。
学習を仲介することで期待される利益(コストや人件費の節約,生産性向上,増収)を予測する。
コストと利益の予測を提供し,問題がある場合,そして,投資を取り戻す必要がある場合に投資効果(return
on investment)を算出する。
他の学習メディア(またはメディアの組合せ)との相対的な収益を説明する必要があるときに,それぞれ
のメディア,またはメディアの組合せについて,比較できる ROI 分析を準備する。
―評価手段:学習者は,サンプル・プロジェクトについて ROI 分析を提出する。
□同意に至った解決策を実施する
クライアントと学習者の信頼関係を築く
適当な学習を仲介(learning intervention)するスタイルを用いる
対面あるいはビデオ会議において適当なボディー・ランゲージを用いる
□管理手法の変化
(管理手法の)変化を起こさせる代理人としてのコンサルタントの役割を説明する
組織的変化のタイプの一覧を作る
個人の変化モデルの段階を明らかにする
変化のための総合品質管理(TQM)戦略を説明する
―評価手段:事例研究プロジェクトを提出する、オンライン・テスト
□プロジェクトの評価と解約
プロジェクトの結果(success)を評価する
プロジェクトが改善されたであろう手法を明らかにする
評価報告書を書く
解約のルールを説明する
新たなビジネスをつくり出す戦略を実施する
―評価手段:プロジェクト・ワーク
―――――――――
出典:e-Learning Professional Competency Framework (2004) The Institute of IT Training. http://www.training
foundation.com/tfimages/ftp/IITT%20e-Learning%20Professional%20Frameworks%202004%20V1.pdf
p.4-6 コンサル
タントコンピテンシーを徳村朝昭が訳出した。
©2004 Junko Nemoto, Shirou Kitamura & Katsuaki Suzuki, Ph.D
Fly UP