エンジニアの鈴木 (a.k.a すずけん)です。
今回、AWS Summit TOKYO 2018 で開催された「 AWS Secure Code Contest - DevSecOps の実践を通じたチーム対抗静的コード解析バトル -」に参加し、🏆優勝🏆することができました！！
AWS Secure Code Contest 午前の部の優勝チーム、sushisecopsのヒーローインタビューです！得意分野を分担して見事優勝を勝ち取りました😆 優勝チームには一万円分のAmazonギフト券を差し上げました🎁
— アマゾンウェブサービス (@awscloud_jp) 2018年5月31日
午後の部もまだ参加可能。ご興味のある方は14時半迄に新高輪3階の天平まで！#AWSSummit #devops pic.twitter.com/7Zfgnc9V6x
この記事では、このイベントの振り返りと今回の学びについて共有したいと思います。
コンテストの内容については本記事では触れませんが、良い結果を残すためのヒントになるようなオープンな情報には触れています。
AWS Summitの楽しみ方のひとつとして、このようなイベントに参加してみようと思う人の参考になれば幸いです。
AWS Secure Code Contest
参加動機
まずはじめに参加動機からです。端的に２つ理由がありました。
- 自分の力を試したいという気持ち
- このタイミングでしか楽しめないことがしたい
一つづつ見ていきます。
前者に関しては、「他社のエンジニアとの共同作業において普段自分が行っていることが効果的なのかを確認したかった」という側面と、「自身の市場価値の確認」という意味がありました。
つまり、現在の自分の立ち位置を見つめ直す機会にしたいという目的です。
後者に関しては、AWS Summitの楽しみ方をひろげるという目的がありました。
昨今のイベントにおいてセッションが動画で公開されるのはデファクトになりつつありますし、自分がやるより遥かに早いタイミングと精度でブログにまとめてフィードバックしてくださる方もたくさんいます。
つまり、情報の取得を目的とした点においては、特別な理由(イベントの雰囲気を肌で感じるなど)がない限り、非同期で済む場合が多くあります。
逆に、ワークショップやハッカソンなどはその場その瞬間にしか存在していません。
AWS Summitをより楽しむ為に、非同期では味わえない経験をしたいという目的です。
事前準備
じゃあ、コンテストを最大限楽しむためにどのような準備をしたのかというと、「問題を予測する」、「やらないことを決める」の２つです。
コンテストという性質上、あわよくば優勝🍣したいという気持ちがありました。
「問題を予測する」為に最初にしたことは情報収集でした。といっても、やることは単純で今回のワークショップのページを確認しながら、関連しそうなワード（aws devsecops）でググっただけです。
すると、AWS のDevOps系のブログが引っかかりました。読んでみるとなんとなく今回のワークショップに近そうな雰囲気があります。きっとこんな感じで出題されそうだなと予想し、一旦ここで紹介されているgithubのサンプルコードを実際に動かしてみるところまでやっておきました。
次に、「やらないことを決める」です。募集要項やFAQを参考に、コンテストに必要そうなスキルと自分のスキルセットを照らし合わせて、やらないことを決めました。
具体的には、「pythonについて勉強はしない」と決めました。
募集要項に、「簡単な Python のコーディング能力が必要」とありますが、正直どれくらい必要なのかわかりません。ですが、FAQには「基本的なプログラミング言語の理解と Python の理解があれば問題ございません。」と書いてあります。
自分はpythonが書けません。
求められるのものとしては、単純なコードなら他の言語の知識を生かしてなんとなく読み込める状態であればいいと理解し、pythonについて時間を割くことはしないと決めました。
当日
当日、弊社エンジニアの磯野も参加するとのことで、待ち合わせをし一緒に会場に向かいます。
会場で受付を済ませ席に案内されると、すでに2名着席しており「あれ？なんか見たことがあるぞ」と言われました。
その方は以前 re:Invent 2017のGameDayで別チームで参加されており、re:Partyでお話させていただいたことがあり、すでに面識がありました。
昨年参加したGame Dayについてのレポート: AWS re:Invent 2017 参加レポート Day 2 - LIFULL Creators Blog
また、もうひとりの方も、弊社と合同勉強会を開いたこともあり、一昨年のre:Inventにも行かれたとのことで共通項がありました。
もうこの時点で、かなりフレンドリーな状態😊です。
同じ経験をしているという共通項がコミュニケーションを円滑にしてくれました。
コミュニケーションは日々も大事ですが、このような瞬発力をもとめられるワークショップでは更に重要だと考えているので、お互いの意見がしっかり言い合えるような雰囲気が醸成されたチームにジョインできたのは、運がよかったなと思います。
お互いについて自己紹介したあとは、コンテストが始まるまで終始リラックスした雰囲気で過ごせました。
主催者側からチーム名を決めてくださいとのアナウンスがあり、「何がいいっすかねー？」「"hogefuga"でどうっすか？」「www」「エンジニアといったら🍣か🍕ですよね？」「中トロはどうですか？」「寿司食いたいなぁー」「じゃあ、今日のイベントにちなんで、SushiSecOpsはどうですか？」みたいな流れで、ふわっとチーム名が決まりました。
いよいよ、コンテストが始まります。
主催者からコンテストの趣旨説明があり情報公開がされました。各自およびチームで設定が始まります。
このとき自分たちのチームでまず行ったのは、課題に対するアプローチ方法の検討です。
はじめは、課題一つに対して、ひとり張り付こうみたいな流れがあったのですが、「１課題に対して２人１組で取り組んだほうがハマった時に対処が早くなると思うので、そうしたい」と自分から提案し採用されました。これは、昨年のGame Dayで得た教訓を有効に活用できた瞬間でした。
あとはもう全力で問題文を読み込み、目の前の課題に集中するのみです。
時折、運営の方が「いまトップですよ！」など励ましの言葉を掛けてくれました。正直スコアに関しては気にしている余裕がないほど課題の量と理解に悩まされました。
終盤、他チームに追い抜かれたものの、最後の最後でわずか0.3ポイント差で接戦を制しました。
この画像はコンテスト終了後、運営の方に掲載許可を頂いています
あっという間の2時間でした。
振り返り
勝敗が全てとは思いませんが、優勝できたことは素直にうれしい😊です。
ですが、結果を出せたのは良いチームメンバーに恵まれたなど、運の要素も強かったと思います。
チームメンバー各自の能力が高いに越したことがないのですが、それはマストではないと思います。 チームとして自分の価値を最大化するために、どのような貢献ができるのかを考え実行できることが大事なのではないでしょうか。
また、限られた時間でのアウトプットを出すために、GameDayでの経験がとても役に立ったと実感できたのは良い経験になりました。
まとめ
今回の経験から、個人的な学びもたくさんありました。その学びの中から強いて２つほど挙げてまとめとします。
1. 勝敗は運の要素も強いが、準備をしておいて損はない
勝負ごとに運の要素はありますが、勝率に関しては自分で工夫できる余地は意外とあるのかなと思います。 事前にできることを「自分でしっかりと考えて準備しておく」という、すごくシンプルなことがなかなかできなかったりするものです。 自戒を込めて、次に生かしたいと思います。
2. 打席に立つことの重要性
当たり前ですが、バッターボックスに立たないと、アウトになることすらできません。
このようなコンテストに参加することは、普段得ることができないエンジニアとしての経験として良いものになると思います。 また、GameDayという打席に立ったからこそ、今回の結果につなげることができたので、点が線につながったと感じることができました。
これからも、積極的に打席に立って楽しんで行きたいと思います。
最後に、一緒のチームで戦ってくれた、田中さん・福井さん・磯野さん、および運営の方々へ リスペクトを込めて、ありがとうございました！！！
