読者です 読者をやめる 読者になる 読者になる

Treasure2016を経て

treasure golang

こんにちはsuzukenです。VOYAGE GROUPでは学生向けエンジニアインターンシップTreasureを毎年開催しています。今年の内容について主に講義の面から振り返ってみたいと思います。

https://voyagegroup.com/internship/treasure/

Treasureは私が入社するもっと前から開催されていて、かれこれ10年弱続いているそうです。去年までは @brtriver がメインの講師を担当していました。今年は私がメイン担当ということで、言語をPHPからGoに変えてみたり、新たな講義を追加してみたりしました。

今年のカリキュラムは http://techlog.voyagegroup.com/entry/treasure2016info にも少し書きました。最終的に今年の講義スケジュールは以下のようになりました。

そしてあとはチームでのアプリケーション開発に取り組んでもらう、という日程です。全体で3週間あるなかで前半が講義という構成になっています。

事前課題

Treasureでは毎年事前課題を出しています。ここで参加者がどれくらい実装できるかというのをみておき、授業資料を調整しています。

Goの事前課題だと以下のものを出しました。

Pull Requestで事前課題リポジトリに解答を提出してもらいました。ちなみに以下のコメントをよくつけました。

  • gofmt おねがいします
  • main 以外で os.Exit や panic するのは大抵好ましくないです
  • error はよっぽど自明じゃないかぎり無視しないように
  • 変数や手続き名は snake_case ではなくて camelCase で書きましょう
  • 変数名は分かる範囲なら短くしていいです
  • 余分なelseを書かないこと。正常なフローのインデントを最小にしましょう。

ほとんど https://golang.org/s/style にあることが多かったです。課題自体はそんなに難しい内容ではないのでさくさく解けている様子でしたが、Goのコードのスタイルについてはやはりレビューでのフィードバックがあったほうがよいと考えています。なので事前課題ではコードのスタイルについても丁寧にコメントをつけてフィードバックしていました。提出は一回して終わりではなく、コメントでやりとりしながら書き換えてもらい、最終的にはマージをする、という進め方をしました。

ちなみに事前課題リポジトリにはwerckerでの go buildgo test を走らせていました。なので動作しないPull Requestは提出時点でわかるようになっています。

最初は https://tour.golang.org を丁寧にやっていれば事前課題は必要ないだろうと考えていたのですが、コードのスタイル周りはやはり自分でコードを書いてもらわないと身につかないのでやってもらってよかったです。

Go講義の設計

Treasureは例年Webアプリケーション開発のインターンとなっています。今回のGoの講義をする上で、何が最低限Webアプリケーション開発のためのベースの知識として必要だろうかと考えました。全体のスケジュールの兼ね合いでGoの講義には時間を使えても2日間だろうということで最終的には以下の内容に絞りました。

  • なぜGoなのか?
  • testing
  • net/http
  • encoding/json
  • テンプレート
  • Goとデータベース

スライドは http://go-talks.appspot.com/github.com/voyagegroup/talks/2016/treasure-go/intro.slide です。

ちなみに原案ではもっと言語の基礎の話をする予定でした。しかしそれをやっていてはもう1日ほしくなる・・ということで結果的には「Tour of Goをしっかりやってきてね」と伝えて、言語の基礎部分については個別に補足していくということにしました。Goの言語仕様は小さいので課題をやっているうちになれるだろうと考えました。

講義は基本的に演習を中心に組み立てています。人間は30分説明を聞いていると眠くなるいきものなのかもしれません・・。ということで講義資料にも一定のペースで演習がはいっています。講義中の演習では以下のものを実装してもらいました。

  • スタック(これはペアプログラミングで)
  • 並行に動作するスクレイパ
  • サンプルアプリケーションにコメント欄を追加しメモリに保存する
  • MySQLのCRUDをする小さなコマンドラインアプリケーションをつくる
  • サンプルアプリケーションにコメント欄を追加しDBに保存する
  • サンプルアプリケーションに機能を追加する

また講義のためにサンプルのアプリケーションを2つ用意しました。両方共 https://github.com/gin-gonic/gin をつかっています。

net/http をそのままつかって書こうとしていたのですが、結局ginを使いました。理由はHTMLテンプレートに値を埋め込むのとJSONを返すのでインタフェースが統一されているため、もともと html/template をつかっている実装をしていてもJSONを返すAPIに移行しやすいからです。

最初はgin-boilerplateだけしか用意していませんでした。事前課題の提出状況なりコメントをみていてあまりWebアプリケーション慣れしていなさそうな参加者も多かったので、ベーシックなHTMLを書くアプリケーションのサンプルがあったほうがいいなと考え、 suzuken/wiki の実装も追加しました。

サーバサイド実装はMVCっぽくなっていますが、単純にpackageを分割する以外のことはしていません。gin自体はルーター拡張 + 便利メソッド集なのであまり凝らずにかかれています。去年のPHPでの実装例では Pimple を利用したDIをいれていたりもしたのですが、今年はGoなので単純に structpackage をつかうのみにしました。アプリケーションの大きさによってはべたっと1ファイルに実装してもいいのですが、テスト容易性やチーム開発時の利便性を考えるとある程度package分割をしていったほうがやりやすいという話をしました。このあたりは一人での開発に慣れている参加者からは幾分面倒に感じられたようです。

より細かい内容や演習の中身についてはスライドをご覧いただければ幸いです。

中間課題とレビュー

中間課題をTreasureでは例年やっています。一通り小さなWebアプリケーションを自分でつくる、という課題です。課題は以下のとおり2コースあります。

  • TODOアプリをつくる
  • なんでもOK

約半分の参加者はTODOアプリですが、わりと好きなものをみんな作っていました。SlackのbotもあればECサイトっぽいものがあったり、Trello的なUIを実装してきたりと様々でした。中間課題の前にアイデアソン、Goの講義、HTTPの講義を終えているので、一通りのWebアプリケーションは作れるという設計です。とはいえこのときのアウトプットには講師一同驚くことになります。

