ハンズオンを作るときに気をつけるポイントって何 ?

ハンズオンを作る際、まず最初に意識していることは、「考えてもらえる」ストーリーを作ることです。最近は、合計 1〜2 時間程度の動画ハンズオンを作成することが多いのですが、この 1〜2 時間で何を伝授したいかを明確にすることからハンズオン作りを始めます。この「何を伝授したいか」は、なるべく課題にフォーカスしたストーリーにするのがおすすめです。「XXX (サービス名) の使い方」といったテーマ設定でもいいのですが、「YYY を作りたい (ので XXX を使う)」「ZZZ の課題を解決するために XXX を使う」といった課題起点のストーリーにする方が、持ち帰ってもらえることが増えると考えています。

また、具体的なハンズオンの工程においても「考えてもらえる」機会を増やすことを意識しています。私自身、ハンズオンが好きでよくやるのですが、たまにその過程が「作業」になってしまい、ひと通り終わったけど内容が頭に残っていない・・・、ということがあります。脇道にそれないハンズオンは資料や手順書としては素晴らしいのですが、順調に進みすぎるとそれが「作業」になってしまうことがあると思っています。

そこで、ハンズオンを作成する際は、手順だけでなく

• なぜこの設定をするのか、この設定をしないとどのような振る舞いになるのか
• その設定をする / しないの判断ポイント

についても解説し、考え方も伝えられるように気をつけています。また、

• 敢えてエラーを発生させ、エラーメッセージを見ながら設定が足りない点を解説する
• ドキュメントを探し、それを読み、利用する機能を選定する

といったあえて遠回りな ( ? ) 進め方にすることも意識しています。これは、ハンズオンのあと、Next Step に進んだ際に、自力で進めていただく方法までお伝えできた方が、真の意味で皆さまのためになると考えているからです。

受け手によってはストレートに進むハンズオンを期待されることもあると思うのですが、オンデマンドで配信するハンズオンの場合はその場でのフォローができないため、確実に学びに繋がるストーリーにすることを優先しています。このあたりは、媒体によって合う合わないがあるかもしれません。ただ、この「あえて遠回りしてもらう」進め方は、ハンズオンをやっていただいた方からも好意的なフィードバックをいただいており、ハンズオン作成の際のひとつの手法として試してもらってもいいかなと思います。

同僚のハンズオンにコメントすることがあると書きましたが、その際は大きくふたつのポイントを意識しています。まずひとつ目は、初学者の方にとってのノイズをいかに無くすかという点です。

ハンズオンに限らず、資料作成全般に言えることですが、

• 資料に情報を詰め込みすぎていないか
• 資料は見にくくないか (改行位置、表記ゆれ、などなど)
• 説明の順番は適切か

のように資料自体が分かりにくくないか注意深く確認します。このあたりは、コンテンツ作成者以外の視点の方が気が付きやすいので、細かいところまで確認するようにしています (口うるさいと思われているかもしれない😌)。

同僚のコンテンツを見る際に、もうひとつ意識していることは「ブラックボックスを極力なくす」という点です。初学者向けのコンテンツを作る際は、特にここに気をつけるようにしています。何かの機能を使うハンズオンを作る際に、それにフォーカスするために前段部分の構築を (AWS CloudFormation などで) 自動化することがあります。しかし、このお膳立てをしすぎてしまうと、実際のプロジェクトに横展開しにくくなってしまうということがあると感じています。そのお膳立てがセットでないとそのサービスの使い方が分からない.. といった状況に陥ってしまうことないでしょうか ?

そのため、なるべくお膳立てしすぎない、するにしてもブラックボックス化しないように、何をお膳立てしたのかを解説するようにしています。あるいは、他のコンテンツでその部分を解説するものを用意し、そちらを引用する形にすることもあります。(例えば Hands-on for Beginners では、ネットワークの基本の部分は VPC のハンズオン を引用し、この知識がある前提で具体的なハンズオンをするようにしています。) 極力ブラックボックスがないコンテンツにすることで、持ち帰っていただく知識をそのまま実務で活用いただける形を目指したいと考えています。

ここまで分かりやすさを机上で追求してきましたが、本当に分かりやすいコンテンツになっているかは試してみないと分からないと考えています。我々がハンズオンコンテンツを作る際は、コンテンツのターゲットとなるレベル感に近い人を招き、実際にハンズオンをウォークスルーしていただきます。その場で頂いたフィードバックや、躓きポイントを精査し、状況によってはレベルを下げる、2 つのハンズオンに分割するといった修正をしながらコンテンツを磨いています。

社内の勉強会向けのハンズオンコンテンツだと、ここまでやらなくてもいいかもしれません。ただ、どうしても作り手は視野が狭くなりがちです。他の人の視点を入れることで、「自分は分かるけど相手は分からない」部分を発見し、コンテンツをよりよくするプロセスを回すことが大切だと私は思っています。前編 で「教えることがいい学び」と書きましたが、このような改善プロセスを通して、自身の「伝える」スキルの向上にも繋がっていると感じています。

さて、ここまでで良いコンテンツができあがってきたのではないかと思いますが、ここがスタートラインです。作ったコンテンツは是非 Public な形にしていただき、多くの方にやっていただきましょう ! (もちろん公開していいものは、という前提です)

公開することにハードルを感じる方もいると思いますが、情報を発信した人に一番情報が集まる、といったことがよくあります。ハンズオンをやった方の感想の中には、ネガティブなものもあるかもしれませんが、それを改善に繋げていくことが自身のスキルアップに繋がると考えています。また、いいコンテンツを公開している方には、登壇や勉強会の依頼のようなオファーが届くことがよくあります。私自身、前職でブログやコンテンツを公開した結果、次の楽しい話に繋がり、それがまた次の話に・・・という経験がありました。このような好循環が生まれるきっかけになると思いますので、せっかくコンテンツを作ったのであれば、多くの方に届く形にしていただけるといいと思います。

実はこの話は、昨年 builders.flash に寄稿した エンジニアとしての個人的バイブルを語る (ソフトスキル編) の中で紹介した 『SOFT SKILLS』という本にも似た内容が書かれています。自分が今やっていること、得意なことを Output し、Public にすることで様々なメリットを享受できる、という話です。ご興味がある方は、こちらもあわせてご覧いただければと思います。