Viewing entries tagged
Interview

Scala先駆者インタビュー VOL.7  水島さん(株式会社ドワンゴ/一般社団法人Japan Scala Association)

Scala先駆者インタビュー VOL.7 水島さん(株式会社ドワンゴ/一般社団法人Japan Scala Association)

Scalaコミュニティが広がっていく土壌を作った日本Scala界の父の話を聞きたい

-- 今回は、前回の麻植さんからのご紹介で、水島さんです。まずはじめに、今回水島さんを紹介していただいた経緯を麻植さんからお伺いしたいと思います。

麻植:まず、Scala先駆者といえば真っ先にお名前が挙がる水島さんがここまで登場しなかったことが不思議なくらいで、作為的な何かを感じます!

一同:(笑)

麻植:私が水島さんと初めてお会いしたのが、Scala Matsuriの前身に当たるScala Conference in Japanのキックオフミーティングでした。当時、水島さんが、「そろそろScalaの勉強会の規模も大きくなってきてイベントを開催したいので、運営をやりたい人はいないでしょうか?」と募集をかけていました。そのときは、私自身Scalaにはまりだしてきたところで活発と言える活動はしていなかったのですが、たまたまそのイベント運営の募集を見ていて、イベント運営は好きだったというのもあってカンファレンスの準備から関わらせていただいていました。それで、カンファレンスを開くとなるとスタート時点である程度の規模が必要になると思いますが、その下地を作ったのが完全に水島さんで、日本のScala界の父のように思っています!その辺りの、あるいはそれ以前のScala黎明期については私も断片的にしか話を聞いたことがなかったので、今回お話を伺いたいと思った次第です。

Scalaへの取り組みは自分が大学院生の時から続いています

-- 最初に水島さんの名前を意識したのは、いわゆるコップ本で著者の羽生田さんと水島さんの名前を見かけたというのがきっかけでした。

水島:そうですね、実は自分がコミュニティ活動に参加するようになったのは羽生田さんからの誘いがありまして、そのきっかけになったかどうかは若干記憶が曖昧なのですが、イベントが2007年に開催されたLL魂でした。その当時、自分は大学院生だったので毎年のようにLLイベントに行っていました。

麻植:法林さんが主催されていたイベントですよね。ある意味では、Scalaが普及するきっかけとなる活動を法林さんが行っていたんですね。

水島:LL魂は自分がScalaに関して初めて主体的に発表したイベントで、Scalaで色々試していて面白いなと思ったことを発表するために参加していました。それとほぼ同時期にScalaに興味を持っていた豆蔵の羽生田さんに、一緒にScalaコミュニティを作らないかと誘われたのを覚えています。そして、Scala-beという名前で、コミュニティの結成イベントを豆蔵さんのオフィスで開催しました。それが日本で第一次に注目を集めたScalaコミュニティだったのかなと思っています。自分はそのコミュニティのイベントをホスティングしていたという感じです。

当時のメモを見ながら...

当時のメモを見ながら...

麻植:その当時、コミュニティに参加していた人達の規模感はどれくらいですか?

水島:30人以上はいたと思います。

麻植:その時点で結構な人数がいたんですね!

水島:意外にも人が多く集まったという印象だったのですが、その頃から色んな人が目をつけていたのかと思います。コミュニティ結成後は、そのイベントを乗っ取ったわけではないですけど、豆蔵さんのオフィスをお借りして趣味でScala関連のイベントを活発に開くようになりました。また、Scala-beとは関係ないのですが、個人的なコネで東京大学の研究室をお借りして、2008年にScala勉強会@関東というのを始めました。そこで、恐ろしいことに、いま考えてもなぜそんなことをしたのか分かりませんが、勉強会の内容をほぼすべて自分の発表で埋め尽くしてしまいました(笑)

麻植:よくそんなにネタがありましたね(笑)

水島:Scala勉強会@関東では、参加者の多くが自分の知り合い繋がりだったというのもあって、けっこう濃い質疑応答ができていました。その時に、発表が終わってから質問するのはもったいないなと思って、発表の途中で質問を受け付けるようなスタイルでやっていました。正直に言うと発表する側は多少疲れはするのですが、その方が面白い議論ができるなというふうに感じていました。

麻植:水島さんはそういったライブ感を意識した発表をすることを重視していますよね。Scalaの勉強会では質疑応答だけではなく発表中にもTwitter上で色んなツッコミを入れるようなこともよく見かけますし。

水島:自分がTwitter上でScalaについて活発にツッコミを入れていたのは2010年が一番すごくて、Scalaでキーワード検索して反射的にツッコミを入れる様がボットみたいだという話もありました。今となっては自分以外にもScalaというキーワードに瞬時に反応してコメントする方も増えてきましたが、その辺のカルチャーというか土壌を作ったのは自分の影響があるのかもしれません(笑)

Scala Days初開催の楽しさは今でも印象的です

水島:2010年までは色々勉強会をしたりIT Proで記事水島さん執筆記事)を書くなどの活動を主にしていましたが、2010年になるとScala Days初開催の告知があって、「これは出るしかない!」と思っておもむろに発表を応募して審査が通ったので、「これでスイス旅行だ!」ということで参加しました。その時は、pegexという正規表現のようだけどより強力なマッチングライブラリをScalaで作ってみたという話をしました。また、英語で発表というのはなかなか大変でした。

麻植:英語で発表というのは相当ハードル高いですよね。しかも、その当時Scala関係の知り合いも少なかったでしょうし。

水島:そうですね。でも、Scala Days自体はとても楽しくて、「Scala Daysのこの興奮と熱気を日本に伝えるんだ!」という妙な使命感みたいなものがありました。そのときの様子を、日本語でツイートしまくっている人がいるというのが話題になりました。

-- そのとき思い出に残っていることなどはありますか?

水島:まず、Odersky先生がキーノートスピーチで壇上に上がるときにこけるという、笑ってしまうような出来事が印象に残っています(笑)あと、そのときはScalaが2.8になるというのがビッグニュースで、Scalaが新しくなることに対する興奮と熱気であふれていたのが印象的でした。

麻植:他にはどんなニュースや発表などがありましたか?

水島:いよいよScalaを使ってみましたという実例や、どうやって組織に浸透させていくのかという発表が多かったです。どうすればScalaを上手く企業に導入できるのかという話題はかなり盛り上がりました。

-- そのときはどういった解決策や案があったんでしょうか。

水島:まず、小リスクで始めようというような趣旨の話がありました。モデル、ビジネスロジック、アプリケーションエンドポイントなどどこで使っていくかという議論があると思いますが、まずはUnit TestをScalaで作るというところから少しずつScalaを浸透させていくのが導入しやすいのではという案がありました。その辺の、冒険的なことは避けようといった考えは変わっていないと思います。
そういえば、そのときの大イベントを他にも思い出したのですが......。Scala Days二日目あたりに、スイスのエイヤフィヤトラヨークトル火山が噴火して、火山灰がヨーロッパ中に広がった影響で交通が麻痺して帰路が延期になってしまいました。ニュースでは一ヶ月くらい足止めを食らうのではということも報道されていました。

麻植:それは、大変ですね......。いつ復旧するか分からない中でどうしていたんですか。

水島:ほとんどの参加者は足止めを食らっていたわけですが、実はそのとき、Odersky先生が一緒にランチしませんかとTwitterで告知するという粋な計らいをしてくれて、そのときまでは気分が沈んでいたのですがランチに参加して元気を取り戻しました。
そういえば、初開催のScala DaysはEPFLで開催されたのですが、Scalaのロゴのモチーフになっている螺旋階段の写真を撮ったことや、螺旋階段を下りながら帰ったのも記憶に残っています。それがとても貴重な体験だったのでまたEPFLでScala Daysを開催してほしいと思っています。

麻植:今は規模が大きくなって難しいのかもしれませんが、私もEPFL行ってみたいです。ちなみに、その当時での参加者はどれくらいでしたか。

水島:だいたい150人くらいだったと思います。規模感からいうと初回のScala Conference in Japanと同じくらいですかね。

色々な人と関わりながら無頓着にScalaの普及活動に情熱を注いでいました

水島:Scala Daysについては、 トラブルなどがありながらも研究室見学など楽しんでいました。一方その裏で、名古屋でScala座というイベントをやろうという話しがScala Daysの開催前からあがっていました。そのイベントには、今でもScalaを使っている西本圭佑さんや、今は観察者的なスタンスでやられているゆるよろさん、証明言語などをやられている今井宜洋さんなどが参加されていて、これをきっかけに知り合った人が多かったです。

麻植:そして、その行ってきたブログを書いたのが吉田さんなんですよね。

水島:そうですね、直接吉田さんとお会いしたわけではないのですが、ここをきっかけに自分を認識してくださった方が結構いるらしく、これを機にScalaコミュニティを都内からもっと広げていこうという活動が活発化していきました。

-- 少しずつ歴史が紐解かれていきますね。

水島:そういえば、Scala黎明期の話をするなら触れないわけにはいかないのが、Scala勉強会@東北という勉強会です。初回が2008年で、主にオンライン上でやっていたのですが、開催回数は合計100回を超えてます。これを主催していたJCraft山中淳彦さんがすごい方で、一人でLiftのコミッターをやられていたり、WiredXなんかはボーイングに搭載されたとも聞いています。その、技術者としての腕もさることながら、100回以上の勉強会を続けられていたというのがすごいと思っています。

-- 水島さんもオンラインでその勉強会に参加されていたんですか?

水島:そうですね。興味のある人がマイペースで参加するという感じでやっていたところに、その当時は今よりも遥かにScalaに対する使命感が強かったので参加してましたね。

麻植:そういった、色んなところに行かれて登壇をするなどの活動を精力的にやられているところが水島さんのすごいところですよね。そのパッションはどこから来たんですか?

水島:自分でもわりと謎なところはあります。最初に一回勉強会をやってみようというのは行き当たりばったりだったのですが、段々とScalaの思想を理解していくと、色々妥協した点はありつつも設計思想としてとても良くできた言語だなという実感がありました。また、その当時は他にScalaと比較できる言語が無かったということもあり、そういった点でScalaに対して惚れ込んだというのが大きいですね。

麻植:でも、Scalaに惚れ込んだあと、それを日本各地に飛んで発表しに行くというのはまた一段ジャンプがある気がするのですが、それはどうやって乗り越えたんでしょうか。お金も時間もかかりますし、そのパッションは凄いことだと思うのですが。

水島:そこは自分が大学院生だったので、無頓着に思いきりScalaに投資できたのかなと思っています。大学院生にもなると、自分の研究と後輩の面倒を見ることくらいにしか時間を割くことがなくて尚且つその配分は学生に委ねられていました。なので、思い切りScalaに時間を使うことができました。その時間をもっと研究に費やした方が良かったのかもしれないなと思ったりもしますが(笑)

麻植:いやいや。それが今どれだけの仕事を生んでいるのかという話になるんですけどね(笑)じゃあ、その当時、水島さんが大学院生だったというのも良かったんですね。

水島:そうですね。大学院生時代のそういった活動があったから今の自分のポジションがあるのかなとも思いますし、大学院生でなければそれだけ続けられなかったのではないかと思います。

就職した後もScalaの普及活動を継続していました

麻植:実際、そのあと就職された時は仕事でScalaを使っていたんでしょうか。

水島:はっきり言うと、現在のドワンゴの職に就くまでは基本的にScalaを仕事で使うことはほとんどありませんでした。最初は、VMをカスタマイズしてお客さんに納品するといった、少し変わったビジネスモデルの仕事をしていまして、CやJavaを使っていました。ただ、少しだけ、テストケースを書くときにScalaを使っていました。

麻植:では、基本的には仕事でScalaを使うことはなかったんですね。

水島:ただ、本の執筆活動は行っていまして、今は絶版になってしまったのですが、2011年に「オープンソース徹底活用Scala実践プログラミング」というScalaの本を書いていました。この頃から日本語でScalaの本がちらほら出てき始めていて、自分達も執筆しようということで取り組んでいましたが、就職してすぐに執筆作業をやっていたので書籍執筆は大変だということを当時感じていました。
2011年の後半になると日本Scalaユーザーズグループの設立に伴って、今のScalaコミュニティでよく名前を耳にする方々が新規参加者として増えてきました。例えば、かとじゅんさんや吉田さんがいます。また、時期は前後するのですが、別途、吉田さんもScala勉強会@渋谷というのをやられていました。

麻植:今のrpscalaに当たる勉強会ですね。

水島:はい。そういった感じの勉強会を開催したり、会議で集まったりしていました。また、ニコニコ超会議でScalaの話をするなどの活動をしながら、Scalaの布教活動としてネット上で荒ぶっていました(笑)2011年だったと思うのですが、その年が一番荒ぶっていたと思います。間違いに対して突っ込みを入れまくっていたりしたので、当時を知っている色んな人の日記に自分の名前が載ったりしていました。

麻植:水島さんが荒ぶっていたエピソードと言えば、Matzさんと水島さんのやりとりがtogetterでまとめられていたのが印象的なのですが。

水島:Scalaの複雑性についての話についてですかね。RubyとScalaを引き合いにした複雑性と難しさの話をしてました。この辺で一つ得たものがあったとすれば、複雑さと難しさは違うという話があります。Rubyは、文法的には比較的難しいのですが、それを扱うのは難しいとは思われてないですよね。

麻植:Odersky先生もいつもそこを強調していて、「simple is not easy」ということを言っていますね。Scalaの設計自体はシンプルな作りにしているものの、それを扱うのが簡単という訳ではないという議論があります。

水島:そういえば、この時は2010年なので自分がまだ大学院生のときですね。

-- 大学院生最後の荒ぶりというところですかね(笑)

水島:Matzさんとは元々面識があって、わりと気軽に絡めてはいたつもりなのですが(笑)

麻植:もともと面識があってある程度信頼関係があるということを知らない人から見ると、とてもドキドキするやりとりだったと思います。ちなみに私もその当時とてもドキドキしながら見ていた記憶があります(笑)

麻植:ちなみに、先ほどは荒ぶったという風にネタにして表現をしてしまったのですが、それは間違った情報を流通させないという文化が根付くきっかけにもなったと思うので私はポジティブに捉えています。

水島:それは今の自分の行動にも無自覚的に影響していると思います。間違ったことがあったら容赦なくツッコミを入れる文化みたいなものが日本のScala界隈に根付いたのかなと思います。

麻植:技術的な突っ込みを入れる時に、それは人格攻撃とは全く無縁で、あくまでも正しさを追求する為の共同作業であるというカルチャーは、私にとってはScala界隈に入ってから自然と馴染んでいった気がします。

水島:技術的な間違いに対する突っ込みは決してネガティブなことではないと思っていますが、一時期はScalaが怖いといったような内容をTwitter上でよく見かける時期もありました。

一同:(笑)

麻植:そういったイメージはScala初心者への敷居を高めてしまう印象があるのかもしれませんが、その一方で、初心者向けのイベントも水島さんがよく開催されていたりと、初心者に対して門戸をむしろ広げる活動をされていましたね。オープンマインドで色々議論できるカルチャーを作る為に、そういった考えが受け入れられると良いなと思います。

