AWSチームの鹿倉です。

2017年10月2日にアマゾンが「Alexa」、「Amazon Echo」を年内に日本で展開のすることを発表しました。そして、我々ハンズラボも日本上陸に合わせて東急ハンズのAlexaスキルの開発に早期に取り組みました。このブログでは今回初めてAlexaスキルの開発をどのように行ったか、またその時出てきた課題などについて共有したいと思います。

Alexaスキル開発の流れ

 

まず、開発〜ローンチまでの主な流れは以下の通りです。

1. Amazonの開発者コンソールからAlexaスキルを新規追加する。
2. デバイス（Amazon Echo）をセットアップする。（開発者コンソールにシュミレーターが用意されているので、ひとまずデバイスは無くても開発は進められます）
3. プログラムを開発する（AWS LambdaもしくはHTTPSベースのAPI）。
4. テスト（実機でテスト＆開発者コンソールのシュミレーターでテスト）
5. Amazonに申請

 

また、今回はローンチまでの期間が短かったので、以下の機能に絞りました。

• 各店舗のイベント情報の紹介
• おすすめ商品の紹介
• 店舗では売っていないネット限定商品の紹介

 

まずはプロトタイプを作成し、ブラッシュアップしていくスタイルで開発を進めました。プロトタイプはエンジニア1人で2〜3週間ほどで完成させたのですが、実際に試してみると色々問題が浮かび上がってきました。弊社でも引き続き改善を行っているところではありますが、いくつか分かっている問題、改善ポイントについてご紹介いたします。

ユーザーの発話パターンは多種多様であること

 

当たり前の話ですが、ユーザがなんと発話するのかにはいろいろなパターンがあります。例えば、イベント情報を聞く時、「渋谷のイベントを教えて」、「今週のイベントは何？」など場所を知りたいケースや時期を知りたいケースなど、まだ単純に「イベント」とだけ言うユーザーもいます。

Alexaではあらかじめユーザが発話しそうな発話例（サンプル発話）を用意しておく必要があります。「○○のイベントを教えて」と言われたらイベント情報を伝える処理をするというような登録が必要になるのです。社内メンバーにもいろいろ試してもらいながら、できるだけ様々なパターンでも応答できるようにサンプル発話を考えました。また、開発時のサンプルは社内メンバーに限られていたので今後運用フェーズで実際にユーザはどのようにAlexaと会話しているのかデータを収集して改善していくポイントだと考えています。

今あるコンテンツが音声発話した時に聞きづらい

 

今回、イベント情報やおすすめ商品を紹介する機能を作成しましたが、機能としては単純にWebで掲載している情報（文章）をAlexaに読ませているだけです。

これがなんとも、、、音声ではかなり聞きづらいし、長い・・・開発する前からなんとなく想定していたのですが、Alexaが勝手に学習してめちゃくちゃいい感じに発話してくれるのではないかと淡い期待をして開発を進めました。たしかにAlexaはすごくて開発中もどんどん発話がいい感じになっていきます。が、さすがに商品名や商品説明とかは聞きづらいです。（特にハンズはマニアックな商品なども含まれるからかもしれませんが）

今後、この機能を充実させるならコンテンツもWebとは別で音声用のコンテンツを用意すべきだと感じました。また、アメリカではディスプレイ付きのデバイスなどもあるらしいので、デバイスが充実してきたら、ディスプレイ＆音声で紹介するような機能を提供できれば便利かもしれません。

Webで検索するよりも、会話形式であった方が便利な機能をユーザに提供した方が良い

 

上記で述べた通り、商品紹介など一方的に会話を進める機能は音声インターフェースよりも、今のところWebの方が良いと感じています。

なので、まずは、音声会話で便利な機能を充実させるべきという方向で改善を進めようと考えています。例えば、ハンズであれば、営業時間や在庫確認、お店までの行き方などのお問い合わせをお電話で受けることがあります。このようなお問い合わせ業務をAlexaで提供することで、よりスピーディにお客様の要求に答えれるようにすること。また従業員の方々の負担を軽減することで、トータルでお客様により良いサービスと提供できるのではないかと考えています。

最後に

ハンズラボでは東急ハンズのAlexaスキルを開発しておりますが、合わせて他の事業社様のAlexaスキル開発についても今後承ります。ご興味のある方は是非弊社にお問い合わせください。

弊社へのお問い合わせはコチラ

こんにちは。百木田です。
CI、回してますか？

CodePipelineで実行するステージの進行状況を手軽に見たいと思い、Slackに流れるようにしたので共有します。

ポイントとしては、CodePipelineからLambda functionを呼ぶのではなく、CloudWatchイベントでCodePipelineステージのステータスの変化を検知してLambda functionを呼び出します。

今回はできるだけシンプルにするために、すでにCodePipelineは作成済みの想定で、すべてのステージにおけるSUCCEEDEDとFAILEDのステータスを通知します。なのでCodePipelineに変更は必要ありません。
また、Slack Botを作成しトークンを発行して使っていますがIncomming Webhookでも同じようなことはできるかと思います。

Serverless Frameworkを使ってCloudWatchイベントの設定と、slackに通知するためのLambda functionをデプロイします。

環境

ディレクトリ構成

デプロイ

コードは記事の下の方に書いときます。上記のディレクトリ構成のように配置したらデプロイします。

デプロイできたらCodePipelineを動かしてみます。そうするとslackにこのような通知が来るかと思います。

いつの実行結果なのかをトレースできるようにCodePipelineの実行IDの前半7桁を表示しています。この辺はお好きにカスタマイズしてみてください。

まとめ

CloudWatchイベントの検知がリアルタイムじゃないので、CodePipelineの進行と通知にラグがあったり、前のステージの実行完了と次のステージの実行開始の通知が前後することなどもありますが、実行結果がわかればいいかなくらいの感じなので気にしないことにしてます。

ありがとうございました。

以下、コードたち

status_notification.py

serverless.env.yml

serverless.yml

※ detailのセクションを消すと、すべてのステータスが検知対象になります。

こんにちは！ブログに登場しすぎなPOSチームの渡邉です。

