インターンシップ体験記・2017(公立はこだて未来大学 石戸さん)

インターンシップ体験記・2017(公立はこだて未来大学 石戸さん)

アットウェアインターンシップ 活動報告

はじめに

公立はこだて未来大学 学部3年の石戸です。8月21日から9月8日までの3週間、アットウェア横浜本社で開催されたインターンシップに参加させていただいたので、その内容などについて簡単にまとめたいと思います。
「Webサービス・アジャイル開発 実践」という募集要項に対し、参加した人は全国各地から集まった大学生と高専生合わせて11名。
全員の力を合わせて「プロジェクト内のタスクを管理するWebサービス」を作成しました。

参加の経緯

インターンシップに参加した理由はいくつかあります。

  • 大人数での大規模開発がやってみたい
  • Webサービスを作ってみたい
  • アジャイル開発の技法について学び、実践したい
  • 実際の現場での雰囲気が知りたい

大きな理由は以上4つです。アットウェアのインターンシップは、自分のやってみたいこと・経験したいことが盛りだくさんだと直感し、応募・参加しました。

活動内容

1週目:アイスブレイク・勉強会

初日はアイスブレイクを行いました。その日に初めて会った人たち数人+社員の方1名でとチームを組んで話し合いながら、ゲームを進めていきます。その中で開発に活かせる手法について学びました。例えばタスクの可視化ができる「かんばん」です。タスクの状態を「ToDo」「Doing」「Done」の3つに分け、そのタスクが現在どのような扱いかをすぐさま把握することができます。2人1ペア(1チーム3人1ペア)を作成し、ペアごとに機能を作成するタスクを割り振っていきます。ちなみにこのペアは1週間に1回変わります。
2日目はインターン期間中に作成するプロダクトの内容決めをし、作成に必要な機能の洗い出しをして、必要な時間を計算しました。はじめに述べたとおり、「プロジェクト内のタスクを管理するWebサービス」を作成することになりました。
3日目は集団開発で必須なgitについて勉強し、開発に必要な技術についてペアプログラミング方式で勉強・開発をしました。ペアプログラミングは1人がキーボードを叩き(ドライバー)、一人が指示を出す(ナビゲーター)開発手法です。1週目では私はドライバーとなり、ペアの指示に従って実装していきました。
4日目以降は各ペアごとに2日目に割り振ったタスクをこなし、機能を作成していきました。

2週目:開発・プログラミングコンテスト

週の初めには先週の内容についてKPTで振り返りを行いました。KPTは「Keep(保っていきたい=良かった点)」「Problem(改善したい点)」「Try(試したいこと)」の3つを考える振り返り手法です。先週の良かった点、改善点を元に試したいことを考えました。
2週目のペアが「自分の開発技術を磨きたい!」とのことだったので、自分はペアへの実装方法の提案や、実装方法の調査などをメインに行いました。
金曜日はインターン生全員でプログラミングコンテストに挑戦しました。出された問題に対し、適切なプログラムを作成する競技プログラミングです。ペアで5つの問題に挑戦します。私のチームは5問全問正解することができました。最後の問題はとても解き甲斐があり、楽しかったです!

3週目:開発・成果発表会

3週目もKPTで開発に取り組みました。この週が最終週なので、全員完成に向かって頑張って開発を行いました。
私は全体のデザインの統一や、全員の作業ブランチのマージ作業を担当しました。コンフリクトの解消や、マージして気づく不足点などの補完を行いました。地味ながらも重要な作業で、大変だったと感じています。
最終日は成果発表会です。参加者全員がこのインターンで感じたこと、成長したことなどを思い思い語りました。

作成したもの

作成したものはプロジェクト内タスク管理Webサービス「ぷろまね。」です。

image-1.png

色々機能はあるのですが、一番わかりやすいのはこの画面です(開始日でこの記事を書いた日がバレバレ・・・)。プロジェクトマネージャー(以下PM)がプロジェクトおよびタスクを作成し、そのタスクをこなすプロジェクトメンバー(以下メンバー)を指定します。メンバーはタスクに対しPMに参加申請をすることができ、PMはその申請をお知らせ画面で受け取り、参加の可否を審査します。タスクに参加しているメンバーはタスクに対し進捗度の更新やコメントを残すことができ、別のメンバーとサービス上で交流することができます。
実はこの画面、最終日から少しだけ個人的に開発を進めたものになります。最終日時点では終了日の未設定機能が未実装だったり、PMでなくてもタスクを削除できるといった実装の荒い部分が残っており、自分でちょっとだけ改修しちゃいました。インターンが終わっても開発のモチベーションが続き、作ったものを改善したい!と思って改修を進めました。この記事を読んでいる一緒に「ぷろまね。」を開発したみんなが、少し驚いてくれたら嬉しいです。

使用技術

