give IT a try

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

Tama Ruby会議01で「テストコードの役割」について発表してきました #tamarubykaigi01

Ruby イベント参加

はじめに

2019年7月6日、渋谷のGMO Yoursさんで開催されたTama Ruby会議01で「なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜」という発表をしてきました。

スライドはこちらです。

このエントリではこの発表の紹介やイベントの感想を書いていきます。

この発表テーマを選んだ経緯

スライドの9枚目にも書いたとおり、もともとは「RSpecを題材にしたテックな話を」とお願いされていました。

f:id:JunichiIto:20190707082424j:plain

しかし、ネットなどを見ていると、「テストって難しい」「RSpecがわからん」と言っているプログラミング初心者さんたちは、テストについて何か根本的な思い違いをしているんじゃないか？という漠然とした疑問や懸念を僕は持っていました。

テストにおける「土台となる考え方」を会場のみなさんと共有したかった

そういう状態でRSpecのテクニック的な話をしてもどこか歯車がかみ合わないというか、発表を聞いた直後は「なるほど、完全に理解した」と思っても、数日経つと結局めぐりめぐって「テストって難しい」「RSpecがわからん」と同じことを言い始めるような予感がしました。
なので、「魚を与えるよりも魚の釣り方を教える」ではなく、「魚の釣り方を教えるよりも、なぜ魚を釣るのか、それは魚でないといけないのか」という話をしたいなと思いました。

また、僕自身、テストを書くときは「○○○だから書く」と何か一つに理由が定まっているわけではなく、あるときはこういう目的で、またあるときはこんな目的で、と、テストを書く目的がいくつかのパターンに分かれていることをなんとなく感じていました。
ただ、これも「なんとなく自分の頭の中にある」というだけで、きれいに整理整頓したことはありませんでした。
そこで、この機会に「なんとなく自分の頭の中にあるパターン」を整理して言語化しようと思いました。

せっかくたくさんの人が集まるいい機会のなので、表面的なテクニックよりもあえて「土台となる考え方」を語って、参加者のみなさんとそれを共通認識として共有する方が価値があるんじゃないか、そして、Tama.rbというRubyコミュニティも比較的初心者向けのRubyコミュニティなので（たぶん）、参加者層を考慮してあえて「基礎の基礎」を語ることはそんなに悪くないのでは？と思い、今回はこのような発表テーマを設定してみました。

当たり前のことをあえて明文化することの価値

とはいえ、発表をする前は「簡単すぎる」「基礎的すぎる」「テック要素が薄くて物足りん」とdisられるんじゃないかと、ちょっと心配していました。
ですが、蓋を開けてみると思いのほか好評だったようで、「このテーマを選んで正解だった」と胸をなで下ろしました。

みなさんの感想はこちらのtogetterページにまとめられています。

ところで、僕は以前どこかで「テーブル設計における正規化理論は、効率良くデータを保存しようとすると誰もが行き着く当たり前の考え方だ。しかし、これをあえて言語化、明文化したことに正規化理論の価値がある」というような話を聞いたことがあります。
自画自賛するわけではないですが、今回の僕の発表も「テストを長年書いている人なら、誰でも経験則として当たり前に思えること」をあえて明文化したことに価値があったんじゃないかなーと思っています。

はじめての基調講演

今回の発表はTama Ruby会議01における基調講演（キーノート）として依頼されたものでした。
基調講演をお願いされたのは今回が初めてで、何をすればよくわかっていなかったのですが、「基調講演の役割は、参加者全員の意識を統一して、あとに続く発表へスムーズにつなげていくことなんじゃないか」と僕は考えました。

そこで、今回の発表では「普段通りの発表 + 最後にこのイベント全体について当てはまりそうな話」という構成にしてみました。
おそらくですが、「基調講演っぽい発表」にはなったんじゃないかと思います。（実際に参加されたみなさん、どうでしたか？）

自己紹介タイムはなし！

あと、これは余談ですが、今回は実験的な試みとして「自己紹介をまったく入れない発表」にチャレンジしてみました。
Twitterの反応を見る限り「で、あんた誰？」とは言われなかったようなので、これはこれで成功だったかもしれませんw

f:id:JunichiIto:20190707095356j:plain
登壇中の僕です（photo by @katsumata_ryo）

イベントの感想等

ここからあとは、Tama Ruby会議01で印象に残っている話をいくつか書いていきます。

持ち時間＝10分制が意外と良かった