暑さも和らぎ、夏嫌いの私にとってはとても嬉しい季節になりました。
ちょっと寒すぎますけどね。寒気さん本気出しすぎ。

さて、今回は2017年度の新卒を代表して、
私渡邉が新卒研修で行われた仮想プロジェクトについて書きますよ！

研修をメインで担当した三井田の記事（こちらとこちら）も是非ご覧ください。

三井田の記事では「研修した側」の視点で書かれているので、
私は「研修された側」の視点からお届けします。

ちなみに研修自体は6月いっぱいで終了しています。大遅刻です。すみません。
今は新卒各々配属先のチームで頑張っています！

 

仮想プロジェクトの概要

 

ざっくりいうと、
〜ユーザーの要求に応えられるエンジニア、チームで円滑に開発を進められるエンジニアになるための「仮想プロジェクト」演習〜
です。（雑すぎ？）

AWSチームのリーダーである鹿倉を仮想のお客様とし、新卒社員5名のみで仮想プロジェクトを遂行します。

ハンズラボの新卒研修の定番です。（まだ２年しか経っていませんが）
来年も、再来年も、お題や形態は変化したとしても、この仮想プロジェクト自体は続いて行くと思います。

 

お題

 

今年の新卒研修のお題は、「botを作ってくれ」というものでした。
鹿倉が提示した機能は以下の5つです。

 

要件1〜4：AWSの情報を取得して通知するBot

1. 特定のタグが付いているインスタンスの一覧を抽出
2. RI(リザーブドインスタンス)の適用率を抽出
3. 特定のセキュリティグループに入っていないインスタンスがないかチェック
4. 特定のインスタンスの情報（OS,インスタンスタイプなど）を入力すると、日本円でオンデマンド、1年RI、3年RIの金額が出力（価格テーブルは常に最新）

 

要件5：東急ハンズのGoogleカレンダーにスケジュール登録したら、自動でハンズラボのGoogleカレンダーにも登録してほしい

弊社社員は、ハンズラボと親会社の東急ハンズ2つのGoogleアカウントを所有しています。そのため、片方のGoogleカレンダーにしか予定を登録してないと、ほかの人がもう片方のアカウントのGoogleカレンダーだけを見て、予定が空いていると勘違いしてしまうことがあります。そこで、東急ハンズのGoogleカレンダーに予定を登録したら自動でハンズラボのGoogleカレンダーにも同じ予定を登録できるようにしてほしい、という要件を挙げました。
（三井田の記事から引用）

要件1〜4について、フロント側の制限は特にありませんでしたが、私たちは最終的にSlackを採用しました。
弊社ではチャットツールとしてSlackを使っていることが大きな理由です。

 

 

完成品

 

いきなりですが、完成品をご紹介します。

 

 

要件1〜4

各要件ごとに1つのSlackBotを作成し、それぞれのbotを以下のように命名しました。

• 特定のタグが付いているインスタンスの一覧を抽出：たぐたん
• RI(リザーブドインスタンス)の適用率を抽出：りざたん
• 特定のセキュリティグループに入っていないインスタンスがないかチェック：せきゅたん
• 特定のインスタンスの情報（OS,インスタンスタイプなど）を入力すると、日本円でオンデマンド、1年RI、3年RIの金額が出力（価格テーブルは常に最新）：まねたん

 

4人合わせて「Labottan」です！！！！！（らぼったん　と読みます）

この名前は、弊社公式キャラクターである「らぼたん」をもじりました。
らぼたん↓

 

らぼたんは本来緑色の髪の毛ですが
Labottanのために色違いを用意して、各botのアイコンに使用しました。

また、Labottanは全てAWS Lambda、AWS APIGateway、Slackで構成されています。

まずはbotを動かすリージョンを設定します。

「set」をトリガーに、4つのbotが参照するリージョンを設定できます。

 

 

要件1　たぐたん

 

たぐたんの機能は3つあります。

1. 「tag」と投稿すると、アカウント内のEC2に登録されているタグのキー一覧を表示
   
   たぐたんの目的は指定したキーバリューを持つインスタンス情報を見ることなので、
   まずは絞り込みのためにキーの一覧を取得します。

2. 「tag <key>」と投稿すると、指定されたキーのバリューを一覧で表示（重複無し）
   
   キーを絞り込んだら、続いてバリューの一覧を取得します。

3. 「tag <key> <value>」と投稿すると、指定されたキーバリューを持つEC2インスタンスの情報を一覧表示
   
   キーバリューを指定したことで、目的のインスタンス情報を得ることができます。

トリガーはtagのみではなく、「Tag」「たg」も対応しています。

構成図は以下です。

例えば、同僚の田中さんが管理しているインスタンス情報を確認したいとします。

・あれ？オーナー管理って、「Owner」だっけ？「Name」だっけ？→「Tag」と投稿してキー一覧を取得
・そうだ、Ownerだった。あれ、名前は大文字だっけ？フルネーム？→「Tag Owner」と投稿してバリュー一覧を取得
・そうだ、Tanakaでいいんだ。インスタンス情報は〜→「Tag Owner Tanaka」と投稿して情報を見る

といった使い方ができます。

 

 

要件2 りざたん

 

りざたんの機能は以下です。

・「riu」と投稿すると、購入済みのリザーブドインスタンスの適用率を表示する

RIUは「reserved instance utilization」の略です。
トリガーはriuのみではなく、「RIU」「りう」も対応しています。

構成図は以下です。

「リザーブドインスタンスめっちゃ買ってるけど、ほんとに全部使ってるよね？大丈夫よね？」という時に
パパッと確認する、という使い方ができます。

 

 

要件3　せきゅたん

 

せきゅたんの機能は3つあります。

1. 「sg」と投稿すると、セキュリティグループ一覧が表示される
   
   こちらもたぐたんと似ており、セキュリティグループ一覧が表示されます。

2. 「sg <セキュリティグループ名>」と投稿すると、指定したセキュリティグループの空いているポート番号と、適用されていないインスタンスを表示する
   セキュリティグループが許可するトラフィックを、インバウンド・アウトバウンドそれぞれ確認できます。また、そのセキュリティグループが適用されていないインスタンス一覧を取得できます。

