Scala先駆者インタビュー 最終回 ChatWork かとじゅんさん 〜後編〜

サービスの規模も変わってきてScalaの活用も色々と試行錯誤しています

－－ チャットのサービスが使えなくなると相当困りますよね。AWSのCloudWatchLogsを日本ではChatWorkさんが一番使ってると聞いたことがありますが、それだけ多くの人が当たり前のように使っているということですよね。

かとじゅん：チャットのメッセージはかなりの流量なので技術的にはすごい面白いところではあります。これくらいの規模感にならないとActorなどがそこまで必要ない気もします。

－－ IoTなどのようにクライアントが沢山増えることでトラフィック量やデータ量が明らかに増えますよね。そこで、リアクティブシステムのような流れになるというところでしょうか。

かとじゅん：クライアントが増えて小さいデータがたくさん飛んでくるといった状況が加速していくと、リアクティブシステムのような概念は当たり前の技術になるだろうと思っています。加えて、無停止でデプロイできる、ワークロードに応じたスケーリングが出来る、どんな状況でもとにかく早くレスポンスを返せる、などができることが理想ですね。例えば、普通はDBが落ちたらアプリケーションも落ちてたと思うのですが、Actorの間に先ほど説明したBackoffSupervisorを入れておくと、DBコネクションをハンドルしているActorがリトライするときにバックオフされていくので、DBには負荷がかからなくなっていきます。そして、DBが再起動すると接続が自動的に回復して次のタスクが処理できるようになります。もちろん、このような仕組みがあっても手放しでは運用できませんが、運用負荷は軽減することが可能です。

－－ そういった運用設計をしようとすると、インフラ部分だけでなくてプログラミングモデルのところからそういうことを意識する必要があるのかなと思います。ただ、どこまで品質の完璧性を求めるのかというところが個人的には気になっていて、サービスによっては5分ほどのメンテナンスタイムを入れても問題ないといった場合もあるかと思うのですが。

かとじゅん：それは要件次第でしょうね。高い非機能要件が問われるWebサービスであれば、Akkaなどのリアクティブシステムを採用することは比較的検討しやすいと思います。一方で、SIだと一口にリアクティブシステムが良いとは言っても、別の変数の価値基準に引っ張られるので簡単には導入できないかもしれませんね。ただ、例えば、社内システムでも可用性を重視してほしいとか、大量データを扱うバッチ処理を短時間で処理してほしいという要望があった場合、開発側もそれに対応できるのであれば検討の余地はありますよね。とはいえ、教育や運用のコストの問題は無視できないと思いますが…。やはり、エキスパートと呼ばれる人がいるかどうかに起因するかもしれません。加えて、アーキテクチャを考えるときには変数が沢山あるので、自分はエンジニアだから社内の政治は無視するという立場を取っていると、技術的優位性だけを主張してもその技術を採用できなくなるというジレンマがありますね。

－－ 私はスクラムでプロジェクトを回すこともありジレンマわかります。さじ加減や思い切りはいつも悩みます。

かとじゅん：他の面で言うと、自分のブランディングのことを考えたときにとにかく適用事例を増やしたいと考えるならば、他の変数は抑えることもできなくはないですよね。エンジニアとしてのポジショニングを考えると自分の得意なことを明確にしてブランディングした方がやりやすいですし。手段が目的化してしまうのは良くないとは言え、差別化の問題やそれで解決できる問題に効果があったりすると価値があるので、そういったことも戦略として考えてもよいのではないかと思います。

転職を考えた時に目的に応じてScalaが使えるというところを選びました

－－ かとじゅんさんも、転職されるときにはそういった価値基準があったのでしょうか。

かとじゅん：僕が転職したときは、Scalaが使えるところを意図的に選びました（笑）もちろん、単にScalaが使えるだけでなくきちんと目的に応じてScalaを採用できるところを厳選したつもりです。スマホが流行して以来、小さなリクエストを非同期で次々に捌く必要が出てきて、そういった問題解決に対してはScalaが妥当だろうと思っていました。Twitterがそれを証明したという後ろ盾の影響も大きいのですが、PHPだとプロセスモデルなので非同期処理が難しいという印象があります。また、Hack/PHPのランタイムである、FacebookのHHVMでもasync/awaitが使えるようになってきているので、スケールするサービスに対してはそういう課題解決が必要だろうと思っています。なので、ScalaでもJVMのパワーも使って、これからの要求に対応できる可能性がかなり高いと思っていました。チャットもどちらかといえばそんなに大きいメッセージは来ないですし。

－－ 絵文字1文字だったりしますよね。

かとじゅん：そうです。「OK」 とかそんなのがぽろぽろ飛んできて、その度にブロッキングしていたら処理が追いつかないので、そういうサービスを考えたときにScalaは妥当だったかなと思います。ちなみに、ソーシャルゲームプラットフォーム企業のG社でもチャットサービスを作っていました。Finagleをベースに自分でルーティング用のフレームワークを作ったりしながら、10名ぐらいで数ヶ月かけて開発しました。

－－ そこで経験を積めばさらに勉強になりそうという見方もできたのではないですか。

かとじゅん：確かに、リリースした後のハイトラフィックな状態で運用経験を積むことができれば相当な知見は溜まっただろうと思いますが、その当時のG社はサービスのライフサイクルが比較的短い状況にあったので、開発したサービスが安定稼働している状態で次にチャレンジしたいという思いがありました(汗)。そのチャットサービス自体は、よい意味で僕の期待を裏切って、今も現役ですね。ほんとそれはよかったと思います。

結局、次もチャットサービスをやってるのですが（笑）

－－ かとじゅんさんの影響はだいぶ大きかっただろうと想像しているのですが、その後チームはどうなったのでしょうか。

かとじゅん：僕が辞める前にチームの中で十分に共有していましたし、僕の後を技術的に支えてくれる人もいたので問題ありませんでした。ただ、10人中で1人抜けるというのは重みはあったかなと思います。若手の人も結構いたので、客観的に考えて信頼の置けるエンジニアが1人抜けたという不安はあったかもしれないです。でも、自分の人生なので「お前らも頑張ってSurviveしてくれよ！」みたいな感じだったのが正直なところです。当時の関係者の方々にはご迷惑をおかけしました（笑）

技術的な部分を先導している人が全部やると周りの人達の成長を阻害する、伸び代を潰してしまうこともあると思うのでほどほどで退くという選択はアリかなと思ってます。

Scala転職が抵抗なくなるくらい採用事例などが広がっていると感じます

－－ 転職の話に繋げてなのですが、かとじゅんさんのTwitterに、Scalaで転職を考えている方は連絡くださいと書いてあったのですが実際に紹介する機会などはあったのでしょうか。

かとじゅん：スタートアップだとエージェントが要求するような採用費用を掛けられないので、エンジニアを紹介してくださいという話などもあり、実際に何人か紹介しました。

－－ 企業が求める側面と、エンジニアから転職したいという側面の両面あると思うのですが、それぞれどんな感じでしょうか。

かとじゅん：エンジニアからという側面では、やっぱり僕の過去の現場や会社の繋がりが主です。あとはScalaMatsuriで知り合った人などですかね。もちろん100%の回答はできませんができるかぎりの紹介をしています。

水島：ScalaMatsuriにいけば企業ブースもありますし、今は供給の方が圧倒的に少ないのでScalaをキーワードにした転職の機会は結構あると思います。

かとじゅん：現時点でScalaをやってない人にもっとScalaに興味を持ってもらって、Scalaを使って仕事をしたいという人が増えて行くと良いですね。

－－ 企業側も色んなレベルのエンジニアを求めると思うのですが、具体的な要望があったりするのでしょうか。