Tama Ruby会議01で面白いなと思ったのは基調講演の僕と五十嵐さんを除いて、各発表者の持ち時間が10分間だったことです。
最初は「LTでもないのに、持ち時間10分は短すぎるのでは？」と思いましたが、実際に聞いてみると意外とそうでもありませんでした。
持ち時間が短いぶん、いろんな人の発表が聞けるというメリットがあるので、これはこれでアリかもしれません。

人数は少ないものの、女性の方が元気そうだった

僕は「女性が参加しやすい（でも女性限定ではない）Rubyコミュニティ」である、TokyoGirls.rbの主催者なので、女性の参加率もちょっと気になっていました。
ぱっと見た感じ、女性の参加率は1割ぐらいかな、という印象です。

f:id:JunichiIto:20190707100251j:plain
当日の会場の様子です

理想は男女半々、最低でも3割ぐらいは女性に参加してほしいと考えている人なので、「やっぱりまだまだ女性は少ないなあ」という感はあります。

ただ、参加していた女性エンジニアは、みなさんアクティブで元気そうという印象を受けました。
登壇者の中に女性が2人いたのも評価したいポイントです（しかも、お二人とも短い経歴のわりに骨太な発表だった！）。

そういう意味では「女性エンジニアがもっとグイグイとRubyコミュニティを盛り上げてくれる余地は十分にある！」と感じました。

TokyoGirls.rb Meetup vol.2も開催せねば！

懇親会では女性エンジニアの方から「TokyoGirls.rb Meetupの2回目はやるんですか？1回目がすごく良かったんで、また行きたいです」と質問＆リクエストも受けました。

はい、やります！（断言）

ただし、なかなか手が回らなくて開催はもう少し先になるかもしれません。
ですが、「1回やって終わり」にするつもりはありませんので、もうしばらくお待ちください！！

顔と名前とTwitterアイコンが一致しない問題

懇親会等では「伊藤さん、いつもチェリー本やQiitaでお世話になっています！」とたくさん声を掛けてもらいました。
そんなふうに声を掛けてもらうのは、ちょっと気恥ずかしい反面、大変ありがたいです。

ただ、非常に申し訳なく思うのが、ほとんどの人について「ごめんなさい、僕はあなたのことをよく知らないんです」状態になってしまうことなんですよね・・・。
でも、イベントが終わったあとにふと振り返ってみると、「あ、もしかしたら、あのとき声を掛けてくれたあの人は、もしかしたらこのTwitterアイコンの人だったのかもしれない！（でも、もはや確認するすべがない・・・）」と思うことがちらほらありました。

Twitterアイコンがわかれば、まだ何とかなるかも？

Twitterでよくいいねやリツイートをしてくれたりする人は、なんとなく「よく見かけるTwitterアイコンの人」という形で僕の記憶に残っていたりします。
なので、名札にTwitterアイコンをドカーンと大きく載せてくれていれば、僕も「あ、このアイコン見たことあります！」と、話しかけてくれた人を認識できていたかもしれません。

ですので、イベントの主催者さんは、参加者各人のTwitterアイコンシールを作って名札に貼ってもらう、みたいなことをしてくれると、懇親会での参加者同士のコミュニケーションがさらに盛り上がるかもしれません。
（僕も次回のTokyoGirls.rbとかで、ちょっと検討します）

ちなみに余談ですが、僕はこんなふうにオフラインで会ったときに「顔と名前とTwitterアイコンが一致しない問題」を極力避ける目的もあって、あえて実名と顔写真アイコンでネット活動をしております。

f:id:JunichiIto:20190707102611p:plain:w300
SNSも実名と顔写真アイコンにしておけば、覚えてもらいやすいですよ！

まとめ

というわけで、このエントリではTama Ruby会議01での僕の発表内容と、このイベントの感想をあれこれ書いてみました。

素敵なイベントを主催してくれたTama.rbのみなさん、会場や美味しい料理・飲み物を提供してくださったスポンサーのみなさん、そして参加者のみなさん、登壇者のみなさん、どうもありがとうございました！

次回は渋谷を離れて、多摩地域での開催ですかね？
僕の好きなTMネットワークが多摩出身らしいので、多摩開催も期待しています！w

参考文献

スライドの中で紹介していた、各種書籍のリンクを載せておきます。

テスト駆動開発

テスト駆動開発

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

はじめて学ぶソフトウェアのテスト技法

はじめて学ぶソフトウェアのテスト技法

leanpub.com

ちなみにスライドの33枚目に出てきたRGB変換プログラムのコードは、拙著「プロを目指す人のためのRuby入門」からの抜粋でした。

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

あと、僕の発表スタイルは「パワー・プレゼンテーション」という書籍の影響を大きく受けています。
自分も上手に発表できるようになりたい！と考えている方はチェックしてみてください。