1. 「sg port <ポート番号>」と投稿すると、指定したポートが空いているセキュリティグループとインスタンス一覧を表示する
   0番ポートが空いているセキュリティグループと、そのセキュリティグループが適用されているインスタンス情報を表示します。

トリガーはsgのみではなく、「SG」も対応しています。

構成図は以下です。

セキュリティグループの見直しをするときは1、
必須のセキュリティグループなのに数がおかしい！どの子だ入ってないのは！というときは2。
8080ポートは開いてちゃいけないから、確認しとこう、というときは3、といった使い方ができます。

 

 

要件4 まねたん

 

まねたんの機能は以下です。

・「price <OSタイプ> <インスタンスタイプ>」と投稿すると、支払い方法ごとに現在の料金が日本円で表示される

構成図は以下です。

客先などで現在の利用料金をサクッと知りたいときに非常に便利！
リアルタイムでAWS使用料（USドル）と日本円のレートを取得し、計算しています。

 

 

要件5

 

東急ハンズのカレンダーとハンズラボのカレンダーで予定を共有・統合したいという要件です。

こちらはAWSではなくgas（Google Apps Script）を使用しました。

構成図は以下です。

15分ごとに発火するトリガーにより、
東急ハンズのGoogleカレンダーのイベントを取得し
そのイベントに招待されている人のハンズラボアカウントをゲストに追加する、という仕組みです。

ハンズラボのカレンダーにも東急ハンズの予定が登録されるようになったので
スケジュールのすれ違いも起こりにくくなった・・・かな？

 

振り返り

 

さて、ここからは振り返りです。
プロジェクトの最終発表会が終わって、打ち上げでどんちゃん騒ぎした翌日に
みんなで（死んだ顔で）ふりかえりをしました。

それを思い出しながら、ひとりふりかえり会をしてみます。

いちばん「成長した」部分

→「5つの要件で1つのプロジェクトだ」という意識が芽生えた
新卒は5名、要件も5個、じゃあひとり1要件でいいよね！ってスタートしたんですが、
自分のタスクでいっぱいいっぱいになって、チームメイトの遅れに「我関せず」な顔をしている時期がありました。
お客様は個人個人に依頼しているわけではなく、会社・チームに依頼しているのに、
「自分の進捗は大丈夫だしいいや」「遅れてるけど自分でなんとかするしかない」って思考になっていました。
最終的には各要件ごとではなく作業内容ごと（テスト班・プレゼン資料作成班）に分かれて作業ができるようになり、
「5つの要件で1つのプロジェクトだ」という連帯感が生まれました。

 

あまり「成長できなかった」部分

→「根回し」
プレゼンや報告会のスケジューリングはギリギリなことが多く、予定を抑えたら抑えっぱなしでした。
事前になんの話をするのか、どんな相談をしたいのかを伝えておくことは最後まであまりできていませんでした。

例として、お客様役の鹿倉にテスト用アカウントを発行してほしいと伝える時に
事前に伝えていたら打ち合わせでアカウントを受け取ることができたかもしれませんが、
打ち合わせでいきなり伝えるので「作ったら連絡します」となり、スケジュールが遅れ・・・

なんてことが最後まで続いてしまいました。

 

いちばん悩んだこと

→コミュニケーション不足による足並みのズレ
（これは私しか思ってないかもしれないんですが）
ひとり1要件でやってしまうと、他の要件には関与しなくていい！という気持ちが生まれて
序盤は特にチームなのに個人制作のようになってしまっていました。
もちろん、制作物やスケジュールに影響も出ますし、何よりも居心地の悪さに悩みました。
夜な夜な三井田にチャットでどうしよう〜助けて〜〜〜（号泣）って散々したなあ・・・今もしてるわ・・・（遠い目
今となってはあの時悩んでよかったと思ってます。今後に活かせそうな話をたくさん聞けました。

 

 

まとめ

 

笑って悩んでぶつかって笑って、とても研修らしい研修になったと新卒ながら思います。

今年の新卒の配属先はバラバラですが、それぞれが先輩に紛れながら頑張れているのは、
「仮想プロジェクトを乗り越えられた」という経験と自信の賜物です。

来年、再来年の仮想プロジェクトはどうなるのかな？
半年後に迎える後輩たちに負けないように、これからも頑張ります！

 

（最終発表会翌日、三井田からのお祝いの花が！さながら卒業式！ありがとうございました！）

iOSエンジニアとしてひーこら言いながらも、現場にも慣れて心に余裕が生まれてきた9月上旬。
7月に新卒研修を終えてPOSチームに配属されてから、HandsPOSの業務をしっちゃかめっちゃかしつつもなんとかこなしていた。
いきなり業務に携わり、大きな不安を抱えながらもそれなりに頑張ってきた。

しかし、配属から2ヶ月経ったその時、それは突然にやってきたのだ。

OJT。

業務をこなしつつ、それに追加して少しずつ課題を解いていく。
基礎的な技術力や知識量の向上が主な目的だ。

そしてトレーナーは言った。
「渡邉さん、来月中にAWSのSAAとってね。」

SAAとは、AWS初心者がまず取得を目指す資格である。

「大したことない課題じゃん」そう思われる方もいるだろう。
確かに、この資格は難しすぎるわけではなく、ほどほどの難易度だ（と個人的には思っている）。

しかし、わたしは目の前が暗くなっていくのを感じた。
これから始まる勉強は、恐ろしく辛く苦しいものになると、わかったからである。

ここで、私渡邉の略歴を書いておく。
普通科の高校を卒業後、情報系の専門学校でiOSとAndroidでのモバイルアプリ開発を専門に2年間学んだ。
2017年4月にハンズラボに入社。現在社内最年少の21歳である。

専門学校で習ったとはいえ、クライアント側以外の知識は皆無である。
具体的に言うなら、HTTPってなんかの規格でしょ？ポートってなんか穴空いてるんでしょ？くらいのものだ。

