デモのネタ作りの為に、試作に励む日々が続いていますが、
試作でも、セットベースは有効！
という事件が起こりました。
新たなチャレンジや、知識が浅い技術を活用すると
何かとトラブルにお会いします。
その回避策を複数案上げておくだけで、セットベース開発と言えるかと。
もしくは、はじめから仕様として実現案を複数準備しておくのも
セットベース開発と言えるかと。
この2つが早く動かす事、早くデモを見せる事に大きく寄与します。
これが、ダメなら、次はこれ！
と、次々にアタックする事で早くなる。
という感じをイメージするでしょうか。
それもありますが、違うパターンもあります。
これがダメなら、次はこれ！
と試す中で、あれ？
前のこれは、こうすればトラブル回避になる！
といった新たな案が出るのです。
そして、その案で、見事にトラブル回避に成功した事例が、先日ありました。
こういう事例があると、モチベーションも上がりますね。
モチベーションが上がると、更に早くなる！
セットベース開発で、開発が早くなる！！
最近、デモの機会が増えています。
製品のデモではなく、
新たな技術を活用する為のデモです。
アイディアレベルなので、デモを継続して進化させる必要があります。
進化させる為にも、
せっかく頂いたデモの機会を最大限に活かす＝次のデモへと繋げる必要があります。
その為の試行錯誤が続いています。
誰にデモするか、どのような背景か
などなど、状況により、目的や見せ方を変える必要があります。
そして、何より、次のデモへと繋げる必要があります。
事前に様々なケースを想定していないと、当日の対応がはちゃめちゃになります…
やはり、キチンと言語化しておこう！
という事で、デモプランシート作成し、試行中です。
記載内容は、こんな感じ。
・背景（デモ実施の背景）
・狙い（今回のデモで狙うこと、その後に狙うこと）
・誰にデモするか
・デモの内容
・デモ後にどうなる事を期待しているか
・何に注力するか
いまのところ、事前に話すべき事、議論すべき事は出来ている感じです。
さてさて、狙いどおりの結果が出る確率はどうでしょうか？？？
次のデモに繋がる確率はどうなるでしょうか？？？
昨年から「スピード感」という言葉に振り回されている気がします。
自分でも良く使ってしまう気がしますが、この言葉は、とても曖昧でやっかいですね。
「遅れている」は、必ずといっていいくらい、
具体的にどのくらい遅れているかをハカろうとしますが、
「スピード感」は、ハカろうとしない傾向にある気がします。
なぜでしょうか？
大きくは、使い方、活用シーンが違いそうですが、
聞いてる側としても、
漠然と「今より早く」、「更に早く」、などなど
それぞれが、漠然とした認識を持つので、
あまり数値化する意識にならない気がします。
それぞれ違う認識である可能性が非常に高いと思うのですが、
結果的に、それぞれがレベルアップ、スピードアップすれば、
特に問題は無いですね。
問題となるのは、スピード感が無いなどと否定された時ですね。
スピードアップしたと感じる人と、
スピードアップしていないと感じる人がいる
場合には、具体化が必要かと思います。
しかし、このようなギャップがある場合でも、数値化しない傾向にある気がします。
漠然とした課題となっているからでしょうか。
となると、
今起きている事の把握、現状把握が必要な気がしますね。
現在状況の共通認識という方が分かり易いですね。
つくづく、現状把握、現状認識、
いやいや、現在状況の共通認識は大事ですね。
少し前ですが、
現状を知る為のヒアリングをしました。
ほとんど何も知らない業界の現状把握だった事もあり、
あちこち話が飛ばないように、時間の流れにそって話が出来るように
業務の流れを想像し、資料にしました。
更には、間違ってても指摘してもらう事で、話のとっかかりとなりますし
それがそのまま現状把握になると考えました。
すると、当日、驚く結果となりました。
とっかかりは資料なので、まずは間違い、相違点があれば指摘して下さい
とお願いしたのですが、
その回答は「この資料の通りです。」
という事でした。
ところが、１つ１つ資料を確認していくと、
大きく異る点がありました！
先方は、大きく違うとは認識していません。
あぶなく、気付きを逃すところでした！！
結果として、大きく2つの収穫となりました。
1）相違点については、気にもとめない些細な事という認識である
2）こちらの認識と手順が違う事
それともう一つ。
手順を分解するのは、JOBS法（Jobs to be done)
のアプローチで、細かく分解しないと効果は無いものだと思っていましたが、
分からない事が多い状況でも、分解の粒度が大きくても、
効果があるものだという気づきを得ました。
最近やってしまった失敗をSpeaker Deckに公開にしました！
アサンプションを全く疑えてない失敗事例です。
他人事だとツッコめるけど、自分だと甘々な事が露呈してしまいました。
お恥ずかしい…
改めて資料にしてみると、
失敗事例は分かり易いですが、
対処方法は1つではないので、どう表現するかが難しい…
この点も、もっと勉強が必要ですね。
最近は、資料で紹介している「G+4箱」を書くようにしていますので、
引き続き、事例資料も作っていこうと思います。
久しぶりにアプリ作成しました。
改めて、作り出すと夢中になってしまうなーと実感しています。
ある程度完成するまでは、他の事は考えたくなくなりますね。
いや、他の事は全く考えなくなります。
私だけでしょうか？！
大昔は、コンパイルに時間が掛かったりなど、
いろいろと隙間時間があり、
その時に、他の事を考えたり出来たのですが、
いまは、ほぼほぼPC上で完結する事が多いので、
テストもガンガン書きたくなるし…
ある程度のところまでは集中しちゃいますよね。
だから、こそ余計に小さく作る事が重要になると思っています。
特に私にとっては！
小さく作って繋げていく。
そして、小さく作るために必要なのが、
「何を作るか」
この「何」をいかに小さくするか
どう繋げていくか、
がとても重要になってきます。
この「何」を決めるには、
ソフトの事も知りつつ、目的もしっかり定めてフォーカスする必要があります。
そして、目的をフォーカスにするのは、やっぱりFRTですね！
このスキルは、今後もしばらく重要になってくると考えています。
最近はデモする機会がめっきり減りました。
オンラインでの交流はあるものの、デモの機会は少なくなりました。
そんな中で、久しぶりにデモの機会があり
改めて、誰かに見せる事は大事だと実感しました。
まず、「見せる」と決めた時点で変化があります。
デモ作りのモチベーションが圧倒的に違いました。
内部デモなどと違い、外部の人に見せるとなると、いろんな事が一気に加速しました。
みんな飢えてただけ？？？
創る側（プログラム作成する側）が
「見せる」ターゲット（人）をイメージ出来ると、加速するのでしょうか？！
イメージ出来るからモチベーションが上がるのでしょうか？
結果、2週間弱で、簡単な3つのデモアプリを作成しました。
簡単とはいえ、スピード感はあったと思います。
「見せる」事が決まると、加速した貴重な体験でした。
