こんにちは。Kaneyasuです。
（まだ年末じゃないけど）今年は複数回ウェビナーやハンズオンの講師をやらせていただきました。
今回はそこから学んだ自分的ハンズオンあるあるを書いていきます。
ハンズオンの需要について
まずハンズオンの需要について述べておきます。
ハンズオンは、基本的に主催者・参加者の方両方にウケがいいです。
表面的には、実際に手を動かすトレーニングなので得られるものがわかりやすく、参加者の満足度が高まりやすい、というのが理由ですが、もうちょっと深く考えると以下のことがあるように感じています。
- 最初の一歩を踏み出すハードルがある。モダンな技術になるほど、その傾向が強い。
- 技術のつまみ食い、独自流で覚えてしまっている人が意外と多い。
後者は多忙だったり、組織の事情でそうせざるを得ない場合もあります。
最初の一歩を踏み出し、知識を学び直すという意味で、ハンズオンは需要が高いようです。
では、次項からハンズオンあるあるを紹介していきます。
1. 過去のドキュメントが役に立たない
AWSを始めとしたクラウドサービスで、よくあります。
1年ぐらい前のドキュメントだとUIや仕様が変わっていることが多いですね。
デザインが変わるのはまだいいですが、厄介なのは設定項目が増減している場合があります。
想定外の動きをすると、進行に支障をきたすので、最悪画面ハードコピーをカットしてでも、仕様変更を追いかける方をお勧めします。
2. ドキュメントの画面ハードコピーの数がエグい
ハンズオンのドキュメントだけで全て担えるマニュアルのノリで書いてしまうとこうなります。
丁寧な故にこうなることもありますが、説明・デモの失敗リスクを避けすぎる側面もあると感じています。
これは、前述の通りツール・サービスの変更が入った場合のメンテ負荷を増加させてしまい、ハンズオンというサービスの再現性を下げてしまうことにも繋がります。
ハンズオンの意義から見ても、ドキュメントを読めばできてしまうのならば、ハンズオンをしなくてもいいのでは？とも思えます。
3. 書く人によってドキュメントの記述粒度が異なる
ハンズオンのドキュメント作成を分担するとこれが起きることがあります。
特にメイン講師とそれ以外の方で分担すると、当事者意識にどうしても差があるため、それがドキュメントにも表れてしまうわけです。
取り急ぎ言えることは、当事者意識の差は言っても変わるものではないので、メイン講師はドキュメントの粒度の差にイラつかないようにしましょう（汗）
4. 参加者ごとの環境差でトラブる
オンラインでハンズオンすると割と起きます。
ハンズオンにあたり、ある程度端末の条件を提示するのですが、社内プロキシやOSは合っているけれど実は仮想マシンやVDIです、という時があります。
環境差によるトラブルは短時間では解決しないことが多いので、これが起きたら進行優先で進めるしかないですね・・・。
これの対策のために、以前はWeb IDEのCloud9を使っていたことがありますが、新規受付が終了してしまったので、今まさに悩んでいるところです。
個人的にGitHubやGitLabのWeb IDEを検討していて、使い勝手がある程度まとめられたら記事にしたいと思っています。
本記事におけるあるあるの傾向とまとめ
4番目はともかく、1～3番目は講師としての未熟さによるあるあるかなと思います。
未熟さのカバーをドキュメントを作り込むことに求めているのがよくないのかもしれませんね。
ドキュメントで完結するならばハンズオンの意義は薄いので、再現性を意識してちょうど良い粒度のドキュメントにとどめ、講師としてのスキルアップに向き合うのが正しそうです。