インターンシップ体験記・2017(豊田高専 専攻科 高さん)

インターンシップ体験記・2017(豊田高専 専攻科 高さん)

アウトライン

 豊田工業高等専門学校専攻科1年の高と申します。8/21から9/7までの3週間にわたって、アットウェアのインターンシップに参加させて頂きました。報告という形で実習内容の紹介や感想などを述べたいと思います。

taka-internship.png

参加した理由

学校の先生からベンチャー企業について興味がないか、と聞かれ話を伺ったところアットウェアを紹介されました。豊田高専からアットウェアにインターンシップで参加した学生は今までいなかったため不安もありましたが、直接アットウェアの方から話を伺った先生からの後押しや、使ったことのない技術であるJavaフレームワーク(Spring Boot)を用いたWebアプリケーション開発をしてみたかったこと、高専でのチーム開発は2~4人程度と比較的小規模だったため、より大人数での開発に携われることなどから参加を希望しました。

実習内容-作成するアプリケーションについて

まず3週間で作成するアプリケーションの仕様決定を行いました。「タスク管理を行うアプリケーション」という大枠は与えられますが、そのアプリケーションに付加する機能や独自性はインターン生9人で話し合いながら決定していかなければなりません。1日かけてようやく仕様を決めることができました。(後々仕様が不十分だったことに気が付きますが)

実習内容―「かんばん」

仕様に沿って洗い出されたタスクは「かんばん」と呼ばれる手法によって管理します。各タスクをTodo(やること)/Doing(やっていること)/Done(やったこと)に分類し、タスクの進捗を可視化することができます。こうすることで、何を自分はやらなければならないのかということを認識することができます。自分のやっていることが分からないのか、という声が聞こえてきそうですが、開発を進めていると前やったところのバグを発見したり、あの機能も付けようこの機能も付けよう、ここはもっとこうやったら効率のいいプログラムになる、といった具合にどんどんタスクを自分の中で増やしてしまって、今は何を開発する工程なのかということが迷子になってしまうことがあります。そんな時にかんばんを見ることで、今はこの機能を作るタスクなんだからこれに集中しよう、と見つめなおすことができました。他にもプロジェクト全体の進捗管理がしやすくなったり、長い間Doingに留まっているタスク(行き詰まっている仲間)を見つけることができるなど、手間をかける以上のメリットがある管理手法だなと思いました。

taka-kanban.png

実習内容―フレームワークを用いたプログラミング

 Javaを用いたWebアプリケーション開発は授業内で経験していましたが、Spring Bootは経験がなかったために最初はわからないことだらけでした。1週目はユーザのログイン機構を作成することになりましたが、とりあえずテキストの真似をして書いたら動いた、という感じで進めていました。ですが開発を進めていくうちに、実装したい機能に対する必要な構成要素を理解できるようになり、だんだんとテキストを参照する機会が減っていきました。社員さんや仲間たちとの協力で、最初に決定した仕様を満たすアプリケーション(一部未実装、バグ多数有ですが)を作成することができ、満足感を得ることができました。

実習内容―1日の流れ

 とある1日のスケジュールを記載しておきます。参加を考えている方にイメージを与えられればと思います。

  8:00-起床
  9:00-出社(通勤時間約40分)
  10:00-昨日の実習内容のまとめ
  10:30-朝会(朝礼的なもの)、開発業務開始
  13:00-お昼休み(1時間)
  14:00-開発業務再開
  19:00-退社
  24:00-就寝

 大体このような感じで生活していました。これだけ見るとずっとパソコンと向き合ってがりがり開発をしているように見えますがもちろん適宜休憩を挟みつつやっています。時々ワークショップが開催されることもあります。(社長の牧野様によるIT業界についての説明会、アットウェアについて、プロコンなど)

感じたこと

 何より「コミュニケーション」が大事だということを感じました。仕様を決定するにもタスクを洗い出すにもわからないことを社員さんや他の仲間に聞くにも、とにかく会話をすることが一番重要です。会話をすることで不十分な機能や仕様に気付いたり、自分1人では考え付くことのできなかったアイデアを、共有することで生み出すことができます。同じ分野を勉強する仲間たちや、面倒を見てくださる社員さんと交流しながらどっぷり3週間開発に打ち込むことができるのはとても贅沢な経験だったなと改めて振り返って感じました。仲間との共同生活や社内での歓迎会や打ち上げ、仕事後にみんなで外食など開発業務以外にも楽しい経験をたくさんすることができました。夏休みの3週間を注いで参加をしましたが、楽しい、かつ今後のためになる、素晴らしい3週間だったと思います。これからインターンで知り合った友達と、このインターン中に作成したアプリケーションのブラッシュアップをしていこうと企画しています。

参加を検討されているみなさんへ

 プログラミングの能力に自信がなく参加に尻込みをしてしまっている方が多いと思います。ですが事前に丁寧にテキストを送っていただけますし、社員さんがしっかりとサポートしてくれます。さらにペアプログラミング形式で開発を進めていくので、わからないところを簡単に仲間同士で相談できる環境になっています。第一、プログラミングに自信がありますと胸を張って言える人はそうそういないと思いますので、自信がないという人ほど自分を成長させることのできる機会だと捉えて参加を考えてみてはいかがでしょうか。また自分は学会発表のために途中で抜けてしまいましたが、そういった所用があっても参加はできますので、諦めずに参加を検討してみてもいいと思います(もちろんそれ相応の負荷はかかりますが)
 きれいなオフィスで、素敵な仲間や社員さんに囲まれて、新しい技術を駆使して、開発業務を体験できるアットウェアのインターンシップにぜひ皆さん参加してほしいと思います。

長文失礼しました。少しでも参考になれば幸いです。

重ね重ねになりますが牧野様はじめアットウェアの方々には大変お世話になりました。益々のご発展を心よりお祈りいたします。

失礼します。

インターンシップ体験記・2017(東京高専情報工学科 赤間さん)

インターンシップ体験記・2017(東京高専情報工学科 赤間さん)

始めに

東京高専情報工学科の赤間です。

