6/22の 第6回 Tokyo Jazug Night のLTで登壇してきました。

JAZUG

Japan Azure User Group (通称JAZUG) は、Microsoft Azureを学び、楽しみ、活かす、日本のユーザーグループです。2010/8/26に結成したばかりのコミュニティです。ぜひ、一緒に作っていきましょう。 ちょっと興味がある＝ゆるふわな方 から 実ビジネスで使うんだよね な方まで歓迎。 職種はなんでもござれ。 ※プログラマ~企画者、デザイナ歓迎。ゆるふわなコミュニティとお考えください。

発表した資料はこちらです。

connpass JAZUG (Japan Azure User Group) ページより

Azure FunctionsとAWS Lambdaの開発フローの違い

今回、社外・面識のない方が大半の場で登壇するのが初めてでした。そのため、なぜ登壇しようと思ったのか、これからどうしていくのかとかその辺書き残しておこうと思います。

登壇のきっかけ

マネジメント

色々あった気もしますが、根本にあったのは特に技術面での成長に対する不安だったと思います。

営業から業務プログラミングとか0でエンジニアへ転職したのが2015年の1月。

思うように伸びない時期が大半だった気もしますが、2017年4月、正式にロールとしてチームの運営的な部分もやっていくことになり、拍車がかかったというのが大きかったと思います。

当時といってもそんなに時間経ってないですが、こんなことを考えていました。

• マネジメントも様々な技術分野同様、専門知識のある一分野なのでキャッチアップしないと
• 業務として純粋にコード書いたりする時間減るかも
• 技術大してないのにマネジメントってなんというかダサい

マネジメントが技術的成長を妨げるとは全く思ってなくて、技術的に成長していける確認が持てていないタイミングでマネジメントもやる絶望感がただただありました。

インプットの質を高めるためのアウトプット

チームではMicrosoft関連の技術を扱っていて、品川でよく開催されている勉強会にけっこう頻繁に足を運んでいました。

3/25に参加したのがこちら。

.NETラボ 勉強会 2017年3月

.NETラボ 勉強会 2017年3月のまとめ #dotnetlab

後の懇親会で色々と話を伺っていると、雰囲気的に自分も登壇できたらなぁと思いました。

そしてたまたま当日目について記事がこちら。

“ただの興味”がいつか武器になる–及川卓也氏が語る、一流エンジニアのアウトプット法

インプットしないかぎりアウトプットできないので、最初にアウトプットするということを続けていくと、必然的にインプットしなければいけなくなるのです。

僕がよく勉強会で言っているのは、「ライトニングトークは敷居が低いから、とりあえず枠を押さえちゃえ」と。それで手を挙げて、「こういうネタで話そうと思ったけどダメでした」と言っても、やさしい勉強会やコミュニティなら許してくれます（笑）。">僕がよく勉強会で言っているのは、「ライトニングトークは敷居が低いから、とりあえず枠を押さえちゃえ」と。それで手を挙げて、「こういうネタで話そうと思ったけどダメでした」と言っても、やさしい勉強会やコミュニティなら許してくれます（笑）。

あと、デザインパターン勉強していて、けどなんかしっくり来なくて「どうやって勉強したらいいですか？」って聞くと、

「実際にデザインパターンが必要な必要な開発・シチュエーションに出会って適用すること！」

っていうお話をしていきました。これは登壇のきっかけではないのですが、自分の「技術的成長に対する不安感」の核心なので後でまた触れます。

今度はどこで話すかというお話です。雰囲気的に3月に参加した.NETラボさんでお話できたらなぁと思っていました。

が、毎月第四土曜に開催されるこの勉強会は参加できないことが多く、どうしよう、と…

思っていたときに4/22のGlobal Azure Bootcamp 2017@Tokyoに参加してやっていく気持ちが高まり、5/17のJAZUG女子部 第11回勉強会で今回登壇した第6回 Tokyo Jazug NightにLT枠があると知って（？）20秒くらい悩んで申し込んでみました。

ネタはまだない。

話すネタ

そう、申し込んでみたものの何も決まってない。

そもそも5分のLTってどういうのあるんやろう…

• 最新情報・動向
• 新しい技術試してみた
• 導入したときのtips
• Deep Dive
• 俺の作ったサービスを見てくれ
• なんとなくエモい話

とかとか？形から入ると一番大事な部分、話す内容がない。

折しも社内ではピアレビューというのがある時期。