かとじゅん：なぜScalaのエンジニアが欲しいのかを企業側に聞くと「Scalaをやってるエンジニアはちゃんと設計もしてくれそうだ」と思っているという話を耳にします。ただ早く作ればよいだけでなく設計もしっかりやってくれそうな人が多そう、というイメージを持っているようです。ひとまとめには言えないですが、カルチャーとしてそういう雰囲気はあると思います。Scala Daysのセッションを見ていると、ドメイン駆動設計の言葉が入っていたりもするので、設計やアーキテクチャを語る人が海外にも結構多い気がします。

水島：そういった上流部分というか、最近はもっぱら設計やアーキテクチャについて語る人が多いですね。

かとじゅん：Konradさんの発表を聞いた時に、高度な設計思想に基づいて問題解決する姿勢に関心しました。聴衆のみんなもあまり難しい顔をせずに聞いていたように思うのですが、Promise、ストリームなどの非同期処理に適したモデルに慣れていない人からすると、割と複雑な概念を話していると思います。なので、Scala界隈には複雑な問題領域に立っている人がいて、特徴が明確になっている気がします。

そもそもTwitterがScalaを採用したのも性能上の問題の限界を感じて導入しようというところからきているので、コミュニティとしても、そういうところに立っている人が多いのかもしれません。大量のトラフィックをどう捌こうかといったような方向に関心が向いている特徴はあるかなと思います。

かとじゅん：転職の話に戻りますが、ScalaMatsuriだとコネクションはすぐできると思うので、気づいたら転職していたみたいなこともあるかと思います。セプテーニさんを始め、将軍スポンサーを筆頭にいくつかの有力な企業がScalaを採用したり、イベントを開催したりしていると思います。

－－ Scala採用の募集は広がっていると思うのですが、その中でもみなさんはどう考えてScalaで転職しようと考えているんでしょうか。

かとじゅん：純粋にこれから新しい言語をやってみようというモチベーションだったり、ハイトラフィックなコンテキストでやっていきたいというところですかね。一昔前のウェブはLL言語で支配されていたので、静的型付き言語は扱いづらいとか大袈裟というような印象があったのですが、今となってはその文化圏にGolangやScalaが食い込んできて昔とは勢力図が違っていますよね。なので、そこそこやっていた中堅の人が静的型付き言語でWebができるらしいということで興味を持ってたりもしているようです。

水島：全世界的にだと思うのですが、静的型付き言語の復権みたいなものがあると思っています。RubyやJavaがいた2000年代前半から中頃だと、Webにおける支配的な静的型付き言語はJavaしかありませんでしたが、その頃はJavaの進歩が止まっていたうえに静的型付き言語を窮屈に感じてLL言語への流出があったのだろうと思います。でも、その時はたまたまJavaの進歩が止まっていただけで、その後にScalaみたいな言語が登場してきて、型推論があったりして静的型が再注目されたのだと思います。

かとじゅん：その話の流れで、RubyがSoft Typingを取り入れる話とかありましたよね。あれは構文チェックのような仕組みなんでしょうか。

水島：構文というか静的型チェッカーを入れるような感じですね。Matzさん曰く、型は書きたくないからそれを推論したいというようなところでしょうか。PythonもType Annotaionみたいなものが入って静的型付きの特徴を取り入れるような動きが見られます。

かとじゅん：またJavaScriptの話になってしまいますが、最近はRx系のプロダクトも意図的にTypeScriptで書いてコンパイル結果のJavaScriptを配布していたり、flowtypeを使う人も増えてきているので、静的型付きの復権みたいなものはあるかもしれませんね。SmartNewsさんやドワンゴさんやGREEさんも使っていて、Scalaは既に実績のある言語として認知されているので転職に対しても抵抗が少なくなったのかなと思います。

コミュニティーへのフィードバックを意識して今後も活動していきたいです

－－ 今後、力を入れたい取り組みとしてはどのようなことを考えていますか。

かとじゅん：先ほども話した通りWebな文脈でいくとハイトラフィックな方向に興味が向かっていますし、障害が起ても全体に波及しないアーキテクチャというような文脈でどんどん実践経験を積んでいきたいと思います。そこに対しては、アクターモデルがベターかと思っているのでこれからも使っていくと思います。あとは、運用で払わないといけないコストが課題になっているので、その辺りの知見を貯めてコミュニティーにフィードバックしていくのと、自分のブランディングの一つとしても活動を継続していければ良いなと思います。

Scala先駆者インタビューはカラーが出た企画としてよかったのでは

－－ 最後の話題となります。このScala先駆者インタビューという企画をはじめて約2年、今回で終了となりますが、お二人の目からみていかがでしたか。

かとじゅん：こうやって声をかけてもらう前から見ていました。先駆者というだけあって「歴史を築いてきたすごい人達だな」と思いながらも、自分としては「すごい人達だなというよりも一緒に作り上げてきた同志」という風に感じています。前出さんや竹添さんの回など、立場が違えど、色々苦労なさったんだなというのがわかったり、同じ思いでScalaというモノに関わってきたんだなと。こういう方々がいないと今のScalaコミュニティが存在していなかったんだと改めて思いました。

Scalaコミュニティーを一緒に築き上げてきた人達とは、各々で別々の形でScalaに関わってきましたが、それゆえに色んな方向性を持った人が集まれる健全なカルチャーを築けたと思います。例えば、僕はScalaイベントでDDDの話しをしたり、岡本さんはReactive Streamsの話をしたりと、それぞれカラーがあり、一つの色だけに合わせる必要がないので、個性をもった人がScalaコミュニティから弾かれるようなことはありません。

Scalaのコミュニティはそのような成り立ちから色んな人がいますね。今では、コミュニティも大きくなり、自分の興味ある分野にさらに入っていきやすいのではないでしょうか。

－－ この企画自体も、Scalaを使い出した時に少しでもコミュニティに還元できることはないかと思い始めました。元々縁があったNulabの吉澤さんに声をかけさせて頂いたところから始まり、あまり後先考えずやりはじめましたが、出演だけでなく助言や紹介などしていただくなど、すごくScalaコミュニティの方々の温かさを感じました。

水島：Scalaをやりはじめたような方々に「Scalaのコミュニティはこんな感じの人がいるのか」というのを知ってもらうきっかけになったのも良かったと思います。Scalaに馴染みがある人からすると「この人が今更？」というのがあるかもしれませんが、今回のかとじゅんさんのことでも、付き合いが長い自分自身も知らなかった「きっかけ」が聞けたり、「そういう風に考えていたのか」など新しい発見もありました。

かとじゅん：僕も同様に見えていなかったところに気づけましたし、色んな人にとって、先駆者たちがロールモデルになっているので広く目を通してもらいやすいのかもしれないですね。

－－ ズバリこの企画は成功だったのでしょうか。

水島：たぶん成功だったと思いますよ。

かとじゅん：アリだと思います。改めて個人のパーソナリティに触れる機会ってあまりなかったので、登場している人と「二人で飲みに行きませんか？」って言える人ならいいのかもしれませんが、そうでない人も多くいて、「でも話は聞きたい」という人もいますので、いい機会になったのでは。

－－ そういう意味では、この企画では実は、私が一番ラッキーで得したのかもしれません。話をするのは緊張するのですが、こういう機会でもないとかとじゅんさんや水島さんと長時間お話する時間はとれないですし、「実際のところどうなんでしょうか？」といったオフレコのようなことを聞けたり、私が普段感じたちょっとした疑問やぶつかっている壁や悩みや仮説のことなど相談できました。