今回は7/31 - 8/4の間アットウェアのインターンに参加させて頂いたので、その間の内容を記します。

今回のインターンに参加する動機

大きく分けて2つありました。

  • 学校外で自分の技術を使って何かしたかった
  • 仕事と部活での開発の違いを知りたかった

概要

メンバーは4人

  • 大学院1年生
  • 学部4年生
  • 高専2年生←自分
  • 工業高校2年生

開発したものと技術

開発したもの

  • 誰でも簡単に立ち上げが可能な競技プログラミングの問題・採点サーバ
  • 名前は'Instant Coder'!

使った技術

  • Java(Spring)でWEBサーバの処理を実装
  • HTML, CSS, JavaScript(jQuery, Ajax)でフロントエンドを実装
  • Scalaで提出されたコードの実行・採点をするサーバを実装
  • Docker, Docker Composeを使ったサーバ立ち上げ

内容

7/31(前準備)

やったこと

  • アイスブレイク
    • ドミノをした
  • タスクの切り分け
  • 見積もり
    • プランニングポーカを使った見積もり

一日目は以上のような、開発の下準備をしました。

特にプランニングポーカは、インターン後に学校等で開発をするときによく使っています。

8/1 - 8/3(開発)

やったこと

僕はJavaとSpringでWEBサーバを担当しました。

主には以下の作業をしました。

  • 問題一覧、問題表示ページの作成
  • 解答ページの作成
  • 解答の受取
  • 認可・認証

8/4(発表)

最後に発表をしたのですが、直前までコードを書いて最後の最後に、 最低限競技プログラミングサーバとして動くものができました。

最後に

感想

以下のようなものを今回のインターンから得られました。

情報系に関する話や情報共有のできるメンバーや、アットウェアの方々とのつながり

インターンで知り合ったメンバーやアットウェアの方々とは現在も、SNS等で繋がっています。

技術の向上

今回書いたJava Springの技術や他の情報系の知識を、作業や周りの方々との会話等から得られました。

またそれらの知識からまた新しくやりたいこと・学びたい技術を見つけることができました。 具体例を以下に上げます。

  • SQL周りの勉強
    • メンバーの方でDB周りで詳しい方がいて、その方の話を聞いてSQL周りに興味がわきました
  • Rust
    • Rustをやろうかなと思いながらもずっととどまっていたのですが、Rustをやっているアットウェアの方の話に感化されてRustを始めました

仕事と部活での開発の違いへの理解

仕事と部活での開発の違いを動機として上げていましたが、例えば作業を終わらせることに充填を置いて、自分で作るということに重みを置く学校とは大きく違うことに気づけました。

まとめ

今回のインターンで貴重な知識・技術・経験等を得ることができ、非常に楽しく有意義な5日間となりました。

企画して頂いたアットウェアの方々や、メンバーの皆さんありがとうございます!

今後ここで得た知識・技術・経験等を様々な場所で活かしていきたいと思います。

VimConf2017 スポンサーレポート

VimConf2017 スポンサーレポート

参加者のブログがすでに30件ほど公開されており、当日の熱も覚めやらぬ中、来年以降の開催に向け、スポンサーを検討している皆様に参考にしていただけるように、スポンサー視点でブログを書きたいと思います。

VimConfの今までと今年

2015〜2016年 にかけて

当時のVimConf閉会式で「誰か特定のメンバーがVimConfを主催しているのではなく、前年度とは異なるVimコミュニティの面々で運営され人依存ではなくなった。それは、コミュニティ形成の土壌ができたということだ。」的なことが、述べられたことを覚えており、この時期はひとつコミュニティが次のステージに進んだんだなと実感していました。

フォローバックエントリーからも当時の様子がわかります。

これには、感慨深いものがありました。

そして 2017年

兼ねてから国際的なカンファレンスを謳っていましたが、今年からスポンサーを募ることと、海外からスピーカーを招き、全セッション同時通訳されることがvim-jpより発表されました。

スポンサーになるまでの流れ

詳細はまったくわかっていなかったのですが、すぐに会社に稟議をとおし即日でTwitterの @vim_jp へ連絡をしました。 後述で書く VimConf2017のスポンサーになる理由 はあったので、会社とはすぐに話がつき、金額やスポンサード内容については概ね任せてもらえることになったのでした。

IMG_9630.JPG

スポンサーメニューを入手

個別に準備会メンバーから連絡をいただき、枠数や価格やスポンサー特典が書かれたメニューを入手しました。 非公開なものなのでここでは詳細は差し控えますが、企業スポンサーとしては妥当な金額なレンジでしっかりしたものでした。

弊社はプラスして下記のような提案をさせていただきました。

日中に温かいコーヒーとオレンジジュースを参加者に無償(飲み物を弊社が用意して提供いたします)で飲んでいただけるようにして、Vimらしいプリントした紙コップをノベルティとして配布し、当日を楽しんでいただければと思っています。

会場都合の確認や人数算出や提供方法など、準備会メンバー1名の方と数十通のメールをやり取りしました。 初回ということも重なってやりとりや確認事項も多く、仕事をされている中で各社とやりとりするのは大変だった思います。

ブログレポートやツイートにもありましたが、よくこのスタッフ人数で回せたなとスポンサー視点でも感じました。来年のスタッフはあと数人は増えるといいですね。

スポンサーになってみて

当日を過ごし、懇親会や参加者レポートを拝見し、得れたことや感じたことです。

  • 参加者の満足度が高いカンファレンスとなった結果、来年の更なるコンテンツを期待できた。
    • いち参加者としても嬉しい限り
  • スタッフの方々にとても感謝された
    • 開催の原動力は準備会に関わった方々のパワーが大きいですよね
  • 弊社の名前を司会の方から何度か紹介してもらった
    • スポンサーへの配慮をしていただいていると実感
    • 参加者の頭の片隅に残って何かの機会で「あー。あの時の。」ってことになるんじゃないかと
  • 一般参加した弊社メンバーにも「スポンサーになってよかったんじゃないか」とフィードバックをもらった
    • 一緒に働く人の理解もあって、Vim出張にも気兼ねなくいける!(2年ぶり3回目のVim出張に今月行ってきます)

