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

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は既に実績のある言語として認知されているので転職に対しても抵抗が少なくなったのかなと思います。

29607781604_8aed527142_k_2.jpg

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

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

かとじゅん:先ほども話した通り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先駆者インタビュー

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

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さんといったところが、AkkaErlangの実用経験を通して溜まった知見をコミュニティーの中でフィードバックしていければ、助けが得られて良い形で広がっていくのかなと思います。個人的には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先駆者インタビュー

第13期を迎え

第13期を迎え

本日2016年12月1日、株式会社アットウェアは第13期を迎えました。

毎年のことながら、一年の節目の日を多くのお客様に支えられ迎えられたことを社員皆と共に喜びたいと思います。 オギャーと産まれた子どもが中学校を卒業する歳になったということです。 とにかく、おもしろい仕事をしたいと起業してからの12年、本当に様々なことがありました。リーマンショック、東日本大震災は言うにおよばず、会社の大きな転換期を迎えるような大きな仕事をさせていただいたこともありましたし、プライベートでは人生の大きな、本当に大きな出来事もありました。ずいぶん歳を取って、過去のことがなかなか思い出せず、大変だったような気もしますが、楽しくおもしろい仕事を積み重ねた12年間であったように思います。

社員の数も増え、様々なチャレンジができる規模にもなりました。12年前、想像すらしていなかった環境や仕事をさせてもらっていることに素直に感謝したいと思います。

あらためて、今の私がどんな会社を作りたいと思っているか、どんな価値観でいるかを私自身の言葉で表し、13年目の節目の時に社員の皆さんにお話ししました。 ホームページに載せたらどうかといううれしいコメントも貰ったので、自分自身が常に意識していられるようにこちらに掲載することにしました。

決して順中満帆な第13期の船出ではありませんが、いまいちどアットウェアと私自身の夢の実現のため、悔いのない一年を送りたいと思います。 引き続き多くの皆さんのご支援を賜れますよう、お願い申し上げます。

インターンシップ体験記・2016(千葉大学 中平さん)

インターンシップ体験記・2016(千葉大学 中平さん)

千葉大学3年の中平です。この度8/22〜9/2の2週間、インターンシップに参加させていただきましたのでその内容について簡単にまとめさせていただきます。

はじめに

私は転職サイトWantedlyでアットウェアのインターン募集を見つけて応募しました。インターンに参加しようと思った理由には以下のようなものがありました。

  • 今後の進路選択に向け、IT業界についてもっと理解を深めたかった
  • Webに興味があり、Webアプリ開発をやってみたかった
  • チームで開発をしてみたかった

今回、学校を通じての応募ではなかったことや、インターン直前の応募になってしまったことから参加できるかとても不安でしたが、社長の牧野さんが丁寧に対応してくださいました。結果的に、上記のインターンでやりたかった3つのことは、実際にインターンでやったことに変わり、充実した時間を過ごすことができました。

インターン内容

概要

集まったインターン生でWebサービスを1つ開発しました。今回は私と同じく2週間のインターンに参加する仲間が4人と、それよりも1週間早く開始していた仲間が4人おり、計8人で一つのサービスを開発しました。

私がインターンに参加した時点で既にサービスの企画と設計のフェーズが終了していたため、主に開発に携わらせていただきました。

プログラミング

開発の内、私はサーバーサイドを担当させて頂きました。Web開発は初めてであったため、MVCモデルが一体どんなものなのかを知るところから始め、主にビジネスロジックの部分を実装しました。開発ではJavaのSpringMVCと呼ばれるフレームワークを用いました。また、Java言語についてもあまり経験がなかったので、オブジェクト指向を用いたプログラミングの実践の機会にもなりました。

最初の1、2日は参考書や仲間のコードを読んでもあまり理解が進まず、悶々していましたが、一週間が終わる頃にはわかる部分とわからない部分が明確になり、仲間とうまく作業分担しながら作業を進めることができました。開発のほとんどは学習と同時並行でしたが、インターンに参加したメンバーもWeb開発が初めてという方が多かったので、アットウェアの社員の方々のフォローを頂きながらスムーズに開発を進めることができました。

最終的にはWebサービスを一つ完成させることができ、大きな達成感と自信を得ることができました。インターンに参加する前はHTML, CSS, JavaScriptのフロントエンド技術しかわかりませんでしたが、サーバーサイドの技術を学ぶことができたことが私にとって特に大きなポイントでした。

チーム開発

インターンではプログラミングだけでなく、チーム開発についても様々なことを学ぶことができました。その内の一つはカンバンと呼ばれる手法で、主に"タスクの見える化"を行うものです。ミーティングで事前に洗い出したタスクの中から、毎日今日やるタスクを選び、各人がDoing(今やっているタスク)欄にタスクを移してから作業を始めます。タスクが終了した時には見積もり時間に対して実際にかかった時間を記入してDone(消化したタスク)欄へと移していきます。

カンバンを用いながら開発することで、特に以下の様な点に気づきました。

  • あとどれくらいやることがあるのかという全体的な視点を意識しながら作業できる
  • プロジェクト自体の進捗が管理がしやすくなる
  • 長い間同じタスクに留まっている仲間を発見できる

このような手法は一人でプログラミングをする上では経験できないため、実際にそれを使ってチーム開発をすることができ、良い経験になりました。