かとじゅん：それも、いいんじゃないですか（笑）

－－ 特に会社としての取り組みや、お客さんやチームで一緒にモノづくりをしていく時にどんなことを考えているのか意見が聞けたり、前出さんがあれだけ苦労されていたというのは、話を聞くまではとても意外で、共感を持てるところがたくさんありました。

かとじゅん：Scalaコミュニティ以外のコミュニティの方々にもそういうメッセージが届いているのではないでしょうか。

こういった企画を続けていけると良いですね

かとじゅん：ということで、今後この企画どうなるか？という辺りの話ですね。

－－ はい、この企画を始めた序盤に登場していただいた瀬良さんや竹添さんの時点で「やっぱ水島さんですよねー。先駆者と言えば。」という話題も度々出ていて、水島さんに辿り着いたらゴールだと内々心の中では決めていました。そして、最後の水島さんからの紹介いただいたかとじゅんさんで締めさせていただきました。

水島：Twitterで「先駆者といっていいのは@kmizuだけだろ」と言及されたのは印象に残ってます（笑）

－－ ずっと続けていくと、中だるみもでてくるでしょうし、一旦先駆者というテーマ区切りをつけることにしました。

かとじゅん：いいと思います。また、最後に声をかけてもらって光栄です。（笑） 僕は「あちこちでScala入れて回っている」というようなことを、D社時代の同僚から言われました。

まぁ、僕だけじゃないと思いますが（笑）

－－ 私は、みなさんほどScalaを使い込んでいるわけでもないですし、もし、次の企画をするとなると、どういうモノが望まれているんだろうか？私が聞いても話題を引き出し切れるのか？という懸念はありますが、ただ、今回のごきげんよう形式は面白くてよかったので、別テーマで「AWS」「クラウド」などにしたり、またはScalaの別テーマなどをするのもアリじゃないかと思っており、この企画シリーズ自体を続けて、OSSを使わせてもらっているフィードバックや貢献として何かできればいいなと考えています。

かとじゅん：実は瀬良さんと飲んだ時に、この話をしたことがあって、Play FrameworkやAkkaなどの有名なコミッターの方にハングアウトで繋いで、英語ができる方々と一緒にインタビューして記事に起こしたり、LightbendのYokotaさんも巻き込んだりするのも面白いね。と。

半年に一回くらいになってしまうかもしれませんが、こういうことができたらいいですね。

水島：海外の方にインタビューするなら自分も協力できます。

かとじゅん：引き続き日本国内を対象にやるなら、Scalaを採用している会社の話をきかせてもらうのもいいかもしれませんね。ドワンゴさんやサイバーエージェントさんなど、採用サイトで書いてあること以上のことを知るきっかけになるのでは。

日々どういった考え方で、Scalaを仕事にいかしているかなど聞けるとよさそうですね。

－－ パーソナル中心ではなく会社中心で繋げていくという感じですね。

かとじゅん：教育のこともつきまといますし、企業が興味を持っている分野と、個人が転職する時の材料としてそういう情報を見たがると思います。

－－ 最初の一社としたら、お二人から紹介していただけそうな会社ありますか。

かとじゅん：やっぱドワンゴさんじゃないですか（笑）

水島：もしやるなら会社の人にたぶん話もできますし、サイバーエージェントさんを紹介できるかもしれません。

かとじゅん：Scalaが人気でる前からやっていた会社さんからインタビューを始めて、徐々に最近やりだしたところに繋げると良いかもしれませんね。

－－ この企画を続けると喜んでくださる方もいそうなので、続けてみたいという気持ちになっています。

かとじゅん：そうですね。僕に協力できることがあれば。Scala以外を考えているのであれば、JavaScriptをはじめ他の言語やクラウドなどの分野でも紹介できる方もいますよ。

水島：他のプログラミング言語など興味もあります。何か続けていかれるのであれば、協力したいと思うので、できることがあればいつでも言ってください。

－－ どうもありがとうございます！今日は長時間ありがとうございました。また新たな企画を考えた時にはご相談させてください。

出席者

• インタビューイー ChatWork株式会社 かとじゅんさん
• インタビューワー アットウェア 浅野・三嶋、 株式会社ドワンゴ／一般社団法人Japan Scala Association 水島さん

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

• VOL.8 ChatWorkかとじゅんさん 〜後編〜
• VOL.8 ChatWorkかとじゅんさん 〜前編〜
• VOL.7 株式会社ドワンゴ／一般社団法人Japan Scala Association水島さん
• VOL.6 株式会社BONX／一般社団法人Japan Scala Association麻植さん
• VOL.5 ChatWork大村さん
• VOL.4 TIS前出さん
• VOL.3 ビズリーチ竹添さん 〜後編〜
• VOL.3 ビズリーチ竹添さん 〜前編〜
• VOL.2 エムスリー瀬良さん
• VOL.1 ヌーラボ吉澤さん

Scala先駆者インタビュー 最終回 ChatWork かとじゅんさん 〜前編〜

めぐりめぐってたどり着いた最終回

－－ 過去7人の先駆者をご紹介しましたが今回で最終回を迎えます。最後は水島さんからのご紹介で、かとじゅんさんです。水島さんとかとじゅんさんの出逢いの頃からお話をきかせてください。

かとじゅん：水島さんとの出会いは、ちょうどScalaを実践投入しようと思っていた時でした。

水島：実は、そもそも自分がかとじゅんさんといつどこで出会ったのかをあまり憶えていないんですよね......（笑） かとじゅんさんが書いていたブログに時々出没してコメントしていたのは憶えています。

かとじゅん：ブログにもよくコメントいただいてましたよね。僕が初めて水島さんと出会ったのは、確か僕がD社時代にまだScalaを実践投入してない段階で、Scalaを勉強するために一度社内勉強会を開いたことがあって、そこに水島さんを呼んだ覚えがあります。

水島：なるほど、そう言われると加藤さんに呼ばれた記憶はあります。

かとじゅん：あとは、吉田さんやゆろよろさんも来てくれた気がします。ただ、今みたいには盛り上がっていない状況ではありました。僕が最初に水島さんを見かけたのは、2007年頃に筑波かどこかで開かれたJJUGでScalaの紹介をしていた時だったと思います。

水島：はい、していましたね。

かとじゅん：その頃の僕は、Java寄りの考えがすごく強かったので、Scalaを見た時は「全然訳がわからないな」と感じて1回身を引いたことを憶えています。そこから、3年くらい時間を空けた2010年頃、ちょうどドメイン駆動設計をやり始めて、Viewモデルとドメインモデルやドメインモデルとテーブルモデルの、レイヤをまたいだモデルの変換をmap, foldなどの高階関数を使って考えていた時にScalaをやり始めました。きっかけとしては、Asakusa Frameworkを開発している荒川さんから、そういった問題解決には関数型の考え方が役に立つのでScalaをやってみると良い、というアドバイスをもらってそこからアクセルをかけてScalaを実践的に始めました。

色々な障壁がありながらもScala導入の土台作りに取り組んでいました

水島：加藤さんがScalaを使い始めたのは、どちらかというと、プログラミングの面よりも設計手法として見たところからなんですね。

かとじゅん：そうですね。Scalaを学びたいというよりも問題解決のための設計手法を学びたかったという気持ちがあって、オブジェクト指向をベースにしながら関数型の考え方を取り入れているところは、僕の中ではすごくフィットしてました。実際にやってみるとすごくやりやすかった印象があります。Scalaでは、Javaの資産との結合部分にnullが登場して扱いが辛いなどという話はありますが、mapやreduce、foldなどミクロな解決手法を組み合わせて大きな問題を解くというコンセプトがドメイン駆動設計をやるときにマッチした気がします(ただ、高階関数の名前はユビキタス言語には対応付かないことが多いので、ドメイン層のI/Fではなく、その内部実装で使えそうという話です)。そこが出発点で、そこからはひたすらそういうことばかり考えていた気がします。この時は、まだD社の社内で導入できるかどうかというところではありました。

