AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

ハンズラボ新卒研修2017 (1/2) 〜カリキュラム編〜


上の画像の文字には、FIGletを使用しました 公式サイト

こんにちは、エンジニアの三井田です。

新卒採用受け入れ2年目となったハンズラボは、今年も5名の新卒エンジニアが入社し、4〜6月の3ヶ月間、新人研修を行いました。

6月末に新人研修が無事に終了し、7月から新卒のみなさんが各チームへ配属となりました。7月から始まった私の開発も少し落ち着いたので、今回は2017年度のハンズラボ新卒研修について、講師の視点から備忘も兼ねてまとめようと思います。

他企業様で新卒研修に関わっているみなさまの参考に少しでもなれば幸いです。

前提

今年の弊社新卒について

最初に、今年の弊社新卒について簡潔に説明します。

今年は、IT経験者4名(情報系学部・専門学校卒)、未経験者1名(語学系学部卒)の計5名の新卒エンジニアが入社しました。

経験者のプログラミング経験に関しては、授業でCやJavaなどを学習した人が多く、ネイティブアプリ開発を学校で学んでいた人もいました。しかしながら、各々が実際どのくらいコードを書けるかは、選考時にコーディングのテストを行っていないため、入社するまで分からない状態でした。

未経験者は、IT未経験だったものの、内定後から入社まで週2〜3回のペースで弊社でアルバイトをして、プログラミングの基礎的な勉強をしてから入社した、という状況です。

2017年度新卒研修の指導体制・方針について

次に、弊社の2017年度新卒研修の指導体制について説明します。

AWSチームで担当する

2017年度の研修は、R&Dその他もろもろを行っているAWSチームが担当することになりました。また、プロジェクトの稼働率等の問題から、他のチームの人への講義などの依頼は、よほどその人にしかできないことでない限りは避ける、という制約がありました。

* AWSチームに関する詳しい業務内容は、同じチームで働く百木田(からきた)がこちらにまとめております

まずは、アプリケーションをしっかりと開発できるようになってほしい

「バーサタイリスト(なんでもやる人)を育てる会社」を謳っている弊社ですが、新人、特に新卒エンジニアには、まずはアプリケーションをしっかりと開発できるようになってほしいという方針があります。故に今年度の新卒研修は、当初はインフラ系の研修時間を多くとっていましたが、最終的にはアプリケーション開発中心のカリキュラムとなりました。

以上を踏まえてチーム内で議論した結果、チームリーダーの鹿倉を除いたAWSチームの中で、比較的アプリケーション開発経験のある私が、新卒研修のメイン担当となりました。

私について

今年度の新卒研修を担当した私、三井田に関してですが、実は去年の3月に学部(情報科学専攻)を卒業した2016年度新卒なので、去年は新卒研修を受ける側でした。ハンズラボに入社後、3ヶ月の新卒研修を経て配属されたチームで、ECサイト・スマホアプリのAPIや管理画面の開発などに携わった後、今年の2月からAWSチームに移籍しました。実務経験豊富な熟練エンジニアではありませんが、新卒のみなさんと年齢や境遇が近い分、同じ目線に立って研修をすることが少しはできたのではないかな、と思っています。

研修目標

研修を行うにあたって、以下の3つの研修目標を立てました。
1. 自走できるエンジニアになる
2. ユーザーの要求に応えることができるエンジニアになる
3. 共に開発する仲間を大切にできるエンジニアになる

1. 自走できるエンジニアになる

受け身ではなく、主体的に問題を解決する力

  • 自分で本やWebサイトを使って調べる、分からないところを具体性を持って人に聞く

 

自分が書いたコードに責任を持つ

  • 自分で考えてコードを書く。自分がなぜそのようなコードを書いたのか人に説明できる
  • 脆弱性のないプログラムを書く。指示されていなくても、常にセキュリティのことは念頭に置いておく

 

2. ユーザーの要求に応えることができるエンジニアになる

* ユーザーが言ったことは全て二つ返事でやらなければいけない、という意味では決してありません!!

自分が開発したものは、必ず誰かに使われる

ユーザーの要求・要望に対して、全て「難しいからできません」では、次から何も頼まれなくなります。ユーザーの要求に応えるためには、以下の2つの力を養うことが必要だと考えました。

  • ユーザーの要望を正確に理解する力(根気強くユーザーとコミュニケーションをとることが必要)
  • ユーザーの要望を実現する技術力

 