パワー・プレゼンテーション (グロービス思考シリーズ)

パワー・プレゼンテーション (グロービス思考シリーズ)


あわせて読みたい

この発表で使ったスライドの作り方（Keynoteの便利テクニック）をこちらのエントリで紹介しています。
blog.jnito.com

恥ずかしがらずにオープンな場で積極的に質問していきましょう、という話

よもやま話 チェリー本

はじめに

先日、Teratailに以下の質問が挙がっているのを見つけました。

Ruby - irbと打つと「can't find gem irb」とエラーが出ます。どうしたらいいでしょうか｜teratail

質問の内容は、「rbenvのインストール後、irbを起動しようとするとエラーが出て起動しない」というものです。
質問者の方は拙著「プロを目指す人のためのRuby入門」の学習を進めようとして、この問題に遭遇したそうです。

エラーが出てirbが起動しない、という現象は今まで聞いたことがありません。
irbはRubyが持つ基本機能の一つだからです。

原因は僕もはっきりわからなかったのですが、"rbenv-communal-gems"というあまり聞き慣れないrbenvプラグインを使っていたので、もしかしたらこれが原因ではないかと推測しました。
そこで、「もしかすると"rbenv-communal-gems"が原因ではないですか？」回答を入れたところ、予想が的中したようで、irbが正常に起動するようになったみたいです。

質問者の方は「まさかの著者様からの回答、本当に感動しています。ありがとうございます！こんな事あるんですね」と喜んでおられました。

クローズドな場所での質問よりも、オープンな場所での質問の方が嬉しい

質問者の方だけでなく、質問を受ける側（つまり僕）としても、こんなふうに「みんなから見える場所＝オープンな場所」で質問してもらえる方が嬉しいです。

その反対で、ときおりTwitterのDMなどで書籍「プロを目指す人のためのRuby入門」に関する技術的な質問を受けることがあるのですが、こういうクローズドな場所で質問するのはなるべく避けてほしいなあと感じます。

また、この話はネット上の質問だけでなく、IT系勉強会や講演会などでもほぼ同じようなことが言えます。

その理由について、僕が普段考えていることを以下につらつらと書いていきます。

個人的に質問してくる人はフリーライダーだ、という意見

ちょっと前に、ネットで以下のツイートが話題になったことがありました。

上のツイートの画像に書いてあることは以下のとおりです。

  • 海外から来日したある講演者いわく、講演の最後に「質問はありますか？」と尋ねても、日本人は誰も手を挙げない。
  • 講演が終わると名刺交換の列ができ、その最中に「実は質問が・・・」と切り出す人が数名出てきた（もしくは後日メールで質問してきた）。
  • その質問をみんなの前でしていれば、会場の全員が知識を共有できた。
  • 個人的なやりとりで回答を引き出そうとするのは、知識を独占しようとしていることと同じだ。こいつらはフリーライダーだ！（怒）

このツイートを見て、「なるほどなー」と僕は思いました。
たしかに個人的なやりとりで回答を引き出すのは、その人の知識を独占しようとしていることと同じになってしまいますね。

「恥の文化」にとらわれがちな日本人

もちろん、質問する側の気持ちもわかります。
質問する側の気持ちとしてはおそらく、

  • こんな初歩的な質問をみんなの前でするのは恥ずかしい。
  • きっと周りの人はみんな理解しているのに、自分だけが理解できていないに違いない。
  • こんな質問をしたら、みんなからアホだと思われてしまう。

と、こんなふうに思っているのでしょう。

日本人の行動様式は「恥の文化」で特色づけられていると言われます（参考）。
なので、「恥をかきたくない」という気持ちが湧きあがると、その気持ちが最優先されてしまいます。

僕も日本人なのでその気持ちはわかります。
が、技術コミュニティにおいてはその気持ちは捨て去った方が良いです。

あなたがわかってないことは、周りのみんなもわかってない

そもそも、「みんな理解しているのに、自分だけが理解できていないに違いない」と思っていることは、たいてい周りの人も同じように感じています。
ですので、そこで自ら手を挙げて質問をすれば、周りの人はきっと「よく質問してくれた！ありがとう！」と思ってくれるはずです（口に出して言う人は滅多にいないので実際のところはわかりませんが）。

講演者は質問が大好物

それに、講演会のような場面では質問がたくさん挙がった方が講演者は嬉しいです。
逆に質問がまったく出てこないと、講演者は「退屈だったのかな？」「全然理解できなかったのかな？」と不安になります。

つまり、積極的に質問することは、講演者を喜ばせることにもなるのです。