水島:学術研究においても、間違いの指摘をする際は比較的端的な言葉でやりとりされることが普通ですし、間違っていると言われたら謝らなくてはいけないなどとあまり深刻に考える必要はないと思っています。悪意があって言うのではなく単純に指摘をしたいだけであるというのが広がれば良いなと思います。

麻植:そういう技術的なツッコミをネタにしてしまうと余計な誤解を生んでしまうことはあるのかもしれないなと、自分でも反省しないとなと思っています。

水島:自分もついネタにしてしまうこともあるのですが......。

一同:(笑)

麻植:Scalaに対するイメージは色んな人がそれぞれの考えをお持ちかと思いますが、特にScalaの初心者向けに草の根的な活動をしている方々も最近は増えていますよね。

水島:最近は、特にScala関西の方々が精力的に活動されていますよね。

麻植:今度、10/8(土)に開催されるScala関西Summit関連だときの子さんは初心者向けの勉強会を積極的に開催されていますね。Scalaのコミュニティー活動も日本各地で活発になっているのを感じます。

水島:あとは、ヌーラボの縣さんが中心になって開催されたScala福岡なんかもありますよね。九州コミュニティも徐々に活発になっているという印象です。

最近はScala教育に力を入れています

麻植:最近の水島さんの興味はどの辺りに向かっているのでしょうか。

水島: 最近だと、ホームページが公開されてしばらくになりますがDottyの動向が気になっています。今のScalaに関しても継続的にウォッチしてコントリビュートしていきたいとは思っています。将来を見据えて言うのなら、DottyがいずれはScala仕様として置き換えられるようなので、そこに先駆けてコントリビュートしていくのが良いのかなと思っています。

麻植:この前、Scala Daysに行った先でOdersky先生と立ち話をした際に、Dottyはいつくらいに入るのかと聞いたところ「Hopefully 3.0」と言っていました。なので、もっと先の話になる可能性はあるなと思っています。

水島:ホームページでも「it will be - eventually」となっているのでまだ先の話かもしれないですね。一つはDottyで、もう一つはScala Nativeですかね。中長期的な目線で情報を追っていってコントリビュートしていきたいところです。それらと並行して、Scala教育に関する取り組みはを更に洗練させていきたいですね。

-- そういえば、ドワンゴさんがScala新卒研修の資料を公開されたと思うのですが、その後の反応はどうだったんでしょうか。

水島:反応はそんなに悪くないと思いますし、よくできた資料ですねというようなコメントをTwitter上でいただいたこともあって嬉しかったです。公開したからには、色々なフィードバックをもらいながら改良していきたいです。また、公開した資料をきっかけに、とある大学の方がインターンシップに応募していただいたこともあり、公開した意味はあったと思います。

麻植:資料作成には水島さんはどれくらい関わったのですか?

水島:公開されている資料のうち、5分の4くらいは書いたと思います。また、作成した資料を元にして自分が社内のScala勉強会を主導したりもしています。あとは、ドワンゴが設立した通信制高校であるN高で、オブジェクト指向の初学者向けにScalaを使った講義を開催する話があるのですが、その教材のレビューもしています。

麻植:では、最近の仕事では、そういったScala教育などの方面に注力しているということでしょうか?

水島:そうですね、実際にはScalaの研修資料の継続的メンテナンスとそれらを社内で主導してくこと。さらに、自分の好きな研究をやったりしています。自分の他にも江添さんという方も研究的なことをしているのですが、そういったポジションにつけるのはドワンゴのScalaエンジニアの層の厚さがあるからこそだと感じています。これで給料をもらってよいのかという葛藤はありますが(笑)

-- 研究開発や教育という立場もとても立派なことだと思いますよ。

水島:もっと堂々と自身を持ってScala教育と研究に携わっていますと言えるように精力的に活動していきたいところです。

-- ちなみに、Scalaの社内勉強会というのはどういった具合で開催されているのでしょうか。

水島:今の所は週に一回ペースでやっていて、チームのメンバーがScala再入門のような形で資料を読み進めて、質問があれば随時対応するようなことをしています。実際に資料を読み上げていると新たな気づきもあるので、眺めるだけではなく実際に触れてみるということが大切だと感じています。

麻植:ちなみに、新卒の方がメインでその資料を利用していると思うのですが、そちらの研修はどういった具合で進んでいるのでしょうか。Scala教育で困っている色んな会社さんの参考にもなると思います。

水島:今年はScala強い勢の方々がいたのであまり困らなかったのが正直なところです(笑)

麻植:ポテンシャル採用のような方達に向けてはどのように教えるのでしょうか。

水島:そういった人たちには、できる人が教えるという形でした。また、新卒の方が分からなかったことをまとめて社内Qiitaのようなものに書き込むなどしてます。社内で新卒入社組でお互いにサポートしてくれているのが助かっています。

-- 新卒の方々の他にも中途の方など様々な方が入社されると思うのですが、そういった方々に水島さん自身が刺激を受けることはあるのでしょうか。

水島:入社時点ですでに競技プログラミングなどで実績を残している方などはほんとうにすごいなと思っていたりします。あとは、社内Slackの技術チャンネルで技術について語り合うなどで刺激を受けていて、ドワンゴくらいの規模があって色んな人がいるからこそだと思っています。技術チャンネル以外にもアニメチャンネルなどもあります(笑)

プログラミング言語に対する興味は尽きないです

麻植:実際、今でも色んな言語を触っていると思うのですが、他の言語で興味があるものの中でランキング一位はズバリなんでしょうか。

水島:いまのランキング一位だとRustですかね。一つは、メモリセーフでありながらGCのようなパフォーマンスの不確定要素は排除しているというところです。Rustを使っていると驚くのが、なぜこれがコンパイルエラーになるんだ!みたいなものが沢山出てきます。例えば、オブジェクトを引数に渡して、渡した後にそれを参照するだけでコンパイルエラーになります。要するに、引数に渡した時点でリソースを使用したとみなして、再利用できないというリソース管理の方法を型システムによってプログラマに強制しています。

麻植:そういった仕組みは、例えばどういった用途に向いているんでしょうか。

水島:汎用プログラミングに使うのが難しいということはありますが、一方でシステムプログラミングに極めて向いていると言えます。つまり、OSを書く、システムコードを呼び出す、あとはブラウザの下のレイヤを実装するなど従来Cが適していたと言われている領域です。システムプログラミングではパフォーマンス特性を把握しやすいということが重要なので、性能の不確定要素を取り除くための設計は助けになると思います。

麻植:Rustは関数型界隈でも時折話題に上がるかと思うのですが、型クラスを言語としてサポートしているんでしたっけ。

水島:traitというのがあって、幾つかの制約はあるものの基本的には型クラスと同等の機能を持っています。型クラス勉強会というのが今度開催されるのでそちらでも詳しい話をしようかなと考えています(公開日現在は終了)。

これからに向けて

-- では、最後に水島さんの方から一言いただけますでしょうか。

水島:自分が一番適していた役割はある程度果たしてきたのかなとは思うのですが、今後もScalaの普及活動およびScalaのより良い学習方法などを考えることを主軸に活動していきたいと思います。また、Scalaに限らず、プログラミング言語の研究や好きな構文解析への探求なども継続していきたいと思います。

-- 次回の話をしたいところなのですが、この企画を開始して暫くしてから、水島さんをラストに迎えて終着という思いがありましたが、まさかこんなにも早く水島さんを迎えることができるとは思ってもいませんでした。企画をやっていてこうやって色々なお話を聞ける場が楽しいので、続けたい気持ちもあります。また、一旦区切りをつけて違うテーマをつけてシリーズで始めるのも、メリハリができてアリなのではないかとも考えています。読者の視点も踏まえ、ご意見などいただけると嬉しいのですが、どう思いますか?

麻植:私も、水島さんを紹介するにあたって、本当に今紹介しても問題ないのかと確認してしまいました(笑)

水島:真のラスボスとしてOdersky先生を紹介して、Scala先駆者インタビューに続く新たな企画を相談しに行くというのも面白いかもしれないですね(笑)

麻植:海外に目を向けるというのも面白いですね。ここらで一旦、先駆者という視点を離れて新しい企画を練るというのはアリだと思うのですが。

-- なるほど。ではその辺りも踏まえて、水島さんが思うScala先駆者の方でこのシリーズを締めくくらせて頂いて、次の企画を考えるなどしていきたいと思います。

水島:では、前回と今回ではScala Matsuriつながりで来たので、少し趣向を変えて、ドワンゴ繋がりもあってScalaをプロダクションで積極的に使っていくという面で先駆者だと思っているかとじゅんさんを紹介したいと思います。

-- ありがとうございます!本日は長時間どうもありがとうございました。

出席者

  • インタビューイー 株式会社ドワンゴ/一般社団法人Japan Scala Association 水島
  • インタビューワー アットウェア 浅野・三嶋、 株式会社BONX/一般社団法人Japan Scala Association 麻植

過去のScala先駆者インタビュー

Scala先駆者インタビュー VOL.6  麻植さん(株式会社BONX/一般社団法人Japan Scala Association)

Scala先駆者インタビュー VOL.6 麻植さん(株式会社BONX/一般社団法人Japan Scala Association)

麻植さんならコミュニティの方面にも話題を広げられるかなと

-- 今回は前回の大村さんからのご紹介で麻植さんです。大村さんと繋がりある方の中でこの企画で次に話を聞いてみたい方として麻植さんをご紹介いただいた経緯を聞かせてください。

大村:吉澤さん、瀬良さんと続いて、その後、竹添さん、前出さん、そして私も前職がSIerだったということもあり、Web周りの事がキーワードとなって続いてきました。麻植さんをご紹介したのは、Scalaのコミュニティのエキスパンションにすごく力を入れられており、コミュニティの方面に話題を広げられるかなと思ったのと、お互いが興味を持っていて知り合うきっかけになったDeeplearning4J話を中心に機械学習の方面のことも話題にできればなと思いました。

-- この企画はごきげんよう形式で、次の人をご紹介していただいて繋がりがある二人を中心にインタビューをさせていただいており、当日の話を踏まえた上で次に聞いてみたい人をご紹介のお願いをするのですが、「麻植さんのお話も聞いてみたいよね」とあがる事も多かったです。

麻植:ありがたいことです(笑)

-- 私の方から「〇〇さんをご紹介ください」というのはしておらず、流れの中でご紹介頂く形に乗っかりたいなと思っているなかで、大村さんの第一声が「麻植さんいかがでしょうか?」とでてきて、「おぉっ!!」となりました。

麻植:こうやって声をかけてもらえるのはとても光栄だなと思いつつ、自分が先駆者って言える所ってどこかな?と考えてみたのですが、なかなか難しいなと思うところが幾つかあります。

黎明期に日本でScalaを広められたのは水島さんだと思います。水島さんがScalaのカンファレンスを日本でやってみたいという声に賛同して、私もScalaコミュニティの活動をやりだしました。

Scala Matsuriの前身であるScala Conference in Japanに最初から関わっていたとはいえ、そういう背景の中でどんなお話ができると面白いかなと考えてきました。

コミュニティワークの輪としてできたこととして、日本のScalaコミュニティと海外のScalaコミュニティを繋げるというところは、私が先駆者っぽい貢献ができたのかなと思っており、そのあたりの話ができたらと思います。

アイディアの源泉を辿ると

大村:今年のScala Matsuriで、Scala By The Bayという大きなカンファレンスを主催しているAlexy Khrabrovさんなどを日本に招待して実施した、世界のカンファレンス集めた「コミュニティLTセッション」あれ良かったですね!

麻植:実は前から、「数あるコミュニティがどういう活動をやっていて、どういう人がいるのか知りたい」「コミュニティの活動を発表したい」という声がスタッフからもあがっていました。せっかく今回Scalaカンファレンスを海外でやっているオーガーナイザーが日本に来てくれることになったので、やらない手はないと思い開催直前にやりたい言ったら、大きな反対もなく実現しました。

AlexyさんとはScala Daysでお話させてもらっていたのですが、Alexyさんと仲が良いDeeplearning4Jの開発者のAdamさんから「AlexyがScala Matsuriに行きたいって言っていたよ」と聞き、また彼からもコンタクトをもらった後、やりとりも盛り上がり、イスラエルなど世界各地のコミュニティの方や、Scala関西サミットオーガナイザーのきの子さんなど日本各地のコミュニティの方の参加もあって、いい企画になりました。

今年のScala Matsuriでは他にもパネルディスカッションなど、たまたまその場に来た参加者が集まって1つのコンテンツを作るという趣旨のセッションも多く開催されました。

過去にはコードクリニックという、Martin Odersky先生に希望者のソースコードをレビューしてもらえるセッションをしたこともあり、Odersky先生の指摘に「いやいやそれは好みの問題でしょう」という返しをする方もいたりして、とても盛り上がっていましたが、当時は内心ハラハラして見ていた記憶をしています。(笑)

Scala Matsuri開催にあたってこんな草の根活動をしてました

-- 今回のScalaMatsuriで印象に残っていることは、参加者が見たいセッションを投票する形式で、発表者の倍率がすごいことになっていたことでした。注目度のすごさを感じました。

麻植:カンファレンスのトークのクオリティは競争率に比例する部分も少なからずあって、その時に多くの方のサブミッションを集めたく、コミュニティ運営のイベントなので透明性を担保したいという思いがありました。

スタッフの一人であるEugene Yokotaさんのアイディアで、彼の好きな「NE Scala」というカンファレンスで採用されている投票制にインスパイアを受けて、議論した結果CFP(Call For Proposals)を試してみようということになりました。

-- ここ数年、Scala Matsuriはチケット発売から完売までがあっという間で、注目度・人気が高いカンファレンスです。そういうカンファレンスには発表者自らの申し込みも多いと思います。いつ頃から発表応募者の増加が顕著になってきたのでしょうか?

麻植:最初の2回、2013年と2014年には招待講演者枠という形で海外のMartin Odersky先生や当時LinkedIn社内でPlayの開発リーダーだったYevgeniy Brikmanさんなどに発表をお願いする事はありましたが、それ以外の方は招待というより、お声がけして勧誘して応募して頂く形でした。

大村:今回はCFPのみでしたので、誰が来るかは投票が終わるまでわからないので違った意味で面白さもありました。主催者としてはスピーカーが埋まらない事も心配されたのではないでしょうか?

麻植:草の根活動として、1年前近くからアメリカで開催されたScala Daysをはじめ、他の世界各地のScalaイベントに出向き、多くの現地の方に宣伝しました。特に一番最初のタイミングで「CFPに応募してくれそう」という方を見つけるところからでした。過去にもOdersky先生が基調講演をするということがある前提で、話が広がったり次に繋がったりしていきました。

一番最初にどういう人がしゃべるか、誰が応募しているかは誘引力としては重要でした。

実は当初Scala Matsuriは2015年の秋にやる予定だったのですが、アメリカのイベントでScala Matsuriのことを伝えると「日本に行くんだったら冬がいいな。スノボやスキーがやりたい!」って言う人が多かったんです(笑)

いつの間にかスノボやスキーの話になっていたのですが、改めて落ち着いて話をきいてみたところ、Scalaはそもそもスイス工科大学で作られた言語で、近隣にコアな関係者が多く、土地柄アルプスも近くてスキーをたしなむ方・好きな人が多いのです。