(+α)ユーザーの潜在的な要求・要望に応えられる力も、ゆくゆくは身につけてほしい

また、ユーザーは必ずしも技術的な専門家ではないため、ユーザーから言われた要望だけに応えるのではなく、ゆくゆくは、ユーザーが言語化できない不満・欲求も汲み取って解決できるエンジニアを目指してほしいです。
 

3. 共に開発する仲間を大切にできるエンジニアになる

会社では、1人で開発することはほとんどなく、チームで開発を進めていくことになります。故に、チームで開発する際には、以下の点を意識してほしいと考えました。

開発に関わる全ての人たちをリスペクトしよう

 

独りよがりの開発はやめよう

  • 例:自分だけが分かるプログラム
  • 他の人が後でそのプログラムを修正するかもしれない!

 
 

4月

〜自走するために必要な、開発の基礎力育成フェーズ〜

研修内容

4月の研修内容は以下の通りです。

  • 経験者・未経験者問わず5人全員一緒に研修
  • JavaScriptのeラーニング・社内講座を通して、プログラミングの基礎的な知識を学習
  • 終盤は、jQuery・Node.jsの座学・演習を通して、Webアプリケーション(クライアント・サーバモデル)の仕組みを、実際に手を動かしながら理解する

 

4月の研修で身につけてほしいこと

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

(補足)JavaScriptの選定理由

賛否両論あるかと思いますが、今年の新卒研修で学ぶ言語は、JavaScriptを選択しました。主な選定理由は以下です。
1. フロントエンドもサーバサイドもJavaScriptで書ける
2. Web開発をする上で避けて通れない
3. Node.jsの、社内での採用実績

1. フロントエンドもサーバサイドもJavaScriptで書ける

JavaScriptという1つの言語を学ぶことで、フロントエンドもサーバサイドも実際に手を動かしながら学ぶことができます。4月に社内で研修ができる期間は、外部研修を除くと実質12日程度しかありませんでしたが、学ぶ言語を一つに統一できたことで、プログラミングの基礎からWebアプリケーションの仕組みまで、一通り学ぶことができました。

2. Web開発をする上で避けて通れない

さらに、弊社は一部iOSネイティブアプリを開発するチームがあるものの、アプリケーションを開発しているほとんどのチームは、Webアプリを開発しています。現在、フロントエンド開発ではJavaScriptを使うことはもはや避けられないため、よく「難しい」「クセがある」と敬遠されがちなJavaScriptを、しっかりと指導できるこの研修期間中に体系的に学んでほしい、という思いもありました

3. Node.jsの、社内での採用実績

また、一時期社長の長谷川が、フロントエンドもサーバサイドもJavaScriptでやることを推進していたこともあり、社内の多くのプロジェクトのサーバサイドにNode.jsが採用されています。サーバサイドをNode.jsを使って学ぶことで、研修後の配属先で一からNode.jsを学ばなくてよくなる、というメリットもありました。
 
 

5月、6月

〜ユーザーの要求に応えられるエンジニア、チームで円滑に開発を進められるエンジニアになるための「仮想プロジェクト」演習〜

仮想プロジェクト

もはやハンズラボ恒例の仮想プロジェクト、今年もやります。去年の仮想プロジェクトの模様は以下のリンクからご覧いただけます。

 
今年も仮想プロジェクトという名前自体は同じですが、研修内容が違うこともあり、主に以下の点が昨年と異なります。

  • 仮想お客様であるAWSチームからお題を出して、それを開発してもらう
  • 開発言語は、4月に勉強したJavaScript

 

なぜ仮想プロジェクトをやるのか

「配属後に実際のプロジェクトで経験するであろうことを、なぜこの研修期間でやるのか」「座学や、課題を与えて解いてもらう時間をもっと増やした方が良いのではないか」と社内でも議論になりました。弊社がそれでも新卒研修期間に仮想プロジェクトを行う理由は、以下の2つです。

仮想プロジェクトは、失敗できる

実際のプロジェクトではお客様からお金をいただいて開発するため、失敗はできません。しかしながら、仮想プロジェクトは仮想なので、最悪大失敗に終わっても大丈夫(?)です。

