DevRelの活動の一つにハンズオンがあります。なかなか機会がなかったり、そもそも普段の業務では触ることのない技術に対して、ハンズオンはそれを体験できる良い機会になります。サービス提供側としてはファーストタッチを得られ、さらに使ってみたことで感じた問題点や課題をフィードバックしてもらえるというメリットがあります。
そうしたハンズオンで問題になるのがレベル設定です。目的によると思いますが、幾つかに分けて考えることができると思います。
技術に関してまったく知らない方も対象にする場合、最悪プログラミング言語を知らない方まで来る可能性があります。そうした場合、そもそもサービスを体験してもらうところまで辿り着けないこともあります。
この場合、コピペだけで動くレベルまで資料をあらかじめ作っておく必要があるでしょう。例えばコードはキーを変えるだけで終わりで、後は管理画面だけの作業で終わるといった具合です。
この時の目的としてはファーストタッチの獲得だけになります。フィードバックがあったとしても、管理画面くらいだけでしょう。もし、この時点で「簡単に動きますね」といった感想がもらえたとしても、それはコードがあらかじめ書いてあるからに過ぎません。
プログラマーを対象にする場合、注意するのはスキルレベルがバラバラであると言うことです。プログラマと言っても対象のプログラミング言語に精通しているとは限りません。そしてスクール形式でみんな揃って作業をスライドを見ながら進めてもらう方法で行うと、必ずずれが生じます。
慣れている人はどんどん進められるのですが、不慣れな人が遅れてしまいます。スクール形式では一番遅れている人に合わせて進めていきますので、結果として熟練の人(DevRel的にはこういう人に積極的に使って欲しいと思うものでしょう)の不満が残ってしまいます。
また、利用技術が多岐に渡ると効率が落ちます。自社サービス、何らかのフレームワーク、プログラミング言語、UIライブラリなど含めると途端に敷居が上がります。特にWeb系のハンズオンではUIライブラリが必要になるものですが、その選定は慎重に行う必要があります。
この場合、ハンズオンの目的は「体験」に据え置くのが良さそうです。コードは殆ど書く必要はなく、2〜3行のコードだけ書いたら動くくらいに留めておくべきです。UIライブラリなどもあらかじめ組み込んでおき、参加者の手を煩わせる(そして大抵トラブる)のは避けましょう。
すでに自社サービスを使っている方々をターゲットにしたハンズオンの場合、目的はより深く自社サービスを使ってもらったり、新機能を体験してもらうことになります。前提知識の敷居は低くて済みますが、資料をきちんと作り込んでおかないと満足度が低くなりがちです。
そして広く浅い目的ではなく、狭く深い(特定の)目的にターゲットを定めます。この場合、目的は利用者増、フィードバックがメインになっていくと思われます。コードを書く範囲は広くても構いませんが、外部ライブラリ部分はあらかじめ書いておいた方が良いでしょう。
最後にオマケ的なコンテンツで応用編をつけておくと喜ばれます。応用編は自分で考えながら書く部分で、資料ではあまり深掘りする必要はありません。
ハンズオンの参加者は実に千差万別です。全員満足するコンテンツを作成するのは大変でしょう。個人的にはテキスト形式を採用しています。だいたい3〜4つくらいのコンテンツに分けておき、どこで終わってもそれなりに満足できるようにしています。その上で個人の作業はテキストをみながら進めてもらい、分からないところがあればヘルプする方式です。これであれば作業スピードは自分なりで良くなるので、早い人もそうでない人も満足できます。
ちなみにテキストとしては、例えば以下があります。
どちらもMIT Licenseとして公開しているので参考にしたり、フォークしても問題ありません。
メールにてDevRelに関するニュース、アップデートをお送りします。
Contact is below.