中間課題はデモをしてもらいます。例年ではそれで終わりなのですが、今年はせっかく全力で書いてもらったコードなので個別にコードのレビューもして返すことにしました。とはいえ20人超のWebアプリケーションのコードをレビューするのはなかなか大変ではあったのですが・・個別のフィードバックほどクオリティを上げる方法もないかなと思いやっています。だいたい以下のようなフィードバックをしました。

  • DBの正規化をうまくつかおう
  • HTTP APIの名前付けをちゃんと考えよう
  • 使ってないコードは消しましょう
  • package分割をうまくつかってみましょう
  • 変数のスコープはなるべく小さくしましょう
  • structをうまくつかおう
  • エラーハンドリングは適当なヘルパやハンドラを書くといい
  • HTTPハンドラの中でカジュアルにpanicしないこと

特に変数のスコープについては半分以上の人にコメントしたような気がします。コードを読んでいる人は、変数が有効なスコープを意識して読みます。そうすると変数のスコープが広いと「あれ、今この変数はどういう状態なんだろう?」というのがわかりづらくなります。

特に対面フィードバックの際に「なぜこう書いたの?」と聞くと「動くから」という返答が多かったのも印象的でした。他の人にとって読みやすいコードを書きましょうという話をしたものの、やはりこれは複数人でコードを書き、コードをある程度の期間メンテナンスするということをしないとなかなか実感が得られないのかもしれないなと思うのでした。

またstructをうまくつかおうというのは関数の引数が長くなってしまっているケースが多い場合に話しました。こういうケースは引数のパラメータ化をしたいパターンとstructに状態を持たせたほうがよいパターンがあります。今回は後者のようにしたほうがよいケースがいくつかありました。なので関数ではなくメソッドをつかうことで問題をシンプルに解決できることもあるという話をしました。特に関数の名前がどうしても説明すると長くなってしまうようなものの場合、うまくstructを使えていないケースというのが多かったように思います。

エラーハンドリングについては特に他の言語に慣れている人にとっては面倒に感じられているケースが多いようにみえました。単純に以下のような簡単なヘルパを書くと楽になる例もあります。

func iferr(err error)

ひとによっては「 var ErrInvalid = errors.New() のような定義が増えて辛い」という話もありました。こういう場合はstructに対して Error() string を実装すると ハンドリングしやすくなる場合があります。パッケージレベルでのエラーを書く場合には var でグローバルに宣言してもよいですが、コンテキストによってエラーの内容を変えたいような場合には error がインタフェースであることをうまく利用するとハンドリングしやすくなります。以下のブログも参考にするといいでしょう。

Error handling and Go - The Go Blog

グレースフルにエラーをハンドリングしたい場合には、https://github.com/pkg/errors をつかうのもよいでしょう。

HTTPハンドラの中でカジュアルにpanicさせないというのも上のエラーハンドリングに繋がる話です。HTTPハンドラの中でpanicしてもginだとrecoverされてしまいますが、だからといって積極的にpanicさせるのは好ましくありません。panicは本当に例外的な状況でのみ使われるべきです。なので、ログ出力とエラーレスポンスを返すことを正しくやりましょうという話をしました。今回は認証周りだけmiddlewareを使う例を示したのですが、このあたりは net/http での実装を説明したほうがわかりやすかったかもしれません。上のブログでも紹介されていますが、以下のようなエラーハンドリング用のラッパーをハンドラとしてつかえるようにしておくことで、単純にerrorを返せばエラーレスポンスが返るようにしておくこともできます。

// https://blog.golang.org/error-handling-and-go より
func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    if err := fn(w, r); err != nil {
        http.Error(w, err.Error(), 500)
    }
}

こうすると例えばすべて500で返すのではなく、エラーの型に応じてエラーレスポンスを変えることもやりやすくなります。

講義全体の設計

今年は例年いれていないインフラとチーム開発の講義を追加しました。これは私達が普段働いている時もエンジニアとして知ってもらいたいと思っていることを感じてもらう何らかのきっかけになってもらえたら、と思い今年からとりいれることにしました。Treasureの後半戦は数人でチームを組んでアプリケーション開発をしてもらっています。例年「何をつくるか」で議論になってなかなか決まらないということがおきます。各チームの方針が決まるまで、なかなか進みだすことができません。それによって実装することがどんどん遅れていく、という問題がよく起きていました。

チーム開発というものを講義に入れようというのは今年の全体設計をする上で最初から考えていました。とはいえどういう講義にすべきかをなかなかイメージできませんでした。そこで @katzchang にお願いしてみようと考えました。インターンでのチーム開発と僕らが実際に仕事でやっているチーム開発というのは似ていて非なるものでもあります。とはいえ、そこから何かしらのエッセンスを伝えられたらよいだろうと考えました。この講義はある意味Treasureのエッセンスがつまっているとも言えるものでした。

インフラ及びCIの講義についても今年からはじめてのものです。これは @_nishigori@s_tajima_tech 後半のチーム開発でのサーバ環境を用意してもらうというのとセットで講義をお願いしました。この講義の狙いは以下のとおりです。

  • 私達が普段仕事でつかっているようなCIの環境をつかってもらうこと
  • 各チームごとに独立したdisposableな環境を用意し、自分たちでインフラ構成をいじってもらうこと
  • そしてインフラやCIもプログラマが問題解決に関われる領域であるということを知ってもらうこと

この講義は、私達が仕事で扱っているようなデプロイの整備された環境を提供して便利さを感じてもらうともに、インフラやCIといった部分にもソフトウェアエンジニアリングは活かすことができるというのを学生に疑似体験してもらう目的もありました。TreasureはWebアプリケーション開発のインターンであるというイメージが強いですから、参加者も「プログラムを書くことはWebアプリケーションをつくることである」と暗黙的に思っている人が多かったりします。ソフトウェアというのはいたるところにあって、実装するアプリケーションの選択肢もたくさんあります。Webアプリケーションを普段書いている人以外でも、プログラマの活動できる領域はもっとあるのだよ、ということを感じてもらえたらと思い、この講義をいれてもらいました。インフラ・CIの講義では実際にCIのスクリプトを自分で書いてもらう、ということもやってもらいました。

このあたりは参加者にあとから聞いてみると9割以上が難しいと感じていたので、継続してやってみると面白いかもと思っています。

まとめ

前半講義及び私の担当したGoの講義にしぼってTreasure2016のあとがき的なものを書いてみました。私自身、ソフトウェアエンジニアリングとの関わり方も毎年変わっていっています。事業環境もそうですし、よりよくアプリケーションを開発する方法というのも毎年多くのエンジニアが考え、実践し、改善されていきます。そのような背景を踏まえ、Treasure自体も毎年少しずつ形や内容を変えながら取り組んでいます。参加者のみなさんが少しでも多く現場のエンジニアから学び取り、今後のエンジニアリングに活かせてもらえたなら嬉しく思います。