水島：2011年8月頃に第1回Scala会議を、かとじゅんさんが開催しましたよね。

かとじゅん：やりましたね！いろんな人に助けてもらって開催できましたね。感謝しかないです。記憶が定かではないですが、その年の12月に第二回も開催していたようです…。Scala人口を増やすためにScalaのコミュニティーを育てて、Scalaを使うための土壌を広げたかったという思いがありました。手段を目的化してしまっているような側面もあったのですが、実用言語として実力のある言語だとその当時も感じていたので、課題感が同じ人達が集まって情報共有できると良いなということでやっていました。

－－ その当時で何人くらい集まっていたのでしょうか。

かとじゅん：80人くらいです。

水島：今でこそ、ScalaMatsuri(2017年開催はこちら)は海外の人も含めて大勢の方に参加していただけるようになりましたが、当時の浸透度や認知度からすると、かなりの人数が集まっていたと思います。

かとじゅん：今では、ScalaMatsuriの規模感が当たり前みたいになってしまっていますが、僕からすると、あの当時と比べても短期間で劇的に変わったなという印象です。

－－ それは日本だけでなく、海外で見ても同じような盛り上がりなのでしょうか。

水島：そうですね。最近はApache Sparkを使うというところからScalaを使い始めたという人達も多くなっていますよね。

かとじゅん：Sparkを使いたいからScalaを使うのは当たり前みたいな話もあるようですから、違和感なく使い始める人も多くなっていると思います。

水島：Scalaに関して言えば、Sparkが一つの火付け役になって、キラーミドルウェアとして良い影響を与えてくれたと思います。

かとじゅん：Scalaをやり始めた当時は、Scalaをプロダクトで採用する時にはすごく苦労しましたね。PHPとJavaの運用実績があるなかで、それ以外を導入すると運用が大変になるという理由から、新しいモノを導入することについては、インフラを担当する方達が簡単には首を縦に振りませんでした。ただ、Scalaが良かった点として、伝統的なJavaのランタイム上で動くということがかなりのアドバンテージになっていたのは事実です。あの当時は、Javaであるということが導入障壁を下げたという感じです。コンパイルが遅いなどの辛さはありますが、JVM上で動くのであればインフラの人も既存の知識とツールで対応できる、というところがハードルを下げましたね。Scalaと言わずに「Javaのアプリケーションです」と言って使っていました（笑）

水島：今のD社だとチーム単位に裁量があって責任を持つという空気感がありますが、当時は違った雰囲気だったのですね。

かとじゅん：インフラの最高責任者の人が首を縦にふらないと新しい言語やミドルウェアは採用できないという風潮がありました。これは、会社とかインフラ部門が悪という話ではなく、全体最適を考えた場合にすごく妥当な判断だったと思うんですよね。でも、僕らは個別最適も必要と考えていたので、そういう難しいゲームのルールを把握し、インフラ部門の協力者も得て、Scalaの導入に成功したという感じです。ちなみに、D社でScalaを最初に取り入れたのが、友人で元同僚のヨシオリで、彼が当時のチームでKestrelを導入しました。僕がPlay FrameworkでRESTサーバを書いていたより前に本番環境に乗っかっていたようです。だから、一緒に飲むと、彼に”最初に道を作ったのは俺だぞ”とツッコミをもらうことがあります(笑)

ただ、Scalaが黎明期だったということもあって、そういうことを大手を振って発言できないカルチャーではありました。なので、D社でScalaを採用しますと最初に表立って発言したのは僕かもしれないですが、それ以前にも隠密で実践している人達はいました（笑）

水島：ひっそりとですか（笑）

かとじゅん：今でこそ、非同期・ノンブロッキングで処理をしたいとなったら一つの選択肢としてScalaは有力候補になるのですが、当時はPHPでもメッセージキューを使えばできるだろうということを言われましたね…。

土壌がない状態でやるからには覚悟を決めて実践してました

－－ 何もないさら地からScalaを導入したと言った感じでしょうか。

かとじゅん：最初はScalaの土壌が無い状態で導入を図っていたこともあってか、上司には"ほんとに大丈夫？"などと心配されるようなことがありました。まぁ、上司としては適正な振る舞いだと思います（笑）。そういった事情もあって、Javaアプリケーションだということだけを伝えて(ScalaコンパイラとJVMという分離された信頼性という担保があったから)、表立ってはScalaとは言わずに採用するということをしていました。「許可を求めるのなら謝罪しろ」ということではないですが、エンジニアが良いと思ったものを裁量で導入して、上手くいかなければ謝る覚悟を決めて実践していました。これを真似すればうまくいくとはいいませんが、技術的に裏打ちされた、現場の強い覚悟みたいなものがありましたね…。

－－ 一方で、チーム内での評判はいかがだったんでしょうか。

かとじゅん：チームメンバーの理解が得られやすいものという一定の基準は当然ありますね。実際に、メンバーには新しいものが好きな人が多くて、そもそも大学で関数型の研究をやってた人やOCamlができる人が自分の周りにいたので抵抗なくやっていました。たまに、なぜScalaは引数を型推論できないのかといったような内容の質問を受ると、困るので、「そういうのは水島さんに聞こう」と言って水島さんに質問したりしていました（笑） そういう意味では、無理なく浸透した感はありました。

－－ 水島さんは結構そういう質問を受けたりするんですか。

水島：そういうのはしょっちゅう聞かれていました（笑）引数の型推論の話について言えば、nominalとstructureのタイプの引数の推論について、OCamlの例などを挙げてモヒカンばりに突っ込んだりしていました。

最近では問題解決手法の一つとしてのScalaが段々と認知されてきたように感じます

かとじゅん：さきほどモヒカンという言葉が出ましたが、当時は、社内勉強会に参加してくれていたモヒカン達が勉強会でモナドに代表される型クラスの話を普通にしていて、そういう話を聞いたScala入門者の人達がカルチャーショックを受けて良い刺激になる、というのが何回か繰り返されるのを見てきました。もちろん、実際にScalaを実践投入するならPlay FrameworkやFinagleが良いといった実用的な面での情報交換もありました。ただ、単に仕事で使う言語というだけでなく、自分がもっと上手く扱うことができればコードの表現力を向上させることができると話す人達が結構いて、実用でありながら工学的なことも考えるというコミュニティーのカルチャーにはJavaコミュニティーには感じられなかった学ぶべき世界観があったと感じています。

水島：それもありますが、実用で使っている人でもScalaから何かを学び取ろうという感じで触っているというコミュニティーのカルチャーはあるかと思います。

かとじゅん：そうですね。実用もさることながら、Scalaを使って何かやってみよう、学びを得ようといった入り方は共通認識として通じていましたね。

－－ 関数型から何かを学びたい活かしたいという流れから、数年前にFunctional Reactive Programming(FRP)というプログラミングモデルが話題になりましたよね。

かとじゅん：言わずもがな、FRPを学ぶには関数型プログラミングの知識は必要ですね。ChatWork社の大阪のメンバーも数年前からFunctional Programming in Scala(和訳版はScala関数型デザイン&プログラミング ― Scalazコントリビューターによる関数型徹底ガイド)の勉強会を月1回のペースでやってます。色々な人が集まる中で、Haskellなどの関数型プログラミングに詳しい方からサポートを受けながら進めているそうです。