それ以外にも2週間のチーム開発を通して、わからないことがあった場合に一人で悩みこまずに気軽に仲間と共有できる環境の素晴らしさを実感しました。また仲間のコードを読んだり、仲間と考え方を共有しあう中で、設計や実装がブラッシュアップされる体験も非常に楽しいものでした。インターンでは普段の学校生活ではあまり経験することのないチーム開発に触れる事ができます。紹介したカンバンやgitなどの開発手法・ツールに触れることも貴重な体験ではありますが、初めて会った仲間とどれだけ蜜にコミュニケーションを取れるかも重要な要素です。もしコミュニケーションに不安のある方でもアットウェアのインターンに参加することで自信をつけるきっかけになると思います。

インターンで使った言語・フレームワーク・開発環境

今回のインターンで学んだ技術的なものについて、具体的に名前を列挙してみました。言語やフレームワーク、ツールなどが入り混じっていますが、少しでも今後参加する方の参考になればと思います。

技術要素
全員Java, Tomcat, Git(Source Tree), Eclipse
クライアントサイドHTML, CSS, JavaScript
サーバーサイドJSP, SpringMVC, Hibernate, MySQL

さいごに

私は最初インターンに参加するにあたり、Javaでのプログラミング経験が少ないことや、Webサービスの開発経験がないといったことが大きな不安要素でした。しかし、今終わって振り返ってみると、わからないことはアットウェアの社員の方々が丁寧に教えてくださったり、一緒に参加していたメンバー同士で教え合うことができる環境で、とにかく"楽しみながら"開発をすることができました。

また、アットウェアのインターンでは社内で歓迎会や打ち上げを開いていただいただけでなく、皆でご飯を一緒に食べに行ったり、横浜スタジアムに野球観戦しにいったり、卓球をしたり、開発以外にも楽しい経験が盛り沢山でした。もしこの記事を読んでいるあなたが、技術的なハンデに関する不安で参加を迷っているのであれば、そんな心配は全く不要です!是非インターンに参加して欲しいと思います。また、アットウェアでは大学の単位認定についても対応して下さいますので、もし今後個人で応募する方がいましたら参考にしてください。

この度は本当にありがとうございました。

インターンシップ体験記・2016(奈良先端科学技術大学院大学 原さん)

インターンシップ体験記・2016(奈良先端科学技術大学院大学 原さん)

はじめに

奈良先端科学技術大学院大学の原です. 8月15日から9月2日までの3週間, アットウェアでのインターンシップに参加しました. そこで私はクラウド並列分散処理基板構築という内容を実施しました. 3週間で実施した内容を簡単に紹介したいと思います. また, 本記事が今後アットウェアへのインターンシップに参加する方のご参考になればと思います.

 

実施内容

本インターンシップで使用した主要技術は4つあります.

  1. Scala
  2. Spark
  3. Zeppelin
  4. Amazon EMR

これらの技術は私にとって経験値の少ないものでしたので, 学ぶことも多く, 非常に楽しく開発できました. そして, わからない所や深く知りたいことは, 社員の方々に聞くことができました.

本インターンシップで実施したことは2つあります. 1つ目は, アクセスログの並列分散処理と解析です. 2つ目は, 野球データの解析です.

アクセスログ

あるアクセスログを解析し, そこから何か有益なデータを見つけるといった内容です. 具体的には, アクセスログをSparkを利用して並列分散処理し, 集計されたデータをZeppelinで可視化するという流れです. このアクセスログは, 実際に運用しているプロジェクトのアクセスログであったので, ユーザが実際に利用している風景を想像しながらアクセスログを解析できました. ここで, 私はScala, Spark, Zeppelin, そしてAmazon EMRを利用し, データの並列分散処理と解析の基礎を身につけました.

野球データ

MLBで利用されているPitch f/xのデータを並列分散処理し, 解析しました. Pitch f/xは野球の投手の投球速度や投球軌道を追跡するスピード測定器システムです. イメージとしては, プロ野球1球速報のようなものです. このデータを元に, 投手はどのような配球で打者から三振を奪うのか調べました. 初めは, 下図のように三振を奪った投手の全ての配球を可視化したのですが, どのような配球で三振を奪ったのかよくわかりませんでした.

そこで, 三振を奪った配球を部分系列パターンとして抽出し, それを可視化しました. 全体的な流れを以下に示します.

  1. Pitch f/xのデータを習得
  2. Sparkで並列分散処理できるように, データセットを作成
  3. そのデータセットを用いて, 部分系列パターンとして抽出
  4. 抽出した部分系列パターンをWEBで可視化

また, 部分系列パターンとして抽出する際, データのフィルタリングしました.

  1. 投手と打者の指標
  2. 右打者, 左打者あるいは右腕, 左腕

これらを考慮することで, 優秀な左腕投手は, 優秀な右打者に対してどのような配球で三振を奪うのか知ることができます. 投手の指標として, 今回はK/BBを採用しました. これは奪三振数と与四球数の比です. 打者の指標として, 今回はOPSを採用しました. これは打者の出塁率と長打率の和です.

成果物

野球データに関する成果物を紹介したいと思います. 完成した成果物を下図に示します. これは右腕投手が右打者から三振を奪った際の部分系列パターン群です. 1つのパネルが抽出した1つの系列パターンの1要素となります.