社内向けニュース提供APIをS3+API Gatewayでサーバーレスにサクっと構築してみた

こんにちは!VOYAGE MARKETINGシステム本部の@gomachan46です。 普段はRuby on Railsを用いてPeXというポイント交換サイトの開発を主に行っています。

さて、PeXにはポイントを貯められるコンテンツがたくさんあります。その中のひとつ「YOUの気持ち聞かせてよ!みんなのNEWSウォッチ」は、ニュース記事を読んでリアクションするだけで、簡単にポイントが貯まるコンテンツです。

pex.jp

今回は、「みんなのNEWSウォッチ」のコンテンツストレージとしてはもちろん、APIとしても縁の下から支えてくれているS3の活用事例について書いていきたいと思います。

3行まとめ

  • S3をAPIとして実際に利用してみた
  • 負荷や管理周りなど考える事が減って良い
  • ファーストリリースの価値検証等のフェーズでは特に一考の価値あり

「みんなのNEWSウォッチ」の仕組み

はじめに「みんなのNEWSウォッチ」の仕組みを簡単に説明しようと思います。

登場人物

  • ニュース提供元
    • 「みんなのNEWSウォッチ」の大元となるニュース記事を提供してくれている社内外のメディア
  • ニュースAPI
    • ニュースを配信するための社内用のAPI
  • PeX
    • ニュースAPIを利用して「みんなのNEWSウォッチ」を提供する自社サイト

「みんなのNEWSウォッチ」でニュースを表示するまでの流れ

ニュース提供元が用意したニュース情報をPeXが利用するまでには、簡単に言うと以下のステップが必要となっています。

  1. ニュース提供元に取り込んで欲しいニュース情報をxml形式で記載してもらう
  2. クローラが定期的に取得する
  3. ニュース情報を蓄積する
  4. 蓄積されたニュース情報をニュースAPIで取得可能にする
  5. PeXからニュースAPIを利用して「みんなのNEWSウォッチ」を表示する

はじめに検討していたシステム

一番はじめにパッと思いついたのは以下の構成図のようなシステムでした。

f:id:shiro_goma:20160908110534p:plain

Ruby on Rails等を用いたオーソドックスなwebアプリケーション+RDBの構成ですね。

バッチ処理でニュース提供元から情報を取得し、RDBに取り込む。そしてフロントとしてAPIサーバを立てて要求に応じてRDBにアクセスしニュース情報を返す。

そんな感じのごくごく普通のアプリケーション構成を考えていました。

出来れば楽をしたい

当然ではありますが、出来れば楽をしたいものです。

上記のような一般的なアプリケーションを一から作ってもまぁ良いのですが、出来れば

  • 開発は少なくライトに済ませたい
    • 新規コンテンツリリースというところもありコストをかけずにまず価値を検証したい
  • 安定して稼働するために色々頑張りたくない
    • 冗長構成など
  • 負荷とか気にしたくない
    • 負荷状況に応じてスケールアップ/スケールアウトするなど
  • レスポンスタイムとか気にしたくない
    • API周りのパフォーマンスチューニング等
  • データ量とか気にしたくない
  • 安く済ませたい

というように色々と欲はあるので、どうにかもう少し良くできないか、というところを考えた結果アプローチとして取ったのがS3でした!

S3を活用してサーバーレスAPIを実現

実際に構築したシステム構成図は以下の通りです。

f:id:shiro_goma:20160908111031p:plain

今回は、上記ステップの

ニュース情報を蓄積する

蓄積されたニュース情報をニュースAPIで取得可能にする

という部分をS3に任せるようにしてなるべく楽が出来るようにしてみました。

ニュースAPIとしての部分は、

などを用いて比較的簡単に実現することが出来ます。

S3を上手く活用することでニュースAPI周りのサーバーが不要になり、サーバーレスなアーキテクチャに近づける事が出来ました!

S3を活用にすることでどう楽が出来たか

ニュースAPI周りをサーバーレスに出来たことで、色んな恩恵が受けられるようになりました。

開発は少なくライトに済ませたい

webアプリケーションを一からカチッと作るのではなく、ニュース記事を取り込むスクリプトを1つ用意して定期的に実行する程度で済むようになりました。

APIとして安定して稼働するために色々頑張りたくない

S3任せにできるので、基本的に気にしなくて良くなりました。

負荷とか気にしたくない

ここもS3任せにできるので、基本的に気にしなくて良くなりました。

データ量とか気にしたくない

ここもS3任せにできるので、基本的に気にしなくて良くなりました。

レスポンスタイムとか気にしたくない

ここもS3任せにできるので、基本的に気にしなくて良くなりました。

出来れば安く済ませたい

上記のように強いAPIを作るための頑張りどころがS3任せに出来るようになったので、サーバ代を大きくコストダウン出来ました。S3も相当安いのでほぼ気にならない程度です。

また、監視体制などもだいぶ手軽なもので良くなったので、管理コストなども下げる事が出来ました。

まとめ

いかがでしたでしょうか。

もちろん普通にwebアプリケーションを作るよりも機能面での幅の効き方は劣ってしまうのでケース・バイ・ケースな部分はありますが、余りあるメリットも持っているアプローチだと思います。

要件と照らしあわせてみて、採用出来た時のメリットなどが少しでも伝われば、と思って書かせて頂きました。

リクエストに応じた動的な挙動(例えば検索など)はやはり静的コンテンツを扱うS3では厳しいですが、要件によっては必要十分な機能を取り揃えた、非常に簡単で、かつ安定したAPIを提供することが出来ます。

また、仰々しい構成を取らなくても良くなるので、機能は限定的でも良い新規コンテンツなどのファーストリリース等、価値検証のフェーズでの投入は有効なアプローチなのではないかなと思っています。

引き出しの一つとして持っておいて損はないのではないでしょうか。

「VOYAGE GROUP内ではこんな風にS3をAPIとして実際に活用しているよ!」という一例としてのご紹介でしたが、「うちではこんな感じに使ってるよ!」などなどあれば是非教えていただけると嬉しいです。

ライトニングトークで社内コミュニケーションを活性化させる3つの仕掛け