余談ですが、関数型はパラダイムが違うので難しいと言う人は多いですが、モダンなJavaScriptを書く人達は、高階関数なんて当たり前に使っているので、Scalaにも応用できる広い世界観を持っていると感じています。core.jsのインタフェースを見てるとmapやreduceは元々あって、Scalaに慣れている僕からするとすごくやりやすいです。ファーストクラスファンクションなカルチャーだから自然に慣れてしまうんだなと思いました。逆に、兼ねてからJavaを使っている人達からは、JavaSE 8で導入されたStream APIで記述されたコードを見ると何をやってるか分からないという、声も聞きいたりします。処理の効率性や宣言的な記述としては意味はあるんだろうけど、理解し難いというメンタリティーはあると思います。

ただ、Microsoftが.NET向けのRx(Reactive Extensions)を開発したきっかけで、.NETだけでなくJavaScriptをはじめ様々な言語に広まったことは有名ですが、Springも力を入れているようでReactive StreamsのAPIに準拠したReactorというプロダクトを開発しているようです。そういう意味ではリアクティブシステムに関連する話題が増えました。つまるところ、最近の、ハードウェア・ソフトウェアに関連するエコシステムの変化は、マーケットの要求に追従するためにそういう方向に向かっていることは間違いないと思っています。だた、コミュニティーとしては、そこまでのメンタリティーを持って追従している人は少数で、多くの人がまだまだこれからという印象があります。

水島：私にもそう見えます。