VimConfをスポンサーするメリット

閉会の言葉では、VimConf2018に向けて、さらなるスポンサーを募っていましたね。検討しようと思った方々も多いのではないでしょうか?

弊社事例を紹介します。

採用に繋がる効果

アットウェアではVimのおかげである優秀な新卒社員を今年迎えることができました。

ISUCONというエンジニアの総合力を試されるチューニングコンテストがあるのですが、今年のISUCON7にその新卒社員も参加し、難関である予選を上位で突破しました。

入社してもらえるきっかけが、交流があったとある大学のコンピュータサークルから「勉強会でVimネタの話が聞きたい」とリクエスト受けて、新幹線に乗って大学へ訪問したことでした。彼はVimとラーメンも好きだったので横浜のこの地を選んでくれたのでした(採用担当の熱心な活動があったという事実もあります)。

これは、VimConfの幾つかのセッションで触れられた、「ダイバーシティや若い層の関心やコントリビュートもあって今がある」という点にも繋がっているように思います。

極端な事例なのかもしれませんが、弊社のような知名度が高くない会社でも「ポテンシャルを持った若者に関心を持ってもらえるきっかけになる」という恩恵をVimから受けました。

こういうことって本当にあるんですね。えっ!?

最後に

去年も良かったと思ったVimConfでしたが、今年はさらによかったですね。

スポンサーに名乗り出て、場づくりに貢献できてよかったです。

準備会および参加者のみなさまお疲れ様でした。VimConf2018でまたお会いしましょう!

これからも、弊社はVimConf以外にも社員が熱心におこなっている活動やコミュニティへ積極的に支援していきます。

インターンシップ体験記・2017(武生工業高等学校 三崎さん)

インターンシップ体験記・2017(武生工業高等学校 三崎さん)

はじめに

武生工業高等学校の三﨑です。7月31日から8月4日までの5日間、アットウェアでのインターンシップに参加しました。
私がインターンに参加しようと思った理由は

  • プロの仕事を少しでも知りたかった
  • チームでの開発をしてみたかった

です。5日間という少し短い時間でしたが、十分充実した5日間でした。
事前にオンラインミーティングもして、メンバーがとても優秀な方々だったので、インターンシップが始まる前からとても楽しみでした。

インターンシップの内容

インターンメンバー4人で instantcoder(簡単にプログラミングコンテストを開催できるシステム)を開発しました。私は、フロントエンド側を担当しました。競技プログラミングも行ったことがなかったので、様々なことを知ることができました。

開発を始める前に

マルチタスクのパフォーマンスの悪さを改めて実感しました。数字とアルファベットとひらがなを同時に書くのと、一種類ずつ書くのではかかる時間が圧倒的に違うというのを体験したからです。
レゴを使った、簡単なオブジェクトを作りました。単に作るだけではなく、何を作るか、最初に何をすると早く作れるのか、などを考えタスクを分けました。2チームに別れて行ったのですが、作るものに対してこだわらなくてもいいところにこだわったりしたので、他のチームは完成してプラス何を付け足すかのところまでいっていたのですが、私たちのチームは全て完成とまではいきませんでした。タスク管理の方法や短い期間しかないので開発での重要なところから作っていくなどを実感しこの後のインターンでの開発が行いやすかったです。

開発

私はwebアプリーケーションもまともに作ったことがなくgitでのプロジェクト管理も初めてだったので、初日はわからないことだらけでしたので、他のメンバーに迷惑をかけてしまいましたが、開発していく上で必要不可欠なスキルなので、学べて本当に良かったです。
私はフロントエンドのhtml、javascriptを使った開発を行いました。デザインの知識もあまりなかったので、Bootstrapを使いました。また、javaのフレームワーク、spring bootのthymeleafを使ったwebアプリケーション開発だったので、javaもあまりやったことがなくtymeleafの知識もほとんどなかったので、そことの都合を合わせるのが大変でした。

アニメーション、バックグラウンドあり

アニメーション、バックグラウンドあり

アニメーション、バックグラウンドなし

アニメーション、バックグラウンドなし

instantcoderのログイン画面です。このバックグランドは幾何学模様がアニメーションするライブラリを使っているのですが、ここに載せられているのは画像ですが、このバックグラウンドがあるのとないのとでは印象がだいぶ違うと思います。
実際に、このバックグラウンドは他のメンバーの方などにも支持されました。このように実際のwebアプリケーションとしての機能は同じなのにフロントエンドのUIはちょっとした工夫でユーザーなどに与える印象が全然違うということを実感しました。普段、私たちが使っているwebアプリケーションも様々なUI/UXの工夫があるということに気づきましたので、ただただwebアプリケーションを使うだけでなくそこの部分を考えながら使えるようになりました。

今後やりたいこと

  • UI/UXを考えて作れるようになりたい
  • SPA(シングルページアプリケーション)
  • gitでの開発になれる
  • サーバサイドの勉強

普段はiosアプリを作っていますが、今回webサービスを開発して、楽しかったので、今回作ったものよりもう少し高度なものを作ってみたいです。また、今後gitを使う機会は増えてくると思うので、早く慣れたいです。

まとめ

html、javascript、bootstrap、tymeleafへの対応など普段はやらなかったことができて5日間、充実な時間を過ごせました。
チーム開発は難しかったですが、とても楽しかったです。
インターンシップにいくことによって、普段は味わえない体験、インターンシップメンバーからの刺激などが得られます。特にインターンシップメンバーからの刺激は大きく、知りたいことがこのインターンシップ期間中に数多く増えました。例えば、今回はフロントエンド側の開発だけでしたが、サーバ側にもとても興味を持ちました。
社員の方やインターンシップ生の方々にはお世話になりました。本当にありがとうございました。

インターンシップ体験記・2017(徳島大学 居石さん)

インターンシップ体験記・2017(徳島大学 居石さん)

1 はじめに

徳島大学工学部 知能情報工学科 4 年の居石峻寛です.
7/31 - 8/4 の 5 日間,アットウェアでのインターンシップに参加させていただきましたので,その内容について記していきます.

