テキスト

仕様書の意味

今回、皆さんに使っていただく雛型は講師(北村)が実際に、eラーニングや研修を受注する際、発注する際の両方で使っていたものです。講師のかつての勤務先は東京海上日動グループ内の各社から研修を受注する教育サービス事業者としての立場とグループ外に発注する際の発注窓口としての立場の両方を持ち、講師もその両方の立場で仕事をしていました。

前者の立場での受注時には、クライアントとの打ち合わせは、この仕様書を埋めながら行っていきました。そして、仕様書を抜粋してクライアントに提示し、打ち合わせや修正の上承認を得、発注書の添付書類として提出しました。

一方、後者の立場での発注時にも、この仕様書をある程度埋めて、パートナーであるeラーニングベンダーや教育サービス事業者との打ち合わせに臨んでいました。つまりいわゆるRFP(Request For Proposal 提案依頼書)としても使っていました。

普通はeラーニングや研修のRFPをユーザは書けないものです(受講者の皆さんがユーザ側であれば話は別ですが・・)。自分達に何が必要か、与件が何かをユーザは明らかにできないことが殆どだからです。従って、提案する受注側から「やりたいことはこういうことではありませんか?」「こういった制約があるのではありませんか?」と示し、確認し、最終的に承認し共有していくことが大事です。実務上は、受注側・相談を受けた側としては仕様書の項目を埋めながら、顧客にインタビューし、顧客のニーズや与件、案件の問題点やリスク(費用の超過、スケジュール遅れなどの可能性)を顧客と一緒に明らかにしていくことになります。

このように「仕様書」は、単に仕様を整理しまとめるだけではなく、ニーズや与件、リスクを明確にするためにも重要な役割を担っていると考えた方が良いでしょう。

出口・入口・評価を大切に

雛型には各項目のワンポイントアドバイスも書いてありますので、参照しながら記載していってください。ここではeラーニングや研修の受発注時にもっとも重要なポイントについて解説します。それは「出口・入口・評価」です。

既にインストラクショナル・デザイン I やeラーニング概論で学んだとおり、これらはデザインをする上でもっとも重要です。同時に、eラーニングや教育をビジネスとして行っていく上でも、極めて重要かつ注意を払う必要があります。

一般に顧客は教育活動により高い期待を抱きます。極端に言うと、「社内のすべての問題はこのeラーニングですべて解決する」「すべての社員がこの研修ですばらしい成果が挙げられるようになる」とさえ考える可能性(危険性)があると考えておいた方が良いでしょう。もちろん、そういったものが提供できれば良いのですが、現実には不可能なケースが殆どのはずです。

そこで「提案するのは、このような条件下で(このような対象者が)、ここまでを達成できる研修やeラーニングです」といったように、何をもって成功とするかを決め、責任を明確にしておく(限定しておく)ことが、ビジネス上重要になります。

出口(学習目標)に関しては「~が出来るようになれば良いですね」という確認と、顧客の問題解決や課題達成が出口とイコールで無い場合には、研修やeラーニングの後で顧客が何をしなくてはならないかを明確にしておく必要があるでしょう。

入口(対象者)に関しては、受講に必要とする前提知識や職務経験などを明確にしておき、それらを満たさない人が受講しないようにどのような手段を講じるか、満たさない人が受講してしまった場合にどう対処するか(ドロップアウトを容認する等)を決めておく必要があります。

評価に関しては、何をもってその研修やeラーニングを成功(あるいは完了)とするか、評価の方法と基準を定めておく必要があります(例えば、事後テストの点数、研修中の実習の完了等)。

これらの項目を決めておくのは、研修やeラーニングの完了時に、提供側として自らの責任を果たしたことを示し、問題解決や課題達成が成し遂げられた場合の寄与や貢献、あるいは成し遂げられない場合の原因(が自分達に無いこと)を明らかにする必要があるからです。このことによって、ビジネスに継続性が生まれます。これらに曖昧さがあると、最悪の場合、顧客からの苦情やトラブルに発展してしまいかねません。

従って、ビジネスの上においても、出口・入口・評価を顧客との間でしっかり定めておくことが極めて重要と言えます。経験的にはこの部分のすりあわせで打ち合わせ全体の30~50%の時間や労力を割くことになります。

仕様書は進化する

前述の通り、今回皆さんに使っていただく雛型は講師(北村)が実際に使っているものです。しかし、これがベストとは限りません。通常はここまで詳細なものは求められないと思われます。そして、講師自身、eラーニングや研修の受注や開発をするたびに、雛型に変更を加えています。

みなさんなりの項目や書き方もあるかと思います。今回の雛型を踏まえつつ、ご自分なりに仕様書フォームを進化させていってください。

なお、今回は一応雛型の項目を埋めつつ、さらに必要と考える項目を加えるにとどめ、項目の削除はまた別の機会にお願いします。

サンプルケースについて

サンプルケースについての仕様書の例(見本)を以下に示します。項目数が多いと感じられるかもしれませんが、実際にeラーニングや研修を企画し・デザインする際にはこのような項目について考慮していきます。記述のしかたの参考にしてください。
なお、「見本」であって「手本」ではありませんので、記述されている内容については批判的な視点で見てください。

第10回 コース仕様書(PDF:265KB)

【コラム】「RFPの書き方・使い方」

前述の通り、ユーザにとってRFPを書くのは難しいものです。ユーザはそれほど多くの発注をする訳ではないので、RFPを書き慣れていません。従って、どのような様式で、どのような項目について考えてゆけばよいかも分からないのが実際のところです。

ユーザ側のRFPの書き方・使い方がかいま見ることができるWeb上のコラムを見つけました。講師(北村)もユーザの立場として「確かに悩ましい問題だな・・・」と頷きながら読みました。皆さんはどう思われますか?

異論・反論「RFPの作り方」:ITpro
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050422/159946/

最終更新日時: 2021年 11月 5日(金曜日) 16:44