あまり知られていないのですが、日本は世界有数の豪雪地帯で雪質がいいことで有名なんです。北海道のニセコは海外の方に大人気で、Lightbend社の方達がScala Matsuri直前にニセコツアーを組んでがっつり滑って、その様子をTwitterで流されていました。

今の話はカンファレンスのコアとは関係ないですが、片道12時間のフライトで来てもらうとした際に、カンファレンスの魅力だけで勝負するよりもプラスアルファの楽しみがある方が来たくなりますよね。

そういう事を考えて日付設定するのはそれほど間違っていないと思い、Scala Daysの初日に日本のスタッフとチャットで議論をしたら合意がとれたので、2日目に「冬にしたよ」と言ったら、とつぜん肩を組まれて「Great Decision!(素晴らしい決断だ!)」と言われました。(笑)

そこで話をしていた人が真っ先に複数本CFPを出しくれて、その時のメンバーがLightbend社CTOのJonas BonérさんやAkka開発者のKonrad Malawskiさんなどでした。

こういう事が誘引力となって広がり、CFPでたくさんの方に応募していただき盛り上がったんだと考えています。

-- いい連鎖反応ですね!

大村:Konradさん含むAkkaのコアコミッターの方達やOSSで活発に活動している方達がいらっしゃって、そういった方達とScala Matsuriで議論できてよかったし、アジアのコミュニティをアピールできたいい機会だったのではないかと思います。

麻植:そうですね。

世界と日本を繋ぐということは

--アジアや日本は海外からどう見られているのでしょうか?

麻植:海外の方が日本のScala Matsuriに来て口々にするのは「コミュニティの大きさ」と「活発さ」です。

Scala Matsuriは世界で見ても5指にはいる規模だと思います。おそらく3位くらいの大きさです。
世界各地にはたくさんのカンファレンスが存在し、200人くらいの規模が多いですが、Scala Matsuriは500人規模で、一段階大きい、数少ないカンファレンスです。

-- コミュニティの形成は簡単ではないように感じます

麻植:はい、いろんなバックグランドの方が集まると、イデオロギー同士の衝突があります。イデオロギーは星の数ほどあり、カンファレンスとしてはイデオロギーに関わらずできるだけ多くの人が集まれる環境にしたというのは、コミュニティ主催のイベントはどこも持っていると思います。

それを、どういう風な思想にするかは行動規範に現れてきます。スタッフでは他の事例をシェアして参考にしあったり、Scala Matsuriのケースに照らし合わせ議論したりしています。

-- 汎用的につかえる行動規範や麻植さんのScala Matsuri2016のふりかえりブログエントリーを拝見しました。

麻植:私の中であの記事を書いたのには理由があります。

Scala Conference in Japan発起時のことです。発起人の水島さんと話した際に「日本のScalaコミュニティがどんどん大きくなっていくとはいえ、海外のコミュニティとはまだ距離がある。そういう所を埋めるイベントを作りたい」というのが経緯となって始まりましたが、最初の2回は海外からの一般参加者がほとんどいませんでした。

今回のScala Matsuri 2016では招待ではなく一般参加で海外から参加したり、CFP応募してもらったり、言葉の壁があったにもかかわらず楽しんでもらえました。4年越しでようやく海外コミュニティとの交流が実現でき始めたな、ということを1日目で感慨深く感じたので、ああいう感じのブログをまとめてみました。

モチベーションは「楽しんでもらえる」という喜びから!

-- カンファレンスのエピソードやふりかえってみて楽しかった思い出はありますか?

麻植:楽しかったことは、ScalaTestの作者でScalaスケールプログラミング(通称コップ本)の共著者でもあるBill Vennersさんから、Scalazのメンテナの吉田さんとしゃべりたいから紹介して欲しいと言われて、懇親会でその二人の会話を通訳していたのですが、それがすごく楽しかったです。

大村:いいですねー。

麻植:その時の様子は吉田さんのブログでも紹介されているので、もしよかったら見てください。

生で温度感を感じながらみていると、コミュニティの人間模様が見えるところに面白さを感じます。実は○○さんが××さんのファンだったりすることも少なくなく、Bill Vennersさんは完全に吉田さんのファンでしたね(笑)

技術的に面白いので勉強になるし、海外と日本の人が繋がった瞬間でした。また、そのディスカッション結果が今後ScalaTestにも反映される可能性もあり、こういった機会を提供できたのが面白かったし、いろんな楽しさが凝縮した瞬間でした。

-- これだけのことをするにはモチベーションがないとできないと思いますが、やりがいやモチベーションはどこから湧いてくるのでしょうか?

麻植:(ひと呼吸おきながら)私の場合は「自分の開催したイベントに来て楽しんでくれている」というのが、一番嬉しいです。そのイベントだけに終わらずにイベント後に繋がる方もいて、「当日学んだことを活かしてこういうことをやり始めた」という人や、「興味や関心がわき仕事の方向性を変えてみました」という人、こういう話を聞くとうれしくなります。

自分が貢献できることがあるというのもモチベーションになります。
最初のキックオフミーティングのできごとです。各自の役割を割りふってみたのですが、誰も手をあげないポジションが1つだけありました。「経理」というポジションです。

ややこしいし、責任もあるし、エンジニアとしてはそれほど好きな役割ではないですよね。
昔に経営管理やイベントの収支管理を仕事でやっていたことがあり、私としては苦にならないので「私でよければやりますよ」ということで、「経理」という役割を引き受けました。

海外交流を狙ったカンファレンスということもあり、以前公用語が英語の職場にいたこともあったので、ある程度コミュニケーションもとれると思い、「これは自分の好きな領域で自分ができることが多く、かつ需要もある」ということで、ピタッとはまったなという実感があり、モチベーションが湧いたことを覚えています。

基本的にコミュニティ活動は自分の時間を使ったボランティアワークなので、「うれしい」とか「楽しい」など自分にとってメリットがあるから、継続して活動できます。

実際、他のカンファレンスではオーガナイザーがオーバーワークで継続難しいから開催を断念することになったり、そこまでいかずとも無理がすぎてネガティブになってしまった事例もしばしば目にします。やはり活動そのもの自体が楽しいからこそ続くんだと思います。

-- 社内勉強会や小さなコミュニティでも通ずるものがありそうですね。

麻植:そうですね。私もタイミングが合った時に参加している「rpscala」という5年くらい150回を超えて続いている勉強会があります。僕を含めたオーガナイザーの中で継続性の話をしたときに「続く秘訣はゆるさですね」と話題になりました。

毎回特定の人たちだけでネタを用意して発表してたりするとネタはすぐ尽きますし、来れないこともあります。コアメンバーの仕事が忙しくなってこれなくなってしまうと、勉強会が続かなくなってしまいますが、rpscalaの場合は発表会のネタは誰が用意するかは明確に決まっていなくて、その時にしゃべりたい事がある人に手をあげてもらったり、しゃべることがなければ、その時のホットなScala界隈のニュースを紹介して、リリース系の話題だったらどんな機能があるかをみんなで見てみたり、質問から広げてその場で座談会になったりして、毎回空気に合わせてやることがかわり、最後に飲みに行くというような感じを続けています。

こういったゆるさで誰も疲れないというのが、コミュニティを長く楽しく続ける秘訣なのかもしれませんね。

大村:いい話ですね。

麻植:Scala以外でいえばもっとコミュニティ活動を長くしている方もたくさんいらっしゃるので、そういった方の話もぜひ聞いてみたいですね。

麻植さんの魅力は人柄以上にオーガナイズ力がすごい所です

-- 最初にお聞きすればよかったのですが、大村さんから見て麻植さんの魅力ってどういうところでしょう?(笑)

26175273806_e71627cfe0_k.jpg

麻植:まずは、ありますか?(笑)

大村:(笑顔で)あります。

麻植:よかったです。(笑)

大村:さきほど、人見知りとおっしゃってましたが人当たりがいいですよね。 私にはない、イベントオーガナイズ力や人をひっぱってくる力などはすごいなぁと。

人柄以上にオーガナイズ力がすごいです。「やります」だけでは、人は集まるかはわからないし、集まったとしても形にすることは難しく、場を共有して色んなことが事が起きる・形にされているところは私では到底できそうにありません。

麻植:私はある種強引なところもあります。

その場の雰囲気に任せて導き出した結論の方が納得感がでやすい課題と、誰かがリーダーシップをとってガンガン決めないと前に進まないと課題があって、最近はそこをかなり意識的に区別するようにはしています。

裾野の広がりは知名度ある企業の情報発信も大きいのでは

-- 話は少し変わってScalaと企業についてはどうでしょうか?

大村:Scalaは水島さんが草の根的に広げ始めた時から思い出すと、今はこれだけ企業のスポンサーさんがついたり、企業さんがイベントの企画をしたり、このScala先駆者インタビューもその一環だと思いますし、「よく育ったなぁ」という感じがありますよね。

麻植:そうですね。最近は自分が思う以上に裾野が拡がっている印象があります。

-- 裾野が拡がったり実感があるとのことですが、どういう風に感じていますか?

麻植:ドワンゴさんがニコ生のバックエンドをPHPからScalaに切り替えた成功事例があって、その後ドワンゴさんにどんどんScala界隈の人材が集まってきて、そこで得た知見やScala関係の情報を発信してくれている動きがあったのが、大きいのではないでしょうか。

他にも事例でいうとサイバーエージェントさんのAdTech Studioもコミュニティ活動に力を入れてくださっています。Scala Matsuri2014の時に開催直前に当初予定していた会場が使えなくなって困っていたところ、サイバーエージェントさんが会場の場を提供してくださり助けてくださってなんとか開催できたということがありました。今年開催した2016年の時も大きな会場全体でWifiを使えるように全面的にサポートしてくださいました。

AdTech StudioではScalaの活用も全面的にされており、Scalaエンジニアの人数も日本有数な規模です。またブログで情報を精力的に発信されています。

大きい、知名度のあるWeb系の企業がScalaを採用した事を積極的に発信・展開をしてから、一気に国内でScala採用が加速したなという印象がありました。

その他の企業さんもスポンサードをする以外に、コミュニティ開催のイベントを支援していただけたり、自らコミュニティイベントを開催(Scala将軍達の後の祭り,Scala大名の平成維新〜殿中でScala!〜)されてたりしますし、企業としても個人としても活動がアクティブになってきています。

ChatWorkさんもScalaにリプレースしますという事を発表され、その後かとじゅんさんや大村さんが入社され私の中で大きな驚きもありました。

大村:そうでしたね(笑)

実は「人見知り」だったという衝撃の事実...

-- 人をつなぐということを麻植さんはよくされているように思います。私は人見知りで恥ずかしがり屋なんですが、初めての人と繋がっていく楽しさはありますか?

麻植:私、実はけっこう人見知りなんです。

周り:えぇぇ!!(笑)

麻植:知らない人の中に入るのは気疲れします。意識的にギアをあげないとうまくしゃべれなくて、海外カンファレンスの前日に「XXのホテルで飲んでいるんだけど」とGitterなどでつぶやかれているんですが、少し悩んで「よしっいこう!」と気持ちを奮い立たせて行きます。

顔見知りがいないときは、すみっこの辺りで私と同じようなシャイなエンジニア同士でたわいない話をしながら飲んでギアを上げつつ、移動のタイミングでグループで話していた中心の人たちに話しに行くようなことが多いです(笑)

誰かと繋がることが楽しみではなく、結果的に仲良くなるとすごく楽しいので、自分の中でハードルは高いのですが、乗り越えた先に「何か楽しい事があるかもしれない」と思って奮い立たせてがんばると、結果として楽しい事が多いです。

-- 結果的にたのしい。結果的にリア充ですね!

大村・麻植:(笑)

麻植:はい、結果的にたのしいですね(笑)

大村:日本の文化は恣意的に人脈を作るのは打算的と言われ「いいこと」ではなく「ちょっと違うんじゃない」と思われがちですが、海外では自分がしたい事があったり得たいものがあった時に、それを人脈から得ようとするのはオープンなことで、シリコンバレーではmeetupは星の数ほどありますが大抵ネットワーキングの時間があります。

そこにお酒や飲み物があって、みんないろいろしゃべります。
あまり興味がない人同士が会って少ししゃべってダメだったら結構ドライで「じゃ、またね!」という感じで、波長があって求め合うものが違うだけで、嫌っているわけじゃないです(笑)

そういう文化もあります。

麻植:よくわかります。

そういう機会を利用して、カンファレンスが始まる時にちょっとしゃべった事がある人を見つけたり作っておくと、会話のハードルがぐっと下がります。

ドライにいろんな人としゃべってみてもいいのですが、この人しゃべりやすいなという人がいたらカンファレンス会期中にも「おはよー」とか「次このセッション行くんだ」とか「さっきのセッションでの話はどうだった?」などたくさん声をかけてみます。カンファレンスを通してしゃべれる相手ができるし、楽しそうに会話していると、通りがかった人が「ハーイ!」と会話に入ってきて、新しく繋がりが増えてきます。

しゃべりたい人がいても直接行くよりも、楽しそうな会話の輪を作って、移動しながらしゃべりたい人を巻き込みに行くというようなこともします。最終的に会話もはずみますし、お互いの良い印象で終えれますし、そのときに何かの勧誘をすると効果が高いというのは感じています。

第二言語だと、自然に任せた文脈でのコミュニケーションが難しいので、できるだけ自分が話しやすい土壌を作るなど、工夫したりしています。

OSS活動やディープラーニングの話も聞かせてください

-- コミュニティ以外の話題で大村さんが麻植さんに聞いてみたいことはありますか?

大村:コードで海外を繋ぐという意味で、ND4SというOSSの活動についても聞いてみたいです。

麻植:JVM上で動くDeepLearningのフレームワークに関わったOSS活動をしています。DeepLearningはニューラルネットワークを使って学習をさせるための機械学習の一分野です。ニューラルネットワークでバックエンド計算する時にN次元行列計算で進行するので、そのためN次元行列計算をできるライブラリが重要になってきます。

計算速度やAPIの豊富さなどが、性能と使いやすさに大きく影響してきます。
DeepLearning4JというフレームワークではND4JというN次元行列計算のJVM用のライブラリを自前で用意しています。ただ、DeepLearning4J・ND4JともにJavaで実装されているので、Scalaから触りやすいようにするライブラリがND4Sで、ND4Sを私が作ってメンテナンスもしています。

大村:国内でも世界的に使われるライブラリやフレームワークを開発されているすごいOSS開発者の方はいますが、普通のScalaプログラマ方たちが海外のOSSにコントリビュートしていけばいいか、きっかけのつかみ方など聞かせていただけないでしょうか?

DeepLearning4JやND4Jをほとんど一人で開発していたAdam Gibson(インタビュー記事1, 2,GitHub)さんとやりとりしてND4Sを公開されているので、どうやっているのかなどTipsはありますか。

麻植:貢献をする時の敷居を下げたり、第一歩を踏み出すためのTipsという話しですね。

私の場合は「相手の事を知っているか」というのが大きいです。相手の事を知っているとちょっとした時にやりやすくなります。最近ですと、さきほども紹介したGitterが最初の敷居をさげるのにとてもいいと思います。

GitHubのIssueだとコミュニティによって作法もあったり、プルリクエストも一定の規約などを設けている場合もあります。Gitterのチャットでは最初に触り始めた時にバグなのか自分の使い方が間違えているのかを気軽に聞けます。