2 実施概要

  • 日程 : 7/31 - 8/4の5日間
  • 場所 : 株式会社アットウェア 横浜本社
  • 内容 : インターン生で「競技プログラミングコンテストを簡単に開催できる Web システム」を共同開発
  • 参加者 : 4人 (大学院1年生,学部4年生,高専2年生,工業高校2年生)

3 スケジュールと活動内容

3.1 オリエンテーション,見積もり (7/31)

午前中はアイスブレイクを兼ねてインターン生のみんなでミニゲームを楽しみました.実施概要の参加者を見ていただけると分かると思うのですが,学年や所属している組織の性格も全然違っています.また住んでいる地域もバラバラだったので最初はうまくやっていけるのか不安でした.しかし社員の方が一生懸命考えてくれていたアイスブレイクのお陰で,昼食を摂る頃には気軽に話して盛り上がれるようになっていました.
午後からは開発したいものからタスクを炙り出し,プランニングポーカーで見積もりを立てていきました.今回は一週間しか期間がないということもあり,何を開発するかについては事前に Skype ミーティングで決めていました.しかしながら思った以上に難しく,見積もりをまとめるのにも結構時間と苦労をかけていた記憶があります.

3.2 開発 (8/1 - 8/3)

とにかく開発,テストの繰り返しでした.Scala で回答プログラムの実行・評価部分を開発していたのですが, なにぶん Scala での本格開発は初めてで社員の方々に訊いて回りながらなんとか組み上げました.
また技術以外の面でもブランチ管理に始まり,タスク管理ツールの使い方やコミュニケーションの取り方など共同開発をしていく上での必要な事柄が沢山学べたのは非常に大きかったです.
また雰囲気の方もただひたすらに開発をしてデスマーチのようになっていたかというとそうでもなく,インターン生同士で話をしながら和気藹々とした雰囲気での開発ができました.メンターの方々もときどき様子を見に来てくださったり,昼食を一緒に摂ったりして社員の方との交流も多分にでき非常に楽しかったです.

3.3 成果発表会 (8/4)

最終日にはスライド作成とスライド発表をしました.偶然海外からのインターン生も期間が被っていたようで, 成果発表は彼らと一緒にやることに · · · お世話になった社員さんたちや海外の学生さんらが聴講してくださっている中,緊張しながらも発表を耐えきりました.
最後に振り返りをして,反省をしつつ一週間のインターンは幕を閉じました.

4 成果

今回のインターンで開発させていただいたものは「競技プログラミングコンテストを簡単に開催できる Web システム」です.誰でも簡単に開催できるよう Dockercompose 一つを実行するだけでシステム全体が再現できるようになっています.システムの構成は下の図になっており,主催者がサーバを立ち上げて問題を作成し,回答者がそこへ回答プログラムを投稿すると自動で実行されて評価されるというものです.
僕はこの中で回答プログラムを受け取り,実行してテストケースをパスするか判定する評価部分を開発していました.

system.png

5 所感

 最初はうまくやっていけるか心配でしたが,メンターの方々のフォローやインターン生にも恵まれ,非常に充実した実りある一週間となりました.
 プログラミングで作ってみたい,誰かと一緒にモノを作る喜びを知りたい,IT を生業としている人と交流したい · · · そんな方には是非是非オススメのインターンシップです.
 最後にお世話になったアットウェアの皆様,この度は素晴らしいインターンを体験させていただき本当にありがとうございました.

インターンシップ体験記・2017(京都産業大学大学院 中村さん)

インターンシップ体験記・2017(京都産業大学大学院 中村さん)

アットウェアインターンシップ

はじめに

京都産業大学大学院生一回の中村です.7/31(月)から8/4(金)までの5日間,アットウェアでのインターンシ ップに参加しました.インターンシップでは競技プログラミング環境InstantCoderを開発しました.他に もタスクの切り分けなど実際の開発プロセスに近いことを行いました.インターンシップは僕以外に三人 参加しており,その三人とともにチーム開発を行いました.

インターンを通して行ったこと

  1. 顔合わせ
  2. タスクの切り分けとイメージの共有
  3. 開発

顔合わせ

まずインターンシップ初日にメンターとの顔合わせを行いました. そしてその後ドミノ倒しやレゴブロッ クなどで開発プロセスをざっと勉強しました. 具体的にドミノ倒しは,ドミノ以外にギミックがありその ギミックを最低5個使用しないといけないルールでした.そこで最善のギミックを選ぶ練習をしました. レゴブロックは実際にやるべき内容をタスク分割し,「Do, Doing, Done」でタスクの見通しを良くして組 み立てていきました.これにより実際のチーム開発でのカンバンの手法を学びました.

タスクの切り分けとイメージの共有

顔合わせが終了した後は,本格的に今回作成するInstantCoderを作成するために必要なタスクを切り出 し,それを分割していきました.その後分割したそれぞれのタスクに対して,そのタスクが終了するまで の所要時間を全員で考えました.所要時間の決め方は,全員に各所要時間の記されたカードを配っておい て,各人はタスクごとに自分が思う所要時間カードを出します.そして過半数の人が同じ所要時間のカー ドを出すまで出し直しを行いました.出し直す際は,どうしてその所要時間を出したのかを各人に聞 いてから出し直しを行いました.これによりタスクのイメージを全員で共有することができました.

開発

タスクの切り分けが済んだ後,そのタスクをbacklogに登録し実際に開発を始めました.今回制作したサー ビスは,ユーザから直接アクセスされるクライアントサーバ,実際にプログラムを実行して結果を返す実 行サーバに分かれています.なので人数をクライアントサーバ二人,実行サーバ二人にして分割しました. 今回僕は実行サーバ側でDockerを用いて,サービスの環境構築をしました.基本的にはMySQLとサーバの 環境を構築し,環境(コンテナ)間での通信を行えるようにしました.後は残っているタスクを消化する手伝いをしました.

成果物

idとpasswordを入力してログインします.

  • ログイン画面
title.png

その後問題を作成します.

  • 問題作成画面