正直に言おう。わたしはサーバーサイドやインフラを食わず嫌いしていた。
学生時代も学ぶ機会はあったが、なんとなく避けてきていた。
ついに逃げられなくなった。だから絶望したのである。

しかし、ここで逃げては問題を先延ばしにするだけだとわかっていた。進展はない。
絶望すると同時に、絶対に成し遂げてみせる、そう思っていたのもまた事実なのである。

こうして、私とSAAの戦いは幕を開けた。

chapter1. vs 参考書1周目

AWS SAAの参考書といえば、これが有名だろう。

例にもれず、私もこれをまずは購入した。
持ち運びしやすいサイズ、適度に薄く書き込みしやすい紙、軽さ、全てにおいて最高の参考書だ。

意を決して開いてみる。
リージョンとAZの概念はすんなり理解できた。IAMというものがあるのか。ふーん。
IDフェデレーション。フェデレーションってなんだ。
ほう、そんな認証方法があるのか。ふーん。

1周目なんて、わからない言葉を都度調べて書き込んで、
書かれている日本語を私が理解できる言語に噛み砕くだけだ。作業ゲー以外のなにものでもない。
眠くなる。寝たい。やめたい。しかし、やらなければならない。
今辛いのは、今まで奴らから逃げてきたツケだ。

自分に鞭を打ちつつ、まずは1周、読破した。

chapter2. vs 模擬試験

ところで、私のOJTトレーナーはAWS Solutions Architect Professionalを取得している。
「10日でAWSのアソシエイト資格3つ制覇した話」の人見だ。

今読んでも10日間で全部取ったのは尊敬する。尊敬しすぎてちょっと引く。

それはさておき、その人見が「模擬は早めに受けろ」と繰り返し言ってきた。
なぜかと聞くと、「その方がいいから」というなんとも微妙な答え。
しかしプロを取得した人見がいうのだから間違いはないだろう、と、参考書を1周終えてすぐに模擬試験を受けた。

この問題は本で読んだからわかる。これは書いてあった気がするが自信がない。なんだこれは。初めて見る言葉だ。
結果は、50%。不合格ラインだった。当たり前だ。

しかし、早めに受けたこの模擬試験には2つの大きな利点があった。
一つは、実際の試験の形式がわかったこと。もう一つはどこまで理解を深めれば合格できそうかのイメージがつかめたことだ。
早めに目標ラインが定まったのは、その後の勉強の効率を高めることにつながった。

chapter3. vs 参考書2周目

模擬試験を終え、参考書に戻った。
参考書に書いてあるどの部分を頭に叩き込めばいいのかがわかった今、
インフラやサーバーを食わず嫌いしていた私はいなくなっていた。

インフラやサーバーに興味がでたわけではない。
好きになったわけでもない。
AWS SAAという壁を打ち破りたい。ただの意地だった。

この部分は本番で出題されそうだ。
これに関してはすっかり抜けているな。しっかり抑えよう。
参考書の文だとわかりにくいから、自分がわかりやすい文章に変えてしまおう。

参考書の余白への書き込みはどんどん増えていった。
汚れていく参考書。消えていく余白。蛍光ペンのインクがなくなる。
買いに行く時間が惜しい。ボールペンで勉強を続行する。
結局、最後まで蛍光ペンを買い足すことはなかった。

参考書には各章の最後に確認問題があるのだが、
その解答を覚えてしまうほどやりこんだ時、一抹の不安がよぎった。
試験3日前のことである。

chapter4. vs WEB問題集で学習しよう

試験3日前。参考書はほぼ暗記してしまっていた。参考書の問題集の正答率は100%だった。
これなら合格できそうだ、と一息ついたときに、一つの記憶が蘇った。

模擬試験に、参考書ではみたことがなかった言葉が使われていたのを思い出したのである。

つまり、参考書で出題範囲を全てカバーしているわけではないということだ。
当たり前の話なのだが、AWS SAAを倒すと息巻いている私にとって、
この「カバーしきれない範囲」は恐怖対象へと変わったのだ。

手元にある問題は暗記してしまっている。勉強にはならない。
どこかに初めて見る問題はないのか。本に載っていないような問題はないのか。

そこでたどりついたのがこのサイトだった。

フリープランに登録して、まずは解いてみる。
ボロボロだ。今までなんども解いたから問題と答えを暗記していただけであって、
根本の理解をしているわけではない。

まずい。

試験前は3連休だったのだが、ある意味本気の勉強はここからはじまった、とも言えるのかもしれない。

chapter5. vs 参考書3周目

2周目の参考書は、確認問題を重視していた。
一発で正解すれば理解している、という指標としてわかりやすいからだ。
確かに、それはわかりやすい。しかし、なんども繰り返し解くのには向かない。

そこで私は、今一度各章の解説部分を読み直すという行動に出た。
想像以上に時間がかかる。しかし、根本を理解するにはもうこれしかないのである。

読み終えたあと、確認問題（今更だが選択形式だ）の正答と誤答それぞれの理由をつぶやきながら確認問題を解いた。
ここまでやっても詰まる問題はある。
正答がわかっても、理由が説明できないのなら、そこからの応用はない。

解説に詰まったら、戻る。これを繰り返す。作業ゲー以外のなにものでもない。
しかし、辞めたいとは思わなかった。意地が勝った瞬間である。意地の塊と化していた。
元来、わたしは両親がお手上げするほど意地っ張りなのだ。

chapter6. vs BlackBelt

AWS試験の教材として、BlackBeltを参考にしている人は多いのではないだろうか。
実際に使われている様子や、細かい仕様などの解説が動画で見られるのは大変ありがたい。

しかし、私はBlackBeltはほぼ視聴しなかった。
具体的には、最後の最後まで不安だったAuto Scailingのオンデマンドセミナーのみを視聴した。

理由はとてもシンプルだ。時間的制約。

勉強期間は1ヶ月。その間SAAの勉強のみをしていたわけではなく、
仕事や家事、やることは盛りだくさんだ。参考書を開く時間すらない日も少なくなかった。