大村:私もプルリクエストを出して直された事があります(笑)

麻植:作法は「for Contributors」というような形で諸注意をドキュメント化されているところもあれば、IssueやプルリクエストやMLなどを読んで空気を読んで知るというケースもあります。

それだと敷居が高いですよね。
Gitterが普及してきて気軽に聞けるので敷居が下がったとはいいつつも、完璧を求め全部調べつくした上でプルリクエストを送ったりIssueを立てるようなことは大変なので、GitterやTwitterなど聞きやすいところで聞くようにしてます。聞きやすい環境を使う、というのを私の中で大事にしています。

ND4SはDeepLeaningを勉強する過程で作るにはちょうどよかったというところもありました。なぜこういう仕様になっているかも聞きました。

作法や運営の丁寧さはOSSによって違うので、カジュアルに話せる場がもっとあるといいのではないでしょうか。
コミュニティの話にもつながりますが、モメンタムを作るというはカンファレンスや勉強会などで一緒にワークショップをした・立ち話をしたという経験の影響は大きいと思います。

Adamさんとの関係もそういった感じで仲良くなって、チャットでのコミュニケーションしてディスッカッションできるまでに発展しました。最初のコミュニケーションの下地があったからこそ、できたことかもかもしれません。

最初から対面が難しいと思うので、近くにそういう事をやっている友達や日本で活動している人の話を聞くのはすごく参考になると思います。

-- お話を聞いていると麻植さんが人と人とを繋ぐ架け橋となって何か連鎖的にアクションが起こっている事も多そうですね。

麻植:架け橋といっても本人のOSS活動がベースにあるという事が大きいのですが、リアルに会ったことによって心理的距離が近づくというのはオープンソースでもプラスに働く面があります。たまにマイナスに働いちゃうこともありますが(笑)

そういうところは私は積極的に支援できそうですし、海外のOSSとの距離を近づけるという意味でも良さそうですね。

普段のお仕事で麻植さんはどんなことをされている?

-- フリーランスとして働いているとのことですが、お仕事でScalaを書かれているのでしょうか?

麻植:最近ですとAndroidアプリをScalaで作っています。他にもScalaのトレーニングとして、最近ですとセプテーニ・オリジナルさんのScala新人研修を行わせていただいたりもしています。その他の活動も細々としています。

-- Scalaの導入支援や教育サービスは、Scalaをやり始めた会社にとっては底あげやScalaらしい書き方などを知れる足がかりになるのでいいですね。

麻植:これからそういう需要も増えてくると思いますし、Scalaのコミュニティが大きくなっている状態なので、新しくScalaを採用される企業などでScalaが経験豊富な人がいないというケースも少なくないです。

そういった時に私もサポートできたらうれしいですし、最初に採用した時にくじけずにプロダクトとして波に乗れて、一つ目のステップを超えられる会社が増えれば増えるほど、日本全体としてもScalaの次の波がくると思います。

Scalaのエンジニアが欲しいという話であれば、アプローチの仕方やアドバイスなどちょっとした相談にのらせてもらう事もあります。

また今年の6月からアウトドア向けのウェアラブル端末とアプリを提供している株式会社BONXに入ることにしました。創業期から業務委託でお手伝いしていたIoTスタートアップなのですが、昨年秋のクラウドファンディングでは2500万円超とIoTプロジェクトの中では当時の国内最高額となる支援を集めたりと、今まさに伸びているスタートアップです。

優秀なメンバーに囲まれた仕事自体も面白いですが、アウトドア好きな人たちで構成されていて、たとえば冬場は平日開発して、土日に同僚たちとスノボにでかけてフィールドテストをする、みたいな生活をしたりと、とてもユニークな文化が形成できていることを気に入っています。

-- Scalaと関係ないかもしれませんが、フリーランスのよさはありますか?

麻植:人それぞれだと思います。私自身はフリーランスが大好きというわけでもなく、今までではフリーランスのような働き方をしたほうが選択肢が広く持てるので続けていたという感じです。

コミュニティワークをしていると時間のフレキシビリティが効くのはいいですね。自分で調整できるフレキシビリティがないと潰れてしまうので、コントロールしやすいのはいいです。ちなみに株式会社BONXでは、そのあたりの私の特殊事情について配慮をしていただいていますので、ScalaMatsuriなどの他の活動も当分続けられそうです。

興味があることやこれからに向けて

-- いろんな方と関わることが多いと思いますが興味深いことを教えてください

麻植:LightBend社が今後どういう方向に行くかは興味あります。
それと、世界の主要ベンダーも集まってできたScala Centerがどうなっていくかです。

Lightbend社には最近色々な新しい動きがあるので興味深くみています。オープンソースをビジネスにするのは難しいことです。言語だけで儲けるのはハードルが高く、言語というコアの技術をもちつつ、どこに手を伸ばしていくのかというにが気になります。言語のコミュニティとしても持続可能で、なおかつ会社としても有益になれるというところが示せるといいですね。Lightbend社には成功して欲しいです。

-- 最後にこれからについて一言お願いします

麻植:コミュニティ活動なので私一人の一存で決まるわけではないのですが、もっと海外との垣根をとっぱらえたらと思えます。海外からの参加者を増やしたいし、日本から海外のカンファレンスに行く人が増えたらもっと楽しいなと。なおかつ、海外に行った時には日本から来た同僚だけで固まらず、色んな参加者とコミュニケーションをとってくれる人が増えるともっと楽しんでもらえるだろうなと。

逆に海外から来てもらった時にも楽しんでもらえるようになれればいいですね。海外カンファレンス常連組が顔を合わせて話せる機会以外に、一般の参加者さんとも話せてもらえる状況をどうやったら作れるかなぁと。

楽しみ方はそれぞれなので一概には言えないですが、楽しみ方を両方選べるようにできたらいいなと。
他にもいろいろチャレンジしてみたいなと考えていることはいろいろあるので、いい場を提供できるようにがんばっていきます。

-- 次回に繋げていきたいので、今日の話しの流れも踏まえ、麻植さんや大村さんがお話を聞いてみたいと思う方をご紹介いただけないでしょうか。

麻植:実は先駆者といえばこの人以外ありえないだろう?という方がいて、なぜか今まででてこなかった方がいらっしゃいます。なにか意図があるんじゃないだろうか?と思ってしまうくらいです。真っ先に名が浮かんだ水島さんをご紹介いたします。

-- ありがとうございます!本日は長時間どうもありがとうございました。

出席者

  • インタビューイー 株式会社BONX/一般社団法人Japan Scala Association 麻植
  • インタビューワー アットウェア 浅野・三嶋、 ChatWork 大村

過去のScala先駆者インタビュー

Scala先駆者インタビュー VOL.5  ChatWork大村さん

Scala先駆者インタビュー VOL.5 ChatWork大村さん

前出さんとの出逢いはシリコンバレー

-- 今回は前回の前出さんからのご紹介でChatWorkの大村さんです。アメリカでの大村さんとの出会いがリアクティブへ方向転換するきっかけになった、というのがご紹介いただいた理由でしたよね。

前出:はい、そうです。

-- 前出さんと出逢う以前からアメリカで活動されていたということですが、当時の話をお聞かせいただけますか。

大村:前職で2012年の5月にアメリカ赴任が決まって、次に技術開発をするべき新規技術の開拓・調査と、協業できるパートナー会社をシリコンバレーおよびアメリカ全土で探すというミッションの元、現地法人で活動していました。

そこで、GoogleやFacebookやTwitterなどがどんな技術に注目して使っているのかの調査をしていました。

日本にいる時に「プログラミングScala」を翻訳する機会に恵まれたこともあって、当時Scalaを業務では使っていなかったのですが、アメリカにいる時も興味をもって引き続き使ったりトレンドを追いかけたりしていました。

前出さんとはSIerでの先を考える同志のような共感を持ちました

-- 前出さんと大村さんの出逢いでどんなお話をされたのでしょうか

前出:Scalaをエンタープライズで広げていく事を考えて、プログラミング言語で広めていく以外でどんなことが出来るのかを模索していました。

そういう中で、弊社もシリコンバレーに現地オフィスがあり渡米した時のことです。

現地のメンバーに「シリコンバレーでScalaの事を調査していたり取り組んでいる人っていないですか?」と聞いたところ、大村さんを紹介してもらいました。

「日本で同じSIerとして早い段階からScalaの本を翻訳されている方の話を聞いてみよう!」ということになって訪問し、その時にやっていた取り組みを打ち明け、そこでリアクティブの話になりました。

大村:もともと私はAkkaに興味を持っていたのですが、周辺で変化がおき始めた事に気づきました。Typesafe(2016年3月10日にLightbendへ改名)が会社になり、リアクティブという言葉を使い出したり、WebinarやカンファレンスでC10K問題を例にしてサーバサイドのアーキテクチャにおけるパラダイムシフトの必要性を話していました。具体的には1リクエストに1スレッド割り充てるようなモデルではだめで、Akkaのような固定のスレッドプールでイベントベースで処理するようなモデルが適しているという事でした。

私もそれに共感し、Akkaを追い続けていたこともあり、前出さんには「SIerでエンタープライズのシステムで取り組むといった時に、今までのアーキテクチャを前提にしていると行き詰まりますよ。」「新しいパラダイムとしてリアクティブという考え方がイケています」と言う話をした覚えがあります。

前出:これが転機になってリアクティブで推していくアプローチに変え、問題解決の糸口の一つとして活動を続けていくことにしました。

大村:私とはミッションが少し違ったんですね。私は海外拠点にいて、人員も限られていたので、調査業務や報告業務が主で、新しい概念や理論、原理などが実現可能であることを示すため活動である、POCのような事が充分に行えず葛藤していたところ、同志のような前出さんがいらして、やりがいや気苦労など共感したのを強く覚えています。

-- シリコンバレーで同じような境遇の方が集まるような場ってあるのでしょうか?

前出:2ヶ月ほどシリコンバレーにいて感じた事は、毎日のようにMeetupが開催されていて、興味のあるエンジニアが自然と集まるという印象を受けました。日本人の集まりというのもありました。

大村:日本人のみが集まるmeetupがあったり、Scalaというテーマでは北と南で大きな2つのmeetupがあります。SF ScalaScala Bayが存在し、毎月開催で100人程度が集まります。サンフランシスコで開催されるSF ScalaはAlexy Khrabrovさんがオーガナイザーで、ScalaMatsuri 2016でも来日されコミュニティについて発表されていました。Scala BayではVlad Patryshevさんがオーガナイザーで型システム、圏論に関連するScalaの話題が多い印象です。

-- 出会いが多いシリコンバレーにいると会社を移るきっかけも多そうですね

前出:シリコンバレーで新しい技術にチャレンジするという環境に個人的な憧れを持っているのですが、それをやめてまでChatWorkに移った経緯ってあるのでしょうか?

大村:新しい事を調査するのは刺激があって楽しいのですが、エンジニアとして立ち戻った時に、もっとモノを作ってみたいという思いもありました。ChatWorkは東京と大阪にオフィスがあるのですが、実は社長は日本にいなくて、一人でシリコンバレーにいます。シリコンバレー駐在時に社長と知り合って、アメリカで開かれたRe:InventにChatWorkのScalaの開発者メンバーも来ていて一緒に話をして、情報交換会をしたのが繋がりの最初でした。

前出:SIerからWebサービス会社に移った大村さんに聞いてみたいことがあります。

SIer在職者視点になりますが、サービサーに行くという事はそのサービスをずっとやっていくことになりますよね。私はそれが自身の事になるとあまりイメージできなくて、SIに対する様々な意見はありますが、自分がいいと思った技術で、色んな会社の色んな業種・規模のシステムやサービスに関わり貢献できる所に楽しさを感じています。大村さんは「チャットワークという1つのサービスをずっとやっていくんだ」みたいな感じで移る事を決心したんですか?

大村:技術的なマッチングもあったのですが、創業者である社長の魅力に惹かれた部分も大きいです。ChatWorkの「やらないこと14条」があって、ちょうど私が入る頃に、「他人の資本をいれない」「株式公開しない」という2つを外した時があり、「なぜ外したんでょうか?これからタガが外れていくんですか?」と聞いたところ、「そうではない」と返事がありました。

ChatWorkには会社の「Make Happiness」といういい理念があって、その理念に共感してくださらないお客様とは取引しないくらいに徹底しており、すごくいい会社だなと思ったのが大きく、ただ単にWebサービス企業に行きたかったわけじゃなく、人とScalaという技術で次に行こうという姿勢でした。

また、お話を伺う中で、Slackが台頭してきている中で、ただ巨象を追いかけるだけでなく、ChatWorkとしての立ち位置をしっかり見据え、戦略を持って成長しようとしている所がいい会社だなと思って、ご縁もあり決めました。

前出・浅野:おぉぉ、いい話ですね。

-- という経緯があって、ChatWorkさんでScalaで大きくシステムのリプレースをしようとしている取り組みの一環もあり、入社されたわけですね。

大村:はい、2015年8月頃の話です。入社後はすぐにScalaのプロジェクトに入ってアプリケーションのコードを書いたり、AWS周りの事に取り組んだり、Akkaを使ったプログラミングもしています。

Akkaをプログラミングする時にスレッドプールのチューニングはやっぱり悩みます

-- 入社してプロダクションでAkkaを使ってみてどうでしたか

実はまだプロダクションでAkkaを使えているわけではなく、まだ開発中です。ただ開発の中で、竹添さんのインタビューでも言及されていましたが「Akkaを使った時に難しくなるのはスレッドプールのチューニング」と言う事は実際にあって、私もそう思いました。ブロッキングするコードがあるとスレッドが詰まってしまうので、できる限りブロッキングにしないようにする大事さを体感しています。

-- どうしてもブロッキングしないといけない時はどうされていますか

大村:この問題はずっとChatWorkでも課題にあがっています。ScalaMatsuri 2016の時に来日したAkkaのメインコミッターでもある Konrad Malawskiさんに「負荷テストをしたらスレッドが詰まって困っている」と相談したところ、「ブロッキングIOをするアクターには専用のたくさんのスレッドプールを割り当て、詰まるかどうかは負荷テストの中で調節しなさい。それしかないと思います。」との回答をいただきました。

-- 突発的にSNSやメディアに掲載されたりしてバズった場合のようなケースで、リクエストが急激に増えるような場合にすぐに対応はできるものなのでしょうか?

大村:すぐには難しいかもしれません。スレッドプールがギリギリになったらダメですね。Fork/Joinプールを使うとスレッドを増やす事はできるのですが、そうしてしまうと今度は逆にOutOfMemoryで落ちることもあるので、難しい問題だなと思います。

-- 今のユーザ数や増え方であれば現在の使い方で問題なく運用していけそうですか?

大村:そうできるように現在取り組んでいます。

-- 開発中のシステムの中でリアクティブは取り入れていますか?

大村:sprayとAkkaを使って良さを引き出そうとしています。ただ、完全に非同期にアクタープログラミングまでにはしていないので、完全にリアクティブかと言われれば微妙ですが、部分的にリアクティブであるとは言えるかもしれません。

ネットワークを介するマイクロサービスは考える事も多い

