give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

【2019年10月版】「Everyday Rails - RSpecによるRailsテスト入門」のセットアップ解説動画を作成しました

はじめに

僕が翻訳者として参加している電子書籍「Everyday Rails - RSpecによるRailsテスト入門」は2014年の日本語版発売以来、現在まで随時内容をアップデートを繰り返しています。
今の内容も十分実用性があるのですが、使用しているライブラリのバージョンが若干古くなっているせいか、ときどきネット上で「サンプルアプリのセットアップがうまくいかない」というコメントを見かけたりします。

そこで僕が実際にゼロからサンプルアプリをセットアップする動画を作成してYouTubeにアップしてみました。

今回作成した動画はこちら

今回作成した動画はこちらです。再生時間は約18分です。

【2019年10月版】「Everyday Rails - RSpecによるRailsテスト入門」の環境作成手順

動画の内容

この動画ではGitHubからサンプルアプリをクローンして、サンプルアプリが起動することと、masterブランチのテストがすべてパスするまでの手順を説明しています。
実行環境はGitHubのこのコミット(8b3800f)時点のコード、および本書の2019-10-01版の内容にあわせて次のようになっています。

  • Rails 5.1.1
  • RSpec 3.8.0(書籍の中では3.6.0が使われていますが、大きな違いはありません)
  • Ruby 2.4.9 (2019年10月14日時点のRuby 2.4系の最新版)

ただし、この動画では以下の内容は説明していません。

  • rbenvのセットアップ
  • gitのセットアップ
  • Chromeのインストール

また、対象となる実行環境はmacOSです。(具体的にはmacOSX Mojave 10.14.6)

ざっくりとした手順

というわけで、具体的な手順については動画を見てやってください!・・・で終わってもいいのですが、動画を見る時間がない、という人のために簡単に手順を紹介しておきます。

# GitHubからコードをクローン
git clone git@github.com:everydayrails/everydayrails-rspec-2017.git

# ディレクトリを移動
cd everydayrails-rspec-2017

# 実行環境をRuby 2.4系に設定(2.4系のRubyを事前にインストールしておく)
rbenv local 2.4.9

# Bundlerのインストール(まだインストールしていない場合)
gem install bundler

# gemのインストール
bundle install

# マイグレーション実行
rails db:migrate

# サーバーを起動して動作確認(最初はSign up画面にてユーザーを作成)
rails s

# テストが全部パスすることを確認
bin/rspec 

動画の中でもお話ししたとおり、僕が今回試した手順では特に大きなトラブルもなく、テストが全部パスするところまで実行できました。

2021-3-27 追記

mimemagic gemの過去のバージョンが削除(yank)されてしまった関係で、bundle installすると以下のようなエラーが出る場合があります(参考記事)。

Your bundle is locked to mimemagic (0.3.2), but that version could not be found in any of the sources listed in your Gemfile. If you haven't changed sources,
that means the author of mimemagic (0.3.2) has removed it. You'll need to update your bundle to a different version of mimemagic (0.3.2) that hasn't been
removed in order to install.

このエラーが出た場合はbundle installの代わりにbundle update mimemagicを実行するとgemのインストールができるはずです。

bundle update mimemagic

ただし、gemのインストールが成功しても以下のようなエラーが出る場合があります。

Failures:

  1) Tasks user toggles a task
     Got 0 failures and 2 other errors:

     1.1) Failure/Error: visit root_path
          
          Selenium::WebDriver::Error::SessionNotCreatedError:
            session not created: This version of ChromeDriver only supports Chrome version 90
            Current browser version is 89.0.4389.90 with binary path /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

この場合はGemfileを開き、"chromedriver-helper"を"webdrivers"に置き換えてください。

 group :test do
   gem 'capybara', '~> 2.15.4'
   gem 'selenium-webdriver'
-  gem 'chromedriver-helper'
+  gem 'webdrivers'
   # Or use poltergeist and PhantomJS as an alternative to Selenium/Chrome
   # gem 'poltergeist', '~> 1.15.0'
   gem 'launchy', '~> 2.4.3'

さらに、"selenium-webdriver"も一緒にアップデートした方が良いので、Gemfileを保存したらbundle update selenium-webdriverを実行してください。

bundle update selenium-webdriver

僕の環境ではこれで全テストがパスしました。