create_problem.png
  • 問題一覧画面
problem_list.png

後は問題ページに行って,問題を投稿すると実際に動かしてくれて結果を出力してくれます.

  • 問題提出画面
submit_problem.png

  • 結果画面
result.png

まとめ

一週間という短い期間でしたが,学ぶことが非常に多くあったと思います.まずは常に一緒の机でのチー ム開発における一体感を初めて感じました.気軽に今何をやっているのかを聞くことができ,ホワイトボ ードなどで考えを共有することができました.そしてbacklogでタスクを管理したのでよりタスクを可視化できたと思います.これからも開発し続けていけたらなと思いました.一週間という短い期間でしたが, お世話になりました.

VimConf2017のスポンサーになりました

VimConf2017のスポンサーになりました

VimConf 2017が11月4日(土)に開催されます。

今回はホール会場を借り、新たにスポンサーメニューも揃え、世界中の企業からスポンサーを募るとうかがっておりました。弊社社内にはVimユーザーも多く、普段からお世話になっているOSSやコミュニティへの還元活動の一環と、弊社を知ってもらえるいい機会でもあるので、ブロンズスポンサーとしてスポンサードさせていただくことになりました。

カップイラスト.png

コーヒーもスポンサードします

過去にもアットウェアは幾つかのカンファレンスのスポンサーをさせていただいてきました。弊社メンバーがカンファレンスに参加するときに大事だなと思っているは、その場を楽しめる空気感です。これは、セッション内容だけでなく、いろいろな立場の人が気軽に参加できる心遣いやおもてなしの心も大きいのではないかと考えています。

そういう、一日を心地よく過ごすための一つの心遣いとして、社員の「開催期間中にフリードリンクあったらいいな」の声を反映し、VimConf準備会様へ弊社がコーヒーもスポンサードさせていただきたいと申し出でて、厚かましくもVimConf2017のオリジナルカップまで制作させていただくことまで、承諾いただきました。

わずかな数ですがノベルティとしてVimconf2017オリジナルスリーブ付き紙コップを、当日みなさんに飲む時に使っていだだく分とは別に、弊社配布物としてお配りできればと準備をしています。


最後に

配布させていただくチラシも印刷業者様から届きました。参加者チケットも販売開始され、いよいよ間近になってきたことを実感しています。当日多くの方とお会いできるのを楽しみにしています!

コミュニティベースで活動されてる主催の準備会のみなさまにおきましては、当日は運営で大変だとは思いますが、陰ながらスポンサーという形で応援いたします。

届いたチラシ&ダンボール_リサイズ.jpg

We're looking forward to seeing you!

アットウェア社内ISUCONを開催しました

アットウェア社内ISUCONを開催しました

兼ねてから社内ではアワードコンテストをはじめプロコン大会など技術イベントが開催されてきましたが、ISUCONのような業務でやっていることに近い内容のイベントを社内で開催できたら面白いだろなと思っていました。

そこで、ちょっとした賞金も出せるように企画し実施したので、運営として工夫したことや所感を書きたいと思います。

参加してもらえるようにはどうしたらいいか?

まず、コンセプトを練り、こういった趣旨は下記をかかげて、会社に企画プレゼンをしたら、

  • 社内コミュニケーションの活性化
  • 技術を使ったレクリエーション
  • 切磋琢磨してモチベーションアップ
  • 現状を知る機会を創出

「いいんじゃない」とふたつ返事で開催と賞金周りの予算調整を含め、協力と理解を得ることができました。

弊社の特徴としては、受託開発・実証実験向けのPoC・保守・開発チームビルディングを含んだアジャイルでの開発など、弊社の仕事の特性には多様性があって、普段なかなか交わらないメンバーもいたりします。

そういう中で、普段関わらないメンバーとチームを組んだり、以前に一緒のプロジェクトメンバーだった人とやるのは面白いんじゃないか?、といった、どのようなチームができあがるかを想像するのは、遠足や旅行の時のように当日までの楽しみの一つでした。

日に日に申し込みが増えていき、壁ホワイトボード領域を利用した「だれかタッグを組みませんか?」的な呼びかけも自然発生。

日に日に申し込みが増えていき、壁ホワイトボード領域を利用した「だれかタッグを組みませんか?」的な呼びかけも自然発生。

やったこと

参加申し込みのポスターを作った

お手製のポスターを通路口に貼り、参加チームを書き込んでもらうようにしました。

声かけ

開催日は半日ほど時間を使いますので、早めに仕事の調整をつけてもらえるように、ひとりひとり声かけしながら開催に向けて準備していきました。この地味な活動により想定以上の参加率となりました!

環境

Y!ISUCONを使わせていただき、AWS上に立てました。 参加者用のインスタンスはAMIを立ち上げたら実行できるようにし、ポータルとベンチマークはTerraformで構築できるようにしておきました。 GitBucketも用意しましたが、当日に認証系設定がうまくいっていないことがわかり、時間を少しロスさせてしまい、もったいないというか申し訳なかったです。

レギュレーション

事前にISUCONがどのようなものなのかといった説明は、社内のWikiにページをつくり展開し、質問はチャットや口頭で受付て、公平性を担保できるように、質問内容と回答は全チームにむけてチャットで展開しました。今回はけっこうローカルルールも運営判断で取り入れました。また、自前でISUCON問題や環境までは作成できなかったので、ネタバレしないように、「Y!ISUCONだけは参照しないでね」と伝えておきました。


当日を迎えて

レギュレーション説明とスケジュールをした後、チームに自由に時間を使ってもらいました。

ベンチマークを走らせてすぐに各チームの結果がわかるからか、楽しそうに戦略たて進めていました。

あるチームが、ベンチマークを短い間隔で定期的に走らすということをしたり、終盤は各チームがベンチマークを回しまくるので、ベンチマークサーバーを増やし並列実行できるようにしました。

スナップショット

結果

最後劇的な順位入れ替えはありませんでしたが、戦略がうまくいった1チームが更に飛び抜けて高得点を叩き出し、それ以外は激戦でした。少ない時間でしたので、まだまだやれることやりたいことはあったようで、競技が終わった後もチューニングを楽しんでスコアが伸びたことに満足して一日を終えていた方もいました。