みなさんこんにちは.新卒2年目 fluct DR 開発本部の @ism1000ch と申します. ふだん広告配信サーバを賢くするお仕事をしています. アドテク業界の規模感,スピード感に唸らされる毎日です.

またメイン業務外の活動として,社内のライトニングトークの運営チームに所属しています. VOYAGE GROUP では社員同士のコミュニケーションを促進するために様々な「仕掛け」を行っており,その一環として開催しているイベントです. 初回は2008年11月にはじまり,以降3ヶ月ごとに開催し,前回2016年8月で第34回になりました. 今では多いときで100名近くも参加するイベントになっており,全社での交流イベントとして継続的に運用できています.

そこで今回は,VOYAGE GROUP で取り組んでいる社内ライトニングトークの様子を紹介し,その運営で気をつけているコミュニケーションを活性化させるための3つの仕掛けについてお話しします.

f:id:ism1000ch:20160830105814j:plain

ライトニングトーク?

ライトニングトーク(LT)とは,自分の興味あることなどを5分間で発表する,ショートプレゼンテーションのことです. プレゼンテーションというと堅苦しくきこえてしまいますが,要は登壇者が好きなことを話せる表現の場,というイメージです. 最近では各種技術勉強会などにおいて開催されることも多いですね.

以下,実際に VOYAGE GROUP におけるのLTの様子をご紹介します.

技術系

業務で利用している技術や,最近の注目技術についてのトークです. 他事業部の方の話やノウハウの共有として,非常に参考になるものが多いです.

こちらは @at_grandpa さんによる crystal言語を触ってみたレポートの様子です. 「達人プログラマー」を読んで以降,「毎年1つ新しい言語を学ぶ」を実践されるなかで触れたのだそう.

f:id:ism1000ch:20160830103731p:plain

f:id:ism1000ch:20160830105356p:plain

f:id:ism1000ch:20160830103739p:plain

自己紹介系

最近のハマっているもの,などスピーカーの趣味全開のトークです. 新たにジョインしたメンバーの人となりを知るためのトーク,という意味合いが強いです. 顔を広めると言う意味で,毎年春は新卒紹介特集が組まれたりもしています. 様々なトークがありますが,あらためて社内には色々な人がいるな,と感じます.

こちらは @maki さんによる 買ってよかったものリスト紹介の様子です. 過去買ったものを紹介すると,その人のパーソナルが見えてきますよね.

f:id:ism1000ch:20160829211917p:plain

f:id:ism1000ch:20160830190825p:plain

f:id:ism1000ch:20160830190834p:plain

つくってみた系

業務で使っている技術には関係なく「ものづくりする身として,とにかく作ってみたぞ!」というアツい思いを感じるトークです. 自分のアイディアを形にしてみたぞ!どや!という作り手のアツい気持ちを感じるものが多いです.

こちらは 私 @ism1000ch による ライブ鑑賞支援システム作ってみた発表の様子です. ライブに出かけたときのサイリウムの光で会場が一体になる感覚に感動し, 自宅でブルーレイ見るときも再現したい!という思いであれこれしたお話です.

f:id:ism1000ch:20160830105042p:plain

f:id:ism1000ch:20160830105059p:plain

f:id:ism1000ch:20160830105134p:plain

このように,VOYAGE GROUP のLTでは 技術トピックに限らず様々なテーマについてトークをしています. LT中に反響の多かったトークの中には,下記のように本ブログの記事になっているものもあったりします.

コミュニケーションを活性化させる3つの仕掛け

VOYAGE GROUPのLTは,技術共有ではなく社員同士のコミュニケーションを第一の目的として運営しています. これは技術ノウハウの共有などはコミュニケーションが活性化されれば自然と行われるようになる,と考えているためです. そのおかげか,上記見てきたように毎回様々なトークが集まり盛り上がりを見せています.

ここでは,運用を続ける中で得られたコミュニケーションを活性化するための知見をいくつかご紹介していきます.

仕掛け1. テーマを絞らない

コミュニケーション促進をうたう以上,最も重要なのは広く様々なクルー(社員)の参加を促すことです. しかし発表を技術トピックに絞ってしまうと,「自分の技術力には自信ないな」「間違ったことをしゃべったら嫌だな」など,初めて発表する参加ハードルが上がってしまうことが想定されます. その結果,登壇者が固定クルーになってしまいがちです. こうなってしまうと,固定クルーでの身内イベントとなってしまい,社内全体の活性化にはつながりません.

そこでVOYAGE GROUPのLTでは,少しでも発表のハードルを下げるため,トークのテーマを絞らないようにしています. これにより新規の発表者でも参加しやすい環境を作っています. 「技術の共有」よりも「発表者を知る」ことに重きを置いている,ともいえますね.

仕掛け2. 発表者は依頼制

テーマを自由にすることで登壇者のハードルを下げることができますが,それでも「自分が話すのはちょっと...」ということは多々ありますよね. また登壇者が自分の知らない人ばかりだと今ひとつ楽しめない,ということもあります.

そんなクルーの参加を促すため,聴衆としても楽しめるよう,登壇者は運営から依頼する制度を取っています. ここで工夫している点が2点あります. ひとつは各チームから,ひろくアサインすること. これにより,なるべく登壇者の中に1,2人は知り合いが入るような形を目指しています. そしてもう一つは,新しくジョインしたクルーをアサインすること. 自己紹介を兼ねたLTをお願いして,早く会社に顔を知ってもらえるようにしています.

そして依頼枠(8~10人)とは別に飛び入り枠を設けており,自由に話したい人が話せる時間を用意しています. 最近では依頼枠よりも飛び入り枠の方が多くなることもあったりします. 中には前半のLTをみて「そういえばこんな話もあるぞ」という飛び込みLTをするクルーもいたり. このような状況を見ると,LTの文化が根付いているなと感じます.

仕掛け3. 会場全体で作り上げる

このようにしてクルーの参加を促しても,発表が一方的なものになってしまってはコミュニケーションになりません. 登壇者と聴衆が共に楽しめる仕掛けが求められます.

そこで我々は,登壇者の発表スライドとは別に,横に実況用のslackを流すスタイルでLTを行っています. 発表のなかで気になったワードがあったりすると目に見えてタイムラインが進み,盛り上がっている様子がわかります. 発表者としてもたまに実況チャンネルをのぞき,ちょっとした質問に答えるようなコミュニケーションが生まれています. 逆にコアな技術トピックのトークでは,皆トークに集中しているため流速が下がることもあり面白いです. またこのような中で,一方的に喋り散らすスタイルのLTもあり,それが一定の根強い人気をはくしていることも付記しておきます. 聴衆の反応の見える化により,トークスタイルのバリエーションが豊かになってきたな,と感じます.