-- リアクティブシステムという面で見た場合はマイクロサービスが前提である事が推奨される一方、マイクロサービスの面で現状を見た場合には最初からマイクロサービスにすると失敗するケースもそれなりにあり、最初はモノシリックに作り、徐々に切り出していくというアプローチも良いという声も聞きます。

そういう中で、リアクティブとマイクロサービスを一緒にやったら、どれくらいうまくいくものかという事に興味があります。マイクロサービスというキーワードが関わった時に熟練度との関係など実際どうなんだろう?というのが以前から気になっていました。

というような、マイクロサービスに関する話をお聞かせいただけますか。

大村:例えば、1つのマイクロサービスでWebサービスを提供していたらそれはモノリシックと言えます。マイクロサービスは幾つかサービスがインタラクションするのが前提になりますので、インタラクションして繋ぐ所が、ひとつ大事になってくるところだと思います。

ネットワークを介してやりとりするので、エラー処理をしたりタイムアウトもありえます。サービスディスカバリも考えないといけないので、マイクロサービスは簡単ではありません。マイクロサービスを呼び出す時にはCircuit Breakerのような障害の連鎖を防ぐ為のような仕組みが必要だったり、同じようなリクエストを束ねるような仕組みも必要だったりします。

サービスディスカバリという側面で言うと、私が好きなNetflixのOSSライブラリの中でEurekaというライブラリがあります。通常、ロードバランスする時は一つのリバースプロキシが処理を振り分けるのですが、Eurekaでは発想を逆転させ、どこで動いているかを覚えているサービスを立てておき、クライアントはどこで動いているかだけを問い合わせし、クライアント側でロードバランシングをします。

外部に公開するサービスだとこの方式は難しいのですが、内部でサービス同士をスケーラブルに繋ぐ場合はこういう技術も大事になってきます。ただし、たくさんでているOSSを組み合わせて、マイクロサービス間を繋いで全体として、レジリエントかつスケールするシステムに仕上げるのは、言うほど簡単ではないと思っています。

着目点を疎結合以外に目を向けてみよう

-- DIを使ったMVCフレームワークがメインの頃のシステムより、リアクティブ+Netflixが提供しているようなOSSを組み合わせたシステムの方が複雑度は高そうに感じます。

大村:そうですね。複雑度は増していますよね。

-- インタビュー冒頭で、「このままでは今までのアーキテクチャでは行き詰まるのでリアクティブにしていかないと」という話題になりましたが、開発規模・複雑度を踏まえ切り替えるタイミングや交差する起点ってどのあたりになるんでしょうか?どういったチームや環境にあっているかなど、そういったお話が聞ければと。

大村:以前に前出さんとディスッカションをした事があるテーマですね。リアクティブシステムを作る時にはメッセージ駆動が中心になります。今までのアーキテクチャはサーバーを並べた時にスケールしているのですが、捌けると思っていてもよく見てみるとスレッドってブロッキングIOですごく遊んでいる事が多いのです。

そこをメッセージ駆動で置き換えていくと、CPUリソースを限界まで使い切ることができる所に、メリットがあるのではないかと思います。リアクティブと今までのアーキテクチャの交差点というより、プログラミングモデル以外のそこに気づくかどうかじゃないかと思います。今の巨大なエンタープライズのお客様でもServletのシステムモデルで30台〜300台で運用しているところを、ノンブロッキング実行モデルで書き換えると実はそこまで台数が必要なく、よりスケーラブルになる可能性が高いのではないでしょうか。

着目点として同じリクエストが捌けるけど、コストがどれくらい違うのかという視点ができそうですね。

-- こうやって二人はよく会ってディスッカッションしているんですか

前出・大村:いやぁ〜。どうでしょう(笑)

大村:リアクティブの勉強会やイベントには都合がつけば行っているのでそこで会った時にお話をするという事が多いですね。

Scalaの型システムの強力さに惚れた

-- そんな大村さんがTypesafe以外のところで注目したり面白いと思っている事はどのあたりでしょうか

大村:RxJavaが生み出したプログミングモデルも面白いと思っています。少し前はFinagleがScala界隈で流行っていて、それはServerをRequestからResponseのFutureを返すというモデルで抽象化したのですが、RxJavaはRequestの流れからResponseの流れへの変換がサーバーであるとした所が面白いですね。

-- Scalaをやっている時の楽しさはどのあたりでしょうか

前出:大村さんが好きになった理由はなぜか記憶に残っています。(笑)
「Scalaの型システムの強力さに惚れた」でしたよね?

大村:はい、最初にScalaへ興味を持ったのは型システムの柔軟さです。JavaのGenericsでもすごいと思っていたのに、Scalaを勉強した時にVariancesという概念を知った時と、Context BoundがないScala2.7の時代になりますが、View Boundは革命的だと思いました。それはソフトウェアの変更に対する考え方で「Open-Closed Principle」があり、Open-Closed Principleの意味が示す、「拡張に対しては開いており、修正に対して閉じている、そしてコンパクトである」というコンセプトを具現化できている事に魅力を感じました。

その後Context Boundという文法がでてきて、Open-Closed Principleをさらに綺麗に具現化できることになってまたまたすごいなと思いました。

楽しさはそのパワフルさを感じながらコードを書いているときですかね。(笑)

-- コードを書いて開発している時はどういう感じでやっていますか

負荷テストやスケールさせるようなものはクラウドにのせていますが、それ以外はローカル環境で確認しています。負荷テストは日常的に回せるようにしたいねという話をしていたります。

単体テストなどはCIなどでやっており特別変わった事はしていませんが、Scala Checkを要所で使ったりはしています。

Akkaでマイクロサービスを実現するという仮説は面白いアプローチ

-- 前出さんから大村さんに現時点で聞いてみたい事はありますか?

前出:マイクロサービスの話で私が持っている仮説があります。サーバーがリモートなのでエラーが発生することを考えないといけなく、分散処理という難しさがあるのはAkkaでも同じと考えています。ということは、最初からマイクロサービスで作らなくても、Akkaで分散できるようにアーキテクチャを作っておけば、そこからマイクロサービスに移行するのはハードルが下がるんじゃないかと思っています。

もし「これからマイクロサービスをやっていかなければ」となった時に、マイクロサービスというアーキテクチャにハードルを感じるのであれば、「まずはAkkaで分散という風にやっておけば必要な時にすんなりと移行できる」という仮説です。この仮説に意見をもらえないでしょうか。

大村:いいアプローチだと思います。マイクロサービスとなるとHTTPとなりがちですが、昔からRPCがあったりAkka-Remoteもありますし、必ずしもプロトコルがHTTPじゃなくてもいいのでは。

前出:Circuit Breakerの仕組みがAkkaに入っていますので使えるとは思いますが、大きいサービスを意識した時に設計のポイントになりそうな所はどのあたりでしょうか。

大村:マイクロサービスの繋ぎ込みのところで、Akka-Remoteを使う時にハードルになるのは、スケーラブルにどうやって繋ぐかという点だと思います。Akka-Remoteだとアクターがどこで動いているかを知らないと透過的に呼び出せないので、その時に使える機能としてAkka Clusterの中に「cluster-aware routers」というものがあります。

これを使えば、Akka Clusterの中であれば、あるアクターから役割を持ったアクターの集合に対してスケーラブルにルーティングしてくれるので、そこにCiruit Breakerも仕込めるし、クラスターだとロールも持てるので、それを活用すれば、うまく繋げ、エンドポイントも分けれるんじゃないかと思います。

仮説がうまくいけばですが...

-- 仮説検証の結果をどこかで聞いてみたいですね!

大村:そうですね!

Akka Clusterは難しさもありますが、便利そうです。

前出:レジリエンスを担保していきたいのであれば、この流れになるんじゃないかとは思います。

大村:分散システムではレジリエンスは一番大事な性質で、ScalaMatsuri 2016でJonas Bonérさんも言っていた「レジリエンスがなければなにもないのと同じ」というフレーズも記憶に新しいです。

マイクロサービスを呼ぶ時に、呼び出し先が落ちてて呼ぶ側も一緒に落ちちゃったら意味がないので、フェイルオーバー用のサンプルの値を返す事ができれば、サービス全体と考えた場合に画面全てがエラーになるのか、例えばオススメ表示部分だけ1件も表示されないだけなのかは大きく違いますね。

Webサービスの企業だとサービス自体が収益元なので、稼働率はものすごく気にする必要があり、そういう意味でもレジリエンスが重要になり「落ちない、落ちてもなんとかして戻ってくる、どこかが落ちてもなんとか動く」という性質は大事だと思います。

Akka Clusterを使ってマイクロサービスを実現するアイデアは面白く、できる気がしてきました。

早くAkka HTTPがStableになって欲しい!

-- 他にも何か前出さんから聞いてみたい事がありそうですね。

前出:はい。私はプロダクションよりもPOC的なことをやる仕事が多くなっているので、実際に今プロダクションを作られている大村さんに、エクスペリメンタルなモジュールの採用をどう捉えているかを聞いてみたいです。

大村:方針としてはエクスペリメンタルなモジュールは気軽には使っていこうとはなっていません。早くAkka HTTPがStableになって欲しいです!

でも、魅力的なモジュールが多いですよね。

これからAkkaをやってみようという人に向けて

-- 大村さんはScalaやAkkaが手になじんでいるとは思いますが、これから入っていく人にステップとしてどうやっていくのがオススメですか?

大村:パッといいアイデアは思いつかないですが、Scalaはドワンゴさんや、はてなさんが公開しているテキスト(ドワンゴさん「オリジナル新卒エンジニア向けの研修資料」、はてなさん「はてな教科書」)をやってみるのがいいんじゃないかと思います。

前出:アジャイル開発の例になりますが、ラボのようなところに入門すると、アジャイル開発を進めるにあたって必要なロール毎にメンター役がいて実際のシステムを一緒に開発することでアジャイルを身につけ、次からはメンター無しでアジャイル開発ができるようになって巣立っていくというようなサービスを聞いたことがあります。単に困っていることの相談にのるだけのコンサルではなく、このようにチームの一員として一緒に苦労してScalaやAkkaでそういう枠組みが実現できるといいなと思っています。

大村:よく知っている人の弟子になってScalaやAkkaを学んでいければという感じですね。学ぶ方も楽しいし面白そうですね。

大村:私がAkkaを学んだ時にやったことなんですが、Erlangの本でプログラミングErlangという書籍の例題で、「アクターでリングを作ってメッセージをリングの中で回して計測してみよう」というものがあって、それをAkkaで最初にやって学びました。応用として、リングを壊すときもリングの頭にメッセージを流すと順番にストップのメッセージが流れていって、アクターが全て綺麗に終了するというようなものです。

そこで、計算させようとすると例外が発生したりもするので、自分で色々シナリオを膨らませる事もできて、ノードが勝手に落ちた場合に復帰させたい時には、スーパーバイザーやデスウォッチの仕組みが必要になったりするので、小さい課題の題材としてよかったです。

単純すぎるのでわかった気になるのは早すぎですが、入り方としてはちょうどいいかもしれません。他の言語にも応用できるので新しい言語でアクターを学ぶ時は私はいつもこの題材をやっています。

最後に一言

-- 最後にこれからについて一言お願いします

大村:ChatWorkに転職した目的でもありますが、Scalaという技術を使って次世代のチャットワークを作っていきたいというのがあるので、ScalaとAkkaを使ってチャットワークが成長していく時に支えれるようなバックエンドを実現できるように、日々学びながらも仕事に活かしていければいいなと思います。

前出:国内でも貴重な会社だと思うので是非頑張って欲しいです!

-- 次回に繋げていきたいので、今日の話した大村さんや前出さんがお話が聞いてみたいと思う方ご紹介いただけないでしょうか

大村:私と親交が深い、Deeplearning4jの開発やScalaMatsuriのオーガナイザーをされている麻植さんをご紹介します。

-- では、本日は長時間どうもありがとうございました。

出席者

  • インタビューイー ChatWork 大村
  • インタビューワー アットウェア 浅野、 TIS 前出

Scala先駆者インタビュー VOL.4  TIS前出さん

Scala先駆者インタビュー VOL.4  TIS前出さん

最初に

浅野:今日は前回の竹添さんからのご紹介でTISの前出さんです。まずは竹添さんからご紹介の経緯を聞かせてください。

竹添:私がこのインタビュー企画のお話を瀬良さんから「元SIerとWeb界隈の両方経験を合わせた話を聞きたい」ということで紹介頂きました。私はSIerで頑張りきれなくて挫折してしまったのですが(苦笑)、現役でSIerで頑張っているTISの前出さんだと貴重なお話が聞けるのではないかと思い、声をかけさせて頂きました。Web界隈ではScalaを使っている会社はたくさんあって、色々な方からお話を聞けたりご紹介もできそうでしたが、私自身も話を聞いてみたいと思いました。

前出:苦しい話ばかりかもしれませんねー(笑)

浅野:言われてみると、Scalaイベントでは発表者は自社サービスの方が多いイメージですね。

前出:そうですね。でも、確か、竹添さんがScalaMatsuriで最初に発表された時にはSIerに在籍中でしたよね?

竹添:はい、一昨年が前職で去年が現職でした。

前出:私が業務の一環としてScalaの活動をし始めた時には竹添さんが作って下さった道があった気がします。例えば、Scala逆引きレシピが出版されていたり、Javaとの比較をしたプレゼンをされていたり。きっと竹添さんがSIerで取り組まれていた時に比べると、まだやりやすさはあったのだと思います。

竹添:私がやっていた時は小さなチームでやっていたので、会社名を背負ってやっていたわけではなかったのですが、前出さんはTypesafeの取り組みを含め会社の看板を背負ってやっている印象があります。

dsc02767jpg_22844489854_o.jpg

「最初から苦難の連続でした」

前出:最初の1年くらいはこじんまりと活動をしていました。Scalaを会社でガッツリ使う方向に持って行きたかったのですが、すぐには実現できず、R&Dとして継続して活動していくには会社への何らかのメリットが必要で、模索した結果としてTypesafeとパートナーシップを結びコンサルティングサービスを始めました。R&Dとしてやって行く限りは、会社の看板を背負っていることは常に意識しています。

浅野:会社ではその取り組みを一人でやり始めたのでしょうか?

前出:はい、元々は研究開発の部署で社内フレームワークを作ったり・社内展開をしたりして生産性をあげることを目的とした取り組みをしていました。そこではSeasar2をはじめOSSを活用し、3〜4年間で自分なりにやりきった感はありました。さらに生産性をあげる事を求められるわけですが、社内フレームワーク自体の機能拡張やCIなどの周辺技術の改善だけでは、生産性をあげていく事への頭打ちが見えてきました。

そういうなかで、これまで大前提としていたJavaから言語を変える事を視野に入れ始めた時にScalaに興味を持ち始めました。動的型付け言語はチームがスケールしていく上で選択肢として外しおり、「LLみたいに使えて且つ静的型付けで、我々の持つJavaの資産も使える」ことがScalaを選んだ理由です。

竹添:私もJavaで生産性が頭打ちになって他に何かやらなければならないと感じScalaをやり始めたので、動機は前出さんと同じですね。

前出:また、当時のSeasar2は新たに機能追加をしないという状況で、これまでメインで開発とかサポートをやっていた社内フレームワークは社内標準ではなくなるという決定が下されたということも後押しし、自身も次のステップに移ることを決め、次世代の標準フレームワークを模索するということで本格的にScalaに取り組むことにしました。