下図は横から見た図です. パネルが奥行きを持って並んでいることがわかります. この奥行きを持って並んだパネルが1つの部分系列パターンです. また, パネルの1番奥の部分が三振を奪った球種とゾーンです. 例えば3つのパネルが奥行きを持って並んでいる所に注目すると, これは右打者に対する投球の中でアウトローのボールゾーンのスライダーが3球出現したことを示しています. そして, アウトローのボールゾーンスライダーで三振を奪ったことを示しています.

右打者や左打者, 右腕や左腕の組合せで, それぞれの傾向が見られたので, 非常に面白かったです.

 

まとめ

この3週間で私は以下のことを深く学び, 経験できました.

  1. Sparkを用いた並列分散処理
  2. データの可視化(見せ方)の難しさ
  3. エンジニアとしての振る舞い

私にとって経験値の少ないScalaやSparkを用いた開発, そしてデータの並列分散処理から可視化までの一連の流れを経験でき, とても価値のある3週間でした. 特に3については是非アットウェアへ行って自身の耳で聞いてください. 私がここで記事にするよりも有益な情報が得られます. また, 今回私はインターンシップ生同士でチームを組んでいなく1人でしたが, 隣でチームで作業しているインターン生や社員の方々を見て, 普段私がしているチーム開発を俯瞰的に見ることができ, 改めて振り返る機会を得ることができました. そしてインターンシップでの3週間, 私はとても楽しく有意義な空間と時間を過ごすことができました. 最後になりますが, 社員の方々やチームは異なりますが, 共に過ごしたインターンシップ生の方々, 本当にお世話になりました.

内定式を開催しました

今年の内定者の2人 左 - 大埜さん  右 - 松村さん

今年の内定者の2人 左 - 大埜さん  右 - 松村さん

10月4日、内定式を開催しました

来年から2名、アットウェアの仲間が増えることになりました。内定者の大埜さんと、松村さんです。実はアットウェアは今の今まで、内定式らしい内定式というものをやってこなかったという衝撃の事実がありまして。今年こそ社会人になるための通過儀礼としてやっていこうということで開催に至りました。

 

開会の挨拶

なぜか超笑顔の石上さん

なぜか超笑顔の石上さん

ファシリテータの肩書きを持つ石上さんが、内定式の取りまとめをやってくださいました。内定式のファシリテーションは初めてだったせいか、ど緊張してました。いっちょまえに、式次第なんてものを用意してお堅く進めていく予定でしたが、全体的にアットウェアらしい、ゆるめな内定式となりました。

 

 

記念品贈呈

ようこそアットウェアへという想いを込めて記念品を用意しました。用意したのは「名刺」。今回の内定者は2人とも関西出身の方々で、地元を離れるということだったので、親御さんや友人に渡せるように、こういう会社に入ったんだよと報告できるように、という意図で名刺を選びました。肩書きはルーキーです。アットウェアは自分で肩書きを決めるカルチャーがあるので、入社してからオリジナリティある素敵な肩書きを考えて欲しいと思っております。

 

懇親会

記念品を贈呈して、アイスブレイクをして、簡単な業務体験をしたあとは懇親会を行いました。当日に声かけしたにもかかわらず多くの社員さんにご参加いただきました。懇親会では二つの企画を用意しまして、一つは「One Shot, One Ambition」(社員一人一枚のスライドで、最近を表す写真と、野望を表現してもらうというもの)、もう一つはLT(ライトニングトークス)でした。LTは内定者にも事前に用意してきてもらって発表してもらい、大盛り上がりでした(内定者の二人が一番真面目な話をするという謎の展開でしたが....)。企画した私たち自身も楽しめたので、非常に有意義な内定式となりました。

 

来年から一緒に働けることを社員一同楽しみにしております!!
大埜さん、松村さんこれから、よろしくお願いします!

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

ヌーラボ様のサイトにてインタビュー記事が掲載されました。

ヌーラボ様のサイトにてインタビュー記事が掲載されました。

先日、株式会社ヌーラボ様にインタビューしていただいた記事が掲載されました。
アットウェアで社内ツールとして利用している Backlog、Typetalk、Cacoo の活用事例です。

Backlog と Typetalk の API を活用するアットウェア社のユニークな取り組みをご紹介! - ヌーラボ [Nulab Inc.]
https://nulab-inc.com/ja/blog/backlog/how-atware-use-backlog-and-typetalk-api-userinterview/

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

「IT 技術者のための移住・就職セミナー ~あなたの力で函館をITのまちに~」に参加します

「IT 技術者のための移住・就職セミナー ~あなたの力で函館をITのまちに~」に参加します

魅力度ランキング 2 年連続 1 位の函館であなたも働いてみませんか?


7/2(土)に東京で開催される「IT 技術者のための移住・就職セミナー」に参加します。
当日は弊社・代表取締役 牧野が「函館で自己実現を果たす」をテーマにお話させていただく予定です。
函館での U ターン・I ターン就職をお考えの IT 技術者の皆さま、この機会にぜひご参加ください。


「IT技術者のための移住・就職セミナー ~あなたの力で函館をITのまちに~」(主催・北海道函館市)
日時:平成28年7月2日(土) 17時30分~20時30分(受付17時~)
会場:東京交通会館5階 ふるさと回帰支援センター内
   (東京都千代田区有楽町2丁目10-1)
概要:セミナー他、個別相談あり(要・事前予約)


セミナーの詳細はこちら → http://www.city.hakodate.hokkaido.jp/docs/2016051700026/



