五月末にRubyKaigi 2018が仙台で開催されましたが、既にお伝えしている通り、私たちSiderチームも参加してきました。そこで幸運にも、開発者であり、HerokuのDeveloper Advocateでもある、Jonan Scheffler（ジョナン・シェフラー）氏にインタビューする機会をいただくことができました。
RubyKaigiでのジョナンさんの知名度は高く、特にセッションの合間に突然始まる非公式イベント「デカ外人クイズ」の主催者・出題者として親しまれています。そんな気さくなジョナンさんに、今年のRubyKaigiでの新しい試みから、Herokuでの仕事の話、日本の温泉まで、幅広い話題を語ってもらいました。
なお、本記事でのインタビューは日本語で行われました。日本文化を大学で専攻していたジョナンさんが、日本語で回答してくださったものを、少しだけ読みやすく編集して掲載しています。どうぞご覧ください！
ポーカーリーダーからプログラミングへ
Soutaro:
RubyKaigiの参加者の間では、ジョナンさんは「RubyKaigiに来ると会える”デカ外人”」っていう感じでみんなに知られていますけど、それ以外の方のために自己紹介していただけますか。
Jonan Scheffler:
私のことをみんな知ってるって言われると照れますね。5年前からRubyKaigiに来ているので知り合いは結構いるんですけど、その頃はソフトウェア開発を始めたばかりでした。実は私、昔はいろんな仕事をしていて、ソフトウェア開発の前はポーカーリーダーでした。
Soutaro:
え？
Jonan Scheffler:
カジノでポーカーディーラーをやってました。他にも車の営業とか、いろいろやりました。ホテルのフロントとかね。
ソフトウェアの道に進むことになったきっかけは、コードスクールという、アメリカの6カ月ぐらいでソフトを学べる学校に行ったことです。Hungry Academy (ハングリーアカデミー)というんだけど、ほんとに（コードスクールの中でも）最初にできた学校だったから、入れたのはすごくラッキーだったと思います。運がよかった。
でも、その学校に入る前にはすでにRubyKaigiに来ていました。少ししかソフトウェア開発はわからなかったけど、RubyKaigiに参加しに来日していました。
Soutaro:
そのときは趣味でやってたんですか?それとも大学とか、そういうところで勉強していた？
Jonan Scheffler:
大学ではJavaを勉強しました。そのときは友達も大体Java系の人しかいなかったんですけど、そのみんなはゲームの会社に入って何だかすごく辛そうな仕事をしていたので、「いやあ、楽しそうじゃないな」と思って途中でやめました。最初は学位を2つ取ろうとしていたんだけど。コンピューターサイエンスと、もう1つは日本の文化。日本語の文法もやったけど、文化を中心に勉強しました。だからまだ漢字は読めません。
実は高校卒業後、ロータリーの交換留学で日本に1年間いました。それで日本語を覚えていたので、アメリカの大学の初年度にテストを受けて、大学3年レベルの日本語の授業にいれられました。ただ、大学3年に進級した時、自分の履修していた大学院レベルの日本語の授業が、コンピューターサイエンスの3年次の授業と時間がかち合っていたんです。その二つの授業を同時に取る人は他になかなかいないでしょうしね。どちらかを選ばなくちゃいけなくて、日本文化の方を選びました。
そうこうして、会社に入りました。グラフィックデザインの仕事でフォトショップを使ったりもしていました。仕事でRubyを使っていたので、それでコードスクールに行きました。7年前の話です。こんなところでしょうか。
RubyKaigiと日本
Soutaro:
RubyKaigiへは5年前に初めていらっしゃったということなんですね。それから毎回いらしてるんですか？
Jonan Scheffler:
そうですね。最初に来たのは、Final RubyKaigiというKaigiでした。多分2011年。その次の年、RubyKaigiがなかった年以外は全部行きました。築地と広島と京都とここ（仙台）と、あともう一つの東京で開催されたものがありましたよね。その5つ。
Soutaro:
RubyKaigiによくいらっしゃってるんですね。日本に頻繁に来ているんですか？
Jonan Scheffler:
私は日本にいろんな知り合いがいるから。留学していた青森県によく行きます。
だから、私は温泉などの、青森とかの田舎にあるものがすごく楽しいなと思います。温泉は絶対に入ったほうがいいです。もしRubyKaigiに来ることがあったら、温泉に入んなきゃならない。あっ、でも恥ずかしかったら、家族風呂をおすすめします。もしホテルに家族風呂があれば、予約すれば一人で安心して入れますから。でも、もしできるなら、みんなで入る日本の文化にチャレンジしてほしいですけどね。無理だったら家族風呂がいいですね。
Soutaro:
日本で一番お勧めなのは温泉?
Jonan Scheffler:
温泉かな。温泉とお寿司ですね、やっぱり。
アメリカで出てくるお寿司は大体が日本のコンビニで売っているみたいな寿司です。もちろんアメリカにも素晴らしい店はありますけど、だいたいの店の魚は冷凍したものだからまずい。ウニは特にまずいですね、冷凍すると。その日に獲れたウニが一番おいしいから、日本に来たらぜひウニを食べてほしいですね。アメリカでウニを食べて、「あ、これは食べられない」と思う人は多いと思うので、日本で再挑戦してほしいです。いろんな食べ物を楽しんで、自分の食の嗜好の幅を広げてほしいなあと思います。
Soutaro:
ありがとうございます。RubyKaigiに出席するために日本に来た際には、こんな風に日本を楽しんでもらえたら良いですね。RubyKaigi自体は、どんな風に楽しんでますか？MAGIC？
Jonan Scheffler:
ええ。今年は『MAGIC : The Gathering』というカードゲームの選手権をやってます。「国際Ruby MAGIC選手権」です。
これまで3〜4回ぐらい、カンファンレンスでMAGICをやりました。すごく楽しいんですよ、みんなでやると。友達も作りやすくなりますしね。RubyKaigiでやったのは初めてだけど、来年も絶対やります。
その他では今回生放送をやってます。ペアプログラミング。それもすごく楽しいです。みんなの前でコードを書いて見せるのは、初心者に親切だと思う。プログラミングを始めたばかりの人たちは恥ずかしがったりしますよね。先輩たちのすごさを見て、自分はできないんだって思いますよね。例えば、あなたがgemを出したら、初心者はその完成したコードを読んで「ああ、すごい。これは素晴らしい。私には絶対書けない」って思うかもしれない。
だけど、あなたもそのgemを開発している最中に何回も失敗してきたと思うんです。私は、その失敗を初心者の人たちに見せたいんです。「みんなもこういう失敗するから大丈夫だよ、それで」って初心者にも安心してもらいたい。そういうことを見せるために生放送をやっています。
コードレビューと自動化
Soutaro:
今の、実際に良いコードを書ける人たちがプログラミングしてるところを初心者に見てもらって、「どんな風にやってるか」「どのくらい失敗しているか」っていう様子を見せたいっていう話、すごく興味深かったです。
Jonan Scheffler:
そうですね。別にうまい人だけが入ってくるところではないですね。みんなとやりますけど。みんなで楽しむためにやっています。
Soutaro:
今の発想みたいなのは、仕事をされているなかで、コードレビューとかトレーニングとかをやってきたうえで出てきたアイディアなのかなって思ったんですけども、どこからそういう考えを得たんでしょうか？
Jonan Scheffler:
Herokuにはわたしを含め、Developer Advocateが二人いるんですけど、主な活動はカンファレンスに行くことと、ブログを書くことの2つです。カンファンレスによく行くとは言えないけど、（カンファレンスがどんなものか）だいたいのことはわかりました。
その他に、デベロッパーとコミュニケーションをとる方法を探していたところ、Twitchという生放送を行えるウェブサイトに出会いました。これはゲームの話をしている動画が大半なんですが、最近プログラミングのカテゴリーも出てきて、「ああ、これやってみようかな」と思い始めました。
それを使って、コードレビューをHerokuの内部でやっています。コードレビューや、いろんなエンジニアがどんなソフトを開発しているのかなどの皆に共有したいことについて、Herokuの内部用に非公開のビデオを撮ったり、ポッドキャストを作ったりしています。Herokuの社内の人のカンファレンスが今度あるんですが、その時も社内用のビデオを作って、コードレビューとかの話をします。
Soutaro:
Herokuではコードレビューはどういう風にやっていますか？大事なことだと思うのですが？
Jonan Scheffler:
もちろんですね。大きい会社では、PCIコンプライアンス（Payment Card Industry Data Security Standardクレジットカード業界のデータセキュリティ標準）とかHIPAAコンプライアンス（米国の医療保険の携行性と責任に関する法律）などの様々なコンプライアンスのために、コードレビューが必要です。HerokuでもHIPAAに準拠したサーバーを出していますし、そういったサーバーをリリースする前にも、チーム内で頻繁にコードレビューを実施しました。チームによって違いますが、いろんなツールを使っていました。RuboCopを使っているチームもたくさんあって、私がいたInternal toolsのチームでも使っていました。一般に公開されるツールというよりは、Herokuのソフトウェアエンジニアのためにツールを作るチームでした。
その頃はRuboCopをよく使いました。SaaSの製品も使いますし、flayみたいな複雑さやコードの重複を検出するツールも使っていました。そういうツールを使って、例えば、プログラムの中で頻繁に変更されている部分、つまりコードチャーンが見えるようになります。もしあるコードが何度も編集されているようだったら、やばいところだと思うので、ちょっと目をかけた方が良い。
Herokuの中でも、そういうことをよく行っています。
Soutaro:
今のはHerokuの話だったんですが、これまで幾つかのソフトウェアの会社で仕事をされてきたと思うんですけれども、それぞれでレビューのスタイルの違いとかはありましたか？
Jonan Scheffler:
GitHubで”Approved”とかレビューの結果を表現できるようになる前に、きちんとレビューが通ったことの確認をできるようにしていたことがあります。2、3年前ぐらいの話だけど、絵文字をコメントに書いたらレビューの結果になるようなツールをツールチームで作っていました。チームメイトがレビューして、Pull RequestにThumbs upとかスマイルフェイスを書くと、Approveの意味でそれでマージしてもokになる。もしApproveの前にマージしてしまったら、それはバツで、そのアプリが「誰かがまずいことをやった」ってEメールを送る。
これはチームメイトがApproveするんだけど、Herokuの前の職場はそうではなかった。そのときは、実装の前にアーキテクトの人たちに聞いていました。「こういう考えがあって、これをやりたい」と話して、で、実装してからまたアーキテクトにレビューしてもらう。私はそういう形はあんまり好きじゃなかった。なんか上に偉い人がいて、「あなたたちこれを書け」とか、書いた後は「どうです？」とか、そういう形はいや。ソフトでみんな一緒に頑張れば楽だ。
Soutaro:
ピアレビューイングのほうがやりやすい?
Jonan Scheffler:
やりやすいよね。そもそもアーキテクトって会社の中で3人か5人ぐらいしかいないから、忙しいじゃん。だから、私たちが書いてるコードにすごく詳しいわけじゃない。誰がこのコードについて一番知ってるか？それは私、私たち。だからそういう人に聞けばいいんじゃないって。そっちの形の方が好き。
Soutaro:
ピアレビューする方法と、アーキテクトみたいな「レビュアー」がいる方法、2つを比べたときに、書けるコードの品質とかプロダクトの品質という観点ではどちらが良いと思いますか？
Jonan Scheffler:
作ってるものはピアレビューで強くなると思う。なぜかというと、速く書けるようになるから。それだけで強くなるわけではないけど、速く書けるようにするには、上の（立場の）誰かが見る形は駄目ですね。
例えば私たちが2人でコードを書くと、この2人は全部分かるよね。わたしがあるファイルを書いていたとしたら、チーム全員がその内容を理解できているのが理想的。ただ、チームが少し大きくなって、合計8人くらいになるともう難しいですよね。でもその大きいチームの中でも、ピアレビュープロセスがあれば、みんながコードがわかるようになります。周りは何をやっているところだとか、いろんなPRでコードの全部を見ることができるので、深くまでは見えなくても把握できるようになります。で、そのシステムの全容が分かれば、これはレビューのプロセスとしてうまくいくと思います。
逆に、レビュアーが決まっていてその人だけが確認するような形だけを使うとすると、それは一番まずいと思います。チームの中で他の誰が何をやっているか分からなくなってしまうので。
レビュー自動化サービスの使い方
Soutaro:
ありがとうございます。ところでSiderはご存知ですか？
Jonan Scheffler:
Webサイトぐらいは見たことあるけど、まだサインアップしてない。RubyKaigiに来てから知ったので、これから試したいと思いますけど、やっぱりKaigi中はちょっと忙しいので。
Soutaro:
ちょっと説明すると、Siderはコードレビューを自動化するためのサービスです。いくつか競合がいますけど、我々は「プルリクエストをレビューするときに役に立つ」っていうところにフォーカスしています。
Jonan Scheffler:
Herokuの中でも同じようなサービスは使っているんですけど、みんなあまり見てませんね。大体のエンジニアの人たちが、送信されてくるメールをきちんと読まない。セットアップするときに、あまり気にせず適当にやってしまうので、ちゃんと通知設定ができていなくて、すごくたくさんのメールが来てしまう。そうするとうるさくなってしまって、「まあいいよ、これは。ひとまずおいておこう」って感じに相手にされなくなる。
だから開発を始めるときに、丁寧にやるときには通知の設定をきちんとやります。あんまりうるさくならないように、1日1回だけとか、1週間で1回だけとかに設定します。RuboCopとかも、どのルールを有効にしてどれを無効にしてというのを、丁寧に設定する。きちんと設定しておけば、警告が出たときに無視されることがなくなってちゃんと直してもらえるし、あとは遅いコードの検出とかも見過ごされることがなくなる。
Siderも多分同じで、問題が検出されたときに無視されないようにデザインするのが大切。「あ、これは絶対いけない」みたいな問題から、すぐに直さなくても大したことがない警告までいろいろあるので、その通知を上手く設定できるようにできたら強いプロダクトになると思う。
今はそういうサービスを使っているけど、前の職場では自分たちでflayとかそういうgemを使って、レビュー自動化の仕組みを作っていました。上手くやるのはとても難しいんだけど、ほんとに大切なことだと思うから、いろいろな会社があればいいねって。Siderを使うのはすごく興味がありますね、私は。
Soutaro:
そうですね。ありがとうございます。
Jonan Scheffler:
どうもありがとうございます。
ジョナンさん、お忙しいなかどうもありがとうございました！