オンラインの工夫

先日、とある高校の「総合的な探求の時間」の社会人講師として

お話しました。

当初は、教室でAR体験などしてもらいながらお話する予定でしたが、

前日に急遽オンラインとなりました。

当然、準備していた体験は出来ません！

全90分（質問で15分くらい）の中で、体験で40分くらいで考えていましたので、

まるまる75分、お話しをする事になりました！

オンラインで、高校生を飽きさせないようにしながら

何をお話するか？！

しかも、準備する時間はほとんどありません！

頭の中にUDEクラウドが浮かびます…（納期と内容充実のジレンマですね！）

考え、悩んだ末、

やっぱりオンラインでも、高校生達とインタラクティブにやりとりしたい！　

対話、会話をする事で、飽きない時間に出来るのでは？！

という事で、

お話する小テーマをいくつか作っていたので、

小テーマ（言葉）１つだけを1スライドに大きく記載したスライドを作成し

学校で印刷＆黒板に貼り出してもらいました。

そして、当日は、そこに投票してもらい、話をしました。

投票などで、体を動かす事や、何に投票するかを考える事、

投票理由を聞く事などで、

興味を引く事は出来た気がします。

このようなちょっとした工夫がオンラインでは重要な気がしました。

同じ釜の飯を食う　ではないですが、

オンラインでも同じものを見て、持って、触る

事で、一体感というか、共同体的な感じが出る気がしました。

工夫、大事ですね！

マルチタスクとチャット

以前、簡単なマルチタスクのテストで、

私は非マルチタスクよりマルチタスクの方が早い結果が出たのですが、

それと、最近、チャットで仕事を進める事が多く、

複数プロジェクトが走っている状態での指示、確認に

チャットが向いているなー

と実感する事が多々あり、

活用するツールで、マルチタスクの負荷や効率はある程度改善出来る？！

と、ふと思いました。

マルチタスクが効率悪いのは疑う余地はなく、

私のテスト結果は、たまたま　だと思っています。

チャットの短いコミュニケーションは、短い故に

ちょこちょこアドバイスする程度であれば、

比較的マルチタスクの状態でも、脳の切り替え負荷も小さくなる気がしました。

ドキュメントチェックなども

ちょこちょこ追加、変更して共有してもらえると

確認も短時間で終わるので、切り替え負荷が小さく感じました。

となると、やはり使い方も関係しますね。

結局、どんな事も、状況に応じた活用ツールの選択と使いかたですね！

理想？のプログラミング体験

先々月、とある活動にて、高校生二人から相談を受けました。

こんな事したいのですが、出来ますか？

という相談で、「こんな事」は、以下の通り。

1）文化祭で音楽を流したい。

2）時間で流す音楽を変えたい。それまでは同じ音楽を流し続けたい。

3）WindowsPCかMAC Bookで再生したい

ソフトウェアエンジニアなら誰でも同じように答えると思います。

「もちろん、可能だよ！」

二人ともMAC Bookは個人で持っているので、パソコンの知識はあるようです。

アプリやインターネットが身近になっても

ソフトで出来る事、PCで出来る事は、まだまだ未知の世界のようですね。

考えてみれば当たり前ですが、とてもとても新鮮でした。

と、同時に、やりたい事、実現したい事があった上での

プログラミング体験は、とても貴重だなと思いました。

ただ、言語のルールを教えて、Hello World　を動かすより、

やりたい事から、言語を学ぶというより、動かしながら変更していく方が

どんどん吸収していくように思いました。

今回は、私が作成したバッチファイルをコピーせずに、

画面で見せて、タイピングしてもらいました。

もちろん、意味もわからず打ち込みますからタイプミスもあり、

一発では動作しません。

表示処理を入れながらデバッグしていきます。

これで、十分なプログラミング学習だと実感しました。

やりたい事から始まるプログラミング体験！
とても貴重な体験でした！

デモで繋がる

ソフトウェアで出来る事、

ARで出来る事のデモ活動で人が繋がっています。

我々も技術で何が出来るかを知ってもらう為にデモしていますが、

こんなにも繋がるものかと驚いています。

最も大きい要因は、人の力だと思います。