スコアグラフ2.png

Run Benchmark

まとめ

運営として一日を過ごしてみてみましたが、参加者としては事前準備も必要なく、始めからみなさん楽しそうにしていて、穏やかな一日を過ごすことができ、準備やチームを募るところはそれなりに労力がかかりましたが、やってよかったなと感じました。

今回は仕事の都合で参加できなかった方もいましたし、また次回も開いてくださいという声もあったので、普段の仕事とは違う楽しみとして、またこんな企画を定期的に開催していきたいです!

未来シェアへの出資額を増額しました

未来シェアへの出資額を増額しました

株式会社アットウェアは、弊社と公立はこだて未来大学とのベンチャー「株式会社未来シェア」に対して、株式会社北洋銀行様が運営する北洋イノベーションファンドと共に第三者割当増資の割当に応じました

弊社は、交通システムの未来に劇的な変化を与え、日本のみならず広く世界中の人々をしあわせにする技術「SAV (Smart Access Vehicle)」の可能性を信じ、その事業化を目的とした株式会社未来シェアを昨年2016年7月に公立はこだて未来大学と共に設立いたしました。

未来シェア設立後は、本格的な事業化に向けた開発をおこない、本年2017年7月には事業化第一弾「つばめエアポートシャトル」を就航いたしました。また並行して様々な都市および利用シーンでの実証実験と事業化の検討を進めています。

さらなる開発および事業化を加速すべく、今回の第三者割当増資を実施することとしました。SAVの生まれ故郷で未来シェアが本店を置く北海道を地盤とする株式会社北洋銀行様が割当に応じてくださり、またあわせて弊社も割当に応じました。弊社からは二回目の出資額の増額となります。

引き続き弊社は筆頭株主として未来シェアの経営および事業の推進に協力して参るとともに、SAVによる未来の交通システムの創出に尽力して参ります。

前佛さんを招いて「クラウドや運用自動化を取りまく状況」をテーマとして社内勉強会を開催しました

前佛さんを招いて「クラウドや運用自動化を取りまく状況」をテーマとして社内勉強会を開催しました

DockerやHashicorp関連のエバンジェリストとしてもよく知られている、前佛さんを招いて社内勉強会を開催しました。

開催するきっかけは、弊社ではかねてから得意としている Java x アジャイル の技術をベースに クラウドの推進 に取り組んでおり、各々立場で自分の言葉でクラウドに対するアプローチや考えを顧客やユーザと対話をしていけるようにいきたいと考えがあり、平たく表現すると、あたりまえのレベルを底上げを狙いとしたいというところでした。

そういった背景もあり、以前から関心を持っていた、エンバンジェリスト活動から運用まで携わっている前佛さんの生の声をぜひ聞かせてもらいたいと思い、登壇をオファーし実現しました。

お忙しい中、弊社に出向いていただきお話いただきありがとうございました。

勉強会のテーマと内容

「最近の私が考えていること "自動化・Docker・Hashicorp" 」というテーマで発表形式でしていただきました。

特定のプロダクト(DockerやTerraform)やプロセス(Infrastructure as codeやDevOps)の解説というよりも、なぜ自動化が求められているのか、私たちが近い未来に迎える状況に備えるにはどういう考えで、準備や適応をしていくべきなのかということを、考察を交えて話してくださいました。

市場の基盤としてクラウドインフラ採用が進んでいくのとは別のベクトルとして、製品・サービスを支える仕組みづくりに「今は壁がある」、それ解決していくための一つの方法として「自動化」や「コンテナが支えるインフラ技術」が存在しており、手法より課題やありたい姿が先にある

というような話を聞き、視点に共感しました。

コンテナの話の流れから「ここまでDockerの話をあまりしなかったのですが、興味ありますか?」と前佛さんが言うと、会場から「聞きたい!」とリクエストがあると「では補足しますね」と、別スライドを使って参加者の多くがエンジニアだったことを察して、スライドの要点をつまみながら、ボリューム満載でしっかりと話してくださいました!!

DockerとDocker Hubの操作と概念

https://www.slideshare.net/zembutsu/docker-container-image-command-introduction-2017-03

こちらのスライドを使って説明いただきました。

マイクロサービスとコンテナ

Scala先駆者インタビューという企画でもよく話題にあげさせていただいたテーマです。これについても発表の中で言及されており

必ずしも「マイクロサービスにしたらコンテナにする」という必要性はなく、「状況に応じて」と採用を検討しましょう

と言っていました。マイクロサービスのいい所とプロジェクトやチームという特性の絶妙なバランスがあるなぁと、私が最近考えているところとシンクロしました。

また、

運用チームがついてこれなくて自分たちで運用することになりがち。 Dockerのバージョンアップが早いので互換性の注意が必要です。

と話されていたように、運用チームを意識した設計はアーキテクチャを決める重要な要素のプライオリティがますますあがってきているのではないかと感じています。SIプロジェクトでも運用チームを立ち上げなどのチームビルディングが重要で、同じコンテキストの思考に持って行くまでには、社内勉強会や教育といった分野だけでなく、採用・ブランディングまで小さな積み上げが影響しているんだなぁと・・・

メッセージ

前佛さんは「docs.docker.jp」などをはじめ、様々ところで翻訳活動もされています。

その活動のモチベーションとして「小さい頃にBasicがわからなくて周りに聞ける人がいなかった」という情報格差を感じたことがあって、その障壁がなければ違った状況だったと思うし、日本における知る機会・聞ける障壁を少しでも改善できれば。

というようなことを言っており、最後に、このようなメッセージをいただきました。

実際に試していますか?聞くだけじゃなくていろいろ試してみましょう。 ただ、手法にこだわりすぎると陥りやすいので気をつけよう。 自動化・コンテナは手法であって手法が最重要とは考えておらず、武器にしていかないと厳しいと思っているからやっているのです、なぜなら世界から置いてけぼりにならないように。

とてもいいメッセージですね。

最後に

