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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一発では動作しません。

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

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

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

デモで繋がる

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

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

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

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

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

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

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

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

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

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

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

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

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

たまたま？

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

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

という事でしょうか。

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

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

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

デモプランシート

以前、次をつくる

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

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

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

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

・誰にデモするか

・デモの内容

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

・何に注力するか

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

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

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

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

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

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

・WHO：誰にデモするか

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

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

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

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

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

今のところ、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

と試す中で、あれ？

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

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

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

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

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

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

次をつくる

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

製品のデモではなく、

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

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

進化させる為にも、

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

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

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

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

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

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

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

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

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

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

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

・誰にデモするか

・デモの内容

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

・何に注力するか

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

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

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

スピード感

昨年から「スピード感」という言葉に振り回されている気がします。

自分でも良く使ってしまう気がしますが、この言葉は、とても曖昧でやっかいですね。

「遅れている」は、必ずといっていいくらい、

具体的にどのくらい遅れているかをハカろうとしますが、

「スピード感」は、ハカろうとしない傾向にある気がします。

なぜでしょうか？

大きくは、使い方、活用シーンが違いそうですが、

聞いてる側としても、

漠然と「今より早く」、「更に早く」、などなど

それぞれが、漠然とした認識を持つので、

あまり数値化する意識にならない気がします。

それぞれ違う認識である可能性が非常に高いと思うのですが、

結果的に、それぞれがレベルアップ、スピードアップすれば、

特に問題は無いですね。

問題となるのは、スピード感が無いなどと否定された時ですね。

スピードアップしたと感じる人と、

スピードアップしていないと感じる人がいる

場合には、具体化が必要かと思います。

しかし、このようなギャップがある場合でも、数値化しない傾向にある気がします。

漠然とした課題となっているからでしょうか。

となると、

今起きている事の把握、現状把握が必要な気がしますね。

現在状況の共通認識という方が分かり易いですね。

つくづく、現状把握、現状認識、

いやいや、現在状況の共通認識は大事ですね。

気づきを掴む！

 少し前ですが、

現状を知る為のヒアリングをしました。

ほとんど何も知らない業界の現状把握だった事もあり、

あちこち話が飛ばないように、時間の流れにそって話が出来るように

業務の流れを想像し、資料にしました。

更には、間違ってても指摘してもらう事で、話のとっかかりとなりますし

それがそのまま現状把握になると考えました。

すると、当日、驚く結果となりました。

とっかかりは資料なので、まずは間違い、相違点があれば指摘して下さい

とお願いしたのですが、

その回答は「この資料の通りです。」

という事でした。

ところが、１つ１つ資料を確認していくと、

大きく異る点がありました！

先方は、大きく違うとは認識していません。

あぶなく、気付きを逃すところでした！！

結果として、大きく2つの収穫となりました。

1）相違点については、気にもとめない些細な事という認識である

2）こちらの認識と手順が違う事

それともう一つ。

手順を分解するのは、JOBS法（Jobs to be done)

のアプローチで、細かく分解しないと効果は無いものだと思っていましたが、

分からない事が多い状況でも、分解の粒度が大きくても、

効果があるものだという気づきを得ました。