かとじゅん：サーバサイドをやってるJavaエンジニアからすると、JavaScriptはできるだけ避けるという考え方もあると思いますが、少し触ってみると新しい発見があるかもしれませんし、それによってScalaに対しても意外に悪くないなという印象はもってもらえるかもしれません。少し語弊がありますが「JavaScriptに型がついた言語でしょ？」という感じで、すんなりScalaを使えるようになったJavaScriptエンジニアを何人も知っています。 あ、誤解しないで欲しいのですが、Javaは素晴らしい言語だし、Scalaを学ぶのにJavaScriptを学ぶことが必須と言っているわけではなく、他のパラダイムにも触れることに意味があるって話です(笑）

僕がそうだったのですが、一つの言語で長く育ったエンジニアは、その言語によって価値観が固定化されやすい傾向にあると思っています。これは無理もないことですが、その前提で他の言語を見た時に違和感を覚えたりしますが、少しでも他の言語にも触れていくと、自分が普段使っている言語を違った視点で見ることもできます。エンジニアとして視野が広いということは、そのような多様な価値観を把握し、どういう使い方をすれば、役に立つか提案できることではないかと思っています。

水島：Springでも、Functional Web FrameworkというJava8のラムダに基づいたアノテーションベースでないものが出ていているので、そういう風がJavaにも来てるのかなと思います。

かとじゅん：Spring ReactorはFunctionalな感じがしますね。

水島：この辺りを見ると従来のSpringと世界観が違いますね。

かとじゅん：関数型プログラミングやリアクティブシステムなどの考え方がオブジェクト指向言語のなかでも問題解決の1つの手法として認知されてきたのかなと思います。

リアクティブシステムなどの文脈と絡めてScalaの知見がもっと広まると良い流れができそうです

－－ リアクティブシステムをSIで適用しようとした場合に、今まではSpringベースでやっていたものをリアクティブシステムに変えるとなると壮大なプロジェクトになりそうですよね。逆に、規模が小さすぎるとメリットを活かしきれなさそうでもありますし、どういう風に導入していければ良いのかなと悩みがあります。それと、どうやって引き継いでいくといいのかという懸念があり、そんな中でも実践を重ねていきたい気持ちもあります。

かとじゅん：教育というところは確かに難しいですね。でも、メッセージパッシングやSupervisorだってErlang/OTPの歴史を紐解けば別段新しくはないですし、リアクティブシステムを構成する一つ一つの考え方(メッセージ駆動、耐障害性、弾力性、即応性)は昔からあったものですよね。ただ、コンセプトとして名前をつけて体系化して共通理解を得やすくなったのは割と最近になってからという気がします。エコシステムとして理解して実用できるまでが難しいって感じかもしれません。

－－ ひと言で言って分かりやすくマニフェスト風にまとめたリアクティブ宣言もそういう助けになっていますよね。

かとじゅん：Many Core時代と言われて久しいですが「サーバを跨いでコアを使い切りたい」「サーバのダウンタイムを限りなく0にしたい」「レスポンスタイムを限りなく短くしたい」「終わりのない大量データを効率的に処理したい」など、文脈に合わせて新しい価値観として作り上げたところに大きな意味があります。リアクティブ宣言のコンセプトに賛同している企業も多く、今後も少なからずITを通じていろいろな業界に影響を与えていくのではないかと思っています。そして、その道を最初に作ったJonas Bonerさんはすごいなって思います。

－－ SIにもそういった流れが訪れて欲しいものです。

かとじゅん：SIの場合だと、リアクティブシステムを採用して事業的にも良いフィードバックを出せるのかもしれませんが、事業が成功するための変数は他にもあるので導入は簡単ではないですよね。ともすれば手段が目的化してしまうので。リアクティブシステムは考え方がガラッと変わるので、設計、運用面、人材確保など諸々難しい問題はありますね。先ほどおっしゃったように小さすぎる案件だとすぐ終わってしまうので、費用対効果が合わないという問題もありますね。まぁエンジニア個人としては素振りしておきたいというのはありますが、ビジネスとなるとKPIにインパクトを与えられないと難しいですね。

－－ ビジネスのことや運用上のことも考えて価値を出していくというのが大事なので、そういうような知見があるかどうかの差が大きいのかなと思います。

かとじゅん：そういう意味だと、Web業界で大規模なサービスをやってるドワンゴさんやLINEさんといったところが、AkkaやErlangの実用経験を通して溜まった知見をコミュニティーの中でフィードバックしていければ、助けが得られて良い形で広がっていくのかなと思います。個人的にはTISさんに頑張ってもらいたいなという思いもあります。

水島：TISさんは実際にLightbendとパートナーシップを持ったり色々試行錯誤もされていますね。

かとじゅん：前出さんは最近akka.ioの日本語訳サイトを立ち上げたので、そこにも段々と人が集まってきて、Akkaを使う人が増えていくのではないかと思っています。

－－ 前出さんが以前言われていたのは、TISさんだけでなく他の企業さんにも頑張ってもらうと、Scalaの導入障壁を下げることにも繋がると仰られていました。

かとじゅん：最近は、僕も利用者の裾野を広げるためにScalaと組み合わせてドメイン駆動設計(以下 DDD)やリアクティブの話をしているのですが、理解を深めてもらうための活動としてこれからもやっていきたいと思っています。

コンピュータリソースをフル活用するためのプログラミングモデルとは

－－ 実際にそういう知見を共有していただける機会などは予定されているんでしょうか。

かとじゅん：仕事ではAkkaを使い込んでいるので、今まさに溜まっている知見をScala Matsuriの時期には共有できる見込みです。実際に、ビジネスロジックでもAkka Streamsで書いているので、プログラミングモデルが今までとは全く変わってしまうことを目の当たりにしています。これは個人的な興味の範囲ですが、PersistentActor(永続化可能なアクター)とActorの位置透過性を利用して、ドメインモデルや集約をどのノードに配置されていてもActorを利用できるようにすることで、スケールアップもスケールアウトも同じプログラミングモデルで実現できるようなシステムを作ってみたいと考えています。

－－ 6年ほど前に、「マルチコアをフル活用するためのプログラミングができる人でなければこの先生き残っていけないし、リソースをフル活用できないと未来はない。」といった話を丸山先生が言っていたのを聞いて衝撃を受けました。最近になってクラウドが台頭してきて、今まさに直面しているという状況ですよね。

かとじゅん：CPUリソースの面でいうと、マルチコア化以降では、単体のコアのクロック数が変わらないか、下がっていく傾向にあるので、それを意識しないプログラミングをしてしまうとスループットが下がるという問題に直結します。単一サーバでマルチコアをいかに使い切るかという話も当然ありますが、さらにサーバを跨いでコアをいくつ使えるかという視点に移っていると思います。CPUリソースの規模の指標が、今まではサーバ台数でしたが、今ではサーバを跨いだコア数に変わってきています。

水島：たとえばIntelのCore i7の性能を見ても、実は最新モデルの1コアあたりの処理性能はあまり伸びていないですよね。8コア16スレッドなど、コアが増える傾向にあるように見えます。

－－ AWSのインスタンスでも1TBのメモリを活用できるようになったので、メモリもCPUコアも増やせるようになりましたね。性能の良いインスタンスでスケールアップできて、性能がそこそこのインスタンスもスケールアウトが出来るので、コアやリソースを使い切るというところがコストに響いてきてお客さんに提供出来る価値にも影響してくるのかなと思います。

かとじゅん：そうですね。スケール戦略を実現する実装手段はいろいろありますが、その1つであるアクターモデルで考えるならば、今までメソッドベースでやってた人達が、アクターが持つ、Fire-and-Forgetのカルチャーに馴染むことができるか否かがポイントになります。

水島：語弊があるかもしれませんが、Javaの視点のまま学んでしまうと途中でつまづくところがあるかもしれないです。

かとじゅん：必ずしもそうではないですが、つまずく傾向にはあるかと思います。

そういう意味では、非同期に処理すると一口にいっても、Promise(Future)、Actor、Reactive Streamsなどの複数の選択肢がありますね。それぞれの目的と向き不向きを実際に試しながら理解することが必要だと思います。

－－ 常にいろんなものを触ってみたり新しいことを身につけていくということが大切ということでしょうか。

かとじゅん：新しいものでも古いものでも、そういうスタンスに違いはないと思います。複数の選択肢があると目的に合わせて選ぶのが難しい側面がありますが、解決方法は解く問題に合わせて選ぶことが大切ですね。エンジニアの基本的なスタンスとして必要じゃないかと。まぁ、これはScalaに限った話ではなく、どの言語でも共通であって、そこで思考停止しない方がよいという意味になると思います。

ChatWork社では常に新しいことをやらせてもらっていて最近はAkkaと戯れる日々です

水島：現在の話になりますが、ChatWork社での、かとじゅんさんはどんな感じで日々過ごされているのでしょうか。

かとじゅん：まだ、あまり具体的なことは話せないのですが、ChatWork社での役割は次のプロダクトの開発で、現行の開発には関わっていないです。言うまでもなくScalaは使っていますが、そこそこ大きいサービスになってきたこともあって問題解決の手法も変わってきました。なので、メッセージ基盤として、ストレージはHBaseを使いながら、アプリケーションはAkkaのActorベースでやっています。前職ではFinagleを利用していたのですが、他と違ってAkkaの良いところはErlang/OTP由来のSupervisionがあるところです。Actorヒエラルキーの下位層のActorが障害を起こしても、上の監督者としてのActor(Supervisor)がそれらを管理することでリカバリもしやすくなる利点があります。耐障害性という面では魅力的な機構だと思っています。

－－ レジリエンスのような話でしょうか。

かとじゅん： レジリエンスは回復力とか治癒力などという意味ですね。先ほども簡単に説明したように、下位層のActorで起きた障害はSuprvisorに通知され、必要に応じて再起動・停止・さらに親のSupervisorにエスカレートすることができます。例えば、子アクターでネットワークやディスクなどのIO例外が発生した場合は、起きた例外をSupervisorに通知し、Supervisorが子アクターに再起動を命じます。そうすると子アクターは破棄され、再び起動(リトライ)できるようになります。これは、障害が起きた部分を正常な部分から隔離するという可用性に優れた考え方で、let-it-crashとも呼ばれています。

無論、要件に応じて、無限にリトライしないようにもできますし、BackoffSupervisorを利用することで指数関数的にリトライまでの待ち時間を調整し、タイトなリトライループを回避して、過度な負荷がDBやネットワークなどにかからないようにすることもできます。

蛇足ですが、この際、アクターのインスタンスは入れ替わりますが、その参照であるActorRefは同じ値を示します。これはなかなかすごいことですが、プログラミング言語の標準機能で同様の実装をするのは骨が折れますが、Actor Systemの恩恵にあずかることで僕らエンジニアは本題に集中できるようになります。

今は実戦でやりきるだけのノウハウを溜めているところで、自らフィードバックできれば良いかなと思っています。話が少しそれましたが、僕の役割は次の事業の基盤になるような開発をすることです。

－－ 普段は開発もこなしつつまとめ役のようなポジションでお仕事されているのですか。

かとじゅん：マネージャーやリーダーなど、チームをまとめる立場の人は別にいます。基本的にはチームで作業していて、その中でも僕は毎日Akkaと戯れているという感じです（笑）日々、Actorヒエラルキーをどう設計するかといったような会話をチームメンバーとしています。

ここから話が少し変わってしまいますが、個人的にもAkka Streamsが好きなので、個人活動としてRedisクライアントを題材に「車輪の再発明」をしてます。

Akka Streamsを知らない人に簡単にまず前提をお話すると、Akka Streamsではストリームの上流でデータを提供するSourceと、下流でデータを消費するSinkというAPIが提供されています。例えば、Sourceは、Source#singleで単一の値を取ったり、Source#applyでコレクションを取ったり、Source#fromFutureでFutureのインスタンスを取ったりできます。また、SinkはSink#foreachであったり、Sink#reduceなどがあります。これらを結合すると、ストリームとしての実行可能なRunnableGraphというオブジェクトが手に入ります。そして、RunnableGraph#runメソッドを実行するとストリームを実行できますが、SourceやSinkが実行中に内部で持つマテリアライズド・バリュー(以下 MVと略す)という値を取得することができます。

あまり内部がどのような仕組みで動いているか細かく説明しませんが、たとえば、数列を合計するようなストリーム処理は以下のようになります。

implicit val system = ActorSystem("myActorSystem")
implicit val actorMaterializer = ActorMaterializer()
// コレクションとして値を持つSource。MVはNotUsed。つまり使わない。
val source: Source[Int, NotUsed] = Source(1 to 10)
// ストリームデータをReduceするSink。MVはFuture[Int]
val sink: Sink[Int, Future[Int]] = Sink.reduce[Int](_ + _)
// 実行可能なグラフを生成。Keep.rightはストリームの右側にあるSinkが実行時に持つMVを取得することを意味する。
// Keep.leftはSourceのMVだがNotUsedなので取得しても意味がない。
val runnableGraph: RunnableGraph[Future[Int]] = source.toMat(sink)(Keep.right)
// 実行可能なグラフを実行すると指定したMVのインスタンスが取得できる。
val future: Future[Int] = runnableGraph.run()
// MVからSinkが得た計算結果を得る。
val value = Await.result(future, Duration.Inf)
println(value)

また、以下のようにActorをSourceとして利用するストリームも作れます。少し難しく見えますが、実行すると前述と同じ計算結果になります。ストリームのデータサイズが固定できない場合や、アクターをインターフェイスにしたい場合などに役に立ちます。

// グラフを構築・実行し、Source.actorRefのMVであるActorRefとSinkのMVであるFutureを取得する。
val (actorRef, future) = Source.actorRef[Int](Int.MaxValue, OverflowStrategy.fail)
  .toMat(Sink.reduce[Int](_ + _))(Keep.both).run()
// SourceとしてのActorRefを使ってストリームにデータを流す
for {n <- 1 to 10} {
  actorRef ! n
}
// ストリームの完了を通知する。
actorRef ! Status.Success(1)
// SinkのMVから結果を取得する。
val value = Await.result(future, Duration.Inf)
println(value)

さらに、ちょっとコードが長いですが、以下のように、このグラフをアクター内部で構築・実行することも可能です(サンプルコードなので、Supervisionは考慮していません)。 Akka StreamのTcpにはoutgoingConnectionというFlowを返すAPIがあって、これを使うと非同期・ノンブロッキングI/Oができるので、これを使ってRedisクライアントを作って遊んでいます。

ちなみに、Flowは、Source, Sinkに並ぶコンポーネントで、上流から受け取った値に何かを行って下流に流すことができます。また、FlowをSourceに結合するとSourceに、Sinkに結合するとSinkになる特徴を持っています。なので、Source -> Flow -> Sinkのようなグラフを作ることができます。以下の例では、リクエストとしてByteStringを流すとレスポンスとしてByteStringが返ってくる Source -> Flow -> Sink なグラフを作っています。

class ClientActor(remoteAddress: InetSocketAddress) extends Actor {
  // requestIdとsenderを紐づける
  private def putSender(requestId: Long, sender: ActorRef): Unit = ???
  // requestIdからsenderを取得する
  private def getSender(requestId: Long): ActorRef = ???
  // Source#actorRef
  private val sourceActorRef: Source[(Long, ByteString), ActorRef] =
    Source.actorRef[(Long, ByteString)](Int.MaxValue, OverflowStrategy.fail)
  // RedisにTCPで接続するフロー
  private val tcpFlow: Flow[ByteString, ByteString, Future[OutgoingConnection]] =
    Tcp().outgoingConnection(remoteAddress)
  // Sink#foreach
  private val sinkForeach: Sink[(ByteString, Long), Future[Done]] =
    Sink.foreach[(ByteString, Long)](responseWithRequestId => self ! responseWithRequestId)
  // 内部でtcpFlowを使うが、(requestId, request) -> (response, requestId)にするFlow
  private val connectionFlow: Flow[(Long, ByteString), (ByteString, Long), NotUsed] =
    Flow.fromGraph(GraphDSL.create() { implicit b =>
      import GraphDSL.Implicits._
      val requestFlow = b.add(Flow[(Long, ByteString)].map {
        case (requestId, request) => (request.concat(ByteString("\r\n")), requestId)
      })
      val unzip = b.add(Unzip[ByteString, Long]())
      val zip = b.add(Zip[ByteString, Long]())
      requestFlow.out ~> unzip.in
      unzip.out0 ~> tcpFlow ~> zip.in0 // request -> response
      unzip.out1 ~> zip.in1 // requestId をそのまま引き継ぐ
      FlowShape(requestFlow.in, zip.out)
    })
  // ストリームの構築・実行
  private val internalClientRef: ActorRef = sourceActorRef
    .via(connectionFlow)
    .toMat(sinkForeach)(Keep.left)
    .run()

  override def receive: Receive = {
    case (requestId: Long, request: String) =>
      putSender(requestId, sender())
      internalClientRef ! (requestId, ByteString.fromString(request))
    case (response: ByteString, requestId: Long) =>
      getSender(requestId) ! (requestId, response.toString())
  }
}

－－ その素振りは面白いですね。

これは、Akka Streamsの勉強をするために作っているので、実用では既に存在するOSSなどを使えば良いと思います。それなりに使い込まないと自分で理解できないので、大事かなと思ってひたすらAkka StreamsとActorを使いこんでいます。あとは、最近あまり参加できていないのですが、、、Akka in Actionの読書会を開いてもらったり、Reactive Messaging Patterns with the Actor Modelsの読書会に参加したりしています。Akka StreamsのActorMaterializer(RunnableGraphをActor上で実行可能にするオブジェクト)の詳細な説明や、コードを読むときの糸口になるようなヒントが書いてあるので、見ておくとコードも書きやすくなるかなと思います。

というか、ほとんど仕事の話をしていませんね(笑)。詳しくはまた時期をみてということで。ChatWork社では常に新しいことをやっています、って感じです。

－－ ズバリ、楽しいですか。

かとじゅん：これで楽しくないと言ったら怒られてしまいますね（笑）実際楽しくやらせてもらっています。Scala化するという宣言をしてから暫くリリース物が出ていませんが、結果を出すまでは絶対にやらないといけないので最後までやり通したいなと思います。

---

後編へ続く（こちら）

出席者

• インタビューイー ChatWork株式会社 かとじゅんさん
• インタビューワー アットウェア 浅野・三嶋、 株式会社ドワンゴ／一般社団法人Japan Scala Association 水島さん

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

• VOL.7 株式会社ドワンゴ／一般社団法人Japan Scala Association水島さん
• VOL.6 株式会社BONX／一般社団法人Japan Scala Association麻植さん
• VOL.5 ChatWork大村さん
• VOL.4 TIS前出さん
• VOL.3 ビズリーチ竹添さん 〜後編〜
• VOL.3 ビズリーチ竹添さん 〜前編〜
• VOL.2 エムスリー瀬良さん
• VOL.1 ヌーラボ吉澤さん

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先駆者インタビュー

• VOL.6 株式会社BONX／一般社団法人Japan Scala Association麻植さん
• VOL.5 ChatWork大村さん
• VOL.4 TIS前出さん
• VOL.3 ビズリーチ竹添さん 〜後編〜
• VOL.3 ビズリーチ竹添さん 〜前編〜
• VOL.2 エムスリー瀬良さん
• VOL.1 ヌーラボ吉澤さん

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以外でいえばもっとコミュニティ活動を長くしている方もたくさんいらっしゃるので、そういった方の話もぜひ聞いてみたいですね。

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

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

麻植：まずは、ありますか？（笑）

大村：（笑顔で）あります。

麻植：よかったです。（笑）

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

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

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

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

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

－－ 話は少し変わって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先駆者インタビュー

• VOL.5 ChatWork大村さん
• VOL.4 TIS前出さん
• VOL.3 ビズリーチ竹添さん 〜後編〜
• VOL.3 ビズリーチ竹添さん 〜前編〜
• VOL.2 エムスリー瀬良さん
• VOL.1 ヌーラボ吉澤さん

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 ScalaとScala Bayが存在し、毎月開催で100人程度が集まります。サンフランシスコで開催されるSF ScalaはAlexy Khrabrovさんがオーガナイザーで、ScalaMatsuri 2016でも来日されコミュニティについて発表されていました。Scala BayではVlad Patryshevさんがオーガナイザーで型システム、圏論に関連するScalaの話題が多い印象です。

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

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

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

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

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

大村：技術的なマッチングもあったのですが、創業者である社長の魅力に惹かれた部分も大きいです。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前出さん

最初に

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

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

前出：苦しい話ばかりかもしれませんねー（笑）

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

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

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

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

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

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

前出：最初の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エンジニアを教育していくぞー」という事が言えれば響くのかもしれませんが、生産性が多少変わるくらいだと難しいですね。

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

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

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

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

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

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

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

「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年くらい先にはきそうでしょうか。

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

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

前出：はい、わかりました。（微笑）

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

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

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

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

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

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

竹添：あまのじゃく的ですね（笑）

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

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

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

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

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

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

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

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

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

前出：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をやり始めるきっかけに貢献していければ...

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

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

---

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をやろうとした時にハードルの高さを感じてしまいそうなポイントはありますか？

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

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

比較的理解しやすいScalatraやSkinny 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のような便利なアプリケーションフレームになっているので、用途に応じて選択して使えば素晴らしいアプリケーションを作ることができるはずです。

瀬良：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のアドバンテージはどういうところか？」を深く考えた先に

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

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

---

浅野：今日は前回の瀬良さんからのご紹介で、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のWebフレームワークであるSkinny Frameworkの創始者の瀬良さんにインタビューしたいと思います。実はアットウェアの社内ナレッジシステムにはSkinny Frameworkが使われているのですが、その話はもう少し後にして、まずは、Scalaを使い出したきっかけを教えて下さい。

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

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

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

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

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

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

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

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

吉澤：そうですねｗ。 瀬良さんが書いている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部分、そしてバリデーションの３つをまとめたものが形になりそうだなというところでつくることにしました。

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

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

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

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

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

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

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

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

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

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

Scala先駆者インタビュー Vol.1 ヌーラボ吉澤さん

「じゃあ今年、発表してみない？」その言葉でScalaの道が開けた！

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

北野：こんにちは、アットウェアの北野です。Scala先駆者インタビュー第一回目は、ヌーラボの吉澤さんとトークしてみたいと思います。ヌーラボさんは、BacklogやCacooという開発者にとっては馴染みのサービス・ツールを開発している会社です。吉澤さんは、ヌーラボの中でもTypetalkというチャットサービスのリーダをしていて、そのプロダクトはScalaで開発されています。早速ですが、吉澤さんはどのようにScalaと出会ったんですか？

ヌーラボ吉澤さん。非常に気さくで人と話すことが大好きな方。

吉澤：Scalaとの出会いはそんなに昔ではありません。就職した頃は、最初はJava言語を扱うSIerに所属していて、その後の転職ではC#へ転向し、それまでは仕事では全くScalaに触れることはありませんでした。2009年か10年ぐらいの時に、Javaが1.5,16あたりで停滞していた時があったと思うのですが、その頃Scalaという存在を初めて知って、Option やコレクション周りで Java にはない機能を目の当たりにしてちょっと触ってみようとしたのが出会いです。

北野：それで、すぐにTypetalkを開発しようとしたのですか？

吉澤：いえいえ。まだまだ、そんなレベルまでは。仕事で使おうというより、初めてのきっかけは、協業している会社さんと合同で行っている勉強会で「吉澤くん、次、何か発表してみようか？」と無茶ぶり的に誘われたことです（笑）。そのお誘いに乗っかり、Scalaという言語がありますよ、的な内容でその勉強会で発表をしました。当時はまだWebのフレームワークとかも今とは違ってPlayは無く、Liftぐらいしかなくて、ちょっと正直、適応するには早いと思っていました。ただ、当時、世間的にはBDDのライブラリとかも流行り始めていて、そういう点でテストとかだったらいいから使ってみたらいいと思って、その発表をしたと思います。

北野：実際に少しずつ使ってみてどうでしたか？

吉澤：その後ぐらいに、ちょっとずつ使いだして、ちょうどTypetalkを作ろうと思って、それに適応してみようと思って。最初は、自分が作っているものが会社のプロダクトして正式に採用される確約は無く、正直自分の空き時間や趣味の時間なども使いながら作っていました。2012年ぐらいですかね？その時に選んだものは、自分がやってて好きなモノを選ぼう。それが楽しいって思って選んでいました。（笑）

北野：それでScala・Playを？

吉澤：そうですね。その時にJavaだったら、Seaser2とかSpringとか、Rubyなどを選択するというのもあったと思いますが、Seaser2はメンテナンスモードに入って進化が見えなくなっていた所だったし、ちょっといろいろチャレンジしてみたいなぁと思っていた頃でした。その頃、Play1を少し触っていて、面白いフレームワークだったのでやり始めたらちょうどそのタイミングでPlayが2.0のRC版を出しますってアナウンスがあり、この波に乗っかるしかないなって。（笑）全部Scalaで書かれているし。これはもう楽しい！そう思いました。 実際Play2.0に触ってみるとマイグレーションの機能だったり、Seasarでは出来ていたホットリローディングとかのそういう機能とかもあったので、勢いでTypetalkのプロトタイプを作りました。

北野：TypetalkをScalaで作り始めたって話だったんですけど、じゃあ実際作っていく中でScala的に苦労した点とかっていうのはありますか。

吉澤：ちょうどその開発を始めた頃、シンガポール支社の立ち上げで現地勤務になって、本当は勉強会とか日本のいろいろな勉強会へ参加して、色々聞きたかったんですけど、結局、シンガポールとかではそんなに盛んではなくて。手探り状態で、ネットを見ながら書いたところですね。

北野：大変でしたね。それを乗り越えて、素晴らしいプロダクトとしてTypetalkが出来たということをお聞きすると、なんだかいままで以上に愛着が湧いてきます！ところで、Scalaを使い始めた時に参考にした情報はなんでしょうか？

吉澤：そうですね、シンガポールに行くときに、日本からScala 逆引きレシピとかコップ本（Scalaスケーラブルプログラミング）を持って行きました。それ以外にもインターネットは役に立ちましたね。いろいろなリソースはありますから。でも、その中でもその本は、見よう見まねで書いていたあの頃には本当に役に立ちました。

北野：今はTypetalkは複数人で開発をしていると思うんですが、人を増やしていった時の話とか、苦労話や、Scalaイイね話があれば。

吉澤：そうですね。Typetalkが私の個人ワークから、会社のプロダクトへと成長した時に、1人女性の方に入ってもらいました。先ほど紹介した本を参考にしながらScalaに触れてもらったり、簡単な部分からTypetalkの開発を始めてもらったり、レビューをもちろんしながら徐々に進めていって、そしたら自然とScalaメンバが増えていきましたね。彼女に後で聞いてみたんですが、「もうJavaには戻りたくない」っていうぐらいの感じです。どこら辺がいいかっていうところを聞いたら、「やっぱり簡潔に書ける所」っていう。やっぱりJavaだとどうしても冗長になってしまうような所があるようですね。まだまだ私たちもScalaの真髄について学習中なところです。本当の意味で関数型を上手く活用できているか？というとまだだと思っています。

北野：Scalaでここはどうにかして欲しいとか未来への期待があればどこでしょうか？

吉澤：んー、唯一どうにかして欲しいと言えることは、コンパイル速度ですかね！（笑）これはScalaが進化していくに対しての大きな期待です。実際に開発者の方もDottyという新しいコンパイラを作っているとのことですし。

北野：いろいろ、お聞かせ頂いてありがとうございました！それでは、次の方を紹介してもらえますか？ 吉澤：えっ、いいとも形式ですか？ 北野：いい例えですね。吉澤さんも次の回に来ていただきたいので、ごきげんよう形式にしたいと思います。

吉澤：いいですね！いきます！では、瀬良さんという方はいかがでしょうか？Skinny FrameworkというScalaで書かれているWebアプリフレームワークを開発している方です。非常に活発にオープンソースに貢献されている方で、Scalaの普及にも多く力を注いでいます。

北野：先日のスマートニュースさんで行われた講演を聞かせていただきました。ついでにいうと、弊社、アットウェアの社内で開発しているナレッジシステムSiita（QiitaクローンでScalaで書かれているので、Siitaという）のベースがSkinny Frameworkです。すごく楽しみにしています。ありがとうございます。