Webサービスを作るにあたって、Javaプラットフォーム向けフレームワーク「Spring Framework」を使用しました。Spring Frameworkはユーザのログイン認証やMVC、データベースアクセスなどを簡単に実装できるものです。Webサービスの開発が比較的簡単に行えるもので、開発前はJavaの初心者でもインターン終了後にはそれなりにサービスが作れるんじゃないかといった上達が見えるすごいやつです。
その他使用した技術要素としては、HTML, CSS, JPA, JDBCです。HTML上のデザインはBootstrapを用いています。

感想

最終日には「短かったなぁ」と感じるほど濃密な3週間でした。開発では社員の方にわからない場所を丁寧に教えていただいたり、コードレビューをしていただいたりと、とても親切に指導していただきました。他にも集団開発でしか経験できないことを多く学ぶことができました。会社の雰囲気もとても良くて、社員の方とも一緒にお昼ご飯を食べ、会話が盛り上がる一面もありました。歓迎会や交流会も開催していただき、開発以外でもとても楽しい3週間でした。この度はインターンに参加させていただき、本当にありがとうございました!

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

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

atWareインターンシップ参加レポート

徳島大学3年の森と申します。 この度、8/21~9/8の3週間に体験させて頂きましたインターンシップについて簡単にまとめました。

はじめに

私はこのインターンに以下の3つの目的を持って参加しました。

  • IT業界の方や他校の学生との交流
  • チーム開発
  • Webサービスの開発

結果として、3つの目的は達成でき意義のある3週間を過ごすことができました。今回は、上記3つの参加動機(体験できたこと)に関して、主観的に感じたことを交えてまとめました。拙い文章ではありますが、これからインターンシップへの参加を検討している方にとって、少しでも参考になれば幸いです。

概要

今回参加したインターンシップの簡単な概要としては、9人のチームで、3週間3回のイテレーションでのアジャイル開発によって、Springを使いWebサービスをつくる、というものでした。インターン生の9人は、4人が高専4年、4人が大学3年、1人が大学2年でした。作成するWebサービスは事前にメールで提案したものから適したものを選んでもらっており、初日にインターン生同士で詳細な仕様を決めました。

交流

チームメンバーの9人ですが、全員が初対面で出身地もばらばらだったので、地元の話や通っている高専・大学の話などの普段聞けない話が聞け、面白かったです。特に普段他校の方と話す機会が少なかったので、カリキュラムや学校行事のことや実習・研究でどんなことをしたかなどの話ができたのは良かったと感じています。3週間の時間があるので休憩時間やご飯のときにじっくり話ができる機会が多くあることも3週間のインターンならではのものだったと思います。
またインターン生だけでなく、社員の方とも話ができたり、開発のアドバイスをもらえたりできたことも、このインターンならではの良かったことだったと思います。今回開発を進めるにあたり、常に新卒の社員の方が付いていてくださりサポートして頂きました。アジャイル開発の進め方を教えてくれたり、Webアプリ開発の技術的な質問に答えてくれたりと、私たちインターン生にとって頼もしい存在でした。

アジャイル開発

開発の進め方はカンバンという手法を使い、タスクの切り分け・コスト見積もり、タスクの可視化、1イテレーション後に反省・改善、という流れでした。まず週の初めにミーティングを行い必要なタスクの切り分けとそれにかかる時間の相談を行います。開発経験に個人差があるのでこのミーティングの際にお互いのタスクへの認識や技術に関する知識を共有できました。開発を進める際には、タスク内容と達成に必要だと推定した時間を書いた付箋をTodo、Doing、Doneのタスクの状態に応じて壁に貼っておくことで、残タスクの量や全体の進捗具合を目で確認しながら進めることができました。1イテレーション毎に行う振り返りでは、それぞれ個人が1週間で感じた良かった点や悪い点を共有するミーティングを行いました。
今まで個人開発が多く9人ほどの人数で開発をする機会がなかったので、9人で1つのものをつくるのは難しいと感じましたが、今後チーム開発する機会は絶対あるので、その時に活かせられる良い経験ができたと思います。

mori-kanban.png

Webサービスの開発

 今回、開発にはSpring(Java、HTML、CSS)やGitを使用して進めていきました。チームではJavaやGitの経験が少ない方も多いため、タスクの切り分けではそのことを考慮し勉強時間もタスクとして設けました。私自身もJavaは学校で学んでいましたがSpringの経験が一切なかったので、勉強しながら開発ができ、無理せず足並みを揃えて進めることができました。また、タスクに取りかかる際には2人ずつのペアに分かれてそれぞれで進めていったため、先に勉強を終えたペアに分からないことや進め方を相談できた点でも安心して進められました。

mori-workspace.png

おわりに

 IT企業のインターンシップはバイトのように業務をこなす形式やハッカソン形式のものがありますが、今回はそのどちらとも違い、学ぶ機会の多いインターンだった思います。最初は技術面で不安がありましたが、チームメンバーでお互い勉強しながら開発ができたことや、社員の方がいつでもサポートしてくれたことや、社長の牧野さんからIT業界や企業に関するお話を聞かせてもらえたことなど、たくさんの学ぶ機会がありました。また同時に、交流の機会も多かったと思います。アジャイル開発やペアプログラミングでの交流だけでなく、歓迎会や打ち上げを企画してくださり、本当に楽しい3週間でした。
 最後になりましたが、インターンを無事終えることができたことに、丁寧に教えてくださった社員の方々や一緒に開発に取り組んだチームメンバーに感謝しております。楽しい3週間をありがとうございました。