BlackBeltはわかりやすいが、どうしても時間が取られる。
対時間コストというのだろうか。時間的コスパが低い。
そう判断し、参考書や模擬の復習を優先した。

chapter7. 試験本番

会場は池袋。目の前のカフェに10:00に入店。試験は13:00からだ。
時間が近づくにつれ、緊張感が高まっていく。

高校受験の時、緊張しなかったことを思い出した。
あの時は「これ以上やれることはない、これで落ちたら仕方がない」と思っていたからだろう。
後悔というのは、やり残したことへの執着だ。
やり残したことがなければ後悔もない。

しかし、緊張していた。
当日のわたしは、自分の勉強方法を悔いていた。
なぜ参考書にこだわり続けたのか。なぜ、もっと他の問題をこなさなかったのか。
今考えても仕方がない。しかし、過去の自分を悔いていた。

やれるだけのことをやろうと心を決めて、試験会場に入った。
その頃には、穏やかな心境になっていた。

勉強方法への後悔はあるが、受験とは違って再度受け直すこともできる。
受かったら万々歳。落ちても勉強方法への反省点という収穫がある。
なにも怖いことはないと、それまでの1ヶ月をぶつけてきた。

合格

結果は、合格だった。
カメラで監視されていることも忘れて、渾身のガッツポーズをした。

頰がゆるみ、凝り固まっていた肩がフッと軽くなる。
飛んでいきそうな足を抑えて会場を後にする。
いつもは人の多さにげんなりする池袋の街が輝いて見える。

会社に戻る電車の中で、結果通知のメールをなんども読み返す。
思いついて、頰をつねってみる。痛い。夢じゃない。
ここまで嬉しかったことはいつ以来だろう。

資格は、成功したときの形がわかりやすい。合否があるからだ。
白か黒か、0か1か、はっきりと結果がでてしまう。諸刃の剣にもなるのだ。

だからこそ面白い。そう思えた。
努力が実るのは気持ちがいい。
実るかわからない努力がつらいなら、何が何でも実らせてやるという意地と根性を持てばいいのかもしれない。

勉強方法に後悔がある状態での合格は、ラッキーだったと思っている。
次の試験勉強は、後悔がない状態まで持っていくのが課題だ。

（サクセスストーリー風にお届けしました。いつもはもっと適当に生きています。）

写真：仮想プロジェクト最終発表会を終え、安堵の表情の2017年新卒のみなさん

こんにちは、エンジニアの三井田です。
先月投稿した「ハンズラボ新卒研修2017 (1/2) 〜カリキュラム編〜」をお読みいただいたみなさま、ありがとうございました。多くのコメントもいただき、大変励みになりました。

少し間があいてしまいましたが、今回は「ハンズラボ新卒研修2017 (2/2) 〜実際にやってみた編〜」と題しまして、4月〜6月の3ヶ月間に渡って行われた2017年度新卒研修の、より具体的な研修方針・内容や、研修を通して考えたことなどをまとめたいと思います。

4月 〜入社、社内技術研修〜

4月の研修は、IT経験者、未経験者関係なく全員一緒に社内で技術研修を行いました。
ビジネスマナーなどを学ぶ外部研修などもあったため、4月に社内で研修ができた期間は実質12日程度でした。

4月に身につけてほしいこと(前編からの再掲)

前編からの再掲になりますが、4月の社内技術研修で身につけてほしかったことは下記です。

• 開発するために必要な基礎的なプログラミング技術
• 自分で考えてコードを書く力
• 分からないところが出てきたときに、それを主体的に解決する力

 

到達度の測り方

各々が上記の目標をどれくらい達成できたかについては、下記の方法で測りました。

中間到達度の測り方

• 配布した問題集の問題が解けているか
  単純に解いた問題の数を確認するのと同時に、エラーが出た時に何が問題なのかを把握し、正しく動作するようにプログラムを修正できているかも確認しました

最終到達度の測り方

• 入社初日に解いてもらったプログラミングテストがJavaScriptで解けるかどうか
  入社初日に解いてもらったプログラミングテストを4月末にもう一度解いてもらうことで、4月の最終到達度を測りました

4月の研修方針と心がけたこと

単純な知識や技術の学習は、基本個人で

単なる知識や技術の学習は、集団よりも個人のペースで行った方が効率が良いと考えたので、各自でeラーニングや書籍を見ながら、分からないところを質問しに来てもらうスタイルにしました。(もちろん、つまづきやすかったり、書籍などを見ても理解しづらいと思ったトピックについては、別途講義を行いました。)

みんなで集まる時間は、インタラクティブに

反対に、みんなで集まる時間は、コードレビューなど参加者全員でコミュニケーションを取れる内容にしました。講義をするにしても、一方的にならないようにできるだけ新卒のみなさんと対話しながら進めるようにしました。

新卒のみなさんの精神的サポートをする

自分も去年の4月は入社したばかりで何かと不安な時期だったので、5人全員の考えていることを把握できるように毎日夕礼を行い、そこで各々の日報に対するフィードバックや、不安に感じていることに対してできる限りのサポートをしました。

4月に学習したこと・行ったこと

今回は技術研修に焦点を当てた話をするため、6日間の外部ビシネス研修やハンズラボの説明など、技術面以外の話についての説明は割愛させていただきます。(昨年度の話になりますが、社内で行った技術面以外の研修については、弊社チーフエンジニア田部井がこちらの記事でまとめております)

4月に社内で行った、正味12日間の技術研修の内容は以下です。

• キックオフ
• JavaScript基礎の学習
• HTML5/CSS3の学習[追加]
• セレクタ・DOM操作演習
• Node.jsの学習
• データベースの学習
• 社内LT会
• コードレビュー会
• その他(マークダウンの書き方、UNIX研修(外部)など)

 

キックオフ

新卒研修概要説明

前編でご紹介した研修目標や、研修スケジュールなどについて研修初日に説明しました。

プログラミングテスト

