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

~ハンズオン “作成” のススメ - 後編~

2021-06-02
How to be a Developer

Author : 金澤 圭

テクニカルソリューションアーキテクトの金澤 (@ketancho) です。じめじめした天気が続く今日この頃ですが、皆さまいかがお過ごしでしょうか ? 私は傘を持たない日に限って雨が降り、1 週間でビニール傘を 3 本も買ってしまう、そんな日々を送っています。日頃の行いが悪いからだと思うので、徳を積んでいきたいです。

さて、この記事では「ハンズオンを作る側になってみませんか ?」記事の後編を書いていきます。前編 では、

  • なぜハンズオンを作ることをおすすめするのか
  • 私のハンズオン作成遍歴
  • ネタ探しの Tips

について書きました。後編のこの記事では、ハンズオンを作成する際の Tips について書いていきます。私自身がハンズオンコンテンツを作る際に気をつけていることであったり、最近は同僚が作るハンズオンにコメントさせてもらうことも増えているので、そのときにチェックしている点であったりを整理・共有したいと思います。

これが唯一の正解 ! と思っているわけではなく、私も絶賛試行錯誤中です。ぜひ記事のご感想や、皆さまがコンテンツ作りの際に気にかけていることを #AWSウェブマガジン  タグで呟いていただければ、私も参考にさせていただきたいです。それでは私なりの Tips について書いていきたいと思います。


「考えてもらえる」ストーリーを考える

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

例えば、昨年の Summit オンラインで作成したハンズオンは、ペルソナ設定、課題設定を具体的に決めました。このハンズオンはサーバーレスをテーマにしていたので、サーバーレスが解決する課題を具体的なエピソードにしてみました。

img_create-handson-recommendation-2_01

クリックすると拡大します

そして、その課題を解決するためにこのような構成を作ります、というストーリーとしました。各サービスの使い方だけでなく、使いどころまで持ち帰ってもらい、実際の業務で使いどころがありそうかを「考えてもらえる」ようにしたいという狙いがあります。ハンズオンは横展開してもらってなんぼだと思っており、そのためには「今日得た知識をいつ・何のために使うのか」までご理解いただくことが重要だと考えています。ハンズオンをやったあとで「今日学んだことで実務に活かせることは何かな ?」と、チーム内でディスカッションが始まる、そんな内容にできればと思っています。

img_create-handson-recommendation-2_02

クリックすると拡大します

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

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

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

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

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

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

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


分かりにくさを削ぎ落とす

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

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

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

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

最後の「順番」は、ハンズオンだと特に重要だと考えています。普通は A → B という順で説明することが多い場合でも、A が B よりも情報量が多い場合、順番を入れ替えることがあります。ハンズオンの場合、「手を動かすことで理解が深まる」という特徴 (メリット) もあるので、小出しにできるもの、今回でいうと B のハンズオンを先にやる方がハードルが低く、さらに B を経験してからの方が、後続の情報量が多い A についても理解を深めやすいと考えます。

img_create-handson-recommendation-2_03

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

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


実際にやってみてもらう

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

このようなレビューの場をセッティングする際は、コメントを書きやすい雰囲気を作ることが大切だと考えています。うまく進めなくなったときに「躓いたけど、これは自分が悪いのでは ? 」という心理が働き、フィードバックしにくいことがあると思います。うまくできないことを伝えるのは恥ずかしさがある・・・のは分かるのですが、まさにその「躓き」を事前に潰したいがためにテストをしています。ですので、フィードバックを吸い上げられるように、積極的にコメントする人をサクラ的に置くようにしています (社内でやる場合は、私がこれをやります。)。また、ネガティブなフィードバックだけでなく、「○○の解説が分かりやすかった」といったポジティブなフィードバックを積極的に書くようにします。レビューを受ける側が心理的に楽になると思いますし、他のレビューアもコメントを書くハードルが下がると思っています。

img_create-handson-recommendation-2_04

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


世の中に広める

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

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

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


まとめ

以上で、ハンズオンを作る側になりませんか ? 記事を終えたいと思います。今回は、

  • ハンズオンを作る際の私なりの Tips
  • ハンズオンをレビューする際の確認ポイント
  • 作ったものを是非 Public に

という内容をお伝えしました。前回の記事を含めて「よし、ハンズオン作るぞ !」と思っていただける方が少しでもいれば嬉しいです。ハンズオンを作った方は、ぜひ Public にして、私にもやらせてもらえればと思います。

また、この記事ではハンズオンの作り手視点の話をしていますが、同僚の吉田さんが ハンズオンの「腹落ち問題」を改善する 5 Tips というハンズオンを進める際の Tips を整理した記事を出しています。ハンズオンをやる際に意識してほしいポイントがまとまっていますし、逆に作り手としてこれらの Tips を意識してハンズオンを作ることもできると思います。こちらの記事もぜひ読んでいただければと思います。

この記事が公開されるのは6月頭なはずで、5月病は (私含め) 皆さん完治しているはずです。一説によると行動しないとやる気は出てこないようなので「やってみる」ことが大切なようです。ぜひ、簡単なもので構いませんので、小さく作るところから始めていきましょう ! (自戒を込めて😌) それではまた次の記事でお会いしましょう !


builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

photo_kanazawa_kei

金澤 圭 (@ketancho)
アマゾン ウェブ サービス ジャパン株式会社
技術統括本部 ソリューションアーキテクト

サーバーレスが好きなテクニカルソリューションアーキテクト。業種業界問わず、お客様のプロダクト開発をサポートさせていただいています。「AWS Hands-on for Beginners」というオンデマンドで視聴できるハンズオンも企画・推進しており、楽しく学べるコンテンツを日々考えています。好きなサービスは AWS Lambda と AWS Amplify で、好きな休日の過ごし方は娘ふたりと川の字になって昼寝です👧👧

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
フィルタ
フィルタ
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する