また、函館に拠点(函館ラボラトリー)を持つアットウェアでは、入社時にお祝い金を支給するなどの就職支援を行っております。
会社説明会や見学会、個別相談会も常時開催しておりますのでお気軽にお問い合わせください。


採用情報やお問い合わせはこちら → http://www.atware.co.jp/careers/#saiyo

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 前出
  • インタビューワー アットウェア 浅野、 ビズリーチ 竹添

ScalaMatsuri 2016をスポンサードしました

ScalaMatsuri 2016をスポンサードしました

先日、東京国際交流館で開催されたScalaをテーマにした日本最大級のカンファレンスScalaMatsuri 2016を侍スポンサーとしてスポンサードさせて頂きました。

ScalaMatsuriのクオリティは素晴らしく、様々な参加者層それぞれが楽しめたのではないでしょうか。

関数型プログラミング・Reactive Streamsなどの話題が多く、セッションのバラエティも富んでいました。参加したセッションによっては過去に聞いた事があった話も含まれていましたが、現状に合わせたブラッシュアップがされていたり、再度理解を深めたり・これから考えていかないといけない事を改めて実感できました。

Reactive Systemsに関しては「どうやってソリューションに適用するパタンを作っていけるか」がポイントとなってきそうです。Reactive Systemsはマイクロサービスを意識する事も必要で、SIerでいう下記のような要素の総合力が求められ、やりがいもあります。(最初からマイクロサービス前提で進める事に対するアンチパタンも存在する現状で、手法が先にならず問題解決領域でアプローチをしていけるパタンを模索するという意味でもやりがいがあります。)

  • チーム熟練度
  • 顧客との開発方針の詰め方
  • 運用ナレッジ

今回のスポンサードをしようとしたきっかけは、Scala先駆者インタビューという企画をやろうと思ったコンセプトに似ていました。大した貢献はできませんでしたが、Scala求人情報を通してSIerとしての取り組みを少しでもお伝えできたので、また一歩踏み出せた感もあり、祭りが終わった後にもやって良かったと感じています。たぶん、弊社だけではなくScalaMatsuriにスポンサーを名乗り出るほど華々しい成果をあげているわけでもないと尻込みしている、SIerさんもいると思います。小さな成果や取り組みでもいいと思うで、事例や取り組みがで目に見える形で公開されていくことで業界に波及していくのではないでしょうか。そういう状況がそう遠くない内にくる事を期待しています!

海外の方を招いて、コンセプト通りの素晴らしい場を提供をしてくださった運営チームの方々ありがとうございました、来年1年間で実践力と失敗も積み重ね、スポンサードという形以外でもScalaコミュニティへの貢献やSIer界隈での波及に寄与していければと考えています。

最後になりましたが、ScalaMatsuriに合わせて弊社のScalaに関する取り組みや状況を書いた求人情報を公開しました。横浜というロケーションで働きたいと関心がある方や、オフィスに見学・遊びに行ってみたいという方は気軽にお声がけください。

Wantedly紹介

2016年 新年を迎え

2016年 新年を迎え

新年あけましておめでとうございます。

昨年は多くの、本当に多くのお客様やパートナーの方々に支えられ、そして何より社員皆の努力により苦しいながらも実り多き一年を過ごすことができました。ありがとうございました。本年も一年、何卒よろしくお願いいたします。我々のビジョン「システムで人々をしあわせにする」を少しずつでもカタチにしていけるよう、より一層の努力をして参りたいと思います。

さて、アットウェアは年末12月24日が創業の日であり、また12月が期首にあたりますから、第12期がスタートしたばかりです。第12期に向けての取り組みなどは年末のatWare Advent Calendar 2015の中で私をはじめ皆が触れてくれていますので、ここでは割愛をします。一ヶ月経過したものの、まだまだそれが成果に繋がる状況にもなく、むしろ十分に形式知化できていなくてやや混乱した状態。それらを皆で考え試行錯誤しつつも歩みを進めている実感が心地よくもあります。

この年末年始の休暇中は、これらの取り組みをいまいちど自分の中で整理をし、これからのことを考える良い時間となりました。頭が良くないので本を読むのも得意ではないのですが、積読だった本を引っ張りだして現状と照らしあわせたり、やろうとしていることを再確認するのに本屋さんで仕入れてきたり。また、昨年末には米国ザッポス社やパタゴニア社を視察させていただく機会を得て、自分の中で悶々としていたものや会社としてあるいは経営者として不足していることを確認することもできました。

私個人としては、今年一年はしっかりと内と未来に目を向け、12歳(人間でいえば小学校を卒業する歳)となるアットウェアが大人へと成長していける骨格を作りなおすことに集中したいと考えています。会社としては新たな事業へのチャレンジを幾つか計画していますし、今まで積み上げてきたことをさらに成熟させていかねばなりませんが、優秀な社員がたくさんいますので、きっと彼ら彼女らが成し遂げてくれるものと思います。皆を信じ、私には私にしかできないこと(それは事業の推進を任せっきりにするのではなく裏方として支援しつつ私にしかできない判断をすることとその先を考えること)に覚悟をもって取り組んでいきます。

「我(々)がやりたいことをやる」だけではなく、「我(々)にしかやれないことをやる」。これが今年のテーマです。

納会 2015

納会 2015

みなさん、こんにちは。年末はいかがお過ごしでしょうか。納会ではカメラ小僧もどきを演じていた新人のまっさんこと、山本です。カメラのセンスがないのかぼくが撮影した写真は全て黄色っぽいです。ショックです。実家が北海道ということもあり、函館ラボの納会にも参加してきました。納会参加レポートで、今年のアットウェアブログを締めたいと思います。

 