失敗する前に注意されるよりも、失敗して自ら学んだ方が印象に残りますし、学びは大きいと考えます。仮想プロジェクトで失敗を恐れず大胆に行動し、失敗から大いに学んでほしいと思っています。

主体的な行動・意思決定ができるようになってほしい

配属後のチームでは、おそらく立場としては一番下で、しばらくは上司・先輩から与えられたタスクをこなしていくことになります。しかしながら、仮想プロジェクトではチームメンバーは全員同期であり、仮にリーダーを決めたとしても、配属後のプロジェクトよりは自分で考えて行動する機会が多くなります。

配属後に、ただの作業員ではなく主体的に業務に取り組むエンジニアになるため、仮想プロジェクトで、組織の一員として主体的に行動・意思決定をする経験を積んでほしいと考えました。

5月、6月の研修で身につけてほしいこと

5、6月の仮想プロジェクトで身につけてほしいことは、以下の3つです。
1. 実際に開発をする上で必要となる力
2. チームで円滑に開発を進める方法・マインド
3. スケジュール遅延による影響と対策を知る

1. 実際に開発をする上で必要となる力

学校の授業や4月の研修で、開発するために必要な技術・知識を学んだだけでは、すぐに実務で開発を始めるのは難しいことが多いです。
具体性を持ってお客様、チームメンバーに聞くなどの質問の仕方であったり、分からないことを調べるスピード力であったり、実際に開発をする上で必要となる力をこの仮想プロジェクトで身につけてほしいと思います。

2. チームで円滑に開発を進める方法・マインド

チームメンバーに技術面で差がある中で、作業の早い人が自分だけでやろうとしてしまうと、その人の負担がどんどん増えてしまいます。技術面に差がある中で、どのようにタスクを分担すればチームで円滑に開発を進められるのかを、仮想プロジェクトで考え、学んでほしいと考えました。

加えて、適切なコミュニケーションの取り方も仮想プロジェクトで最も学んでほしいことの一つです。一口にコミュニケーションと言っても、チーム外の人とのコミュニケーション、チーム内の人とのコミュニケーション、根回し(何かを依頼したり企画したりする時は、早め早めにアポ取りなどの行動をする)など、いろいろな種類があります。コミュニケーションスキルは、研修中だけではなく配属後も必要不可欠なスキルになるので、ぜひ、この仮想プロジェクトでたくさん失敗し、適切なコミュニケーションの取り方を学んでほしいと思います。

3. スケジュール遅延による影響と対策を知る

初めてのプロジェクト開発かつ開発期間が短いと、スケジュールはどうしても遅れてしまうことがあります。去年の仮想プロジェクトも、終盤にスケジュールの遅延がありました。プロジェクト中にスケジュールが遅延してしまった時に、その影響を正しく把握し、適切な対策を講じることができるようになってほしいと思います。

新卒研修のカリキュラムに関しては以上です。
 
 

実際の3ヶ月の研修はどうだったのか?

ここに書くと長くなり過ぎてしまうので、その模様は後日また書きます。

大変な3ヶ月間でしたが(笑)、忘れられない貴重な経験をすることができました。

近いうちに更新するので、そちらもぜひ読んでいただければ幸いです。
それでは、今回はこの辺で。最後までお読みいただきありがとうございました。


東急ハンズでAmazon Chimeを導入した時に調べたこと


こんにちは。百木田です。

今年の2月にリリースされたAmazon Chimeをこの度、東急ハンズの会議に使ってみることになりました。

以下がChimeを採用したいくつかの理由です。

  • シンプルな操作
  • 最大100人がビデオミーティングに参加可能
  • 主催側から参加者をミュート可能

Chimeを本格的に利用することになり、いろいろ調べたのですがまだまだナレッジが少なく試行錯誤したので、わかったことを残しておこうと思います。

Chimeアカウントとユーザー

Chimeにはアカウントユーザーという単位が出てきます。イメージ的にはアカウントは会社やチームなどのグループで、ユーザーは個人に紐づくものです。

ChimeユーザーはAmazon.co.jpのアカウントと紐付いていて、AWSアカウントを持っていなくても使用できますが、AWSコンソールからChimeアカウントとChimeユーザーを紐付けることでユーザー管理をすることができるようになるなど便利に利用できます。

以下がChimeアカウントの種類です。