mori-snapshot.png

立命館コンピュータクラブでRustとVimをテーマに勉強会を開催しました

立命館コンピュータクラブでRustとVimをテーマに勉強会を開催しました

IMG_9721.JPG

「立命館大学の学術系公認サークル「立命館コンピュータクラブ(RCC)」にて、今年の春に開催されたRCCOSSという勉強会が非常に好評をいただいたようでしたので、半年ぶりに勉強会を企画し、事前にいただいた興味あるテーマから2つほどピックアップし、弊社メンバーが2名お伺いしてそれぞれ40分枠で発表してきました。

開催前に

RCCには部室があり、勉強会前に部室に寄らせていただきました。 部室内には参加者20名ほどが10畳ほどの部屋でワイワイやっていて、熱気がすごい。

本棚は古い本から新しい本まで多種多様で、Vim棚もありました。

勉強会の様子

IMG_9771.JPG

Vimの方では Vimで会社や業務を支える技術 というタイトルで、考え方とTips的なものを混ぜて話しました。参加者に発表中にヒアリングしたところ

  • 3割〜5割程度の方はVimを利用したことがある
  • この機会に使い出して3日目という方もちらほら

こんな感じの比率でした。

IMG_9715.JPG

Rustは 使って分かったRustのいいところ というタイトルで、Rustで言語仕様の説明を中心に、実際に作った通知系サービスのコード例を交えて発表しました。発表の中で「一度C++で苦しんでおくと、Rustが神様のようにみえるかもしれない」というフレーズもあり、新しい言語との出会いはいつも面白さがありますね。

懇親会

IMG_9730.JPG

勉強会での感想や関連する話題、普段どんなことに興味があって研究やプロジェクトをしているのか、ハッカソンに参加した時のことなど、いろんな話しをして楽しい時間を過ごしました。

RCCの部員は60名ほどで、こういう活気があって各々が興味があるテーマに打ち込んで、切磋琢磨できる環境に身をおけるのはいいですね。過去に後輩が先輩から受けてきた影響のエピソードを聞いている最中に、別のテーブルでまさにエピソードに近い、そのような光景を目の当たりにしました。

最後に

今回も楽しんでもらえたということが一番の収穫です。

社外に出てこうやって発表する機会を増やしていきたいと思っていますので、私たちの所でもというリクエストがございましたら、お気軽にお問い合わせください!

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

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

1 はじめに

インターンシップでは集まった高専生、大学生で実際にサービスを作成する体験をしました。複数人で集まってチーム開発をするのは初めてではなかったのですが、仕様の話し合いの段階からやったことはなかったのでとても勉強になりました。開発方式はかんばん方式によるアジャイル開発、ペアプログラミングを行ないました。

2 チーム開発

初週の仕様の話し合いは自分の知識が足りず、あまり話し合いに参加できませんでしたが1週間実際に作業をすることで話し合いに必要な知識がついていき2週目以降の話し合いには積極的に参加することができました。 かんばん方式では実装にかかるタスクを切りだし、それぞれにかかる時間を設定しました。それを付箋に書きTodo(やること),Doing(やっていること),Done(おわったこと)の3つに分けたホワイトボードに貼ることで残っている作業、だれが今何の作業をやっているか、どの作業が終わっているかがすぐわかり、プロジェクトの進捗が一目でわかり、とても便利なプロジェクト管理だと思いました。

kondo-kanban1.png
kondo-kanban2.png

アジャイル開発では週の初めにその週にやる作業を決めることで前の週に残ってしまった作業や見つかったバグへの修正を簡単に組み込むことができて発生した問題に素早く対処できました。

3 開発に用いた技術

インターンシップでは以下の技術を使いました。

  • Java
  • Git
  • Springフレームワーク
  • SQL
  • HTML
  • CSS
  • JavaScript
  • jQuery

私はインターンシップ参加前はこれらの知識があまりありませんでしたがインターン参加前にこれらの技術の書籍をいただき、サポーターの方のわかりやすいサポートにより作業を完遂することができました。

4 おわりに

自分ではあまりJavaを用いてアプリケーション作成を行なったことがなかったり、SQLデータベースについての知識があまりなかったり不安に思っていましたが、インターン生の高専生や大学生、社員の方のサポートによりサービスを作成することができました。 歓迎会や打ち上げなどのイベントや社員の方に誘っていただきVimのイベントに連れて行ってもらったりしてとても楽しむことができました。
いろいろと迷惑をかけたと思いますが3週間ありがとうございました。

インターンシップ体験記・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サービスの開発経験がないといったことが大きな不安要素でした。しかし、今終わって振り返ってみると、わからないことはアットウェアの社員の方々が丁寧に教えてくださったり、一緒に参加していたメンバー同士で教え合うことができる環境で、とにかく"楽しみながら"開発をすることができました。

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

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