(参考:動作確認した実行環境)

  • MacBook Pro (13-inch, M1, 2020)
  • macOs BigSur 11.2.3
  • Ruby 2.4.10 (rbenvでインストール)
  • Chrome 89.0.4389.90 (Official Build) (arm64)

Cloud9で動かしたい場合

Cloud9で実行したい人は以下の動画が参考になるかもしれません。

【2019年7月版】Cloud9上でEveryday Railsの`js: true`付きのフィーチャスペックを実行する手順

Qiitaに書いた以下の記事もあわせてご覧ください。

qiita.com

お願い:質問は「みんなが見える場所」で!

この動画を見てもうまく動かない!という場合は、僕の方でできるかぎりサポートします。
ただし、その場合はTeratailやStackOverflowなど、「みんなが見える場所」で質問するようにしてください。(DMでの技術的な質問は基本的にNGです)
その上でTwitter等で「ここに質問を書いたので見てください」とメンションをもらえれば、何らかのコメントを返すようにします。

なぜ「みんなが見える場所」での質問をお願いするのかという理由については以下のエントリにまとめてあるので、こちらも参考にどうぞ。
blog.jnito.com

まとめ

というわけで、このエントリではYouTubeに公開した「Everyday Rails - RSpecによるRailsテスト入門」のセットアップ解説動画について紹介しました。
もし「Everyday Railsを買ったけど、セットアップがうまくいかなくて困っている」という人がいたら、ぜひこの動画を参考にしてみてください!

【2019年10月版】「Everyday Rails - RSpecによるRailsテスト入門」の環境作成手順

あわせて読みたい

さらに、このサンプルアプリケーションをRails 6にアップデートしたときに発生するテストコードの変更点についてもブログにまとめました。
こちらも動画付きです。よかったら参考にしてみてください。

blog.jnito.com

「Everyday Rails - RSpecによるRailsテスト入門」について

「Everyday Rails - RSpecによるRailsテスト入門」はその名の通り、RailsアプリケーションをRSpecを使ってテストする方法を解説した電子書籍です。
難易度的には「RailsやRubyがある程度わかっている人であればOK、RSpecの知識はゼロでも大丈夫」というレベルになっています。

内容の詳細や購入方法等については以下のエントリにまとめてあるので、こちらを参考にしてください。
blog.jnito.com

ご購入は以下のサイトからどうぞ。
Everyday Rails - RSpecによるRailsテスト入門 - Leanpub
f:id:JunichiIto:20190424050314p:plain

発表でうまく話すためには (富山Ruby会議01のPRをかねて) #toyamark

はじめに

僕は今年の8月末に銀座Railsという勉強会で登壇してきました。
講演が終わったあと、Twitterでみなさんの感想を読んでいたところ、こんなツイートを見つけました。

どうもありがとうございます!
発表のしゃべり方は、自分でもうまい方なんじゃないかと思っています(笑)。

コメントをくださった方が「構成の考え方や練習量が気になる」とおっしゃっているので、今回は僕が考える「発表でうまく話すコツ」を書いてみようと思います。

【もくじ】

いきなり種明かし = 実はある本の内容を実践してるだけ

僕が初めて人前で話したのは2012年のDevLove関西のイベントです。

blog.jnito.com

当時は人前で話すのが初めてで、僕はプレゼンのやり方について右も左もわかりませんでした。
そこで、プレゼンのイロハを学ぶために買ったのが、この「パワー・プレゼンテーション」という本です。

この本が僕にとってはすごく「当たり」で、それ以来、ずっとこの本に書かれている内容を実践し続けて現在に至ります。
(これ以外プレゼン関係の本は読んでいません)

僕が大事にしているポイントあれこれ

というわけで、みなさんもこの本を読めば僕が実践しているコツが全部わかります。以上!!

・・・で、終わると、あまりにも肩すかしなエントリになってしまうので、この本の内容で特に僕が大事にしているポイントとをいくつか挙げてみます。
また、この本の中には載っていないけど、個人的に大事にしているポイントもいくつか書きます。

参考:銀座Railsで発表した内容について

ここでは具体例として、銀座Railsで使ったスライドや話した内容を登場させます。
銀座Railsでの僕の発表については、以前書いたこちらのブログ記事を参照してください。

blog.jnito.com

それでは以下が本編です。

聞き手にメリットを与える

