eラーニングのデザイナーや開発者に、自分の役割で最も困難な部分について話し合うよう依頼すると、コースレビューアー（SME）とフィードバックについての話題を持ち出す可能性が高いでしょう。混乱させ、矛盾させるレビュアーから、最後の瞬間まで重要な情報を持って現れなかった人まで、フィードバックプロセス（そして時にはレビュアーたち！）を管理することは大きな挑戦となる可能性があります。
ArticulateヒーローTracy Parishは、この課題のアイデアのためのE-ラーニングヒーローズコミュニティに加わり、組織のレビュープロセスを合理化することができる方法についての提案を探していました。以下は、レビュープロセスを苦痛よりも肯定的にするためのコミュニティのプロのヒントのいくつかの要約です。
ヒント1：前もって役割と責任を明確にする
eラーニングデザイナーや開発者は、自分たちだけでは調整しきれないフィードバックの嵐を理解しようと、しばしば中途半端な状態に陥りがちです。
このような状況に陥らないための最善の方法の一つは、プロジェクトのキックオフミーティングを行い、プロジェクトチームのすべての役割と責任を明確に定義することです。このミーティングでは、意思決定者は誰か、矛盾するフィードバックの収集と調整に責任を持つのは誰かを明確にします。
Holly MacDonaldは、このような役割と責任を前もって明確にするための提案とツールを提供しています。
『あるクライアントがいて、その人たちがコンテンツに責任を持つ場合、RACIチャートはどうでしょう？プロジェクトの初期段階において、「もし...だったらどうするか」という議論の枠組みを作るのに役立つと思います。』
前もって時間をかけて役割と責任を明確にしておくことで、意思決定のための明確なエスカレーションパスをもって、レビュアー間の会話を促進することができるようになります。
ヒント2：レビュアーを教育する
レビュープロセスについて話す時、どのスプレッドシートを使うか、何月何日までにフィードバックを得るかなど、仕組みにばかり目が行きがちで、何をすべきか、つまりプロセスの各段階でどのようなフィードバックを求めているかを見失いがちです。
「修正」と「変更」
フィードバックの種類に関して言えば、設計の「変更」（往々にして好み）と設計の「修正」に関するフィードバックの違い、そしてこの違いがプロジェクトのさまざまな段階で優先順位に与える影響の違いについて、人々は混乱しています。
「修正」と「変更」の違いを明確にするために、筆者が使っている例を挙げます。
この例はシンプルで親しみやすく、全員がこの用語に同意することで、様々なタイプのフィードバックやマイルストーンにどのように対処するかという話に移ることができるのです。
Holly MacDonaldは、この点を見事に要約しています。
『修正と変更を分類し、開発段階の初期には全面的な「変更」があっても良いが、それ以降は洗練するための「修正」を求めていることを理解させてください。レビューには種類があることを明確に説明します。フィードバックのカテゴリーをまとめた表を作成するのもよいでしょう。』
コストと価値の比較
レビュアーがプロジェクトの優先順位を理解するために必要なのは、ちょっとした教育だけである場合もあれば、もう一歩踏み込む必要がある場合もあります。レビュアーが、プロジェクトの成功を脅かすような一線を引いた場合、会話をやり直す必要があるかもしれません。例えば『これらの要件「変更」にはxxxドルの費用がかかります』というように、変更に金額をつけることで、レビュアーにコストと価値の現実を少し確認させるという提案が、コミュニティのメンバーからなされています。このようなリアリティを提示することで、収益に影響を実際に与える前に、その変更の影響を全員がより明確に理解することができるのです。
ヒント3：レビュープロセスをより透明にする
※下記の例の当時は、Articulate360のReview360がありませんでした。
トレイシーの大きな悩みの種は、多忙な複数のレビュアーが延々と互いに矛盾したことを言い続けることでした。このようなやりとりにイライラしないようにするために、コミュニティのメンバーの中には、全員を集めて面と向かってレビューすることが最善だと考える人もいます。たとえば、Mohammad Hassamは、全員を集めて直接会ってプロジェクトをレビューするのが一番だと考えています。
『一度に全員を集めてミーティングを開きます。クライアント、レビュアー、SMEを招待し、コースをレビューするのです。なぜなら、グラフィックやレイアウトを除いて、内容、素材、資料に関して誰かが意見を言えば、隣に座っているもう一人の人がおそらく反対するからです。そのような会話は、ある基本ルールができるまで続きます。議論されていることと、相手のコメント（相手の名前も書いておく）をリストアップして、ミーティング後にメールでコピーを送ります。』
他のコミュニティのメンバーは、大規模な対面式のレビューミーティングは必ずしも現実的ではないと感じたようです。その代わりに、設計・開発・レビューのプロセス全体をより可視化するために、テクノロジーを利用した経験を話してくれました。コミュニティメンバーの中には、reviewmyelearning.comというツールを使って、リリースとレビューのサイクルをサポートしている人もいます。Karlis Sprogis氏のように、Googleドキュメント、Dropbox、Trello、Join.me、Invisionappなどの無料または低コストのツールを組み合わせて使用している人もいます。
Jane Manduke氏は、使用するツールとともに、次のような包括的なプロセスを提供しています。
『Wordpressのウェブサイトにページを作成し、コースをアップロードします。そのページは、メニューやタグクラウドなどからは見えないようにしています。
すべてのレビュアーにリンクを送ります。通常、契約書にクライアント側の担当者を1人決めておき、その担当者がチームにリンクを送ります。リンクを送る際、そのWordpressのページにコメントを投稿するよう依頼します。(コメントを投稿することに抵抗がある人もいますし、時間がない人もいます。しかし、この方法で良い会話をすることができました。）
レビュアーには、プロトタイプやビルドバージョンを1〜2日見てもらい、「統合レビュー」の日時を決めます。
統合レビューは、ウェブ会議・画面共有ツールのJoin.meを使って、私の方から遠隔操作で行います。チームメンバーや関係者全員を招待します。eラーニングの内容を順を追って説明します。フィードバックは通話で収集します。』
プロセスを可視化することで、eラーニングの作成に何が必要かを示し、レビュアーに冗長なコメントや矛盾するコメントを見つけるためのツールと情報を提供し、それらがあなたのto doリストに届く前に、細かい点を議論する専門家によって対処することができます。
まとめ
フィードバックプロセスは、基本的にプロジェクトマネジメントの課題です。プロジェクト管理は、eラーニングデザイナー/開発者の多くの職務の1つであり、他のすべての課題と同様に、準備と十分な練習があれば、最善の方法となります。
プロジェクトマネージャーのように考えましょう。コース開発に取りかかる前に、プロジェクトチームの役割と責任を明確にするための時間を計画しましょう。責任の所在が明確でない場合、つい「プロセス」を考えてしまいがちですが、そうすると、かえって仕事が煩雑になります。その代わりに、まずは期待値を設定し、全員が同じ考えを持つようにするために、よく話し合うことから始めてみてください。
コンサルタントのように振舞う。コンサルタントは、常にクライアントを教育しています。レビュアーを教育するために、デザインと開発の各フェーズを説明する簡単な資料（1ページ）やインフォグラフィックを作成し、各フェーズでどのようなフィードバックを求めているのか、そして誰からフィードバックを求めるのかを説明しましょう。
より透明性を高めるためのツールを追加する。最低でも、レビューのフィードバックを収集し、アクションアイテムを追跡するための共有リソースを検討します。
株式会社ディーシェは日本におけるArticulate製品の販売代理店です