会社では定期的にマネージャー以外にも近くで仕事をする同僚から良い面と良い面を伸ばすために必要なことを書いてもらう機会があります。

そこでもらったコメントの一部がこうでした。

• 得意分野ができて技術をインプットするサイクルはうまく作れるようになったと思うので、今度は情報をまとめるだけじゃなくアウトプットを意識するといいと思う。ここで言うアウトプットは社外での発表とかそういうものではなく、ちゃんと技術を形にしたものであるべき。
• Webアプリ開発などの基礎的なスキルはまだまだ不足していると感じるので、引き続きエンジニアとしてのレベルをトータルで1段あげれるような取り組みはしていったほうがいいと思う。これも勉強会に参加するとかじゃなくて手を動かす時間を取ったほうがいい。

まさに自分が直面している問題の話でそうだなぁと思う一方で、もっと意図が知りたいと思ったのでランチのお時間いただきました。

誤解を恐れつつまとめると

「自分が困った問題の原因を考え抜く、調べきる」

です。

そういうわけで、LTするにしても、LTのためのネタ集めをするのではなく、問題に向き合うことを大前提にすると決めました。

その課題を解決する手段として、今回であればAzure技術を位置付けるような形で話できるのが理想であると。

先ほども少し触れたように「デザインパターンどう勉強したらいいですか」みたいな質問をしてしまう前提として、漠然と自分の打ち手がないことへの不安から何となく教科書的なものを一通りさらっていくような勉強してしまうという自分の弱点があります。

体系的な知識が必要な場面はあるとは思うものの、自分に圧倒的に足りてなかったのは問題そのものに向き合う姿勢でした。

サーバレスアーキテクチャ

今回LTで話したのはAWS Lambdaの話とAzure Functionsの話です。

サーバレスアーキテクチャとか、話は最近よく聞くし、ポップでキャッチーな響きなので登壇後も優しい方々がいいねやリツイートしてくださいました。

本日のLT資料です！ #jazug
/
Azure FunctionsとAWS Lambdaの開発フローの違い https://t.co/DZ3gRxLH7D

— かえる氏の闘争 (@toshi0607) 2017年6月22日

もちろん、このLTの準備はサーバレスアーキテクチャに始まっていなくて、メインは

こうだったのが

こうなった

というのが中核です。

アプリへのレスポンスを改善するためにとった手段が最終的にサーバレスアーキテクチャになっただけで、beforeとafterの間に移行のための別アーキテクチャがあったりします。

とはいえ、手段としてのAWS　Lambdaの特性を知るためのAzure Functionsの勉強はとても有益でした。

• 「サーバレスアーキテクチャ」としてメリット・デメリット
• 制限事項への対応
• 新機能の意図

は特定のプラットフォームにだけ活きるものではなく、両者に活きるものだからです。

LTのスライドだけ見ると、ちょろっと調べれば何となくまとめられてしまいそうな内容になっています。しかし、最終的な成果物がどういう形であれ、問題に向き合うプロセスは別に形にしたり、こんな風に書き留めておきたいと思っています。

登壇の振り返り

そういうわけで、7/25実施の第7回 Tokyo Jazug NightにLT枠で既に申し込んでいます。

よりよくしていくためにほんのちょっと振り返ります

Good

• LTに臨む指針ができた
• 会社でMS関連の技術扱ってることをLT後も含めて伝えられた
• 他社の方と一緒に何かをやるきっかけができようとしている

Challenge

• 間違ってる部分があった
  • シーケンス図→会社の人に教えてもらった。修正済み。LTくらいなら先に会社でさっとやってしまうとよさそう
  • Azure Functionsの実行時間は5分から10分に伸びた→LTの準備段階で参考にさせていただいたブログ書いてらっしゃる方のLT資料に対するご指摘。ありがたい。完璧に準備するのは無理なので、指摘もらった点は資料に反映していくようにしよう
• 緊張しすぎわろた→もうちょい練習しよう
• 平日準備厳しい→土日に8割方終わらせても平日に残りやり切るの厳しいタイミングもあるので、平日は練習するだけ、練習時に気づいたこと直すくらいに…
• 変換コネクタ貸してもらえなかったらアウトだった→type C to HDMIしか持ってってなかったけど、端子トゲトゲの青いやつだった。コネクタ買っとくかな…

次回もがんばるぞー

スライドにも書きましたが、この本よかったです。今AWS Lambda始めるならこれ！という感じです。