f:id:ism1000ch:20160830211822p:plain

まとめ

VOYAGE GROUPにおけるライトニングトークの様子と,その取り組みの工夫についてご紹介させていただきました. いかがでしたでしょうか.

VOYAGE GROUPは「人を軸にした事業開発会社」をうたう会社です. だからこそ,クルー同士のコミュニケーションを活性化させるために様々な取り組みを行っています. その一環であるイベントの運営に関われるのはなかなか面白いことです. そしてなにより,このようなイベントを開いたときに「やろうぜ!」となれる仲間がいること自体がすごく恵まれたことだなぁと思います.

今回は運営上の工夫という形でご紹介させていただきましたが,このような取り組みから生まれたコミュニケーションが別の取り組みにつながるといいなと願いつつ,筆を置かせていただきます.

実際に効果を出せてきた! ECナビのレコメンデーションシステムのご紹介

DataScience

こんにちは、システム本部データプラットフォームグループ(DPG)エンジニアのEthan Huです。

今回はECナビ(http://ecnavi.jp/)で使用しているレコメンデーションシステムについてご紹介します。

ECナビでのレコメンデーションシステムの利用方法は、ユーザ1人1人に合わせた情報配信を行う事を目的としています。この様なシステムの導入時、社内でも話題に上がるのが「そもそもレコメンデーションシステムって効果あるの?」の声です。

また、レコメンデーションシステムは様々な手法(アルゴリズム)があり、正直どれが良いか検証しないとわからない所が大きいです。

今回は各アルゴリズムの評価、効果検証も考慮したレコメンデーションシステムの構成について紹介します。 

レコメンデーションアルゴリズムについて

その前に、レコメンデーションの手法を簡単に説明します。

レコメンデーションアルゴリズムとして「協調フィルタリング」があります。

協調フィルタリングには大きく分けて、メモリーベース(ユーザ行動履歴)とモデルベース(機械学習等の手法)に分けられ、メモリーベースはアイテムベース(アイテム間の類似度を元に推薦)とユーザベース(ユーザ間の類似度を元に推薦)に分類できます。

ECナビのレコメンドシステムは協調フィルタリングになります。 

f:id:EnzhaoHu:20160801153633j:plain

レコメンデーションシステム構成

ECナビのレコメンデーションシステムでは、メモリーベース・モデルベースの両方のアルゴリズムを使用しています。その為、検証したいアルゴリズムパターンが30個近くなります。

また、今回の構成では、複数のアルゴリズムを同時に検証でき、且つアルゴリズムの追加・更新をしやすい構成を取っています。

検証方法は複数のアルゴリズムを同時に検証できるようユーザのサンプリングを行い、サプリングユーザvs各アルゴリズムパターンでの多変量テストを実施してます。 

f:id:tokosa:20160816171122p:plain

上図がざっくりとしたシステム構成です(かなりざっくりですが)。レコメンドシステムはオンプレとクラウド(AWS)を使用したハイブリッドな構成です。

簡単に各処理の説明を書きます。

  • データクレンジング(前処理)
    ETLサーバでは、学習データの元になるデータの前処理を行ってます。データの前処理後、DWHにLoadします。

  • ユーザサンプリング
    各アルゴリズム検証用にユーザサンプリングを行います。サンプリングでは検証用のユーザが偏らないようにする為と、検証に必要なサンプルサイズを担保する為で、検証する際はとても重要なポイントです。

  • 学習データの作成
    学習データは様々な特徴データを作成する必要がある為、DWHで集計→作成しています。データはログデータがベースになるため、大規模な集計になります。

  • 推薦データの作成
    各アルゴリズムによって学習データから実際に推薦データを作成する方法は様々です。メモリーベースの推薦の場合、DWHで推薦データ処理を行なっていますが、モデルベースの場合AWS EMR(Apache Spark)で処理しています。

レコメンデーションのチューニング

レコメンデーションシステムの実装・リリースは完了しましたが、各モデルの精度をさらに向上させるためチューニング作業を行います。

チューニング作業の一般的な流れは以下のようになります。

  1. モデル実装
  2. 検証(2週間 ~ 1ケ月頃)
  3. 結果FB
  4. モデル最適化調整
  5. 上記 1 ~ 4 を繰り返す

まとめ

この記事では、ECナビで実装したレコメンドシステムについて、おおまかに構築した仕組みについてまとめしました。

実際に検証、利用しているモデルや、その特徴量、パラメータの値については、システムのキモとなるのでブログに載せることはできませんでしたが、ざっと10~30近くのモデルを随時検証・走らせています。

実際レコメンドでの効果は、CTRが1.8倍、CVRで4倍位出てます。

また、高速化を求めてSparkのチューニングも頑張っています。

この辺に興味のある方は、ツイッター(@tech_voyage)に気軽に連絡をください。#ajitingしましょう! そして、ECナビでは仲間を募集しています。 http://voyagegroup.com/crew/recruit/career/

Reference

http://www.kamishima.net/archive/recsysdoc.pdf
https://www.moresteam.com/toolbox/design-of-experiments.cfm

中高生のための夏休みプログラミング教室をお手伝いしてきました

みなさんこんにちは、fluct DR 開発本部の @kanufy です。

今年VOYAGE GROUPに新卒として入社し、fluct DR(Direct Reach)にて、広告配信機能のサーバサイドと日々戦ってます。

さて今回は事業・技術ネタではなく、VOYAGE GROUPとしての取り組みの一貫の話をしようと思います。 8/12, 14と東京工業大学CBECプログラムの一貫で行われた、中高生のための夏休みプログラミング教室に協賛として参加してきました。 その様子をお伝えしたいと思います。

伝えたいこと

  • 中高生ののびしろは無限大なので我々も頑張ろう
  • VOYAGE GROUPは良さそうなイベントには協賛としてスポンサーします!
    • ピザまたは🍣、会場提供も致します!

イベント概要

協賛のきっかけ

東工大の特任講師も務める『リーダブルコード』の訳者で有名な 角さん( @kdmsnr )がツイッターで呟いた一言


に弊社エンジニア @katzchang がやりましょう!と言ったのがはじまり。 弊社ではこのようにわりとカジュアルに協賛が決まったりします(社内で審査・議論は行われます)

1日目@東京工業大学

中高生35名が参加してくれたこのイベント。まずは仲良くなろうということで、角さんがアイスブレイクを行ってくださいました。

  • 学年別に一列になってみよう
  • なまえであいうえお順で一列になってみよう
  • 誕生日順で一列になってみよう etc.

f:id:kanufy:20160815143052j:plain:w300

初対面の子がほとんどなのでみんな最初は緊張してコミュニケーションが取りづらい様子でしたが、回を重ねるにつれ自然と会話が生まれていました。 そして今回驚いたのは女の子の参加者が多いこと!参加者の半数くらいは女の子だったのできっと日本の未来は女子エンジニアが増えている、ハズ?笑

さて、いよいよプログラミング! 今回の教室では、

  • Processing 3 でつくる横スクロールゲーム
  • JavaScript(+ HTML/CSS)でつくるメモアプリ

のどちらかを選んでもらい、東工大のtraPのメンバーがチューターとして付いて学ぶという内容でした。 講義資料は東工大traPのメンバーが作成したもので、初心者のために詳しく説明してあってとてもわかりやすい内容になっていました。

教室の様子

f:id:kanufy:20160815144525j:plain:w270 f:id:kanufy:20160815144538j:plain:w270

みんな集中してプログラミングに打ち込んでいました! お昼はお待ちかねのピザ!

f:id:kanufy:20160815144938j:plain:w300

参加者、保護者の方、東工大生、VOYAGE GROUPと総勢約80名でピザを食べて盛り上がりました。

午後もがっつりプログラミング!女の子の参加者が多いこともあり弊社の女子エンジニアの @kanufy@momoe_yoshinaga もサポートしました〜。 みんな自分の作りたいものが作れたかな?

イベントの最後にはスポンサーとしてスポンサートークの場を設けていただきました。 中高生のためにVOYAGE GROUPの簡単な紹介と、弊社の就活支援事業サポーターズの紹介を行いました。

f:id:kanufy:20160815145819j:plain:w270 f:id:kanufy:20160815145827j:plain:w270

最後に記念写真!みんな笑顔で楽しかったと言ってくれて大盛況でした。

f:id:kanufy:20160815150356j:plain:w500


2日目@VOYAGE GROUP

2日目は1日目やり残したことがある子や、もっとオリジナルにしたい!といった子のために VOYAGE GROUPオフィスにて補習を行いました。カンバン術をつかってTODO管理にもトライ。

f:id:kanufy:20160815151856j:plain:w300

弊社人事からはおやつとしてアイスの差し入れもありました。

f:id:kanufy:20160815172428j:plain:w270 f:id:kanufy:20160815151915j:plain:w270

そしてなんと、この補習の最後にある発表会に参加してくれた子には、角さんの声かけで各所からスポンサーしていただいた技術書が貰えるという豪華な特典付き!

f:id:kanufy:20160815151727j:plain:w400

弊社からもVG賞としてソロシアターを用意しました!実はこれ、弊社の事業のひとつ、LUCY ALTER DESIGN で制作されたものなのです!

www.makuake.com

発表会のようす

さていよいよ発表会!みんな堂々とした発表で会場を沸かせていました。

f:id:kanufy:20160815152332j:plain:w300 f:id:kanufy:20160815152338j:plain:w300

みんな技術書を熱心に選んでいました。今回は一人2冊も選ぶことができました!(残りは東工大traPのみなさんへ)

f:id:kanufy:20160815172352j:plain:w300

栄えあるVG賞を勝ち取ったのは、敵を攻撃できるProcessingのゲームを制作した女の子。オリジナリティを求めつつ、やりたいことをミニマムケースから実現した姿勢がよかったですね!おめでとうございます。ソロシアターお家で使ってくださいね〜(^^)

f:id:kanufy:20160815152427j:plain:w300

最後に

今回のように、VOYAGE GROUPではピザや🍣のスポンサーを行っていたり、無料で会議室を貸し出したりしています。 社内審査がありますが、積極的にスポンサーを行っていますので気になった方はぜひ @tech_voyage や弊社エンジニアまでお声掛けください。

http://livedoor.blogimg.jp/ecnavi_tech/imgs/5/9/596d1dab.png voyagegroup.com

初めての技術力評価会を終えたので感想を書いた

f:id:saxsir256:20160815151542j:plainこんにちは、fluct SSP開発本部の@saxsirです。

今年の4月に入社した新人ですが、職場ではgolangとかAWSとかを使って社内向けのプロダクトをゴリゴリと開発しています。

さて、VOYAGE GROUPでは人事評価制度の一つとして技術力評価会という相互評価の仕組みがあります。 これは年に2回ほど開催されており、直近半年くらいの仕事から何かテーマをピックアップし、別チームのエンジニア2名(評価者)に「私はこんなすごいことをやったんだよ、どやっ」とお話しながら自分の技術力を評価してもらうという場になります。

もちろん、新卒も例外なく技術力評価会を行います。

今回は初めての技術力評価会を終えて私が学んだこと、を社外の方向けに書こうと思います。(言うまでもなく、私は被評価者です)

※以下、「技術力評価会」を「評価会」と略して表記する場合があります

TL;DR

  • 「なぜやったのか」を説明するのは難しい
  • 素振りはいいぞ
  • 評価会とは評価制度であると同時に、成長する仕組みでもある

前提

技術力評価会は90分です。何が言いたいかと言うと、その場で自分がやったことを語り評価者とディスカッションするには全然時間が足りません。

そこで、事前に「評価会資料」というものを作成し、評価者にはそれを読んできてもらってから当日に臨むような流れになっています。

なにをやったのか/なぜやったのか/どうやってやったのか等、いくつかのポイントを含むように(なるべく既存のドキュメントを流用しながら)Markdownで書くようになっています。(テンプレートは一応ありますが、ポイントは抑えつつ各自が書きやすいように書きます)

「なぜやったのか」を説明するのは難しい

たとえば今回私は「クローラーのキューイングを外部キューにした」という内容で評価会をやりました。

評価会資料をつくるかー、と思って書き始めて思ったことは「やったこと」と「どうやってやったのか」はスラスラ書けるけど「なぜ」の部分はすごく難しいということでした。

  1. 「なぜ」外部キューにする必要があるのか?
  2. 無数にある方法の中で、あなたは「なぜ」方法Aを選んだのか?

ということを自分の言葉で説明できなければなりません。

今回の例で言うと、実は私が外部キューにする必要がある!と提案したわけではなく suzuken (@suzu_v) | Twitter が、これはやった方がいいという判断をして、それを私が実装したものです。

開発自体は、まぁドキュメントを調べたり試行錯誤していればできるでしょう。

しかし、その妥当性を他人に伝えるためには(仮に)組織的な決定事項や自分の判断ではないとしても「自分の言葉で」説明できなければなりません。

これが説明できないとちょっと残念だなぁ(なんであなたはそれをやっているの?)となってしまうので、まず大前提の部分でこれができていないエンジニアは一人前とは呼べない。というのが弊社のエンジニア文化なのだなぁと感じた評価会でした。

たとえば、私はこんな図をホワイトボードに書いて

f:id:saxsir256:20160815110637j:plain f:id:saxsir256:20160815110643j:plain

  • そもそもこういう構成になっていて
  • 今回ここを変更したんです
  • で、その理由は云々…(ここが大事)

みたいなことを話しました。(これの前にどういうシーンで使われてるかーとかも図に書いて説明した気がするけど画像がなかった…)

素振りは大事

ここまで読んでいただいて、そもそもクローラー…なんで?そもそも全体の仕組みが分からない…という感じになると思います。 社内でもだいたいそうです。ただ自分は詳しいので、なんとなくそのへんはいいかーという気になって進めてしまいがちです。

なので発表前に素振り、と呼ばれる「論点を明確にするための練習」みたいなことをやる人もいます。 私は初めての評価会ということもあって不安だったので、今回素振りをやりました。

これはとても良かったのでオススメです。

  • 自分では分かりやすいつもりでも、だいたい伝わらない
  • 素振りを見に行くと副次的に、別チームのエンジニアが何をしているのか知ることもできるので楽しい
  • 人の素振りを聞いていると質問力も鍛えられる(評価者目線でも見られる)

ので、結構楽しいです。 素振りは業界一般的にやられていることなのか分かりませんが、これはみんなやるといいんじゃないかなーと思います。

別に評価会とかがなくても別部署の同期に自分がやっていることを飲みながら説明する、とかでもいいと思います。

ちなみに素振り最中の走り書きメモがあったのでペタッと。(字が汚くてすみません…)

f:id:saxsir256:20160815111139p:plain

などなど…話しながら自分でも気づいたりするんですが、人に伝えるのは本当に大変だなぁと… あとは、そこは頑張ってたところだしアピールすれば?と言われると、あーなるほどなぁ(嬉しい)と思ったりもできて素振りは良いです。

評価会は評価されるだけじゃなくて成長する仕組み

これは新卒目線かもしれませんが、評価会という場を通じて普段の行動が変わりました。

たとえば、私は開発に入る前に手元のホワイトボードにシステム全体像ややるべき理由を書いてみて、自分に対して説明できるかどうか考えたりします。

これ自体は元からやったりしていたんですが、それだけだとその思考過程が残らないので、それはチケットなりIssueなりに残すべきです。

これは評価会後、意識的にやろうと変わりました。(元々まとめだけは書いていたが、過程も残すように意識し始めた)

やっておくと、将来の自分がありがたいというのもあるし、これは自分だけじゃなくて後から見る人はチケットなりIssueを見れば経緯がわかるので良いです。

たとえば方法Aも試したけど、こういう理由でダメだったからBになったんだなぁを知ることができるし、もしかしたら将来の時点では事業フェーズ的に方法Aの方が良い、となるかもしれません。

あとは、別に「評価会」と言う名称だけど評価者と議論する場なので、実は自分が知らなかった機能やサービスがあったり、経験的な知見からこの辺りのエラー処理はしっかり見た方がいいよ、とか学びの場にもなります。

基本的にチケットに残す文化なのですが、もうちょっと「過程」を含めてしっかり残すようにしよう…と思った評価会でした。

まとめ

やる前はgkbrしてたけど評価会楽しかった。

弊社のエンジニアの技術力の評価制度はこんな感じですが、みなさんどうなのだろう…

なにか気になるところとかあったらTwitter(https://twitter.com/saxsir256)なりで気軽にメンションください。

チームの読書会、4つの工夫

こんにちは、ECナビ事業本部エンジニアの yukimine です。

2ヶ月程前に デザインパターンをチームで学んで得たもの という記事がありましたがご覧いただけましたでしょうか。
Zucks Affiliate事業本部が、@t_wadaさんと読書会を行ってチームでの共通言語が増えたという記事です。

ECナビ事業本部でも、ベテランから新卒まで様々なエンジニアが、@t_wadaさんに設計・実装を相談をさせていただいたり、ペアプロをさせていただいたりしています。

本記事では、@t_wadaさんとECナビ事業本部の取り組みの一つ、 プログラマが知るべき97のこと 読書会 で取り入れている 4つの工夫 について、ご紹介させていただきます。

4つの工夫とは

  • 事前準備なし
  • アクションにつなげる
  • エンジニア席の横で開催
  • SlackのPublicチャンネルで議事録を残す

です。

デザインパターンをチームで学んで得たもの の二番煎じ感満載ではありますが、この読書会によってECナビ事業本部も チームの共通言語チーム共通のネクストアクション (読書会で学んだ内容をどう行動に落としこむか)を持つことができました。

プログラマが知るべき97のこと ってどんな本?という方はこちら
www.oreilly.co.jp

まずはじめに

増刷おめでとうございます!

(増刷時の修正項目には読書会の中で見つかったものも含まれているとか・・・)

「知見の共有」に読書会を使う

そもそもなぜ、 チームで読書会 をやっているのかをご紹介します。

ECナビ事業本部には様々なキャリアを持ったエンジニアが所属しています。
経験してきた業界(SI系やゲーム系など)や年数も様々です。

そういった中で、プログラマが知るべき97のこと という共通知識を付けることはもちろん、本の内容を題材にした各自の知見を共有することを大きな目的としています。

今回は プログラマが知るべき97のこと を選んだのは 監修者直々の解説を受けられる ことも理由の1つです。 プログラマが知るべき97のこと は@t_wadaさんが監修されています。
監修者直々の解説を受けられる稀有な機会ということで選びました。

読書会の流れ

読書会は次のような流れ(時間配分)で進めています。

  1. 読書タイム(10分)
  2. @t_wadaさんの解説(30分)
  3. 質問タイム、ECナビ事業本部のアクションを決める(20分)

14. コードレビュー を読んだときのSlackの会話を交えながらご紹介します。
(Slackは議事録も兼ねているため、文体が乱れている箇所もあるかと思いますが、ご了承ください。)

流れ1「読書タイム」

1回の読書会で読むエッセイは 2エッセイ です。
ECナビ事業本部のエンジニアが、任意の1エッセイをリクエストし、@t_wadaさんがそれにあった 合わせて読みたいエッセイ を選んでくださいます。
この時点で読書会の価値を感じますね。

Slackの様子
f:id:yuk4420:20160727000650p:plain

流れ2「@t_wadaさんの解説」

@t_wadaさんがエッセイについて、著者の背景や本に書かれていない事例、編集時のコラムを付け加えて解説してくださいます。

@t_wadaさんの解説(の議事録)
f:id:yuk4420:20160727000637p:plain

流れ3「質問タイム、ECナビ事業本部のアクションを決める」

エッセイに関する質問や、ECナビ事業本部としてどのような行動に落としこむかを話し合います。

ECナビ事業本部のアクション
f:id:yuk4420:20160727000702p:plain

1 は実際にGitHubのPullRequestで使われており、2 はGitHub Templateを採用する等、読書会から生まれた共通のアクションがECナビ事業本部には多数あります。

読書会の工夫とは?

冒頭で、読書会の工夫を紹介すると書きましたが、実は「読書会の流れ」の中で全て紹介済みです。
工夫といっても、気を張る必要なくルーチン化できるものばかりを取り入れているからです。

ここからは改めてその工夫を取り上げてみます。

工夫1「事前準備なし」

事前に予習する必要はありません。
その場で読んで、疑問に思った箇所はすぐ@t_wadaさんや周りのエンジニアに聞くことができます。

きのこ本の特徴として、1エッセイが見開き2ページで収まっているので、予習なしでも読書会が円滑に進みます。

@t_wadaさんからコメントをいただきました。

@t_wadaさんからのコメント

読書会に何回か参加できなくても、会に復帰しやすい本を選ぶと、読書会が継続しやすくなりますね。
読書会を継続するのが目的になってしまうと本末転倒ではあるけれども、多くの社内読書会は、仕事が忙しい日に参加できずに脱落していく人が多くなってしまうものなので、1,2回参加できなくとも普通に戻れる構造の本を選ぶと、特に読書会の文化がまだ根付いていないうちは続けやすくなるなと改めて感じました。
シーケンシャルに読んでいかなければならない本は、読書会というフォーマットにはあまり向かないのかなとも思います。

工夫2「エンジニア席の横で開催」

プログラマが知るべき97のこと 読書会の開催場所は、ECナビ事業本部エンジニア席の横で行われます。

これにより 作業で手が離せないエンジニアも耳で参加することができます

移動コスト(それくらい惜しむなよと言われそうですが、やっぱりない方がいいですよね)も削減できて楽です。

読書会開催の目的(なぜやっているのか)からも、 参加しやすい環境 は良いと思います。

実際の様子 f:id:yuk4420:20160726235805j:plain

工夫3「SlackのPublicチャンネルで議事録を残す」

先ほどからスクリーンショットを貼っていますが、 この読書会用に #97things というSlackのPublicチャンネルがあります。

使われ方は、 議事録 を始め、 @t_wadaさんがエッセイに関する参考URLを貼ってくださったり読書会に参加していないエンジニアから反応があったり 、様々です。

Slackのチャンネルで、この読書会があることを知って、参加するようになったエンジニアもいます。

工夫4「アクションに繋げる」

先ほど14番目のエッセイ、コードレビュー から生まれたアクションをSlackのスクリーンショットでご紹介しました。

同じように、いくつものアクションが、毎週この読書会から生まれ、実際に適用されたり、GitHub Issueにあげられたりしています。

私事ですが、一人で技術書を読んだり、読書会に参加したりした後、

「いい話だなー」

と思うことは多々あれど、実際に行動に落とし込むことは少ないです。
それどころか、翌月には、

「あの本の内容、なんだっけなー」

と思っている始末です。

チームにとって、もちろん個人にとっても よいこと をチームの共通アクションにできる。
ECナビ事業本部にとって、この読書会はそんな存在です。

参考までに、この読書会から生まれたアクションをいくつかご紹介します。

エッセイ名 アクション アクションの恩恵
06. リファクタリングの際に注意すべきこと 試行プログラミングを取り入れてみる 手軽に取り組める。実際にmergeされなくても、既存のシステムを深く知る機会になる。
10. ツールの選択は慎重に 自分たちが使っているライブラリのアップデート情報収集を自動化する 自分たちが使っているツールのバグによるリスクを回避できる。
14. コードレビュー レビュアーは、これから見ようと思っているPRに :eyes:(アイコン)をつける 「レビューされず放置されているわけじゃないよ」「見てるよ」をレビューイに手軽に伝えられる
64. プロのプログラマとは? 中間地点でのレビューポイント(設計時など)を作る 手戻りが少なくなる。余裕を持ってレビューができる(リリース前に設計の指摘を受けて焦らないなど)。
92. 顧客の言葉はそのまま受け取らない 顧客(ディレクターなども含む)の言葉を同じ抽象度で復唱するだけでなく、会話に「要するに」「具体的には」という言葉を盛り込み、抽象度の上げ下げも取り入れる 認識のずれを減らせる。

4つの工夫を取り入れた読書会の所感

手前味噌ですが、良い読書会だと思います。

知見の共有があり、それが議事録に残せていて、そこからアクションも生まれている、そんな読書会です。

チームで読書会を開催する際、なにか参考になれば幸いです。

はじめの一歩に、是非。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

  • 作者: 和田卓人,Kevlin Henney,夏目大
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2010/12/18
  • メディア: 単行本(ソフトカバー)
  • 購入: 58人 クリック: 2,107回
  • この商品を含むブログ (345件) を見る

質問など、はてぶコメントでお待ちしております。

P.S.

この読書会から生まれた1番のアクションは 議事録をとる です。

やりながら改善してきたこと をお伝えできれば嬉しいです。