その後、新卒のみなさんの技術力が未知数だったため、1時間程のプログラミングのテストを、紙にプログラムを書いてもらう形式で実施しました。回答言語は自由にしたので、新卒のみなさんが選んだ言語は、C、Java、PHP、Swiftなどさまざまでした。そしてこのテストの結果を踏まえて、事前につくったカリキュラムを再度調整しました。

環境構築(Atom、Emmet、EditorConfig、Node.js(Nodebrew経由)、ESLintなど)

今回の研修で使うプログラミング環境の構築や、入れておくと便利なプラグインなどをインストールしてもらいました。最終的にNode.jsでJavaScriptファイルを実行して、前編の最初に出てきたアスキーアートが出たら終了でしたが、全員無事に完走することができました。

JavaScript基礎の学習

eラーニング＆問題集を解く

基本的な文法などは、Schooの動画などを見て各自で学習してもらいました。学習後は、事前に配布したJavaScriptの基礎的な問題が30問程書かれた問題集を解いてもらうことで、学んだ知識の定着を図りました。
もちろん、個人で学習していると疑問点や不明点がたくさん出てくるため、その場合は躊躇せずに私やほかの人に積極的に聞くように促し、適宜フォローを行いました。

社内講義

JavaScriptでプログラムを書く上で知っておいた方が良いことや、つまづきやすい部分に関しては、別途社内で講義を行いました。講義では以下のトピックなどを取り上げました。

• レキシカル環境
• 実行コンテキスト
• this
• プロトタイプ
• ES6新機能(const・let、アロー関数など)

社内講義後には、eラーニングの時と同じくその講義に関する確認問題を配布し、理解できていない箇所がないかの確認を行いました。

HTML5/CSS3の学習[追加]

当初のカリキュラムには含まれていませんでしたが、HTML・CSSを書いたことがない、習ったけどよく分からない人が大半であったため、急きょHTML・CSSの学習を追加しました。

HTML5/CSS3の初心者向けの書籍を一通りやってもらい、基本的なhtmlタグやcssプロパティを覚えてもらいました。また、効率的なマークアップの仕方(Emmetを使った方法など)については、ライブコーディングも交えながらの講義を行うことで補足しました。そして、一通り学習が終わった後は、数種類のサンプルWebサイトを自力でマークアップする練習をしてもらいました。

セレクタ・DOM操作演習

これに関しては「習うより慣れよ」なので、書籍を見ながらひたすら演習を積んでもらいました。

Node.jsの学習

4月の後半は、Webアプリケーションの仕組みを説明してから、実際にExpressを使ってローカルサーバを立ててもらい、サーバサイドの演習を行いました。また、WebSocketについても学習し、同じように通信の仕組みなどを学んだ後、実際にSocket.IOを使ってWebSocketサーバーを実装し、動作確認を行いました。

データベースの学習(DynamoDB)

弊社は、アプリケーションのデータストアにS3やDynamoDBが使われることが非常に多いという特徴があります。そのため、RDB、SQLについて学ぶことはエンジニアとして非常に重要なことだというのは百も承知なのですが、学校でRDBについて学習した人も多かったため、今回は研修期間の都合上、AWSのフルマネージドNoSQLデータベースサービスであるAmazon DynamoDBの学習と演習をメインで行いました。

弊社におけるDynamoDBの活用事例についてご興味のある方は、下記の記事をご参照ください
東急ハンズメッセのピークにお客様の信頼を取り戻した高コスト効率の Amazon DynamoDB

社内LT会

新卒のみなさんにはこれからの長いエンジニア人生、知識や技術をただ学習するだけでなく、学んだことや経験したことを積極的に社内外にアウトプットしていってほしいと考えたので、その第一歩目として、好きなテーマのSchooの動画を1つ見てもらって、それについてのLTを社内で行ってもらいました。ITと関係ないトピックでも大歓迎だったため、新卒のみなさんそれぞれの個性が溢れる大変面白いプレゼンになっていました(もちろん、内容もきちんとまとまっていました)。

コードレビュー会

また、4月に解いたプログラミングの問題について、同期・講師とより良い解法や書き方について議論する、コードレビュー会も複数回行いました。みなさんただ批判するのではなく、お互いをリスペクトし合いながら上手にディスカッションができていたのでとても良かったです。配属後、プルリクエストを送る時などに、ここでの議論の経験が生かされれば幸いです。

その他

マークダウンの書き方に慣れていない人が多かったので、研修中の日報は、昨年度同様マークダウンで書いてもらいました。また、コマンドラインでの操作に不慣れな人もいたため、基本的なUNIXコマンドなどについて学べる外部研修を受講したりもしました。

4月最後のプログラミングテスト

結論から言うと、驚くほど成長していました。大半はJavaScriptを書いたこともなかったため、どうなることかと思いましたが、全員JavaScriptで問題にきちんと回答することができていたので、上記の研修カリキュラムは一定の効果があったのではないかと思います。特に、研修担当者に質問したり、コードレビュー会でコードをレビューしたりされたりすることで、自分のコードを客観的に見ることができるようになったと感じました。やはり自分以外の人と、どうしたら現状のコードがより良くなるかを議論することは、技術力を向上させる上で非常に大切なことだと改めて感じました。

5、6月 〜仮想プロジェクト〜

5、6月は、AWSの外部研修に参加した後、前編でお話した通り、社内で仮想プロジェクト演習を行いました。仮想プロジェクトについては前編をご参照ください。

仮想プロジェクトで身につけてほしいこと(前編からの再掲)

• 実際に開発をする上で必要となる力
• チームで円滑に開発を進める方法・マインド
• スケジュール遅延による影響と対策を知る

 

到達度の測り方

中間到達度の測り方

「設計」「実装(フェーズ1)」「実装(フェーズ2)」「テスト」の各フェーズの最後に報告会を設けました。そこでプロジェクトの進捗などを把握するとともに、報告会の内容、プロジェクトの進め方についてのフィードバックを主にAWSチームから行いました。

最終到達度の測り方

新卒研修最終日に行う「仮想プロジェクト最終発表会」で、最終成果物や仮想プロジェクトの振り返りについて発表してもらうことにしました。最終発表会ではAWSチーム以外の弊社社員にも発表を聴いてもらい、仮想プロジェクト全体のフィードバックなどをより多くの人から行ってもらいました。