At 横浜 YOKOHAMA Office

横浜の納会は、大掃除から始まって、アットウェアアワードの発表、そして、懇親会という流れで行われました。

 

大掃除

エンジニア、バックオフィス、役員が一緒になって、自分たちが働く場所の掃除をしました。私は前日にアットウェアアワードの準備をしたり、徹夜をしたり、寝たりしていたので遅刻してしまいました。私のデスクの前だけ、ほこりがたくさんありました。ほこりを残していただいておいてありがとうございます。

 

アットウェアアワード

アットウェアアワードは、有志で応募したエンジニア達が、社内で抱えている問題をITで解決というものでした。勤怠に関するものや、個人的な悩みに関わるもの、ミーティングルームの空き情報を管理するもの、Backlogと連携させたものなどなど様々な種類のエントリーがありました。

私はテックなポイントが取れないと判断したため、ネタに走りました。とてもよくないと思います。

 

 

懇親会

会社で、料理を食したり、飲み物を飲みながら、今年一年の労をねぎらいました。労をねぎらうという言葉を人生で初めて使いました。

 

表彰式

勤続10年を迎えた方々、ここの目標に対する評価など様々な観点において、表彰式が行われました。ハワイ出身のジェフさんにもしっかり英語で表彰しました。ベトナム出身のナムさんは最近日本語がバリバリできるようになってきたため、日本語で表彰しました。ベトナムからの刺客のナムさんとフイさんは日本語の上達が早すぎます。僕も彼らのように英語を学びたいものです。

 

アワード結果発表

完成度の評価が高かった牧野さんへの表彰

完成度の評価が高かった牧野さんへの表彰

お昼に行われたアットウェアアワード結果発表が行われました。アワードは、プレゼン、技術力、アイディア、完成度といった4つの要素から点数がつけられ、それぞれ点数が一番高かった人、総合的に点数が高かった人が表彰されました。

優勝は、ジョージさん(左下)の姫路城2.0でした。写真がないのが残念すぎます。アワードの結果は追ってブログで紹介したいと思います。しれっと私もプレゼン賞をいただきました。

 

 

 

At 函館 HAKODATE Lab

寒々とした函館駅

寒々とした函館駅

函館の納会は、大掃除から始まって、懇親会という流れで行われました。

私は、出身が北海道ということもあり、実家への通り道ということもあって、函館ラボの納会にも参加しました。お土産を何も持っていかなかったかつ、大掃除にも参加しなかったため、ひどくイジられました。ちなみに函館では、ぼくが帰ったあたりから、雪がバンバン降り始めたようです。さすが前厄エンジニアです。

 

懇親会

卓球台がオフィスに置いてあると今風でかっこいい気がするのですが、函館オフィスの置き方、使い方は何かが間違っているような気がします。私が函館ラボに顔を出した時はいつも、この卓球台にはネットは装着されていません。ですが、ついに懇親会のあと卓球を....しませんでした。やはり彼らはあの台をただのテーブルとしか思っていないようです。全国の卓球ファンに謝ります、ごめんなさい。

 

 


さいごに

vietonameeze.jpg

さて、ざっくりと、アットウェアの2015年の納会を振り返りました。 2015年12月から12期が始まり、アットウェアも新たな体制で年を迎えようとしています。来年はどのようなことが待ち受けているのかワクワクしますね。アットウェアブログをご覧頂きありがとうございました。
それでは、来年もアットウェアブログをよろしくお願いいたします。皆様、よいお年を。

23歳で前厄になるのでお参りしてきた

23歳で前厄になるのでお参りしてきた

僕の名前は山本真平。出身は北海道。公立はこだて未来大学を今年卒業して、晴れて4月からアットウェアで働き始めた。大学のころまで「ヤマ」などと呼ばれていたが、いろいろあって関東では「マッサン」と呼ばれている。そして名乗っている。案外気に入っている。

今日12月24日は弊社、アットウェアの創立記念日であり、アドベントの最後の日である。世の中はアドベントの最後の日、つまりクリスマスイブだというのに、僕らはいつも通り働いている。創立記念日というものは、社員みんなでパーティー的な催しがあるものだと思っていた。今の所、僕のカレンダーにそのような予定はない。

さて、1993年生まれ酉年の僕らは前厄になるのだから、何かしらの厄をどうにかするため、お参りしなければならない。よくよく考えてみれば、「お参り」ではなく、「お祓い」という言葉が適切だろう。どちらにしろ、ベトナム人の同期に、この違いを説明しなければならないと思うと少し億劫である。お墓を蹴っちゃいけないくらいの宗教観しか持っていない僕は、「厄年」というものがそもそもなにか気になって検索した。インターネットとは便利なものである。

厄年というのは、陰陽道で教育、宣伝されているもので、その年齢になると厄災が降りかかるとされています。平安時代には、すでに厄年という概念があり、現在まで長いこと受け継がれてきている風習です。
— yakuyear.com/about/what.html

そういうことか、いや、意味がわからない。なぜその年になると厄災が降りかかりますということが決まっているのか、そもそも厄災とはなんなのか、降りかかるものか、いろいろ突っ込みどころはあるが、「災い」という漢字が入っている以上、良くないことが起きることらしい。ある年に生まれた子供たちが、皆同じタイミングに災いが起きるなどというのは悲しすぎる。悲しい風習だということはわかった。