そこからはScalaで社内向けのフレームワークを作り直したりしました。当時の社内フレームワークはOSSにはないエンタープライズ向けシステムでよく使うような機能群に加え、賛否両論ありますが自動生成系の処理もやっていたので、生産性を考えてScalaで開発するためのGeneratorも作ったりしました。しかし、Scalaという新しいものの壁は大きかったです。様々な障壁があり、単に生産性が高い言語というだけではScalaの浸透はできませんでした。

「Scalaの言語の力で生産性をあげることからReactiveへの転換」

浅野:その後、方向性についてはどう考えましたか?

前出:これまでの社内フレーム同様の環境が整えて、その上でScalaを使えば言語の力で生産性があがる、という方向性では難しさを感じました。ちょうど悩んでいた頃(約1年前に)海外に2ヶ月間赴任する機会があり、Typesafeの方や現地エンジニアの方々とお話させて頂き、「Reactive」が注目されている事を知りました。そして、Typesafeのとあるセールスの方から「Scalaで推して食いついてくるのはあなたみたいなScala大好きなプログラマだけだよ(意訳)」と言われました(笑)「これからはリアクティブのようなユーザーへ価値を提供できるもので推していかないと」という話をしていたところに、Typesafeのホームページもリアクティブ推しに変わってきて、我々も言語推しを控えめにしてリアクティブ推しに変えていこうと考えました。

浅野:弊社でもエンジニアは殆どJavaをメインに使ってWebアプリケーションを書いているのですが、Scalaの取り組みをしていこうとした場合に、言語推しだけだと厳しくて、問題解決領域にフォーカスしてその中で浸透を深めようとしています。

前出:「誰もがScalaを使うと生産性が2倍になるのであれば、全社をあげて1,000人のScalaエンジニアを教育していくぞー」という事が言えれば響くのかもしれませんが、生産性が多少変わるくらいだと難しいですね。

dsc02788jpg_23104910739_o.jpg

竹添:SIerでやっていた当時は実際に数値もとって「生産性2倍」を謳っていました。少人数でScalaを使ってやれば倍くらいにはなるとは思うのですが、SIの場合は開発のボリュームがあって、100人〜200人くらいの規模でScalaを使って倍になるかというと別の話が気がします。私は小規模なチームで生産性を出す事にフォーカスしていたのでやりやすかったのですが、TISさんはどういうステージなんでしょうか?

前出:小規模なシステムやサービスには適用してみました。早く効果を出すという面で小さいチームで早く作る時のベストプラクティスや得意領域を作っていくのはアリだと思います。ただ、それだけで終わってしまうと、SIerとして価値を見出せなくなってしまいますので、最終的には会社全体の生産性を上げていくのに繋げていきたいのです。この辺りの話は今も葛藤があり結論を見い出せていません。

「Reactiveはクラウドは落ちる事を想定するという所で強みとなる」

竹添:素朴な疑問ですが、リアクティブ推しでコンサルは実際にささるのでしょうか?今週、そういう話題をTwitterでつぶやかれているのを見たので。(笑)リアクティブって必要なところはあるとは思うのですが、社内標準的にWebアプリケーションを作るときにどこに使うのだろうと...

技術要素としてはトラフィックが多くてメッセージの流量が多いところにはハマりますが、大人数でエンタープライズなWebアプリケーションを開発する場合の全体の基盤として必要なのかを個人的に疑問に感じています。

前出:トラフィックと障害に強いというところを売りにして行きたいのですが、そういうシステムはインフラと運用とセットでがっしり対策しているので、差別化要素とはなかなか言えません。もちろん、コストメリットはあると思います。一方、エンタープライズ領域も徐々にクラウドに乗せていこうという流れがあります。クラウド以前は、アプリはA社インフラはB社が担当するというタッグを組み、絶対に落ちない基盤を担保するという事をしていました。しかし、クラウドでは落ちる事を想定しないといけなくて、尚且つ、インフラベンダーは存在しないので、アプリ側でそこを担保することが1つの差別化要素と考えています。

それでも、大きいシステムはクラウドに持っていくのは簡単なことではないので... なかなか難しいですね。

「Web界隈ではScalaは盛り上がっているけどSIerにはもう少し...」

浅野:少し話は変わり「現在のScalaを取り巻く状況が2〜3年前には想像ができていなかった」と竹添さんが前回のインタビューで言っていましたが、前出さんはどう感じていますか?

前出:Web界隈では盛り上がっているけど私が働くSIer周りではではまだまだだなと。例えばお客さんのシステムをリアクティブシステムやScalaベースで作るために、弊社が提案しても、まだ弊社でしかできないと見られてしまいます。一見、他社から差別化できて理想の姿に見えるかもしれませんが、お客様からするとTISしか作れなくて、TISしかメンテナンスできないシステムにはしたくないですよね。OSSベースなのにある意味ベンダーロックみたいな。「Web界隈では盛り上がりはあっても、エンタープライズでは特定の会社にしか頼めない」のが現状ではないでしょうか。

お客様はある程度いろんな会社、知名度の高い会社もやっているというのがないと技術にYesと言いづらいですね。

浅野:そういう意味ではSparkがそういう感じかもしれませんね。IBMの数万人投入というニュースがあったり。

竹添:Sparkに関してはどうでしょうか?

浅野:弊社では関わっている案件でSpark関連のものが出始め、盛り上がりは感じています。

前出:Sparkは先日うちのメンバーがハンズオンセミナーをやったり、触り始めましたがまだ本格的には取り組んでいません。現場では使っているのか、使おうとしているところなのか定かではありませんが、そういう声は聞こえてきます。

竹添:Sparkはデータ分析であったり、Hadoopからの置き換えで高速化を狙ったりと引きは多そうです。数台のクラスターで使い始めることができるという手軽さもありますね。

浅野:大きなSIerさんで大規模プロジェクトだとSparkがセットくらいに思っていました。

竹添:去年あたりまではSparkはバグも多かったのですが、最近は安定してきてライブラリも出揃ってきて使える状況になってきました。

浅野:AWSのEMRがSparkに対応して、気軽に使えるようになって一波きた気がします。

前出:こんなにSparkを勧められるとは思いませんでした(笑)

竹添:エンタープライズでScalaというと、私がSIerでやっていた頃はそれくらい突破口を見出すのが難しかったです。

「理想形は現場がScalaでやりたいと言い出してやれること」

浅野:自社のエンジニアでみんながScalaやっているイメージは湧きますか?

前出:私のイメージする理想形は、まず10人くらいのチームを作って、小規模でもいいのでScalaで開発します。そして、別のシステムを作るときは、コアメンバ以外は固定せず、メンバーをどんどんローテーションすることで、現場にScalaエンジニアが散らばっていきます。その状態になれば、最終的にどの技術を使うかを決めるのは現場の人たちなので、現場のチームがScalaをやりたいと言い出して、「これもScalaでやろう」「あれもScalaでやろう」となっていく形ですね。

今は、Webシステムのスクラッチ開発ではJavaベースでフルスクラッチの社内フレームワークが標準になっていて、それ以外の方法で作るとなると十分な説明が求められ、それを避けるため、標準以外に最適なモノがあるかを議論せずに、標準を選択してしまうというケースさえありました。

Scalaを標準として展開するのはなかなか難しく、現場がこの技術が良いと思って選択してくれるのがベストでそういう流れを作り、それをサポートしたいですね。

竹添:カルチャーを変えるところからですね。

浅野:「カルチャーを変える」いい響きですね。

竹添:アーキテクトがいないプロジェクトだと保守的に社内標準を使うというのはあることはありそうですね。場合にはよってはR&D部門から導入支援もしてもらえるし、使いやすいというのは実際現場としてはあるわけで、そこに対抗していくのは難しいですね。

前出:そうですね。さらに、SIは自社サービスとは違い、新しい技術を導入するにはお客様を説得しないといけないという苦労もつきまといます。

そのためにも、自社の取り組みを社外にも発信していますが、他のSIerさんにも入ってきて、どこでもやっているくらいにしないと、いくら現場がやりたくてもお客さんにYESと言ってもらえづらく、両方のアプローチが必要になります。

浅野:Scalaで作りたいことが普通になる状態になる必要がありますか?

前出:そうですね。普通になって、幾つかの会社が「Scalaで作りたい」と名乗りをあげる状況になっていないので、今は自分の周りで普及している感が実感できていません。

浅野:前出さんのような先駆者の方の姿や事例を周りが見て「使ってもいいんだな」と思って広まっていたという形は2年くらい先にはきそうでしょうか。

前出:うーん、2年ですか... R&Dとして成果を出さないと、そこまで続けていくのは厳しいかもしれませんね。今年も、成果が出なければ最後かもしれないというつもりでやっています。幸い今年はコンサルサービスを立ち上げるということで1つ形になりましたし、来年も続けることができるなら今年以上の成果が出せないと最後かもしれないというつもりでやっていきます。広まって使えるのが先に来るのか、ちょっと無理だなと判断する時期が先に来るのか?(笑)

竹添:SIerでScalaの火を絶やさないようにしていって欲しいです。(笑)

前出:はい、わかりました。(微笑)

「モチベーションは反骨精神かもしれません(笑)」

浅野:今Scalaに一番面白み感じるところはありますか?

前出:最初はコレクションあたりを扱うのが楽しかったです。一時期、生産性に着目していたこともあり、「どれくらい短いコードにするか」を楽しんでいた時期があったりしました。今はなんでしょうかね(笑)

浅野:一人でこれだけ推進しようとするには相当モチベーションがないとできないと思うのですが、どこから湧いてくるんでしょうか?(笑)

竹添:ないとできないですよね。

前出:SIerからWeb界隈にいっぱい流れてっている人達がいるのは、ある意味モチベーションになりましたね。自分がSIerでやるしかないと。

竹添:あまのじゃく的ですね(笑)

前出:会社では誰もやっていない新しいことをやろうとしているので、ぶつかることは多かったですね。会社の予算でやらせてもらっているので当たり前なのですが、事ある毎に説明し認めてもらう作業に時間を取られて何も産み出せない時期があったり、なんで続けているんだろう...

自分がやりたいと思って始めたことを途中で投げ出すのが嫌な性格なので、いつの間にか引けなくてなっているのかもしれませんね。

今では、一緒にやる仲間もいますし。

今はJavaがあたり前になっていて、それは誰かが普及させたわけで、Scalaをそういう感じで「Scalaをこの会社に広めたのは自分たちだ!」という未来を思い描いたりして、そんな日がいつか来るかなというのが密かなモチベーションなのかもしれません。

竹添:「この会社で...」に留まらず「日本のエンタープライズで...」とか「SIerで当たり前に使われているのは自分がここまでやったんだ」ぐらいで(笑)

大きなところで施行事例がでて来ると他社さんも使いやすくなると思うので、TISさんみたいな大きな会社が第一歩を踏み出して、Seasarの時のような感じで適用事例が世に出て盛り上がっていければいいですね。銀行さんの事例とか。

前出:いいですね。我々が言っているだけでなく、銀行さんなども一緒に事例を発表してくださるようになると本当に普及したって言えるんでしょうね。

dsc02791jpg_23446732086_o.jpg

「リアクティブのトレードオフは運用がキーになる」

浅野:社外の方を交えた勉強会などされたりしているのでしょうか?

前出:Scalaに関してはReactive System Meetupを開催したのと、細々とReactive Design Patternsの読書会をやっているくらいです。

竹添:意外と営業さんが勉強会の情報を見ているんですよね。営業さんはお客さんと密に対話しているので、ベンダー丸投げではなく内製のすることの重要性などもわかってきています。そういう意味で、そういう方に目につくように社外に情報を出していくのはいいことだと思います。

前出:Meetupはもっとやっていきたいと思っていて、今期もやる予定です。ぜひそこでも登壇お願いします(笑)

竹添:ぜひぜひ。

竹添:技術的な質問をさせてください。Akkaは使っていて大変だと思うのは、プログラムはシンプルに非同期に書けるのですが、設定やスレッドプールの管理が難しいと感じていて、その辺りのトレードオフはどうでしょうか?

プログラミングモデルとしてはシンプルだけど、ランタイムは複雑になるというあたりの捉え方です。

前出:Akkaを使わず非同期処理を実装するためにロックを考慮したり、デッドロックのことも考慮したりということを考えたら、それだけでもメリットは大きいと考えています。設定の部分は、最近はTypesafeモニタリングを使ってActorの状態を監視してみたりしていますね。

竹添:単純なスレッドモデルと比べ、Play Frameworkの場合はバックエンドで動いているAkkaのアクターを意識して複雑な設定をする必要があります。普通のWebアプリケーションを作っている分には割に合わないんじゃないかと。

浅野:Webアプリでは同期処理がほとんどなので、Webアプリを非同期ベースにするのは今じゃなくてもいいのではという話をしていたりします。裏でデータを捌くところを非同期という感じで、使い分けを模索しています。

まだ、適用事例をいくつか試したいという段階です。

前出:私も運用で本気で困るくらいまでは使い倒せていませんね。

最後に

浅野:最後に、次の方をご紹介いただけないでしょうか。

前出:リアクティブに導いてくれた、当時アメリカにいた大村さんをご紹介します。アメリカで出逢った時はOGISさんだったのですが、現在はチャットワークさんで働いています。プログラミングScalaの翻訳もされていますね。

竹添:このプログラミングScalaという本はScala逆引きレシピを書くときにコップ本(コップ本は通称で書籍名はScalaスケーラブルプログラミング)と共にとても参考させて頂きました。

浅野:では、本日は長時間どうもありがとうございました。

出席者

  • インタビューイー TIS 前出
  • インタビューワー アットウェア 浅野、 ビズリーチ 竹添

Scala先駆者インタビュー VOL.3  ビズリーチ竹添さん 〜後編〜

Scala先駆者インタビュー VOL.3  ビズリーチ竹添さん 〜後編〜

Scalaをやり始めるきっかけに貢献していければ...

インタビューイー ビズリーチ 竹添

インタビューワー アットウェア 浅野/エリシール/ジェフ エムスリー 瀬良


Scala先駆者インタビュー VOL.3 ビズリーチ竹添さん 〜前編〜から続き

瀬良:Scala Days 2015に参加したりScala meetupを開催したり、アクティブに活動しているJeffさんからも竹添さんに聞いてみたいことはないでしょうか?

Jeff:そうですね。最近Twitterでも話題になったり、Scala Days 2015でキーノートで紹介された次世代のScalaコンパイラについて聞いてみたいですね。次世代のDottyコンパイラはJVMで動作できるバイトコードやJavaScriptまで一気通貫して生成できるものですが、そのあたりについてどう思いますか?

瀬良:僕らはScalaが好きなのでScala.jsにも興味がありますが、世間一般的にはあまり関心度は高くないような気がします。現在のコンパイル速度が速くないので、そこは一般的な方々が気にしているところでもあります。将来的にコンパイルが速くなれば状況が違ってくるのですが、現在は劇的に速くなる兆候は見られていません。

竹添:Scala.jsについてですが、今、弊社の一部のプロジェクトではTypeScriptを使っています。既存のJavaScriptと同時に使えるというのが大きくて、必要なところだけタイプセーフにできます。Scala.jsは基本的に全てScala.jsの世界に持ってこないといけないのでハードルが非常に高いんですよね。Scala.jsのアプローチがこのまま続くのかはわからないのですが、今の状態だとカジュアルに使うのは厳しいんじゃないかと感じています。