仮想プロジェクトお題 〜Botをつくってください〜

5月初旬の仮想プロジェクトキックオフ時に、仮想お客様であるAWSチームリーダーの鹿倉から、以下の5つの要件をお題として提示しました。

要件1〜4：AWSの情報を取得して通知するBot

1. 特定のタグが付いているインスタンスの一覧を抽出
2. RI(リザーブドインスタンス)の適用率を抽出
3. 特定のセキュリティグループに入っていないインスタンスがないかチェック
4. 特定のインスタンスの情報（OS,インスタンスタイプなど）を入力すると、日本円でオンデマンド、1年RI、3年RIの金額が出力（価格テーブルは常に最新）

クライアント側は特に制約はなく、既存のサービスと連携する形でも、自分たちでフロント側をつくっても良いという条件でしたが、新卒のみなさんは最終的にSlackに上記の通知を行うことに決定しました。

要件5：東急ハンズのGoogleカレンダーにスケジュール登録したら、自動でハンズラボのGoogleカレンダーにも登録してほしい

弊社社員は、ハンズラボと親会社の東急ハンズ2つのGoogleアカウントを所有しています。そのため、片方のGoogleカレンダーにしか予定を登録してないと、ほかの人がもう片方のアカウントのGoogleカレンダーだけを見て、予定が空いていると勘違いしてしまうことがあります。そこで、東急ハンズのGoogleカレンダーに予定を登録したら自動でハンズラボのGoogleカレンダーにも同じ予定を登録できるようにしてほしい、という要件を挙げました。

これらの要件を提示した理由

新人研修ということで多少の配慮はしましたが、基本的にAWSチーム(特にリーダーの鹿倉)がほしいものを依頼しました。去年仮想プロジェクトで私たちが仮想プロジェクトで開発した蔵書管理システムは、研修終了後社内で使われる機会が徐々に減っていき今や忘れ去られているので(笑)、今年度は、「仮想」ではあるものの、研修終了後も実際に使うことのできるシステムを依頼しました。また、技術的な観点からも、要件1〜4に関しては、配属後何度となく使うであろうAWS SDKの使い方に慣れることができる、要件5に関しては、(おそらくGoogle App Scriptを使えばできそうだったので、)4月に習ったJavaScriptの知識を活用することができると考え、これらの要件に最終決定しました。

開発に関して

プロジェクトのフェーズを、「設計」「実装(フェーズ1)」「実装(フェーズ2)」「テスト」に分けました。報告会も含めた各フェーズの日数は下記です(AWS研修2日間とAWS Summit3日間はプロジェクト期間から除外)。

• 設計 :8日
• 実装 :15日 (フェーズ1 ：7日、フェーズ2 ：8日)
• テスト : 7日

IT未経験者に関して

今年度はIT未経験者がおり、4月の研修である程度プログラムは書けるようにはなったものの、ある問題に対して自分でアルゴリズムを考え、それをコードに落とし込む力は、5月以降も引き続き別途鍛えていく必要があると考えました。そこで今年度のIT未経験者に対しては、「時短勤務」という設定で、10:00(始業時刻)〜15:00は仮想プロジェクトへの参加、15:00〜19:00(終業時刻)は個別に上記の力を鍛える補習を行うことに決めました。そして、仮想プロジェクトキックオフで新卒のみなさんに、プロジェクト期間中は、IT未経験者の時短勤務を踏まえた上での話し合い・タスクの分担をするように伝えました。

5月の研修方針と心がけたこと

失敗から学んでもらう

前編の繰り返しになりますが、失敗する前に注意されるよりも、失敗して自ら学んだ方が印象に残りますし、学びは大きいと考えます。仮想プロジェクトではできるだけ先回りして教えることを避け、失敗してからその経験を自分たちで振り返り、そこから学んで次の行動につなげていけるように指導することにしました。

コミュニケーションの取り方を試行錯誤してもらう

コミュニケーションスキルが配属後も非常に重要なスキルになることや、みなさんほぼ初めてのチーム開発ということで、外部の人(お客様)、内部の人(チームメンバーなど)とのコミュニケーションに問題はなかったか、改善できるところはないかを、毎日の夕礼や、各フェーズの最後の報告会で特に細かく指摘することにしました。

技術面でも成長してもらう

とは言え新卒のみなさんはエンジニアなので、コミュニケーションスキルだけではなく、技術面でも成長してほしいと考えました。今年度は私がプロジェクトの開発サイクルの回し方やソースコードレベルまで見て、不十分だと思う点については、補足講義やコードレビューなどの形でサポートすることにしました。

新卒のみなさんの精神的サポート&エンジニアとしてのキャリアパスについて一緒に考える

開発期間が短く、チーム開発に不慣れなため、仮想プロジェクトは新卒のみなさんにとってかなりハードなものになることが予想されます(実体験)。特に精神的な疲れが増してくることが予想されるので、引き続き毎日の夕礼や日々のコミュニケーションで、新卒のみなさんの精神的サポートを行うことを心がけました。

また、去年の自分の反省として、仮想プロジェクト期間中は目先の開発に集中しすぎてしまい、研修後の配属のことや、自分のエンジニアとしてのキャリアパスについて研修中に考える余裕がほとんどありませんでした。今年度は、仮想プロジェクトのことから少し離れて研修後の配属や自身のキャリアパスなどについて一緒に考える時間を、研修中のどこかで設けようと考えました。

仮想プロジェクト期間中に行ったこと

仮想プロジェクト中は基本的に会のセッティングなども新卒のみなさんで主体的に行ってもらいました。仮想プロジェクト中に研修担当側が行ったことも、基本的には新卒のみなさんが行ったことに対するフィードバックだったため、行ったことを箇条書きにしづらいのですが、抜粋すると以下のことを行いました。

• 補足講座
• 面談
• 夕礼での進捗報告に対するフィードバック
• 各フェーズごとの報告会・その後の反省会でのフィードバック
• 最終発表会での最終フィードバック

 