厄年を民俗学的に見ると、『役年』になります。ある一定の年齢になると、神社やお寺で『役』をするという習慣からです。『役』になると、それなりに身を清め、行いを慎まなければいけませんでした。その役を終えて、はじめて一人前の社会人として、周囲の人から認められたといいます。
次第に、この『役』の年齢に差し掛かる頃には、精神的なものや肉体的なことに変化が起こりやすく、体を壊したり、思いも寄らぬ受難を受けたりするという、人生の節目になっていることが分かってきました。昔の人は、厄年を『役年』とすることで、役についた者に様々な制約をもうけ、『厄』から逃れていたのです。
— yakuyear.com/about/what.html

やっぱり意味がわからない。僕の読解力がなさすぎるのか、ヤクヤク言いすぎているこのサイトのどちらかが悪い。明らかに前者だ。23歳くらいにもなれば、それなりの役を任されて、いろんなことがあるから頑張れ的なニュアンスだと思っておけばいいだろうか。

 

OK Google ここから一番ちかい神社は?

と話しかけてはみたものの期待通りの結果は得られず、普通に検索した。わからないことがあったら検索する。それでもわからなければ誰かに聞けばいい。昼休みに先輩につれられて、真相を確かめに近くの神社へ向かった。

 

 

今年のクリスマスのみなとみらいには、福山雅治がいろんなところにいる。福山雅治にも厄年があったのだろうか、あったはずだ。あったと信じたい。

 

 

平日の昼間だというのに、桜木町とみなとみらいをつなぐ動く歩道には沢山人がいる。さすが観光地だ。

 

 

場所がわからず、遠回りをしてしまった。正直、桜木町駅は通らなくてもよかった。

 

 

現在、弊社で開発を進めているの新プロダクトについて先輩と話しながら神社にたどりついた。

 

 

 

 

 

 

 

たどりついた、が....

 

 

 

 

 

 

 

 

 

 

工事中だった。

 

 

 

 

 

おわりに

アドベントカレンダーをご愛読いただき、ありがとうございます。今日でアドベントカレンダーも終わりです。新人という立場ながら、ブログを書かせていただけたことをとても嬉しく思います。弊社は高い技術力を持ったエンジニア集団です。自分は、まだまだヒヨッコプログラマ故、このような記事しか書けませんが、ゆくゆくは技術的なブログやアウトプットも公開していければと思っています。

今年、新卒として働き始めたあなたも、来年新卒になるあなたも、研究を続けるあなたも、新しいステージ、新しい役で、活躍することを願っています。信仰心が強い、おばあちゃんや上司に怒られないように時間が空いた際は、厄払いをしに神社へ出かけてみてはいかがでしょうか。


アットウェアではエンジニアを募集中!

Scala先駆者インタビューも絶賛公開中!!

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

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

なるほどわかった!?色彩のお話し

なるほどわかった!?色彩のお話し

みなさんこんにちは。不破@エンジニアです。最近はWordPressのお仕事を頂いており、高速WordPressを実現させるべく日々がんばっております。あと最近はスプラトゥーンにはまりつつある感じです。

今日のテーマは「色彩のお話」です。 最近のアプリケーション開発ではプロトタイプを制作するケースが非常に増えてきました。 Bootstrapの登場や普及などもあり、デザイナーやコーダーではないエンジニアもWebアプリケーションやスマートフォンアプリのプロトタイプを開発するようになりました。 その一方で、色彩についてよく考えないスマートフォンアプリやWebサイトが増えているように思えます。

そんな私もデザインや色彩については素人です。色々思うところがあって、色彩検定3級の勉強をしています。 今回は、エンジニアが知っておくべき色彩の知識についてまとめました。

色の三属性

「色の三属性」は学校で習った人も多いと思います。色には

  • 色相
  • 明度
  • 彩度

があります。 色相は「色みの違い」を意味し、「青緑」「紫」「赤紫」など10の色相がJIS規格で決まっています。 色相を順番に配置したものを、「色相環」(下図)といいます。

色相環

Wikipedia 色相

明度は「明るさ」を示し、彩度は「鮮やかさ」を示します。彩度が低くなると灰色に近い色になり、逆に彩度が上がると派手な色になります。

補色

色相間の対面にある色の組み合わせを「補色」といいます。 先ほどの色相環図を見ると、非常におおざっぱな見方をすると「赤」の補色は「緑」になります。

補色は、背景色を決定するのに使用します。たとえば、「赤色文字の背景色」を考えましょう。今回は背景色の上に文字(「あ」)を描いてみます。

「赤」の補色は「緑(緑と青を混ぜた感じ)」です。補色を背景にすると、こうなります。

赤文字と青緑

いい感じに赤色の「あ」が映っています。これなら「あ」という文字をすぐ認識することが出来ます。

今度は補色ではなく、色相環的に隣り合わせの色を組み合わせてみます。するとこうなってしまいます。 青と青緑

お互いの色が似通っているせいでよくわからなくなりました。 このように、補色になっていないと読みにくくなります。

Webサービスで「なんかこの色見にくい・・・」と感じた場合、「お互いに補色になっていない」ことが多いようです。

色がもたらす心理的効果

「暖色」と「寒色」