Jeff:Dottyコンパイラを使うと一気通貫してコンパイルできる点以外に、他にメリットと感じているところはありますか?

竹添:今はパッと思いつきませんが、コンパイルが速くなると嬉しくなりますね。

瀬良:もしコンパイルが早くなるとしたら、差分コンパイルだけでなく、フルコンパイルも早くなるかが気になりますね。SBTサーバーなどの取り組みもうまくいくといいですが、どうでしょうね。

浅野:ScalaMatsuriが直前に控えていてScala熱は高まるばかりですが、昔からScalaコミュニティの姿を見ている竹添さんにはどう見えますか?

竹添:エッジが立っている人は先に行って裾野との距離感が5年前と比べるととてつもなく広がったと感じています。

瀬良:どういう所でしょうか?

竹添:新しい領域に踏み込んだり細部を突き詰めて成果を出してくださる方々がいます。それとは別に、新たに使ってくれる人がいてScalaのコミュニティが大きくなっていかないと未来がないと思っています。役割分担だと考えますが、そういう泥臭い所を逆に先端でやっている人が頑張るのは少し違うと思っていて、その辺りを個人的にも会社的にも力を入れていけるといいなと考えています。

Scala逆引きレシピ本を書いた理由も当時すぐ現場に入ってリファレンスにできる本がなかったので、必要だなと思って書いたのと、初心者向けの勉強会をしたりしました。こういう事は全体として重要だと思っています。

この辺りは他の言語と比べるとギャップがあると感じます。

浅野:飛び抜けている人とやり始めた人との中間層が抜けているということでしょうか?

竹添:そうですね。Scalaをやり始めるにあたり、最初から知らなくてもいいことがあって、最初はビビる必要はないのに恐怖感を与えてしまっている所があります。そこに難しさを感じます。

浅野:Scalaをすでに実践的に使っている人に聞くと「関数型プログラミングを完璧に最初から求めなくてもいいよ」「Better Javaとして使うのもいいと思います」という声も聞きます。それでも今からScalaをやろうとした時にハードルの高さを感じてしまいそうなポイントはありますか?

竹添:使うフレームワークに敷居の高さを感じるかどうかですね。PlaySlickは最初の選択肢になりやすいのですが、例えばJSONのReads、Writesを記述する必要が出てきた場合に、Javaならリクフレクション1発で終わっていたところが、どうしてこれが必要なのかを説明しても理解されなかったり、セッションやクッキーの扱いが直感的でなかったりするところも障壁になったりします。

また、入門者がフレームワークのコードを見て解決できるかというと難しいですね。

比較的理解しやすいScalatraSkinny Frameworkなどを使って入っていくと心理的抵抗感はないと思いますが、Playが標準的なフレームワークとなってきたので、Playの教育をせざるをえなくなってきています。

瀬良:私はScalatraやSkinnyFrameworkのメンテナをやっているという事もあって、Servletで済むプロジェクトはそれでいいじゃないかなと思っていますが、ScalaなんだからScalaらしくFutureでやったほうがいいという意見も周りではあったりします。

もう少し言うと、関数型プログラミングとオブジェクト指向プログラミングの対比やFutureの用途の使い分けなどがあります。要件によってはServletでも支障がない場合もあったりするので棲みわけが今後は進んでくるのかなと思います。

竹添:あまり標準的ではないものを使っていくとフレームワークの開発が止まってしまったりといった危険性もあるので、Typesafe社がその辺りの選択肢も用意くれると嬉しいのですが、現在はScalatraやSkinnyといったコミュニティベースのものしか選択がありません。特に受託開発で使う場合はServletで十分なケースに対して標準的な選択肢があると嬉しいのではないかと思います。

私も業務アプリケーションの受託開発では必要以上にパフォーマンスやスケーラビリティが要求されるケースもありませんし、Servletで良い部分もあるのではと思ってやっていました。

浅野:少し話はかわって、Scalaを使っていてワクワクすることはありますか?

竹添:...(少し考え) 新しいものがどんどん出てくるのがテンションが上がりますね。Scala.jsもそうですが、実用的かどうかはさておき、本当に使えるかわからないけど面白いからやってみたというフェーズはJavaでもあったのですが、次第と成熟したプラットホームになると少なくなくなってきます。Scalaは今面白いからやってみたというフェーズで、postgresql-asyncのような興味深いものもたくさん出てきてますよね(笑)

瀬良:postgresql-asyncはNettyを使って実装されている、完全にJDBCを使わず同じようなことを自前で全部やっているやつですね。

竹添:はい。直接PostgreSQLと通信していてノンブロッキングIOで処理するというドライバーです。

瀬良:ブラジルの人が1人で書いてポンッと出てきたというのは今Javaではあまりないですよね。

竹添:そういう面白いものがどんどん出てきたり、ライブラリも使っていると新しい発見もあったりしてそういうところが一番ワクワクしますね。

瀬良:Scalaの普及を助けるという方向性でやっていきたいことや計画していることはありますか?

竹添:Scalaの新しい本を出したいと思っています。とある書籍の翻訳をやっていたり、それとは別に「プログラミング自体を初めてする初心者の人がScalaで」という趣旨の本の企画を考えています。

浅野:竹添さんが作られている、GitBucketの話も合わせて聞かせてください。

竹添:Scalaにとって、Scalaを触り始めるきっかけになるようなキラーアプリが少なく、GitBucketにはプラグインの仕組みがあるので、例えば「Tracのプラグインを作りたいからPythonをやり始めました」というような、ユーザがカスタマイズを通してScalaをやり始めるきっかけになれればいいなと思っています。

すごく熱心にパッチやプラグインを作ってくださっているユーザも増えてきています。

時には「Pythonしかやったことないからすごく難しいんだけどどうすればいい?」って質問もきたことがあります(笑)

浅野:そういう時はどう返信するんですか?

竹添:「いい勉強になると思うよ」っていいました。

瀬良:こういう事をきっかけにScalaをやり始めるというのはいいですね。

竹添:そうですね。これをきっかけにしてもらえると嬉しいです。GitBucketは本体を機能満載にすると身動きが取りづらくなってしますので、プラグインベースにしていきたいと考えています。

瀬良:UIもプラグインで作れるのでイメージとしてはJenkinsに近いのでしょうか?

竹添:はい。プラグインで自由度高く実装できる仕組みにしています。今ならプラグイン数も少なく手をつけれそうな所も多いのでチャンスです(笑)

瀬良:他にもこの機会に竹添さんに聞いてみたいことは...

浅野:Akkaについてはどうでしょうか?普段使っていますか?

竹添:普段使っていますが、なかなか厳しいところがあります。というのも、モニタリングがしづらいという点です。

標準でモニタリング機能がなく、メッセージがどこまで到達しているのか、どこかで詰まっているのかといったことを把握することが難しいためデバッグが困難になります。今はKamonを使ってGrafanaで可視化するということを試しているのですが、AspectJで実現されている仕組みということもあって、Akkaがバージョンアップした時にKamonを追従してアップデートしてくれないという運用リスクがありそうです。Akka自体にJMXなどで監視の口があるといいなと思います。

瀬良:Kamon をすすめる声を聞いたことがあります。

最近、Reactive Streamsが良さそうと言う人が日本で増えてきたのですが、例えばReactive Streamsのバックプレッシャーなどの状態をモニタできるようになればいいなと思います。それが標準的にTypesafeプラットホームで使えるようになればいいですね。

それと、ビズリーチさんの実務での成果をぜひオープンソースにして欲しいですね(笑)

竹添:リフレクションを使ってAkkaの中を確認したのですが、Akkaが中でデータを持っていなくて、通信の口もなく、そうするとKamonのようにインターセプトするようなやり方になってしまいます。

瀬良:Akka HTTPについては?

竹添:今は自社のサービスの使い方でアプリケーションレイヤーでそこまで必要性が出てくるかどうかを見極めています。Akka HTTPを利用すると並列度が上がってFutureベースになっていき、スレッドプールサイズの調整の制御が難しくなるので、透過的にスレッドプール増減を含め管理してくれるフレームワークがあると楽でいいのになと思います。

瀬良:Play 2.0 がでた直後の頃、Akkaの設定をデフォルトのまま本番稼働したところ想定していたほど性能が出ず、スレッドプールのサイズを大きくする必要があったという話はよく聞かれましたね。

竹添:Akka難しいですね。クラスターにして大きくするべきなのか、1個ずつ立ててリモートでラウンドロビンで回した方がいいのか、いろんな組み方ができるので難しいですね。

瀬良:Actorモデルのシステムデザインってみんながスムーズにできるものでしょうか?

竹添:私はシンプルな使い方しかしていませんが、大きなものになってくると運用も設定も難しいでしょうね。

Jeff:Akkaは仕組み的には単純ですがとてもパワフルなプロダクトで、そういう所が好きで私もよく使うのですが、 Sparkのような大規模な分散フレームワークを作るとすると大変かもしれません。小規模のアプリケーションでAkkaを使用していますが、知り合いから聞いた話になりますが、規模が大きくなってきて複数のシステムが関連あってくるようなアプリケーションではトラブルシューティングが非常に難しいと言っていました。

AkkaはSpringのような便利なアプリケーションフレームになっているので、用途に応じて選択して使えば素晴らしいアプリケーションを作ることができるはずです。

22516459691_d5973d0b59_k.jpg

瀬良:Scala習熟度が様々なチームメンバーと一緒にScalaプロジェクトをやってみて発見したことや気づきはありましたか?

竹添:最初はimplicitを多用して指摘を受けるという人がいたりしました。単純に機能を知らない人もいたり、traitの使い道はある程度指針を決める必要はあると感じました。そうしないとチームとしてブレが出たり、後から入った人がわからなかったり、レビューが好き嫌いの趣向で不毛になってしまいがちです。

瀬良:今はこういう風にしていますという、ルールやスタイルはありますか?

竹添:チームによってレベル感や使っているライブラリなども違うので、チーム毎にルールを決めてもらうようにしています。習熟しているチームはscalazを普通に使っていたり、関数型のスタイルを推奨していたりします。

瀬良:私たちのチームもチーム毎に違います。ルールや使うツールを他チームに押し付けるような形にはしていません。

竹添:うちはインフラ周り担当者の負担を考え、最低限WebアプリケーションフレームワークはPlayに統一しようという話はしていますが、必要性に応じてバージョンやそれ以外のフレームワークは変えたりします。

浅野:長時間ありがとうございました。最後に一言お願いします!

瀬良:Scalaの将来について聞きたいですね。2年後くらいの。例えば自分のScalaとの関わり方など。

竹添:たくさんの人に使ってもらえるものを作りたいと思っています。私はツールを作るのが昔から好きでEclipseプラグインを作ったり、今はGitBucketを作っているのですが、ユーザ数は多い反面、Scalaユーザに知られていない印象があるので、知ってもらえたら嬉しいです。

ScalaがJavaの置き換えになるほどの爆発的な普及はしないと思いますが、5年くらい前に今の状況は想像できていませんでした。予想より普及はしているので2年後はどうなるかわかりませんが、普及に少しでも貢献できたらと思います。

浅野:次回のインタビューの人をご紹介いただけないでしょうか。

竹添:私はSIを離れてしまいましたが、現在進行形でSIerでScalaの導入に尽力されているTISの前出さんのお話を聞いてみたいので、声をかけてみますね。

浅野:ありがとうございます。

お知らせ

ビズリーチでは「スタンバイ」という求人検索エンジンを作っています。

スタンバイのシステムではScalaがバックエンドで動いています。もしよければご参照ください。

あとがき

前回までインタビューアをしていた北野さんが急病でダウンで欠席し、当日に急遽私がインタビューアを引き受けて、拙さもありながらもゆったりとした時間の中で竹添さんに色々と自分の言葉でお話を聞ける貴重な体験でした。そういう状況を察してか瀬良さんも様々な質問をしてくださり感謝しています。当日の雰囲気を写真と文章でしかお伝えできませんが、原稿起こしをしている際に再度ワクワクしてしまった事はお二人の魅力の他ありません。どうもありがとうございました。

2015.12.17 Asano

Scala先駆者インタビュー VOL.3  ビズリーチ竹添さん 〜前編〜

Scala先駆者インタビュー VOL.3  ビズリーチ竹添さん 〜前編〜

「Scalaのアドバンテージはどういうところか?」を深く考えた先に

インタビューイー ビズリーチ 竹添

インタビューワー アットウェア 浅野/エリシール/ジェフ エムスリー 瀬良


浅野:今日は前回の瀬良さんからのご紹介で、GitBucket という Scala で書かれているオープンソースのGitHubクローンを開発されている、ビズリーチCTO室チーフアーキテクト竹添さんです。まずは、瀬良さんから次の紹介者として竹添さんをご指名頂いた経緯をお願いします。

瀬良:このScala先駆者インタビューで、最初にヌーラボの吉澤さん、次に私という流れできましたので、毛色を変えた話をできたら面白いんじゃないかと思いました。というのも、Scalaインタビューを実施されているアットウェアさんが受託開発をやっています。そこで、前職で受託開発をして現在では自社サービスをやっており、双方でScalaを採用した竹添さんに、前職を離れてみて感じたことや受託開発当時をふりかえりながら様々な視点で話をできたらいいなと思いました。

竹添:受託開発では結構大変でしたね。技術的な採用決定権がある仕事ばかりではなかったので、Scalaをどういう切り口でお客さんに導入してもらうかといったあたりは最初苦労しました。

浅野:弊社だと、アットウェアのバリューを出してエンドユーザや顧客に価値を届けるためには、技術的決定権だったりいいと思えるものが提案できるという要素は必要だと感じていまして、ある程度技術的なところは裁量をもたせてもらいプロジェクトを進めさせていただくことが多いです。

竹添:そういう技術的決定権やいいものを提案しやすい状況の時にScalaのアドバンテージはどういうところだと考えていますか?前職の時そういうことをよく考えていました。

浅野:私はまだまだScala駆け出しでありきたりの言葉になりますが、後発の言語ということもありマルチコア時代の並列処理が書きやすく、扱いがしやすいのと、分散環境に対して最小限のリソースを最大限に活かしていくという辺りでうまく適用できる辺りと考えています。

瀬良:Jeffさんにも話を聞いてみたいですね。

Jeff:つい最近、1ヶ月でアプリケーションのプロトタイプを完成したいという方がいらっしゃいました。(冗談っぽく)その時私は「この要件だと1ヶ月以内でJavaでやるにはちょっと厳しいですね。逆にScalaで問題なければ、何とかなりますよ。」と言いました。これが、今までのベストアンサーかもしれません(笑)。

全員:アハハハ(笑)。

Jeff:話に戻ると、お客さんにScalaを他のプログラミング言語の代わりに売りにした時は、基本的にはScalaだけではなくTypesafe社の他の技術と一緒に紹介することによって、この技術群の全体的な有用性を強調しています。