私も技術が好きなので、新しいプジェクトには新しい要素を一つは入れようと心がけています。 が、それが時として自分のエゴや興味だけとならないようにということを心に刻みました!

すごくいい感じの勉強会となったので、こういう機会がまた持てればいいなと思います。 次回は一つなにかの技術をテーマにしてやりたいです!

Geeks Who Drink in Tokyo -Backlog Lovers Edition- で課題管理ツールの社内利用事例を紹介しました

Geeks Who Drink in Tokyo -Backlog Lovers Edition- で課題管理ツールの社内利用事例を紹介しました

Geeks Who Drink in Tokyo -Backlog Lovers Edition- というイベントにお声いいただき、弊社武永が登壇いたしました。

イベント概要

イベント告知ページから引用します

Geeks Who Drink in Tokyoは、株式会社ヌーラボがお世話になっているプログラマーやデザイナー、そして私たちのサービス(Backlog/Cacoo/Typetalk)を使って頂いているユーザのみなさんと技術やデザインなどについて語りながら、交流をするイベントです。

今回は「Backlog Lovers Edition」というテーマで、Backlogを使ったコミュニケーションや課題管理について、実際の利用事例や「自社ではこんな使い方をしている」というアイデアを交換し合うユーザーミートアップとなっています。Backlogユーザーではないけれど、クラウド型プロジェクト管理ツールやコラボレーションツールに興味がある方も大歓迎です。

発表者とスライド発表タイトル

  • 株式会社ポートイット 笹尾さん
    • Wikiからはじめるプロジェクト・マネジメント
  • 株式会社アットウェア 武永
    • Backlogでの社内情報共有とAPIを使用したツールを作った話
  • 株式会社ヌーラボ 吉澤さん
    • Let's Typetalk with Backlog

弊社事例発表内容について

各発表者さん内容は他参加者さんからの参加レポエントリーを参考にしていただくとして、弊社事例発表を参加者として聞いて、社内事情を知っている立場として感想を書きたいと思います。

アットウェアからの発表内容は以前にユーザインタビューでお話しさせていただいた内容が主だったのですが、それに加えて最新の事例を付け加えたものとなっていました。

特にSIerでよくある事例が個人的に面白かったです。SIでは複数プロジェクトが立ち上がって終息していきます。5年〜8年を超えて保守を含む継続している息の長いプロジェクトもありますし、レガシーなシステムを引き継いで開発することもあります。

そういう時には、社内デファクトの課題管理ツールとしてBacklogを採用しているものの、過去に使っていた課題管理システムをいきなり切り捨てることはできず、異なるツールを使うならばデータの引き継ぎや使い分けの妥協が必要になってきます。

紹介した事例ではMantisを使っていた既存プロジェクトがあり、それを「Backlogに移行した」というケースで、Mantis -> Redmine -> Backlog という変換機能を連鎖させて課題管理の移行を成功させたというものでした。 途中、完璧な互換性がないので妥協した部分やツールに手を加えてやや強引にインポートをしていって、最終的にMantisと同じことができるという観点ではなく、課題として引き継げ再利用していけるかという観点で移行を進めたということを言っていました。

今回はMantisでしたが、社内標準(デファクト)といっても、状況に応じてフレームワークやツール類もプロジェクト特性や利用者にあったものを選ぶことになりますので、多岐に渡るツール群と付き合っていくのは、これから先もずっと考えていくことになるでしょう。顧客のセキュリティ基準やネットワーク環境、標準ツールとの兼ね合いで、Backlog以外の選択肢になることは十分起こりえます。そういう時には、情報共有とワークフローがうまく進められるように、今回発表されたようなことを引きつづきしていきたいですね。

全体的な感想

また、ポートイット笹尾さんの発表でWikiベースでコミュニケーションが進められている様子を聞き、Wiki駆動となっている様子は、弊社の使い方と随分と違うなぁと思ったりもしました。アプローチが全く違うので参考になりました!

Nulabさんのユーザを対象にしたミートアップでしたので、課題管理・タスクの仕事のやり方など工夫されている方が多く、懇親会でも関心あるGTDやポモドーロといった手法のテーマが話題になったり、とても楽しい場となりました。

弊社コアバリューのひとつとしてはオープンマインドを大事にしているので、こういったオープンな場で社内事例を発表でき、それについて社外の方と交流・ディスカッションできることは、大変うれしいことで、またこういう機会があればいいなと感じました。

OSS活動にコミットしてエンジニアとしての世界を広げよう。立命館大学での勉強会レポート

OSS活動にコミットしてエンジニアとしての世界を広げよう。立命館大学での勉強会レポート

弊社CTOの山下が、RCC(立命館コンピュータクラブ)で開かれた勉強会、その名もRCCOSSに参加してきました。仕事で開発をしながらもOSS(Open-source software)活動をしている開発者はたくさんいると語る山下。OSS活動がエンジニア人生に及ぼす影響、メリット・デメリットについてお話しました。今回はそのときの内容をお届けいたします。


OSSは今やソフトウェア開発に欠かせないもの

まずOSS活動とは何かというところから話はスタート。
 

OSSとは

オープンソース・ソフトウェア(英:Open-source software, 略称:OSS)とは、ソースコードが利用可能で、著作権保持者がどんな目的のためでもソフトウェアを、学習、変更、そして配布するための権利を提供するというライセンスに基づいたソフトウェアである。
— wikipedia より引用

OSS活動とは

OSSを開発することに関わる活動のこと。世の中で一般的に使われているプロダクトに機能を追加するなどして貢献するというものと、自分で作ったフレームワークなどを公開して他人に使ってもらうものがある。
— 発表スライドより
代表的なOSS。開発には欠かせないソフトウェアがほとんどOSSであることがわかる。

代表的なOSS。開発には欠かせないソフトウェアがほとんどOSSであることがわかる。

 

ソフトウェア開発では欠かすことのできなくなったOSS。ソフトウェア開発の現場でなぜ採用されていったかについて振り返る。