赤・橙・黄のように「暖かさ」を感じるような色を「暖色系」といいます。 この時期にヨドバシカメラの暖房機コーナーに行くと、オレンジ色や赤色をベースにしています。暖房機コーナーにある色は基本的に「暖色系なんだ」と思っていただけるといいとおもいます。 文字通り「暖かさ」を示すだけではなく、食欲を訴える色としても使われます。食品パッケージにもよく使われています。また、レシピサイトにも暖色系を使ったサイトが多く見られるのもこのためだそうです。(寒色系が全く使われないわけではありません。)

逆に青系の色は「寒色」といい、文字通り涼しさを感じます。夏になるとヨドバシカメラでエアコンコーナーへ行くと青基調の配置になっているのはこのためです。 また、夏のかき氷やアイスも寒色系を使うことで涼しさを引き立てています。この場合は「おいしい!」よりも「涼しい!」をアピールするために寒色系の色を使うことが多いみたいです。

Webアプリケーションを作るにあたっても、ターゲットに合わせて「暖色」「寒色」を意識してみましょう。 たとえば、食品を扱うサイトであれば明度を低めにしたオレンジ色を使うなど考えることができます。プロトタイプ開発にあたっても、この点だけでも気にしてみるとだいぶ変わります。

色の「視認性」

これはドキュメントを作る時にも心掛けたいポイントです。文字が読みにくいWebサイトになってしまうと、PV数にも直結することになるので注意が必要です。 色の視認性は「背景との明度の差(コントラスト)が大きい」ほど認識しやすくなります。 明るい背景色に対して文字を載せたい場合、明度が低い(黒色など)色を選択します。

違和感を感じたら?

開発中のUIに「なんか見にくい・・・」や「目が疲れる」といったことを感じることが多々あると思います。 ただ、デザイナーさんに「なんか目に悪くない?」と言っただけではなかなか理解されないこともあるかもしれません。 そんなときに、「補色にすればどうですか?」のような具体的な用語が使えると、デザイナーさんにもスムーズに理解してもらえます。

間違いがあったら

この記事は素人が書いています。参考文献をベースにしながら書いていますが、間違いがありましたらお手数ですが不破までメール(fuwa at atware.co.jp)でお知らせください。できるだけ早く修正します。

明日はどうなる?

気づけばアドベントカレンダーも明日で終わりのようです。今年もあとわずかで、今週金曜日は弊社の最終営業日です。 ラストを決めるのは、あの新人です。

参考・引用文献

今回この記事を執筆するにあたって、下記の書籍を参考にさせていただきました。 また、色相環の画像はWikipediaより引用しています。 Wikipedia 色相

いずれの本も、デザイナーではない私が読んでもわかりやすい内容で今後の開発にも活かしたい内容でした。年末休みに更に深く読んでいきたいですね。

みなとみらいの冬

みなとみらいの冬

こんばんは。アットウェアの女子社員です。

みなとみらいで働く私たちにとっては、「みなとみらい」は職場ですが、観光やショッピング目的で遊びにくる方も多くいらっしゃるとおもいます。 (いやいや、むしろ、そういう人の方が多いでしょぉ)

「みなとみらい」では、季節に応じた様々なイベント/催しが開かれ、毎日「みなとみらい」に出社する私たちは、仕事をしながら四季折々の「みなとみらい」を楽しむことができます。

さて、もうすぐ今年が終わろうとしているこの時期にあるイベントと言えば、Xmasですね。

そうなんです、さすがは「みなとみらい」。色々なXmasツリーやイルミネーションをみることができます。

atWare Advent Calendar 2015 の22日目は、この時期だけ楽しめる「みなとみらい」を写真でご紹介します。

では、さっそく、定時後、このオフィスを起点にぐるっとカメラ女子風に徘徊してきたルートに沿ってご案内します。

まずは、私たちのオフィスのあるみなとみらいセンタービルのXmasツリーです。 このオフィスに移転してきたのが12月だったこともあり、移転当日、このツリーをみて感激したことを覚えています。 ココだけのお話ですが、このビルでは何度かCMや雑誌の撮影をしているのをみかけたことがあるんです。そうなんです、お仕事の合間に有名人をみることもできちゃいます。

続いて、お向かいにあるクイーンズスクエアの入り口です。

一度建物に入り、そのまま通り抜けてat!のテラスに出ます。 すると、コスモワールドの観覧車を背景に素敵なイルミネーションをみることができます。 ココでは、スマフォで自撮りをしている方がたくさんいました。

再び、建物に入り海の方へ歩きます。すると、「キューピッドツリー」が出現します。 このツリーは1日に6回、音と光のショーが行われます。

それでは、来た道を戻って桜木町方面へ建物の中をずんずん歩きます。一度、外に出されますが、そんなことは気にせずに、ランドマークプラザへ入り、またまた、ずんずん歩くと真ん中あたりにツリーが現れます。おそらく、ツリーとしては「みなとみらい」で一番有名な場所です。

はい、そうなんです。何も知らずにココへ来た私は驚きました。 例年とは趣が違うのです。ココでも決まった時間になると音楽が流れ、ツリーと名曲を一緒に楽しむことができるので、得した気分になります。

さて、次は、建物を出て道路を渡って、マークイズへ移動します。

お気づきでしょうか。実は先ほどのツリーと対になっています。 ランドマークは「強さ」。そして、マークイズは「やさしさ」をイメージしているそうです。

それでは、せっかく入った建物をまた外にでて、横浜側に道路を渡ると、そこはみなとみらいテラスです。ここでは、水を使ったイルミネーションをみることができます。

