昨日まで聴講期間だった。
ひたすら議事録を取り続けた。
振り返り
- 細かな操作を見せるよりも，どのような選択肢，パラメータがあって，どう組み合わせるかを伝えることが大切。
- 流暢な解説よりも，質問に対して「結論」＋「公式ドキュメントやデモ」を提示できるかが大切。
ということがよくわかった。聴講したのが中級講座ということもあって，受講者もそれなりに「この講座はド素人向けではない」ことは承知している。なので，細かな操作はあとでやってもらうとして，全体として何ができるようになるかを意識してもらうことが何よりも求められる。
また，丁寧な解説を目指すと準備に時間がかかる。準備に時間をかけていると最新serviceの仕様とずれ始める。なので，最初の解説はざっくりでよく，質問が来たら簡単な結論に加えて「公式ドキュメントのここをご参照ください」の方が受講者にとっては都合がよい。ドキュメントを後で調べればよいからだ。聴講中も，自分で疑問に思ったことに対して「これはあとで調べればいい」と思うことが何度もあった。受講者としては「どこを調べればいいですか」くらいは聞くべきだが，私は講師準備をしているので，ある程度は自分で調べる能力を付けなければならない。結論，というのは，AWSの性質上，「〇〇はできますか」という質問が多いので「できる，できない」を先に言うこと。「どうやって?」には，サービス名の組合せをまず答える。パラメータの注意は後で良い，ということだ。
あとちょっと面白かったのが，カメラOff，音声Offで終始すすみ，反応はWebexのリアクション，質問はチャットだったこと。まるっきりYoutuberのノリだった。「リアクションありがとうございまーす」という講師の発言が新鮮だった。反応のパターンはいくつかあらかじめ提示しておくと良いかもしれない。
- 開始終了挨拶
- 準備完了
あたりは「OK」だけでよいと思う。Webexは「挙手」を固定したり，講師側で一括Offにできるようで便利。
- 頷き
- 疑問
個人的にはこの感情表現を事前に提示したほうがよいと思う。受講者からの表情反応がないので，話していて不安になってくる。
質疑応答にチャットを使うのは良し悪しがある。文章として残るのだが，どうしても「読んでしまう」。技術的な質問は長くなるので，読込みに時間がかかる。加えて文章力の差が大きく出てくる。受講者は，対象技術に詳しくないので，特に「主語が抜ける」。聴講中，受講者が何のことを質問しているのか分からない文章を書きこんでいることが何度もあった。
チャットの書込みはタイムラグがあるので「あー，ちょっと文章がまずかったな」と思ったときに再度書き込むと，さらに混乱を招きそうなのも気になった。