少し補足するとこんな感じ。

Amazonアカウント

・ AWSアカウントで管理されていない単独のアカウント(ユーザー)。

チームアカウント

・ AWSのChimeで作成したアカウントにユーザーを招待できる。

エンタープライズアカウント

・ 自社のドメインをAWSアカウントのChimeへ登録する必要あり。
・ そのドメインのメールアドレスでChimeにログインすると自動的にアカウントにユーザーが追加される。

ちょっとややこしいです。整理するために図にしてみました。

グループミーティングをホストするにはPro Editionを付与したChimeユーザーが必要です。主催者によってミーティングがホストされると、Chimeユーザーを作成していない人でもミーティングIDを教えてもらうことでミーティングに参加することができます。

ポートと通信帯域の要件

通常のビデオミーティングをする場合は以下のそれぞれのIPアドレス:ポートに対するアウトバウンド通信を許可してあげる必要があります。

IP Address

  • 52.54.62.192/26
  • 52.54.63.0/25
  • 52.54.63.128/26
  • 52.55.63.128/25

Ports

  • TCP/443
  • UDP/16384:17383
  • UDP/3478

ポートの要件はこちらに記載されています。
hosts-ports-and-protocols-needed-for-amazon-chime

各機能を利用する上で必要な通信帯域はこちらに記載されています。
what-are-the-bandwidth-requirements-for-amazon-chi

料金体系

各ユーザーエディションごとの料金は公式サイトに記載されているとおりです。

ユーザーはAWSコンソール上からエディションをGrantさせたりRevokeさせたりできるのですが、課金されるのはProエディションをGrantさせてた期間の日割り計算になります。
なので1ユーザーを1ヶ月のうち合計20日間ProエディションをGrantさせていた場合、

という計算になります。
なお、課金は1ユーザーごとになるため、2ユーザー以上利用した場合はユーザー数分の課金が発生します。

AD連携

AWSのAD Connectorを利用することでChimeのAD連携をすることができます。しかしながらAD連携するにはAD Connectorがバージニアリージョンにある必要があります。

まとめ

以上となります。Chimeの使用感や問題点、会議する上で工夫したこと、考慮した方がいいことなどあるのですが、そちらは別の機会に書ければと思っています。
Chime自体、登場したばっかりでまだまだ改善の余地がありますがフィードバックをしつつ、アップデートに期待したいと思います。
ありがとうございました。


IAMポリシーで自分の所有リソース以外の操作を制限する


こんにちは。百木田です。

先日、こんなことがありましたね。
Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。

人間が関わっている以上、人的ミスはどうしても避けられないので工夫してミスを減らしましょうという教訓ですね。

今回のブログでは新しい技術は使ってないですが、そんなニュースもあったので人的なミス防止に関連する共有です

AWSを導入している企業であればAWSの機能や技術を検証するために、
サービス提供しているアカウントから分離された検証用アカウントを利用している場合も多いかと思います。
本番環境ではユーザーに適切な権限を付与し、事故を防止していることと思いますが、検証環境では事故の影響が小さかったり、検証するために必要な権限が多い or 不明確であったりということもあり、それぞれのIAMユーザにAdministrator権限に近い権限を付与しているといったこともあるかと思います。

自分が操作しているリソースのすぐとなりに他の人が検証で使用しているリソースがある場合、そういった権限を持っていれば少しコンソール操作をしくじっただけでリソースが消え、両者、冷や汗状態です。

基本的に私はしくじる側の人間だと思っているので、そんな環境でコンソール操作するのはめちゃくちゃイヤなわけで、寝ぼけながら操作しても自分以外の管理するリソースを操作すること無いようにしたかったわけです。
(入社した月にそんなことやらかした時にはもうあれですね。)

今回はEC2インスタンスの[開始/停止/再起動/削除]操作を制限するポリシーを設定します。

設定方法

  1. 操作制限を書いたIAMポリシーを作成
  2. 自分の使用しているIAMユーザーに対して作成したIAMポリシーを付与
  3. 自分が管理しているEC2インスタンスにタグ付け
      Ownerというタグネームに対して自分のIAMユーザー名を設定
      

作成したIAMポリシーは以下です。

「操作するEC2インスタンスのOwnerタグと、現在使用しているIAMユーザー名が異なる場合はActionの操作を拒否」という内容です。
また、どのユーザーでも同じポリシーが使用できるようにユーザー名の部分は変数を指定しています。