オープンな場所で質問してくれた方が時間の節約になる

ネット上での質問に関していえば、Teratailやスタックオーバーフローのような場所で質問してくれると、僕のような技術書の著者にとっては「他の誰かが答えてくれるかも？」という期待ができます。
DMで質問されると自分以外に答える人がいないので、確実に自分の時間が奪われてしまいます。

加えて、TwitterのDMや、Facebookメッセンジャーのようなチャットツールはたいてい技術的なやりとりをするようには作られていないため、コードやエラーメッセージを貼り付けられても読むのがしんどい、というデメリットもあります。（下の写真を参照）

f:id:JunichiIto:20190703112509p:plain:w300
過去に届いた質問DMの例

なので、技術的な質問はMarkdownのような技術者にとって使いやすいフォーマットを使ってもらう方が、お互いやりとりしやすく、時間の節約になります。

追記その1：あなたが質問すると他の人のハードルが下がる

IT系勉強会などで周りの人が「質問したいけど、恥ずかしくて質問できない」という状況だった場合、あなたが先陣を切って質問することで、他の人がぐっと質問しやすくなることがあります。

・・・という話を以下のツイートで見かけて「たしかに！」と思いました。

追記その2：適切な質問かどうかは講演者 or 司会者の判断に任せましょう

「その場では上手に疑問点が整理できなかったので、懇親会で個人的に質問してしまった」という以下のツイートを拝見しました。

もちろん、質問の内容によっては講演者が回答に困ったり、やたら時間を食ってしまったりする可能性はあります。
ですが、もしそうなった場合は講演者が「あとで個人的にお話ししましょう」と言ってくれたり、司会者が「ちょっとその質問はまたあとで」とやりとりを中断してくれたりするはずです。

ですので、何か疑問に思った点があれば、とりあえず質問してみて、講演者や司会者の反応を見る方がよいと思います。

追記その3：運営側も参加者の心理的安全性を高める工夫を

ここまではずっと参加者に対して「恥を捨てて積極的に質問しよう」というお話をしてきました。
しかし、暗黙の了解として参加者一人一人に「恥を捨てて積極的に質問する努力」を期待するのはなかなか難しいです。

ですので、運営スタッフも勉強会のオープニングで「質問はみんなのため、講演者のためですよ」と呼びかけて、参加者の心理的安全性を高めるようにした方がいいと思います。

実際、先日主催したTokyoGirls.rb Meetupでもそのようなトピックをオープニングスライドに盛り込みました。

f:id:JunichiIto:20190702100424j:plain
TokyoGirls.rbのオープニングで使ったスライドの1コマ

その甲斐あってか、各講演のあとには参加者からたくさんの質問が挙がっていました。

追記その4：質問がなければ、代わりに感想を伝えましょう

本当に疑問点がなかった場合、そして会場の誰からも質問が挙がらなかった場合は、「これは質問ではなく、ただの感想なのですが・・・」と、感想だけでも講演者に伝えると良いです。
何かしらフィードバックを伝えることで、壇上で質問を待っている講演者の「つまらなかった？」「わかりにくかった？」という不安な気持ちを和らげることができます。

追記その5：このツイートの言うとおり

こんなツイートを見つけたので貼っておきます。まさにそのとおりですね。

まとめ

というわけで、このエントリではオープンな場所で積極的に質問していくことの重要性を書いてみました。

上で述べたように、積極的に質問をすることは自分のためではなく、周りの人や講演者を喜ばせることにもつながります。
「恥ずかしい」と感じるのはあなたが日本人だからです。「恥の文化」に染まっているからです。

「質問したい、でも恥ずかしい」と思ったときは、意識的に自分の「恥」を窓から放り投げるように心がけましょう😉

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

技術記事を書くことで得られる5つの効能

よもやま話

先日、Qiitaの技術記事を書いているときに、ふと「そういえば、技術記事を書いてると、こういういいことがあるよなー」と思ったので、それをつらつらと書いてみます。

題して「技術記事を書くことで得られる5つの効能」です。

f:id:JunichiIto:20190620073425j:plain

効能1：自分の理解が深まり、知識が定着する

「いいかげんな内容やウソは書きたくない」、「できるだけわかりやすく書きたい」と考えると、中途半端な理解や知識を必死に埋めようといろんなことを詳細に調べます。
その結果、記事を書く前よりもさらに自分の理解が深まって、知識が定着します。

効能2：「これ読んどいて」で説明が終わる

コードレビューとかをしていて何か指摘を入れたくなったとき、そのトピックに関して過去に自分で書いた記事があると、「この記事を読んで修正してください」の一言で済むことがあります。