補足講座

4月で学んでいないが開発をする上で必要な知識については、補足講座という形で私から新卒のみなさんに講義を行いました。例えば、以下のような講義です。

git講座

開発フェーズに入った頃、gitを使ったバージョン管理の経験がない人が多くいたこともあり、それぞれが思い思いにAWSコンソール上でLambda関数のコードを書いていました。そこで、gitに関する補足講座を行い、gitの基本的な使い方や、リモートリポジトリをGithub上に作成し、ブランチの切り方、マージの仕方、コンフリクトが生じた時の対応などの演習を行いました。

非同期処理、Promise講座

AWS SDKを用いたAWSリソース情報の取得は基本非同期で行われるため、開発が進むにつれ、非同期処理の扱いに苦労している様子が見受けられました。そこで、非同期処理について改めて学ぶ補足講座を行い、その後、実際に新卒のみなさんが書いているコードのどこに問題があるのか、なぜ想定通りの動きをしないのかを一緒に考えました。また、最後に新卒のみなさんのコードを、Promiseを使って一緒に書き換えたりもしました。

面談

研修期間中、複数回面談を行いました。去年は配属先の希望を聞く面談を研修終盤に1回実施しただけでしたが、今年は去年より面談回数を増やし、より手厚く新卒のみなさんのサポートを行いました。また、私が企画した面談(私と新卒のみなさん×5回)では、業務内外での悩みを聞いたり、研修後の配属や自身のキャリアパスなどについて一緒に考えたりしました。

新卒のみなさんとの1対1での面談の実施に際しては、ヤフー様で行われている「1on1ミーティング」を大変参考にさせていただきました。
下記書籍にて非常に貴重な知見を共有していただき、誠にありがとうございます。

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

夕礼での進捗報告に対するフィードバック

4月に引き続き、夕礼は毎日行いました。そこでは、当日のプロジェクトの進捗報告をしてもらうと同時に、チームレベル、個人レベルでの懸念点や疑問点を話してもらい、それに対して研修担当の私からフィードバックをしました。また、プロジェクトの進捗報告は夕礼後にAWSチーム内で共有を行い、プロジェクトの進め方で指摘すべき点はないか、きちんとチームで開発ができているかを他のメンバーと逐一確認していました。

各フェーズごとの報告会・その後の反省会でのフィードバック

最終発表会でのフィードバック

これらに関しては事前に研修担当側が何かを用意するということはなく、新卒のみなさんが自分たちで考えて実行したことに対して、研修担当側から気になる点や、こうしたらもっと良くなる点などをフィードバックしました。各フェーズごとの報告会・反省会には、普段の夕礼と違い、AWSチームリーダーの鹿倉や、開発経験・マネジメント経験の豊富なエンジニア田部井、平井も参加して、より多くの指摘・アドバイスを新卒のみなさんに行いました。その甲斐もあり、6月末の最終発表では、社長の長谷川も絶賛するほどの素晴らしい成果物とプレゼンを披露することができていました。仮想プロジェクトの成果物などについては、新卒の誰かが後日書いてくれるかもしれません。

研修を終えて

最後に、研修を終えて感じたことを書き連ねたいと思います。

研修で学んだこと

地味でも毎日コツコツサポートを続ける重要性

今回の研修で4月、5〜6月にそれぞれ設定していた研修目標は、大方達成することができました。4月の最後のプログラミングテストを見た時は、入社時とは別人のような成長を感じましたし、仮想プロジェクトの最終発表でも、初期とは比べものにならないほど落ち着いて、伝えるべきことを簡潔に伝えることができていました。これは、もちろん一番は新卒のみなさん一人一人の努力の賜物なのですが、事前に入念に準備したカリキュラムや、毎日の夕礼や報告会で細かくフィードバックを行ったことも、その成長の一助となったのではないかと思います。地味でも毎日コツコツ、研修を受けているみなさんのサポートを続けることが、研修を成功させるためにはとても大切なことだと感じました。

来年に向けての反省点

4月の研修が、単に技術を学ぶだけにとどまってしまった

4月の社内技術研修についてですが、書籍や動画を見て学ぶことが多かったこともあり、単なる技術の学習にとどまってしまったな、と感じています。せっかく社内で研修を行っているので、実際に弊社で開発しているアプリがどのように業務に役に立っているのかを、東急ハンズの事例を紹介したりしながら学べる機会などがあれば、もっと良かったのではないかと思いました。実際に開発したシステムを使っているユーザーをイメージできた方が、仮想プロジェクトに対する士気もさらに高まったかもしれません。来年度はAWSチームだけでなく、東急ハンズのシステムを内製しているチームなどとも連携しながら、今年度よりさらに良い研修にしていきたいと思います。

研修担当、1人はつらいよ

今回チーム内のリソースの問題もあり、社内での講義や夕礼などは、ほぼ全て私が担当する形となりました。来年度は、少なくとも2人以上はいた方がより手厚い指導やサポートができるのではないかと思います。また、私は新卒2年目のエンジニアということで、新卒のみなさんと年齢や境遇が近く、質問や悩みを相談しやすいというメリットがある一方で、実務経験を踏まえたアドバイスは、経験のあるエンジニアほどできないというデメリットもあります。来年度は、実務経験が豊富なエンジニアと若手のエンジニアの両方が研修にメインで携わるという体制が、より良い形なのではないかと思いました。

おわりに

6月に無事研修を終え、新卒のみなさんは7月から各チームへと配属となりました。AWSチームに配属された人はいないので(泣)、業務中はやや遠目からみんなの様子を見ることが多いのですが、各々配属先で自分の役割をしっかりと果たしていて、頼もしい限りです。また最近は、新人のみなさんを先輩エンジニアがチームの垣根を超えて指導する機会も増えてきており、弊社の教育熱の高まりを感じています。私も新卒研修担当としての役目は終えましたが、これからはこの新卒研修で得た知見を、弊社の教育体制をより良くするために生かしていきたいと思います。

以上で、今年度の新卒研修のまとめは終わりとなります。
最後までお読みいただき、誠にありがとうございました。