試してみる

Ownerタグに自分のIAMユーザー名が設定されているインスタンスは操作できます。

そうでないリソースは操作時にエラーが出るようになりました。

CLIで試しても同様にエラーとなります。

まとめ

権限を少し工夫するだけで安心して作業できるようになりました。
現在お使いのIAMユーザーにIAM操作権限が付与されていれば今からでも手軽に設定できると思いますので実施してみてください。


Serverless Frameworkでバイナリデータを処理するアーキテクチャを構築したかった


こんにちは。AWSチーム百木田です。

サーバーレス、してますか?

この度、「クライアントから画像を受け取ったらLambdaでその画像の処理をする」ということがしたく、受け取る部分を昨年11月に発表されてできるようになったAPI Gatewayでのバイナリデータサポートを利用してやってみました。
そして何かツールを使って楽にデプロイしたいと思い、今回はServerless Frameworkを利用してやってみることにしました。

環境

  • OS(VM): CentOS Linux release 7.2.1511 (Core)
  • Node Version: 7.5.0
  • Serverless Version: 1.8.0

準備

Serverlessの定義ファイル作成

Serverlessのセットアップについては省略させていただきます。’serverless’コマンドが実行できる前提です。

‘serverless.yml’を作成します。

定義している内容は以下です。

  • LambdaからS3にデータを置くためのIAMロールを定義
  • POSTで受けてLambda処理を行うAPI Gatewayを定義
  • 画像を保存するS3 Bucketを定義

注)S3バケット名の部分は変更してください。

タイトルで「してみた」にできなかったのには理由があり、残念なことに肝心のバイナリデータサポートの設定は現時点でServerlessでは対応していませんでした。そのためプラグインを使用するか他の方法で設定する必要があります。今回は泥臭くデプロイ後にマネジメントコンソールで設定することにします。

Lambda実行コードを作成

Lambdaでの処理は受け取った画像データをS3にアップロードするという簡単なものにしました。

ここではデータを’/tmp’に一度保存していますがもちろん受け取ってそのままS3にあげちゃってもOKです。

デプロイ

バイナリデータサポートを設定

‘serverless deploy’するとS3バケットやAPI Gateway、Lambdaといったリソースが作成されているかと思います。その後、API Gatewayのマネジメントコンソールからバイナリサポートのバイナリメディアタイプに’image/jpg’などPOSTで受ける’Content-Type’に合わせた値を設定します。

バイナリサポート設定後のAPIをデプロイするために再度’serverless deploy’をします。再度デプロイしても手動で設定したバイナリサポートの設定は消えません。

これで設定は完了です。

実際に試してみる

お手軽に試すにはローカル端末から以下のコマンドを実行します。

‘Upload Sccessful’が表示され、S3の指定バケットにファイルが保存されています。

まとめ

今回はServerless Frameworkを利用しましたが他にもSAMApexLamveryなどツールが出ているので今後試していきたいと思います。Serverless Frameworkも順次アップデートされているので今後楽しみです。

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


Kinesis FirehoseがS3に出力したファイルを1レコードずつ読み込む


皆々様、お久しぶりのブログ更新です。

Kinesis FirehoseがS3に出力したファイルをPythonでモニャモニャしたいと思っていたところ以下のことでつまづいてしまいました。

1つのファイルに複数レコード出力されている場合、改行(区切り文字)がなく1レコードずつ読み込めない!

改行とか入っていて、1行ずつ読み込むんだろう・・・みたいな想像を勝手にしていたのでちょっとつまずいてしまいました。

AWSのデモデータをKinesisFirehoseに流すと実際のファイルはの中身は下記のようになります。

こういったJsonストリームデータをPythonで処理する時ってどうしたらいいんだろうと調べていたらjsonライブラリにJSONDecoderというのがあるのを見つけました。

下記サンプルです。

これを実行すると下記のように出力されました〜。

そうです、この記事・・・単にストリームデータの読み込み方についての記事です!KinesisFirehoseは完全に引きです!

でもストリームデータを扱うことは個人的には今後も増えそうなので今回調べておいてよかったです!

ではでは〜。


  • IT酒場放浪記 記事一覧
  • エンジニア募集中!