コードレビュー以外でも、「先日こんな問題に遭遇しました。みんなも気を付けて！」と、社内に周知するときに役立ちます。

効能3：自分が思い出すのに便利

記事の読者が「未来の自分」になることもよくあります。
僕はしょっちゅう"正規表現 qiita"みたいなキーワードで自分の記事を検索して読み返しています。


効能4：有益なコメントが付くかもしれない

記事に間違いがあったり、さらに良い方法があったりすると、詳しい人がコメントをくれることもあります。
「しまったなあ、自分はまだまだ理解不足だった」と少し恥ずかしくなる気持ちはたしかにありますが、それ以上に「いい情報が手に入った！得したぞ！」と、僕はポジティブに考えるようにしています。

効能5：文章力が向上する

これは技術記事を書いたからといって即座に効果が上がるわけではありませんが、長年にわたってたくさん記事を書いているとちょっとずつ文章力が向上してきます。
仕事でメールを書いたり、Slackで同僚と会話したりするときなど、生きていく上では何かと文章を書く機会はたくさんあります。
文章力がなくて困ることはあれど、文章力があって困ることはないはずです。

その他・間接的なメリットやご利益

打算的な気持ちや下心をもって技術記事を書くことはどうかなと思いますが、記事を書いていると以下のような「間接的なメリット」や「ご利益」があるかもしれません。

他の人が喜んでくれるかもしれない

自分が困ったことは他の人も同じように困っている可能性が高いです。
自分が困っていたことと、その解決策をわかりやすくまとめておけば、他の人たちから「ありがとう」と感謝されるかもしれません。

バズるかもしれない

すごく役立つ記事や技術的に面白い記事だと爆発的な人気が出てバズるかもしれません。
その一方で、とんでもなくおかしな内容やモラルに欠ける内容を書くと炎上する恐れもあります。
「バズ」と「炎上」は表裏一体な点に留意しましょう。

「あの人はすごい人」と評価されるかもしれない

有益な技術記事をたくさん書いていると技術力を第三者に評価され、それが転職や昇給に役立つかもしれません。
さらに、商業誌からの執筆依頼や、IT系イベントでの登壇依頼が来ることだってあるかもしれません。

ただし、「転職したいから」「有名になりたいから」といった動機で技術記事を書いても、大した見返りは得られないでしょう。
むしろ、見返りを考えずに記事を書く方が、めぐりめぐって自分の評価に役立つはずです。
少なくとも、僕自身はそんなふうに考えています。

まとめ：より高い効能を得るために、「楽に書けない記事」を書こう

というわけで、このエントリでは僕が考える「技術記事を書くことで得られる効能」をあれこれ書いてみました。

ただ、効能を得るためには、ある程度の書き手（つまり自分自身）の努力が必要です。
楽に書ける記事には大した効能はありません。

楽に書ける記事というのは、たとえば以下のような記事です。

  • 「自分用メモ」と称して、第三者に分かりやすく説明する努力を放棄した記事
  • 技術記事というよりも、ただの日記になっている記事（今日は〜を勉強しました。明日は〜をやります、みたいな記事）
  • APIドキュメントや技術書の内容を切り貼りしただけの記事（悪い言葉でいうと劣化コピー）

逆に言うと、めちゃくちゃ調べて、めちゃくちゃ時間をかけて書いた記事ほど、高い効能が得られます。

ただし、ここでいう効能とは、あくまで前半に書いた「5つの効能」を指します。
時間をかけて書いた記事ほどバズりやすいとか、そういう話ではありません。
（そもそも、他人からの評価は基本的に自分では操作できないパラメータです）

もちろん、何を書くのかは個人の自由ですが、「何でもいいから書けばいいことがある」というわけではないので注意してくださいね😉

参考：最近Qiitaに書いた記事あれこれ

「実際僕がどんな技術記事を書いていたのか」という具体例を示すために、ここ最近書いていたQiita記事をいくつか紹介しておきます。


タイトルのとおり、13桁のISBNコードを10桁に変換するプログラムをRubyで書いてみました。


仕事でめちゃくちゃハマった不具合があったので、その内容を3つの記事に分けて書きました。


よく見かける「おまじない」について、「それってほんとうに必要なの？」と問いかけて見た記事です。


たとえコンソールプログラムであっても、MVCを意識して作った方がいいよ、という話を書きました。


「Rubyの関数とメソッドの違いって何？」という疑問をTwitterで見かけたので、僕なりの回答を書いてみることにしました。


その他、これまでに書いたQiita記事は以下のページに載っているので、興味がある人は覗いてみてください。