うまく話すための大事なポイントは、聞き手に明確なメリットを与えることです。
これを「パワー・プレゼンテーション」の中ではウィッフィー(WIIFY = What's in it for you?)と呼んでいます。

発表の構成を考えるときは、自分の中にある「これを話したい!」「これを聞いてほしい!」という思いが起点となることは間違いありません。
しかし、そのままスタートを切るのではなく、一度自分の視点を聞き手の視点に置き換えて「それを聞いて何がうれしいの?」「その話のどこがおいしいの?」と自問自答してみると、聞き手にとっていっそう満足度の高い発表にすることができます。

先日の銀座Railsの発表で言えば、「普段あまり目にする機会がない、"他の人がリアルにコードを書いている姿"を見られること(それを通じて、プログラマがコードを書きながら考えていることや、コーディングのテクニックを知れること)が聞き手にとってのメリットになるはず」と僕は考えていました。

A地点は何か?B地点は何か?

書籍の中では、プレゼンは聞き手をA地点からB地点に連れて行くことがゴールだとしています。

A地点というのは、プレゼンを聞く前の聞き手の状態です。
B地点というのは、あなたのプレゼンを聞いた後に聞き手が抱く気持ちです。

すなわち、聞き手が「話を聞く前は○○だったが、話を聞いた後には△△な気持ちになった」という感想を抱けば、その発表は大成功、ということです。

たとえば、先日の銀座Railsの発表で言えば、A地点とB地点の設計はこんな感じになります。

話を聞く前は「すごいプログラマは何でも知っていて、すらすらコードを書く」と思っていたが(A地点)、話を聞いた後は「別にそんなことはないんだ(でも、自分と違うところもたくさんある!)」と思うようになり、その結果、気持ちが軽くなってこのままがんばっていこうと思えた(B地点)

ペルソナを明確にする

プレゼンの内容を考えるときはペルソナを明確にします。
すなわち、「こんな経歴で、ふだんこんなことを考えている人が最も喜ぶ話を提供しよう」と考えることが重要です。

これはプレゼンに限らず、技術記事を書くときも同様ですね。
qiita.com

プレゼン当日に聞き手が100人いた場合、100人全員が喜ぶ話を提供するのはほぼ不可能です。
全員を喜ばせるような内容にしようとすると、逆に何が言いたいのかよくわからない、誰も嬉しくない発表になってしまうかもしれません。

別に100人の中の5人とか10人ぐらいでもいいんです。
「客席にはきっと、こんなことで困っている人やこんなことを知りたがっている人がいるはず」という「仮想オーディエンス」を設定して、その人が大喜びするような内容を考えます。

こういう設計にした方が、内容が濃くて面白い話になりやすいです。
仮に100人中の90人はターゲットでなかったとしても、濃くて面白い話になっていれば「その話はすでに知ってるけど、たしかにそのとおり!」とか、「へ〜、そういう世界もあるんですね。初めて知りました」と、納得してもらえる内容になるはずです。

ちなみに、先日の銀座Railsの発表で僕が設定したペルソナは、

「プログラミング歴があまり長くなくて、自分のプログラミングスキルにあまり自信がなく、なおかつ他の人がコードを書く様子を見たこともないので、"きっと自分以外のプログラマはもっとすさまじいスピードで書いているに違いない"と、何の根拠もなく考えている人」

でした。

背伸びをしない

「背伸びをするな。自分の言葉で語れる内容だけを語れ」

これは書籍の内容ではなく、僕が初めてDevLove関西で登壇するときに、弊社ソニックガーデンの倉貫社長から言われたアドバイスです。

これはプレゼン初心者に多いと思うのですが、人前で話す自分を想像すると、「あいつ、バカなんじゃない?」とか「大したことねーのに偉そうにしゃべりやがって」みたいにdisられるんじゃないかと、つい妄想してしまうことがあります(僕もそうでした)。

こういった恐怖心があると、「えーと、あまり詳しいわけじゃないんだけど、この話も盛り込んでおいた方がいいかな・・・」という、「見栄をはりたくなる気持ち」が湧きあがってきます。

が、自分がよく知らない話をプレゼンに盛り込むのはやめた方がいいです。

自分がよく知らない話は自信をもってしゃべれないので、説得力がなくなります。
また、質疑応答で「あまり詳しくない話」に質問が来ると、しどろもどろになってロクな回答ができなくなります。

それよりもむしろ、自分がちゃんと理解している内容、自分自身の考え、自分自身の経験だけを話すようにしてください。
その方が話が生き生きとして、説得力が高まります。
質問が来ても自分の中にある話なので、自信をもって答えることができます。

自分が理解していることを自分の言葉で堂々と語っていれば、話のレベルが低いだの高いだの、そんな文句を言う人は出てきません。

アイスブレイクは重要だが、ウケ狙いは不要

プレゼンの冒頭では軽いアイスブレイクを入れて、聞き手の気持ちをほぐしておくと、その後のトークもなごやかに進めやすくなります。

アイスブレイクは何でもいいです。
簡単なのは「〜な人がいたら挙手!」みたいな感じで、会場に向かって質問を投げかけることですね。

先日の銀座Railsでは、「今日、僕は新幹線で東京までやってきたんですけど、この中で僕と同じように新幹線で来た人はいますか!?」と質問を投げてみました。(絶対いないだろうと思ったら、1名だけいましたw)

その一方で、発表中に笑いを取りに行くのは、僕は非常に危険だと思っています。
ウケを狙おうとすると失言につながったり、意図せず誰かを傷つけたりしやすいからです。
会場では何も問題が起きなくても、スライドを公開したあとにSNSで大炎上、みたいなこともよくあります。

また、ウケを狙って盛大に滑ってしまったときは、自分へのダメージも大きいですし、聞き手も痛々しい気持ちになってしまいます。

とはいえ、始終お堅い話ばかりしてもしんどいと思うので、僕は「クスッと笑えるぐらいの軽いユーモア」を入れることはあります。
大爆笑を狙いに行くのではなく、あくまで「クスッと笑える程度」に留めておくのがポイントです(そのさじ加減はなかなか難しいと思いますが)。
軽いユーモアであれば、仮に滑ったとしても致命傷にはなりにくいです。

たとえば、銀座Railsでは若干自虐気味にこういうスライドを挟み込んだりしていました。

f:id:JunichiIto:20191002094615p:plain

客席に目をやる、問いかけを盛り込む

発表中は頻繁に客席に目をやることも大事なポイントの一つです。
話すのに必死になって、ずっと目の前のパソコンを見ていたり、会場のスクリーンに向かって話し続けていたりすると、話し手と聞き手の心の距離がどんどん離れていきます。

発表中は何度も客席の様子を確認しましょう。
自分の話にうなずいてくれる人が何人かいたら、いい感じに自分の話が伝わっている証拠です。

また、発表の途中に「問いかけ」を盛り込むのも効果的なテクニックのひとつです。
「〜ですよね?」とか、「〜だったりしませんか?」とか、「〜ってご存じですか?」とか、こういった問いかけを挟み込むことで、聞き手はあなたと会話をしているような気持ちになります。
そうすると、話し手と聞き手の心の距離が縮まって、聞き手はあなたの話にじっくり耳を傾けてくれるようになります。

以下は銀座Railsで使ったスライドの「問いかけ」の例です。

f:id:JunichiIto:20191002095806p:plain

スライドを読ませない(聞き手の意識をスライドに集中させない)

自分の話したいことをふんだんにスライドに盛り込もうとすると、スライドが文字だらけになります。
スライドが文字だらけになると、聞き手はスライドの字を読むことに必死になります。
スライドを読むのに必死になると、聞き手の意識があなたの言葉ではなく、スライドの文字に集中します。
結果として、聞き手は「あなたの話を聞いた」というよりも、「スライドをがんばって読んだ」という形になります。

このように、「うまく話す」という観点においては、情報量が多すぎるスライドはマイナスに作用します。
そもそも、自分が話したいことをすべてスライドに盛り込むのであれば、何も話さずにスライドを配って終わりにすればいいはずです。

情報量が多すぎるスライドを防止する方法のひとつは、「スライドの中の文字を絶対に折り返さない」という制約を課すことです。
この制約を守るようにすると、自ずとスライドの文字が削られていきます。

以下は「絶対に文字を折り返さないスライド」の一例です。

f:id:JunichiIto:20191002100612p:plain

また、最初から全部スライドの文字を見せると、やはり聞き手の意識がスライドの文字に移ってしまいます。
なので、僕はアニメーション機能を使って箇条書きをひとつずつ表示するようにしています。

f:id:JunichiIto:20191002204114p:plain

同僚にレビューしてもらう

初めての発表で慣れていないときは、発表の構成やスライドがある程度できた時点で会社の同僚にレビューしてもらいましょう。
ちょっと恥ずかしいかもしれませんが、軌道修正は早ければ早いほど良いです。

完全に作り込んでしまう必要はありません。
むしろ、完全に作り込んだあとでは、「発表直前に大量のフィードバックを受けて途方に暮れる」といった事態になりやすいです。
「だいたいこんな感じ」というイメージが固まった時点で早めにレビューしてもらうことをオススメします。

そして最後に練習、練習、練習!!

ところで、冒頭で紹介した感想ツイートの中に「練習とかはどのぐらいしたんだろうか」というコメントがありました。
「練習ってwww 僕がそんな泥臭い努力をするわけないじゃないですか!」と言いたいところですが、めちゃくちゃ練習してます。はい。

練習の重要性は書籍「パワー・プレゼンテーション」の中でも説明されています。

では、どうしたら命を吹き込むことができるのだろうか。それは、「声に出して練習する」ことだ。

その際には、本番で使用するスライドを使い、大きな声で練習してほしい。実際に聞き手の前に立ってプレゼンテーションするつもりで行おう。この「声に出して練習する」プロセスなくしては、効果的なプレゼンテーションなどありえないのだ。


「パワー・プレゼンテーション」183p.

僕はだいたい発表当日の1週間前にはスライドをいったん作り終えて、練習(というかリハーサル)を始めます。

本番までに最低でも4〜5回、多いときは10回以上やります。
ときどきPCの画面と自分の声を録画して、自分で動画をチェックすることもあります。

MacであればQuickTime Playerを使って画面を録画することが可能です。
(参考:MacのQuickTime Playerで画面を収録する - Apple サポート (日本)

事前に練習を繰り返すと、次のようなメリットが生まれます。

当日の時間配分をほぼ完璧にコントロールできる

リハーサルをやると、自分のトーク時間がわかります。
これ、意外なことに時間をオーバーしてしまうケースの方が圧倒的に多いんですよね。
今までリハーサルをしてみて、予定時間より早く終わった経験は一度もありません。

なので、リハーサルをまったくせずに本番にのぞむと、たいていの場合、制限時間をオーバーしてしまうと思います。

時間が足りないと最後だけ急に早口になって「このスライドは飛ばします」みたいなセリフを連発したり、「あっ、あっ、あと5分ください!」とお願いしたりするハメになります。

こうなると聞き手も変に焦ってしまいますし、時間をオーバーするとタイムテーブルが押してしまって、あとの登壇者に迷惑がかかったりします。

ですので、リハーサルを繰り返して、自分のトーク時間をコントロールできるようにしましょう。
リハーサルでは時間をオーバーしても誰にも迷惑がかかりません。
明らかに制限時間を超えてしまう場合は、スライドの枚数や口で話す内容を減らして、トーク時間を調整しましょう。

リハーサルを4〜5回やってトーク時間が制限時間内に収まれば、本番でも同じように制限時間内にしゃべれるはずです。

スライドやトークの内容が洗練される

練習を繰り返したり、録画した自分の発表をチェックしたりすると、第三者の視点で自分の発表を振り返ることができます。
そうすると、「ちょっとここはわかりにくいな」とか、「ここはこういう説明の方がいいな」という改善点が見つかります。

そういった改善を繰り返していけば、スライドやトークの内容がどんどん洗練されていきます。

発表中に挟む軽いジョークなんかも、練習を繰り返すうちに「あ、ここでこういうジョークが入れられるかも?」と気づくことが多いです。

落ち着いて話せるようになる(えー、あー、あのー、の回数が減る)

ぶっつけ本番で話そうとすると、芸能人やアナウンサーではない僕たちは、「えー」「あー」「あのー」みたいな言葉がしょっちゅう出てきてしまいます。

練習を繰り返すと、落ち着いて話せるようになるので、えー、あー、あのー、の回数が減ります。

多少の「えー、あー、あのー」であれば口に出しても問題はありませんが、頻繁にこの言葉が出てくると聞き手も少し落ち着かない気分になってくるので、プレゼン初心者の方は要注意です。
(練習を録画して自分で見直してみると、自分がどれくらい「えー、あー、あのー」を連発しているのか、よくわかります)

また、上で述べたように、発表中はなるべく客席に目をやることが大事です。
これも余裕がない人ほどパソコンやスクリーンに集中しがちになります。
ですので、事前に練習を繰り返して「心の余裕」を十分持つようにしましょう。

まとめ

というわけで、このエントリでは僕が普段意識している「発表でうまく話すためのコツ」をいろいろと紹介しました。

もちろん、発表の上手・下手はこれまでに踏んできた場数によっても変わってきます。
ですが、場数だけがすべてではありません。

ここで紹介したようなコツを意識すれば、プレゼン初心者の人でも「発表、とてもお上手ですね」と言われるはずです。
ですので、みなさんもこのエントリで紹介した「発表のコツ」をぜひ実践してみてください!

あわせて読みたい

Macで使えるプレゼンソフト、Keynoteの使い方を解説した記事です。
スライドの作り方に慣れていない人は、こちらの記事も参考にしてみてください。

blog.jnito.com

最後に宣伝:富山Ruby会議01で発表します!

さて、最後にちょっと宣伝をさせてください。
今度、2019年11月3日(日)に開催される富山Ruby会議01で、招待講演として「○○からRubyへ」という発表をさせてもらいます。

f:id:JunichiIto:20191002203426p:plain

スライドはまだ作り始めていませんが、だいたいこんな発表にしようと考えています。

聞き手のペルソナ

この講演のターゲットとなるのは「普段は地元のSIerでコンパイル型の言語を触っているが、Rubyの名前はよく聞くし、密かに憧れをもっていたりするSEやプログラマ」です。

A地点とB地点

A地点は「Rubyはまだ使ったことがないけど、ちょっと興味がある。でも、実際どうなの?いいの?悪いの?」と疑問を持っている状態です。

B地点は「へ〜、Rubyってちょっと面白そう!このイベントが終わったらちょっと試してみようかな」と思う状態です。

講演のターゲットとなる方々が、僕の講演を聞いてこんなふうに感じてくれたら、僕の発表は大成功、ということになります。

「伊藤さんのプレゼンスキル」は果たして!?

当然のことながら、今回のエントリで紹介した「発表のコツ」は、この発表でもすべて実践するつもりです。
ふつうに発表を聞いてもらうだけでも構いませんが、このブログを読んだ人は「発表のコツがどこで使われているか?」を意識して僕の発表を見てみると、より楽しめるかもしれません。

また、僕の講演だけでなく、このイベントでは著名なRubyプログラマの方々が登壇されるので、その内容も必聴です。
さらに、普段北陸地方とあまり縁がない方は、旅行を兼ねて美味しい魚料理やお寿司を楽しむのも良いと思います(僕も妻と金沢や富山を旅行する予定です😄)。

北陸地方に住んでいる方はもちろん、東京や関西など、遠方に住んでいる方たちもぜひ足を運んでもらいたいです。

登壇者情報と参加申込みページはこちらです。
toyamarb.github.io
toyamarb.connpass.com
それではみなさん、11月3日の富山Ruby会議01でお会いしましょう〜!

追記:フィヨルドブートキャンプの受講生のみなさんへ(2022.3.12追記)

フィヨルドブートキャンプの受講生のみなさんが内部LT会の参考資料としてこのエントリをよく見に来ている、という話を聞いたのでちょっと追記しておきます。

このエントリで想定しているのは「ガチめの発表」です。
「ガチめの発表」というのは、オーディエンスが50人以上いて、発表時間も20分以上あって、発表者はオーディエンスにとって価値のある情報を提供することが期待されている、そういう発表のことを指します。

一方、LT(ライトニングトーク)というのは、この業界(ITエンジニア業界)では「ゆるくて雑な発表(でもOK)」と捉えられることが多いです。

少し古い動画ですが、ベテラン勢が考える「(いわゆる)LT」っていうのはこういうイメージなのではないでしょうか(YouTubeでたまたま見つけてきただけなので、ここでこの動画を紹介することに深い意味はありません)。

www.youtube.com

もちろん、LTでもきっちり作り込んで発表するのはまったく構いません!
ですが、もっといい加減で雑な発表であってもLTであれば許されるはずです。
なので、LT会で発表しようかどうか迷っている人は自分の中のハードルを下げて、もっと気楽に登壇を申し込んでみてください😄

【受付終了】TokyoGirls.rb Meetup vol.2の女性登壇者を募集します #tokyogirlsrb

お知らせ

お知らせです。TokyoGirls.rbの第2回ミートアップを2019年12月21日(土)に実施します。
そして、今回は「女性も参加しやすいRuby勉強会」から一歩進めて「女性も登壇しやすいRuby勉強会」を実現するため、女性登壇者を公募します!

f:id:JunichiIto:20190926101100j:plain
第1回ミートアップの風景(2019年3月2日)

募集要項と申込みフォームはこちら!

登壇者の募集要項はこちらにまとめてあります。

公募スピーカー募集要項 - TokyoGirls.rb Meetup vol.2 · GitHub

この募集要項を読んで「登壇してみようかな」と興味を持った方は以下の申込みフォームから申し込んでください。

【受付終了】公募スピーカー申込みフォーム - TokyoGirls.rb Meetup vol.2

募集要項(簡易版)

正式な募集要項は上のリンクになりますが、このページにもざっくりと簡易的な内容を転記しておきます。

イベントの基本情報
  • イベント開催日時:2019年12月21日(土) 13:00〜18:00
  • 場所:株式会社SmartHR(東京都港区六本木3-2-1 住友不動産六本木グランドタワー 39F)
  • 参加人数:50人〜70人程度を予定(男女比は、ほぼ半々)
  • 発表時間:1人あたり15分(質疑応答の時間を含む)
  • 募集人数:3名(このほかに4名の招待スピーカーが登壇します)

なお、イベントページは準備中です。11月中旬の公開を予定しています。

登壇者特典と制限事項
  • 登壇者はイベントの参加費が無料になります
  • 小さなお子さんがおられる場合は優先的に託児室(無料)を提供します
  • 有志によるコミュニティイベントであるため、交通費や謝礼はお支払いできません。あらかじめご了承ください
応募者の条件
  • 「女性も登壇しやすいRuby勉強会」をテーマとしているため、今回は応募者を女性に限定します(女性の定義にはトランスジェンダー(MtF)の方も含まれます)
  • 年齢やプログラミング経験、登壇経験は不問です
登壇テーマについて
  • RubyプログラマやRailsアプリ開発者に役立ちそうなテーマであれば、何でもOKです
    • 女性向けでも、男女を問わないテーマでも構いません
    • 技術的なテーマはもちろん、ご自身のキャリアや生き方に関する話題でも構いません
    • 技術的なテーマは初心者向けの内容でも上級者向けの内容でも構いません
  • ただし、TokyoGirls.rbのアンチハラスメントポリシーに反するような発表はご遠慮ください
  • 選考時は、運営スタッフが「面白そう、聞いてみたい!」と思ったテーマや、「これは多くの参加者にとって役立ちそう」と思ったテーマを優先的に採択する予定です
登壇テーマの例
  • こんなサービスやこんなライブラリを開発しました
  • エンジニアになって初めてわかった知見や気づきを紹介します
  • 運用中のRaisアプリを○○倍速くした話
  • 弊社で実践している開発プラクティスがすごいんです
  • Rubyで始める娘(4歳)の英才教育
  • 私、こんな修羅場をくぐり抜けてきました、などなど
  • 第1回ミートアップの登壇テーマも参考にどうぞ。

これらはあくまで架空の登壇テーマです。実際にはみなさんが自由に登壇テーマを決めてもらって構いません!

登壇者決定までの流れ
  • 申込み締切は 2019年10月9日(水) です(応募者が少ない場合は延長する可能性があります)
  • 申込みの締切後、応募者の情報を伏せた状態で(つまり、誰が応募したのかわからない状態で)運営スタッフが登壇テーマを選考し、登壇者を決定します
  • 2019年10月18日(金)頃に当落の結果をメールでお伝えします

まとめ

というわけで、今回のエントリはTokyoGirls.rb Meetup vol.2の登壇者募集のお知らせでした。
これからいろいろとイベントの詳細を詰めていきますので、前回参加された方も、そうでない方も、楽しみに2019年12月21日(土)の開催日をお待ちください😆

それでは、みなさんからのたくさんの応募をお待ちしていまーす!

第1回ミートアップに関する情報あれこれ

2019年3月に開催した第1回ミートアップに関してはこちらの情報を参照してください。

blog.jnito.com
magazine.rubyist.net