そろそろ、体も冷えてきたのでオフィスに戻ります。

このブログでは最後になりますが、私たちアットウェアでもXmasツリーを飾っています。

ここでは紹介しきれないほど、たくさんのイルミネーションやツリーが「みなとみらい」では楽しめます。みなさんもぜひ一度、「みなとみらい」にいらしてみませんか?

さて、今年のAdventCalendarも後2日となりました。 明日は、札幌から来た彼が素敵なお話をしてくれます。

認定スクラムマスター研修に参加しました

認定スクラムマスター研修に参加しました

この記事は atWare Advent Calendar 2015 の21日目の記事です。

2015年10月19日、20日に東京で開催された認定スクラムマスター研修に参加してきました。

講師のJames O. Coplienさんと川口さんにも感謝するとともに、成長のチャンスを与えてくれた会社に感謝しています。

これまで1年ほどアジャイルでの開発に携わってきましたが、今回の研修に参加することで再認識できたことや新しい発見もたくさんありました。

忘れないうちに、私が感じたスクラムの間違いやすい点や感想をまとめてみます。

まずは、スクラムの概念で間違いやすいところからです。

POはデイリースクラムに参加する必要はない?

  スクラムガイドには特に決まりはないですが、POは定期的にデイリースクラムに参加したほうがいいです。

  理由としては、まずPOもスクラムチームの一員です。

  POはビジネス価値と詳細要求仕様を開発チームに届ける役割を担っています。デイリースクラムで開発チームの発言をきくことで、「届ける内容」をよりわかりやすいものにすることができます。

スプリントレトロスペクティブ(振り返り)におけるPOの役割は何ですか?

  どのようにPOが関与するのかは、スクラムチームが定義します。

スプリントレビューの主な目的は何ですか?

  ステークホルダーが、チームが作ったものを確認し、次に何をすべきかについての意見を与えるためです。

スプリント中に、変更があったらどうしますか?

  変更はビジネス価値があり、プロダクトオーナーが許容できる期間内にチームが対応でき、かつプロダクトオーナーが承認した場合は、開発作業中いつでも受け入れます。

チームは最初のスプリントでは何を行いますか?

  スプリントゴールを定義します。

次は、超個人的な感想です。

スクラムはイノベーションを生み出せる

  まず、スクラムの特徴である「改善」です。「改善」の延長線上にイノベーションがあるというのはよく耳にする話です。

  そして、スクラムはチームで仕事を進めるためのフレームワークにすぎないと思われるかもしれないですが、独創的問題解決プロセスを活用することでイノベーションを起こします。このプロセスの1つは、解決方法を探るときは、チームメンバーが集合してブレストを行い、アイディアを上げていきます。そして、全員が様々な意見を出し、それを参考にブレストすると、更にアイディアの質も量もよくなります。

常に優先順位の高いものから消化していく

  POがエンドユーザのフィードバックや市場状況の変化に応じて、価値が大きくなるものを優先して順位をつけ、常にその優先度が高いものから消化していくことで、無駄を最大限に減らすことができます。

オープンで生産的なチーム

  スクラムでは、チームメンバーに指示を出したり、チームの方向性を決めるリーダーは存在しません。

  全部がそうではないと思いますが、一部の保守的な開発チームには、タブーとなっている話題があり、通りたくない道を進まないようにしています。まれに、自分に割りあたったタスクが何のためにあるかがわからない時もあります。

  アジャイルでは、温かくあいまいではなく、オープンで生産的なチームを作ろうとしています。

  チームメンバーは一人一人が常に自分のやっていることに責任を持ち、自分がやっていることでどんな価値を生み出していくのかを理解し、誰もが議論を始めることができ、そして、誰もが言い難いことをいえます。

  スクラムチームではのんびりすることはありません。ただ待つだけの人もいません。

チームの疲弊を防げる

  「リリース日に合わせてスコープを調整する」あるいは「スコープに合わせてリリース日を調整する」。

  リリースに向けて追い上げることはしないことで、スケジュールに追われて疲弊になることはないです。

「場」を大事にする

  スクラムでは関係者が同じ場所に集まって、コミュニケーションを大事にしています。

  POがエンドユーザーの声をよく聞く、開発チームはPOの仕様をよく聞く、自分が作りたいものだけを作ったら単なる自己満足にすぎません。エンドユーザーにとって、価値のあるものを作れなければなりません。

バグはいいことだ

  英語で言うと、”Safe-Fail, NOT Fail-Safe”です。スクラムは安全に失敗をさせます。

you should be what you want to be

  スティーブ・ジョブズがスタンフォード大学での卒業スピーチの最後でも似たことをおっしゃっていました。

  ただ、現実は甘くなく、いろいろな”障害”が発生します。

  例え障害があっても、自分ができることは必ずあるはずです。自分ができることを探し、実行しましょう。

最後に

スクラムマスターの資格が取れても、それは終わりではなく、ただのスタートです。(講義中にCoplienさんがおっしゃったことです。)

私自身スクラムマスターの認定をうけてもうすぐで2ヶ月がたちますが、日々の仕事で大きな変化はありません。学んだ知識を日々の仕事にどう活かしていくのかを常に考えています。

自分は何ができるのか、何か改善できることがないのかを常に心かけ、毎日の小さな努力のつみ重ねが、いつか点と点を結ぶことができると信じています。