人が人へ伝える力が大きいのだろうと想像しています。

しかし、それだけでは繋がらないと思います。

どんな要因の影響が強いのでしょうか？

デモの内容が伝え易い？面白い？

エンジニアがやっているから興味を持ってくれる？

珍しい事していると思われている？

我々の「活用してもらう為に、知ってもらう」が刺さった？

実は、知りたいと思っていた潜在ニーズがあった？

たまたま？

などなど考えますが、どれもしっくりきません。

となると、やはり、人の力のみ

という事でしょうか。

活動を知ってくれた人、繋げてくれた人のみなさんの力でしょうか。

今年の4月から開始して、ここまで繋がるのは、一人一人の力ですね。

おそらく、インターネットやSNSでは、同じ結果にはならなかったと思います。

デモプランシート

以前、次をつくる

で、実施したデモプランシート

以前紹介した内容は、以下です。

・背景（デモ実施の背景）

・狙い（今回のデモで狙うこと、その後に狙うこと）

・誰にデモするか

・デモの内容

・デモ後にどうなる事を期待しているか

・何に注力するか

何回か実施していますが、デモ後の期待が実現出来ています。

かつ、この為に実施したのですが、次へ繋げられています。

大きくは変わっていませんが、

今は、こんな感じのシートになっています。

・背景（デモ実施の背景）

・狙い（今回のデモで狙うこと、その後に狙うこと）

・WHO：誰にデモするか

・DEMO：デモの内容（実施内容、手順、どうやって次に繋げるか）

・AFTER：デモ後にどうなる事を期待しているか

・POINT：AFTERを確実にする為のポイント、何を引き出すか

背景、狙いはヘッダーのような形で、

WHO以降がA4を縦半分にして、実施後の結果を書き込むようにしています。

今のところ、

これまで、デモを実施する事に囚われていたのが

見せた人から何を引き出すか！

に注力出来ていて、Afterの内容が全てでは無いですが、達成出来ています。

もう少しシートは進化しそうですね。

また進化したら公開します。

久しぶりのセットベース開発

デモのネタ作りの為に、試作に励む日々が続いていますが、

試作でも、セットベースは有効！

という事件が起こりました。

新たなチャレンジや、知識が浅い技術を活用すると

何かとトラブルにお会いします。

その回避策を複数案上げておくだけで、セットベース開発と言えるかと。

もしくは、はじめから仕様として実現案を複数準備しておくのも

セットベース開発と言えるかと。

この2つが早く動かす事、早くデモを見せる事に大きく寄与します。

これが、ダメなら、次はこれ！

と、次々にアタックする事で早くなる。

という感じをイメージするでしょうか。

それもありますが、違うパターンもあります。

これがダメなら、次はこれ！

と試す中で、あれ？

前のこれは、こうすればトラブル回避になる！

といった新たな案が出るのです。

そして、その案で、見事にトラブル回避に成功した事例が、先日ありました。

こういう事例があると、モチベーションも上がりますね。

モチベーションが上がると、更に早くなる！

セットベース開発で、開発が早くなる！！

次をつくる

最近、デモの機会が増えています。

製品のデモではなく、

新たな技術を活用する為のデモです。

アイディアレベルなので、デモを継続して進化させる必要があります。

進化させる為にも、

せっかく頂いたデモの機会を最大限に活かす＝次のデモへと繋げる必要があります。

その為の試行錯誤が続いています。

誰にデモするか、どのような背景か

などなど、状況により、目的や見せ方を変える必要があります。

そして、何より、次のデモへと繋げる必要があります。

事前に様々なケースを想定していないと、当日の対応がはちゃめちゃになります…

やはり、キチンと言語化しておこう！

という事で、デモプランシート作成し、試行中です。

記載内容は、こんな感じ。

・背景（デモ実施の背景）

・狙い（今回のデモで狙うこと、その後に狙うこと）

・誰にデモするか

・デモの内容

・デモ後にどうなる事を期待しているか

・何に注力するか

いまのところ、事前に話すべき事、議論すべき事は出来ている感じです。

さてさて、狙いどおりの結果が出る確率はどうでしょうか？？？

次のデモに繋がる確率はどうなるでしょうか？？？