昔は、開発で使うソフトウェアがOSSじゃない場合は、お金を出して買ってインストールして、アップデートがあるとアップデート料金を払って買って、ということをしていた。ライセンスがCPU単位だと、今はCPU4個とか、8個とか乗っているので、高額になってしまう。OSSだとそのへんを削減できる。
ベンダーロックインというのがあって、ある企業システムのハードウェアとか、ソフトウェアが一つのベンダーになっていると、あまりよろしくない。そのシステムが一つのベンダーに依存していると、ベンダーが潰れてしまうと、にっちもさっちもいかなくなるが、OSSだと、その辺を回避できる可能性がある。

ソースコードがオープン(OSS)になっていると、作る人がやめても、誰か他の人が継続してくれる可能性もある。実質されないときもあるが、可能性がのこる。

 

コストの面やリスクヘッジという観点で、OSSの採用が増えていったことが伺える。

 

Seasar2のムーブメントとGitHubの登場がOSS活動を身近に

日本発のOSSが生まれたことや、開発のための環境が整ったことによって、OSS活動が身近になったと語る。
 

Seasar2のムーブメントで、OSS活動は誰でも始めても良いという機運がうまれた。さらに、GitHubの登場によって、そのための道具が揃って、更に敷居がぐっと下がった。主にはプルリクエストがそれを後押した。プルリクエストをGUIで誰でもカジュアルに出来るようにしたのがGitHubの功績ではないか。

自分で新しいものをゼロから開発しなくても、OSS活動にコミットすることはできる。新しくできたリポジトリを見つけて、タイポを指摘するといった簡単なところから始める、というような記事を見つけて、なるほどなぁと思った

発表の中で紹介されていた記事 : ショボいPull Requestを積み重ねて、自分の中でOSS活動の敷居を下げる

 

OSS活動にトライする

実際に山下が初めて送ったプルリクエスト

実際に山下が初めて送ったプルリクエスト

山下も最初のプルリクエストはすごくドキドキしたそうだ。上の画像は山下のプルリクエスト第一号。プルリクエスト上で議論が起こることもあるそうだが、この時はそういうこともなくあっさりマージされてしまったそうだ。

 

現在も自らOSSの開発も行っている山下。先月リリースされた、ShareDocsは、Scalaの練習と当時会社で抱えていた情報共有の課題を解決するために開発したそうだ。また、OSS活動を通してソフトウェアを作っておくと、新しい技術を試すよい題材になるとも語っていた。

山下が開発したナレッジ共有ツールのShareDocs

山下が開発したナレッジ共有ツールのShareDocs

 

仕事をしながらOSS活動を続ける

山下自身のOSS活動のモチベーション、続けるコツについて。

仕事上の制約からはずれて自分の好きなコードを書けるのが一番のモチベーションに繋がる。仕事では、業務の都合上、題材や、技術要素、人、納期などが制約になるが、OSS活動はそれらがない。単純に楽しめるし、業務とOSS活動で制約と自由の精神的バランスを取る
OSSを続けるコツは、普段の仕事の一部をうまく切り出すこと。とにかくつくりたいものを作ってOSSにするだけだと、ハードワークになりがちで年齢とともにつらくなってくる。仕事とやりたいことを上手くつなげるというセンスが要求されるものの、そのほうが継続しやすいと思う。
また、そういう活動に理解のある会社なりに身をおいているかどうかも重要。

山下が思うOSS活動がエンジニアにもたらすメリットは次の通り。

  • 客観的評価を得る
  • スキルが上がる / ブーストする
  • 日常的な英語の読み書きの機会を得る
  • イベント登壇の機会がもらえたりする
OSS活動をしていると他人の目に晒すことになるので、スキルアップにレバレッジを効かせることがきる。また、公開を前提にすると書くコードの精度を上げざるを得ないというような意識も生まれる。ドキュメントやコミュニケーションに使う言語は英語でやるべき。英語で発信することで世界中から反応が得ることができるというのが、OSSの醍醐味でもある。発信する人のところには情報も集まってくるメリットもあるため、恐れずに発信すべき。
 

一番大きなメリットはエンジニアとしての客観的評価が得れるということ。企業に属して開発を続けているとエンジニアとしての客観的評価を得るのは難しい。OSS活動はGitHubに公開することになるので、業界における自分の位置をなんとなく知ることもできるそうだ。また、OSSはグローバルであると語る山下。英語で発信することで世界中のエンジニアとコラボレーションができるという。また、GitHubの活動履歴や、スターの数が名刺代わりになることもあるとのこと(勝手にそれなりにデキるっぽい人だとお客さんから評価されたこともあるとか...)。

Git Awards というサービスを使ったときの山下のスコア。横浜でJavaが2位...強い....

Git Awards というサービスを使ったときの山下のスコア。横浜でJavaが2位...強い....

メリットが有る一方で、デメリットもあると語る。

  • (直接的な)金銭的な見返りはほぼない
  • 時間がとられる
  • たまに批判を受ける

一部では、OSS活動を仕事にできている人もいるが、多くの場合はそうはいかない。仕事とプライベート、やりたいことと制約のバランスを取りながら開発するセンスが問われると語っていた。

OSS活動を通してエンジニアとしての世界を広げる

最後に学生さんたちにエールを送った。

今やソフトウェアの中心はOSSで、OSS活動ができる環境は誰にでもあります。仕事で好きなことが出来ないのでは?と思う人もいるかとはおもうが、OSS活動を上手く仕事とつなげる方法はあります。OSS活動をすることで、目の前の仕事をこなすだけでは得られない世界の広がりが生まれるでトライしてみては。
— 山下

 

エンジニアリングが大好きな学生さんの中には、企業に入ってしまうと自分の好きな開発が出来ないと仕事でエンジニアを選択することを諦めてしまうケースも多くない。企業の中にはGitHubを見て採用するというところも増えてきているので、就職後のミスマッチを防ぐためにも自分のやってきたこと、やりたいことをOSS活動を通して、アウトプットしてみてはいかがでしょうか。

今回の勉強会でOSS活動にトライしようと思ってくれる学生さんが増えてくれると、我々としては嬉しい限りです。招待してくれたRCCの皆様には本当に感謝です!

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/