僕が思う理想的な技術系LTや講演の流れ
良く技術系の勉強会やLT枠に発表者として参加させて頂くのですが、 (こんな内容の発表をしてます。)
あなたも出来る！webエンジニアがSwiftでリリースするためにやったこと
Apple審査を一発通過！iOS開発経験0でも出来るじげん流Swift開発のすべて
現場から始める Developer Productivity
その発表後によく、
発表内容を会社やチームで普及していこうと思うのですが どうすれば良いでしょうか。
と、質問されることが多くありました。 今までの反省や今後も踏まえて一度自分なりの 理想的な技術系LTや講演の流れ を書いておきたいと思います。
スライドの流れ
- 自己紹介
- これから何を話すのか？
- そもそも〇〇とは？(参加者による)
- やった事
- やって何が変わったか
- その他
- まとめ
なぜこの構成にしたかについて説明していきます。
自己紹介
- 経歴などからどのような人物かを伝える。
- 趣味や特技から興味を引く。
これから何を話すのか？
いきなりやったことや詳細を話すより軽く何を話すのか説明しておくと 理解度が深まる。
またそれを行った時の背景なども軽く説明する。
- 目次の説明も軽くしておくと尚、良い。
そもそも〇〇とは？(参加者による)
- これは技術領域が違うエンジニアの方が参加する場合、勉強し始めの方が参加する場合に有効
- この説明があると調べるコストや説明するコストが下がり、「会社やチームへの普及活動」へのモチベーションへと繋がる
やった事
- チームでやったことであればチーム構成なども書くと担当配分が理解しやすい。
- 具体的なアクション・プランについて話す。
- 実装であれば工数や品質なども書くと「会社やチームへの普及活動」の説明に役立つ。
- 何が大変だったのか、何に気をつけるべきか実体験ベースで書く。
その他
- やったことのメリットやデメリットがあれば書いておく。
- 技術系であれば横展出来そうな事例で「こんなことも出来るよ」的なTipsも書いておく。
- こんな風に使うと便利だよといった使い方もあれば説明しておく。
まとめ
- 特に自分が言いたいことやこうすると「会社やチームへの普及活動」に繋がることを書いておく
- 当事者であればそれに得られたことを書いておく
このような流れになると
- 参加者が普及させていきたいと思った時に他者に説明がしやすい
- 概要から詳細の流れなので理解しやすい
- 周辺技術や知見も説明されるので興味対象が広がる
などにつながって大分、楽観的に考えて
発表内容をいざ、会社やチームで普及活動をしよう！と思った時に 説明しやすくなって良いですね！
となるんじゃないかなーと思っています。
蛇足も追加しておきます。
蛇足
- 画像には補足説明を付けた方が良い。
- 一枚の画像で説明がきつかったら追加する。一つに無理やりつめ込まない。
- 背景黒画像は見づらい。
- デザインや見やすさを意識する。
【勉強会】Lean Startup Update!! 2015@品川に参加して、リーンスタートアップについて再考してきたよ！
場所：日本マイクロソフト株式会社 31F セミナールーム A
スライド
TOCから俯瞰するリーンスタートアップ (河合太郎)
http://www.slideshare.net/inuro/toc-43579895
リーンスタートアップ導入の現場(黒田樹)
http://www.slideshare.net/i2key/leanstartup-43578851
Lean UX Quest in Tokyo(坂田一倫)
データなし
Lean Analytics(角征典)
http://www.slideshare.net/kdmsnr/lean-analytics-20150116
実録！現場におけるLeanStartupの実践 (冨山香織)
http://www.slideshare.net/ktomiyama/leanstartup-43589215
人間と話す Lean Customer Development(馬田隆明)
http://www.slideshare.net/takaumada/lean-customer-development-lean-startup-update-2015
気になった内容の箇条書きや所感
1.リーンスタートアップ導入の現場(黒田樹)
新規機能開発やプロダクトの改善内容においてのエンジニアタスクは 10個中3個程度に収まることがほとんど。 PMや上から降ってきた改善内容は一旦、「実装しないと本当に検証できないものかどうか」という観点で精査する必要がある。 しなければ限られたリソースを枯渇する原因になる。
改善内容はAARRRが基本で最も大事なのはRetension。
よくグロースハックなどで飛び道具で「ボタンの色を〇〇から〇〇に変えて〇〇%向上」なんて言われるけども、それは本質ではなくてまずは、プロダクトのクォリティをあげることを先にすべき。
2.Lean UX Quest in Tokyo(坂田一倫)
- UXサークル(UX関連に携わる有志で集まり月1ペースで効果のあった検証方法や今後のUXについて議論するサークル) が良さそう
3.Lean Analytics(角征典)
起業家はみんな嘘つき。「強化系のデータ(〇〇というデータが出ているからこのサービスは成功すると実証しやすいデータ)を集める」傾向がある。→知りたいデータだけをあつめる。
知りたくないこと、見たくないこと、知りたくないことを以下に気づくことが出来るかが大事
吉野家とすき屋の指標の違い。 吉野家は「人時客数(オペレーション効率の向上のため)」、すき屋は「人時売上(売上高、人件費抑制のため)」
コスト削減には限度がある。右肩あがりになる指標を置いた方が良い。
見るべき指標が大事。相関関係ではなく因果関係。変化や数値、データを取り、相関関係を見つけ、因果関係を見つける。
4.実録！現場におけるLeanStartupの実践 (冨山香織)
yahoo!がリーンをするのは「新規開発のため」、「正しいものを作れているかを検証するため」、「既存からの脱却のため」
いきなりリーンはキツイから企画書に書いていることを疑う、企画書をテーマとして考えていく。
ユーザーの声を聞く際に、ユーザーの声を聞きすぎてしまう傾向がある。そのときは課題に立ち返る。