竹添:なかなか難しいところですよね。やっぱり何ができるようになるのか、保守を5年~10年して欲しいという話があったり、コストもJavaで作った時と比べてどれくらい安くなるのか、早くできるのかのアドバンテージが出せないとなかなか難しいと当時思っていました。テクノロジーの話だけだと説得力がなくて、一般的な業務アプリケーションではScalaの特徴である並列処理などのメリットも出しづらく、保守でもOSやハードやミドルウェアもすでに購入が決まっていていることもあったりで、そこに突っ込んでいくことが難しかったです。

また、お客様は技術者ではないことも多いのでテクノロジーの話をしても伝わらないこともあります。

瀬良:それっていつ頃ですか?

竹添:2010年ころから取り組み始めてScala Conferenceのちょっと前くらいまでの頃の話ですね。

瀬良:Scalaのバージョンが2.9でTypesafe社もまだ設立前、Play2がちょうど出たあたりの頃でしょうか。Red Hat 社でいうJBossのような土壌がなくて、進みにくい時代ですよね?

竹添:Scalaとしては当時はPlayがネームバリューがあって、巷ではScalaの名前を聞きはじめ非同期とか分散処理に強いという情報が本に載り始めた頃で、Playという単語で攻めていく感じでした。あとは、「うちとしてもトライアルなので一緒にやらせてください」とお願いしたり、Javaで作ったシステムのリプレース案件もあり、当時Seasarの行く先がなさそうだったので、「新しいものにしていかないと保守が辛くなっていきますよ」という話をしていました。

瀬良:アットウェアさんはTypesafeのコンサルティングパートナーということで、興味があって聞きたいことなのですが、Typesafeのコンサルテーションサービスは私が知る範囲ではまだまだ利用が進んでいないように感じています。問い合わせは感覚的に想定より多いものなんでしょうか?

Jeff: クライアントは興味は持ちますが、Scalaを使うところまでなかなかいかず、Javaなど枯れた技術を望まれている事が多いです。ScalaでというよりSparkの問い合わせが多くそれに合わせてScalaがやりやすいので、Scalaを勧めることもあります。

竹添:前職では10名くらいのチームでアジャイルで小さいプロジェクトを短期間でイテレーティブにやっていました。長い間Javaでずっとやっていましたが、これ以上Javaでやっていても生産性が上がっていかないなという頭打ち感があって、他に何か新しいものをやっていく必要性を感じました。

プロジェクト自体が小さく、限られたメンバーなのでやっていけたというところもあります。

プロジェクト規模によってはScalaで生産性をあげるということよりも、きっちり仕様に従って動くものを作ることが重視されることもあります。また、Sparkが普及したからといってScalaのデベロッパーがすごい増えるかというとそういう風には思えず、Web界隈では使われはじめてきていても、エンタープライズな開発にScalaが使われていくようにならないと、全体としてScalaデベロッパーのボリュームが増えたかという観点で厳しくて、やっぱりSIerの数の力というのはすごいという事を現職になってから強く感じました。

瀬良:竹添さんが前職でやっていたプロジェクトは割と少数精鋭でやっている事が多かったと聞いてますが、社内で相談を受ける案件は大きなプロジェクトも多かったのではないでしょうか。

そういう大きい案件は、Javaで作られた基幹システムの一部をリプレースする提案だったり、全体のリプレースに向けた提案だったり前提はあるとは思いますが、Scalaを売りにいこうとしていた大きな案件のタイプと、どう合わなかったのかを教えていただけないでしょうか?

竹添:特定のプロジェクトというより次期システムの計画を立てている段階であったり、Seasarを使っているけど今後どうしていこうか考えているという話が多かったです。大きなプロジェクトだとScalaをできる人を集めるのが難しいという理由が一番大きかったです。

当時はJava8のリリースが控えていたので無理にScalaに行かなくてもというのはありました。

浅野:違う軸で話をしますと、Java6〜7時代の停滞時期もあり、コップ本(コップ本は通称で「Scalaスケーラブルプログラミング」という書籍名です)の発売でScalaの波がきたのを感じました。

瀬良:メインでScalaを使っている人が増えてきましたね。

竹添:実は若い頃LispやHaskellをやっており言語のフィロソフィーには共感していました。ただ、それらの関数型言語は仕事で使うには無理かなと思っていたのですが、Scalaの登場ではじめて仕事で「業務と関数型の力を両立」させられる言語に出会ったというのを感じました。当時の同僚がScalaをずっと前からやっていてはじめて聞いた時には「やっぱりまだ厳しいんじゃないかな」という話をしていたのですが、それから暫く経ってSeasarの次をどうしようかという時に「Scalaはやっぱいけるかも」という話をしたのを覚えています。

瀬良:このあたりの話は以前にもおっしゃっていましたね。竹添さんの立場も変わって1年以上経ちました。違うスタイルでScalaと関わってきています。今の視点でお話が聞けると面白いんじゃないかと思います。

竹添:現職ではスタンバイという求人情報の検索サービスを作っているのですが、最初プロジェクト立ち上げの段階から数十人規模のチームを作らないといけなくて、Scalaで大丈夫かなという心配がありました。

最初から大きくしていく事も想定しておりマイクロサービスも視野に入れていました。 Scalaでやると決めたら育成や採用に力を入る必要があって、前職では無理だなと思っていたが実際にやってみたら意外とできました。

瀬良:どういう工夫をされたのでしょうか?

浅野:育てるという面で社内にScalaを浸透させて駆動していくまでにどういった道のりがあったのか教えてください。

竹添:2本立てとなります。まずは、リクルーティングは絶対に必要ですがすぐにできるようにはなりませんので、外部での発表や記事の執筆などを積極的に行いブランディングに努めました。最近ではScalaで仕事をする上での候補に入れてもらえるようにはなってきて、効果が出てきています。それと両輪で社内の育成をやっています。

基本的にその時点でスキルが不足してもScalaをやりたいと思ってくれている人にプロジェクトに参加してもらうようにしています。いくらJavaで出来る方でもScalaをやってみると詰まってしまう場合もあります。一つ目としては人を選ぶという事と、二つ目にはScalaを普通にしちゃうというのがあります。

最初は難しいと感じる事も多く、例えば「他の言語ではこんな事をしなくてもいいのに」といった話が出てくるのですが、「簡単じゃん」とか「なんでわからないの?」など普通論のレベルをあげちゃうと人はできるものだなと。また、最終的にはどこかで諦める事も必要です。必要以上にScalaらしい書き方を強要することはしません。「ここは本当はこう書くべきだと」というのはあるのですが、要件や機能を満たしていれば納期との兼ね合いを見てどこかで妥協していくという事もしています。そうやって人間的な運用をしています。

瀬良:スタンバイチームではどれくらいの人がいるんですか?

竹添:Scalaが書けるエンジニアは20人くらいはいると思います。フロントエンドとサーバーサイドを分けていて、フロントはフロントエンジニアだけで開発できるようにしています。Scalaエンジニアはバックエンドを担当し、全員がScalaを知っていないといけないという状況にしようとしていないので、それなりの人数でもやっていけています。

瀬良:それって結構大事ですよね。

浅野:できる人でやるという感じでしょうか?

瀬良:HTMLやCSSを書く人がScalaのSBTを起動しないと開発できないというのを避けないと現場が大変になってしまいますよね。

竹添:そういう仕組みで工夫できるところもあると思っています。

瀬良:ビズリーチさんのようにScalaを書けるエンジニアを10人くらい増したいなと思った時に他の会社でもやれそうなことは?(笑)

竹添:「楽しいと思ってもらえるか」ということですね。私が開催していたわけではないのですが、最初は有志で毎朝勉強会をしていました。座学で勉強というよりは、楽しくディスカッションしたり、達成感を感じる宿題を出して「できた!!」というような、心を壁に作らせない、苦手意識を持たせないというようなことができるといいのではと思います。

浅野:学ぶ時は、すぐに動いて、すぐに確認できて、すぐに効果が見える、というのがモチベーションに繋がるなと思います。取り組む時に「こういうライブラリを動かしてみよう」とか「これを使ってみよう」などテーマを持って勉強会を開催されているのでしょうか?

竹添:最初はひたすらコレクションの使い方というのをやっていて「インとアウトをこういう形にしてみよう」という問題を、GitHubですぐにダウンロードして動かせる雛形プロジェクトを作っておいて、そこでサクッとプログラミングできるような準備をして実施してました。

コレクション操作はパズルみたいなところがあるので、面白いのではないでしょうか。Futureをひたすらずーっと1週間やるというようなトレーニングもやっていたみたいです(笑)

瀬良:それは楽しいですね。(笑)

竹添:人によって面白さを感じるポイントも違うみたいです(笑)

後編へ続く...

Scala先駆者インタビュー VOL.2  エムスリー瀬良さん

Scala先駆者インタビュー VOL.2  エムスリー瀬良さん

「オープンソースの成長の源はフィードバック! 」

インタビューイー エムスリー 瀬良

インタビューワー アットウェア 北野/浅野/ヌーラボ 吉澤

北野:こんにちは。今回はScalaのWebフレームワークであるSkinny Frameworkの創始者の瀬良さんにインタビューしたいと思います。実はアットウェアの社内ナレッジシステムにはSkinny Frameworkが使われているのですが、その話はもう少し後にして、まずは、Scalaを使い出したきっかけを教えて下さい。

瀬良:最初に触ったのは2009年頃ぐらいですかね。その時はJavaをメインで使っていて、Scalaをちょっと触ってみたのがきっかけですね。その時は、私の当時の用途ではIDE のサポートなども弱かったこともあり、まだ実用で使うものではなかった印象でした。その後、今の会社に移って 2010 年頃から少しずつScalaの勉強を同僚とやり始めたのがよく触るようになったきっかけです。最初から思うと、こんなにScalaを触るようになるとは思っていなかったですw

北野:私の周りにもJavaをやってる人が多いのですが、参考にそこからScalaに惹かれたのはどうしてですか?

瀬良:自分がやり始めた当時はSIの世界だとJavaからRubyと言われていた時で、 でもJavaとRubyは結構違うし、それだけが次の方向なのかなと。その頃少しずつ触っていたScalaはJavaをベースにしつつもRubyに負けない記述性があって、静的な型付けがありました。そういうところが惹かれたところですかね。

北野:Scalaというと関数型というコンセプトがありますが、そのあたりはどうですか?

エムスリー 瀬良氏。SkinnyFrameworkの創始者・開発者

エムスリー 瀬良氏。SkinnyFrameworkの創始者・開発者

瀬良:そうですね、私はもともとJavaをやっていたので、Better JavaとしてのScalaをやりはじめて、いまもそのスタンスでやっています。関数型バリバリでScalaを使いたいという感じではないんです。いま使っている人の中には、Haskellとか本当は使いたいと思っているけど仕事ではScalaでやっていますという人もいると思うんですが、私はちょっとそれとは違いますね。

北野:今はお仕事でもScalaを使っていると思いますが、仕事で使うとする場合、Scalaのようなチームに取って新しいものを取り入れているときなどに注意することってなんですか?もし経験などがあれば。

瀬良:Scalaバリバリ(関数型)の書き方をして、チームの人達がわからなくなるような記述をしないようにすることですかね。ちゃんと皆がわかるようにすることは大事だと私は思っています。 Scalaを使うことが目的では本当はないはずで、ちゃんと目的のものを作るということであれば、さくっと仕事が終わり、バグも前よりも格段に減るというようなうれしいことが無いと仕事でScalaを使う意味はないはずです。 そういう時にScalaらしく書くというのは第一優先ではなく。使いはじめた時に「あっ、こんな書き方もあるのか?」とかいろいろやっていると楽しくなることもあるんですが、それもほどほどにしておかないと、周りのチームの人達がついて来れなくなったり。それは注意したほうがいいですね。 だから、あまり難しく凝った書き方をしないようにしようと言っています。

吉澤:そうですねw。 瀬良さんが書いているSkinny Frameworkの中とか見ても、関数型臭がぷんぷんする感じじゃないですものね。

北野:あくまでも道具としてまずは皆で使い出して、皆で良さを共感していかないとってところなんですかね。1人だけの意向で突き進んでいくのはリスクも増えていくことか。

北野:瀬良さんは、Skinny Frameworkをオープンソースとして開発していますが、実は、アットウェアでもSkinny Frameworkを使っています。 弊社のナレッジシステムのSiitaというQiita互換のようなものを社内で開発して社内ナレッジを貯めるところとして稼働しています。 SiitaのSはScalaのSというよりは、SkinnyのSなんですw

瀬良:えぇ、そうですか。面白いことやっていますね。是非公開して欲しいです!今度アットウェアに訪問して見てみたいです。

北野:でも、どうしてSkinny Frameworkを開発しようと思ったんですか?

瀬良:そうですね。 ScalikeJDBCというものがあって、それはそれでよかったのですが、もっと一般的なORM であるようなhas-manyの関係性の定義とか簡単にできるといいなと思ってプロトタイプを作ってみたところ、思ったより使えそうな感じにできたんです。また、その頃、仕事でScalatraを使っていたことがあったんですが、少し自分で改良したいなぁと思うところがあったので、それらWeb部分とORM部分、そしてバリデーションの3つをまとめたものが形になりそうだなというところでつくることにしました。

その時はまだORMのプロトタイプしかなかったんですが、その年の10月にドワンゴさんで勉強会があって、来年春までに出します!と言っちゃうことで、 自分でモチベーションを上げていったという経緯もあります。

北野:有言実行ですか、素晴らしいですね。OSSだとフィードバックをもらって成長していくというのは大事なことだと思うのですが、Skinny Frameworkをオープンソースでやっていてフィードバックはどうでしたか?

瀬良:そうですね。GitHubのスターとか、プルリクエストとか来るのは非常に嬉しいことですね。いろいろなフィードバックがあることは本当に助かります。何も反応がないのが一番つらいというか、どこがよくないという具体的な指摘だったり、漠然とした批判的な意見でも何か言ってもらえる方が全然いいです。そんなフィードバックのおかげで、今があると思っています。 あとは身近な人が使ってくれることですね。やはり社内の人とか身近な人からバグってますよと言われるとすぐに直してリリースしたくなりますからね。

吉澤:サービスやアプリでもなんでもそうですよね? 無視されて、なんも反応ないのは本当に寂しいですもん。 みんな本気で使い出すと指摘しだす人もいたり。それって本当に使っているってこと事ですしね。

北野:今後はどのような活動をメインに?

瀬良:Skinny Frameworkのバージョンアップを考えています。今のバージョンは1.3ですが、2系のバージョンアップの活動をメインでやっています。 今のSkinny Frameworkは、他のOSSのライブラリなども使っているところがあって、そのOSSとの依存があったりします。中にはアクティブで無くなってしまったOSSなどもあるので、それを見極めながら、整理をしているところですね。

北野:瀬良さんの話はITに関わっているものとしてすごく感銘しました。もちろんSkinny Frameworkもです。今後も活動をつつけて、日本を代表するOSSコミッターを続けていってもらいたいと思います。瀬良さんとして、そのような活動をコミュニティなどを通して広げており、若い人が瀬良さんの背中を追う日も近い、そんな感じがしました。

北野:さて、次回のインタビューの人をご紹介お願いします。

瀬良:それでは、こちらもGitBucketをはじめとするOSSの活動をアクティブにされていて、受託開発・自社サービス開発の両方でScalaの実用経験をお持ちの竹添さんで!

北野:ありがとうございます。