AWS re:Invent 2016でハッカソンイベントに参加

![DSC_2979.JPG](https://qiita-image-store.s3.amazonaws.com/0/112407/67a524bc-4c6f-9ae7-dab7-945a8be09bb5.jpeg)
## はじめに
　先日、ラスベガスで開催されたAWS re:Invent 2016に始めて出張してきました。折角の機会ですから、ただ情報を集めてインプットしてくるだけではもったいない、何か傷跡を残してきたいと考え、Pre-Dayに開催されたハッカソンに参加してきました。世界中からエンジニアが集まるカンファレンスのハッカソンに参加してくるような腕に自信のあるメンバーの中でどこまでやれるか腕試しをしてきたいという思いからです。それに加えて、世界中のエンジニアとネットワーキングが出来れば面白いと考えていました。

## ハッカソンの内容
　ハッカソンでは4つのNPOから出された課題のうち、事前に1つを選んでおき、同じ課題を選んだメンバーでチームを組んで課題を満たすシステムを作るというものでした。僕は「Wildlife Conservation Society」の課題を選択しました。WCSの自然保護官が保護地区をパトロールしてきたレポートをビジュアル化して分析できるようにするというものです。1日かけてシステムを作り上げ、最後にプレゼンによって課題ごとの優秀賞を決めるというスキームは国内でのハッカソンでもよく見かけるフォーマットだと思います。

## チーム
　1チームが5名平均で、全部で50チームほどがありました。欧米系、インド系、アジア系と世界中から参加者が集まっているようでしたが、日本人と思しき人は見つけることができませんでした。ほかに数名いたかもしれませんが300名程度いたホールの中の1%くらいだったのではないでしょうか。ですのでアウェイ感満載でした。
　僕のチームは全部で6名でアメリカ人が3名、ドイツ人1名、インド人1名と僕という構成となっていました。しかし、インド人の彼は開始と同時に会社から呼び出されて居なくなってしまい、結果5名体制となりました。僕以外の4名はデータアナリストのドイツ人、ワシントンに勤めるモバイルエンジニア、ボストン出身のコンサルタントそして西海岸のベンチャーのエンジニアという人たちでした。
　チームでの役割は自然とそれぞれが得意な分野となりました。ベンチャーがマネジメントを担い、交通整理や進捗把握、タスクの優先度付けを行い、データアナリストがバックオフィスの機能、モバイルエンジニアがフロントの機能、僕がサーバーサイドのAPI実装、コンサルがプレゼンテーションの作成を行いました。

## 課題
　僕らのチームの課題は、各地から報告されてくる密猟者や野生動物の情報を地図上にマッピングし、モバイル端末で簡単に閲覧できるようにする、というものでした。主催者からは各地からの報告データがCSVで提供されます。このCSVデータはファイルではなく、Web APIを通じて提供されます。つまり、特定のURLをGETするとCSVデータが取得できるのです。このデータには緯度・経度・情報種別（密猟者か野生動物か）・概要が含まれています。ですので、取得したデータを、その緯度経度上に情報種別ごとのアイコンで地図表示させるという仕様となります。
　そして、これらの課題をサーバーレスアーキテクチャで実現するというのが今回のハッカソンの技術的な要件になります。ですので、EC2でサーバーを立ち上げて取得したデータをファイルで保存して、Apacheでサイトを作って公開するというのはNGとなります。

## 開発内容
　僕の担当はサーバーサイドですので、主催者側から提供されている複数の生データを取得し、業務上意味のあるデータに加工してフロント及びバックエンドに対して提供するというのがスコープとなりました。
　最初はパフォーマンスを意識してデータを取得して加工するLambda Functionを定期的に実行させてS3に保存し、フロントからの呼び出し時には加工されたデータを返すように設計しようと考えたのですが、実際の運用を考えると元データはリアルタイムに変更されてくることを考えると最新のデータが反映されるまでの時間差が気になり没にしました。次にRDSの導入を考えたのですが、これでは面白みにかけますし運用コストもかかりますので、折角のハッカソンだからもっとアグレッシブに行こうと没にしました。
　結果、データの取得・加工・提供までを1つのLambda Functionで実装し、API Gatewayで公開することとしました。この処理方式では1つのAPIで複数のデータを取得する必要があり、JSがネストしまくって非常に見づらいコードになりました。実務上、こんなコードは書けないだろうなと思いながら。

## スケジュール
　作業時間は9時から21時までの12時間、その中で僕のスコープは14本のAPIを作成することでした。最初は英語の要求事項を読み解くのに時間がかかり、1本目を作るのに2時間くらいかかりましたが、そこからはサクサクと実装をすすめられ、残り13本のAPIを2時間くらいで実装完了しました。9時に開発して13時には一通りの作業を終えられた計算です。ここでランチブレイクを入れ、その後はフロントエンドからの要求で、ちょこちょこデータ構造を直していく感じで、作業負荷はそれほど重いものではありませんでした。
　18時くらいにはメンバー全員開発はほぼ終えて、発表資料の作成に移っていきました。ここでネイティブの英語プレゼンができない僕は任務終了ですね。みんながどういった英語表現が好ましいかを議論していますが、「推を改め敲に作さんと欲する」と言われても、その違いを認識できませんから。みんなの議論を眺めつつ、他チームの準備をのぞいたりしていました。

## 結果
　22時から課題ごとに分かれて10チームによるプレゼンが始まりました。まずは課題ごとに優秀賞が表彰され、その中から最優秀賞が選ばれましたが、残念ながらアワードをとることはできませんでした。それでも、最後までとても楽しめたイベントでした。チームメンバー全体のスキルも高く、タイムマネジメントもしっかり出来ておりパフォーマンスを発揮するというのは、こういうことなんだなということが良くわかりました。逆にしっかり普通に作りすぎて「Wow!」となる機能を提供できなかった点が物足りなかったのかなという気づきを得ました。優秀賞を取ったチームはシステムとしての完成度は決して高いものではありませんでしたが、審査員が「Wow!」と思うな使い方の提案をしていました。

## 振り返り
　今回のハッカソンはAWSのイベントの一環でもあるので、若手エンジニアはほとんどおらず30代から40代が参加者の中心になっていました。なのでメンバーのスキルレベルは非常に高かったです。普段の仕事では、自分ひとりが全力で突き進むとチームとしてのバランスを欠いてしまって持続可能な組織とならないため、エンジニアの仕事はそこそこにコーディネートなんかを中心に働いているのですが、今回は自分が全力で突っ走っていてもチームのメンバーは、それを上回るスピードで動いているので、自分が開発のボトルネックにならないように一生懸命くらいつくのが精一杯でした。それでも何とか明らかに足を引っ張るということはなく、チームメンバーとして平均的な活躍はできたかな、という感触でした。
　ハッカソンに参加してみて、自分はプログラマとして海外でもやっていけそうだ、という自信を得られたのは非常に大きな収穫だったのと同時に、普段の受託開発とは異なるエンジニアファースト・コーディングファーストでの進め方は非常に楽しいものでした。日本でのアメリカでの開発技法がいろいろ導入されるものの、いまいち爆発的に普及しないのは、この標準的なエンジニアの能力差に由来するものではないかと思いました。これはアメリカ人のほうが優秀というわけではなく、40代でも現役のプログラマとして熟練したエンジニアが現場にたくさんいるのか、ある程度経験を積むとSEやPMとしてコードを書かなくなり、プログラムは若手が書くという日本のSIという年齢層の違いが大きな差別要因ではないかと思ったのです。
　一方で、英会話スキル不足は痛感しました。技術的な話や仕様の話はできるのですが、コーディングしながらの雑談には全くついていけません。英語は仕事をしながら自然に覚えていったので、日常会話の経験が全く足りないのです。それと同時に、非英語圏の人たちとの仕事で英語を覚えたので、ネイティブの表現がよくわかりません。たとえば、「理解する」を「make sense」と表現したりするのですね。「Understand」しか知りませんでした。ドイツ人とは会話が成立する一方で、東海岸のネイティブたちの英語はまったく聞き取れませんでした。チームメンバーには色々と気遣いやフォローをさせてしまったなぁと反省しきりです。とはいえ、普段から英語ネイティブの人たちとは、なかなか会話をする機会がないので、今回のような機会では遠慮せずに恥をかいていって成長するしかないかなというものでした。