伝承進化し続ける技術イベント: git challenge開催記念インタビュー
こんにちは、ミクシィグループ 人事部です。
今回で第6回目*1を迎える、競技型技術イベント「git challenge (ギット・チャレンジ)」開催にあたり、運営に携わるエンジニア社員の国分さんと轟さんにお話を聞いてきました。
過去5回の大会を振り返るとともに、git challengeへの想いを語っていただきます。 #mixi_git
新卒研修受講レポート～テスト編～
はじめまして、17新卒エンジニアの村上と林です。
今回は「テスト」という「プログラムが正しく動作しているかチェックするためのプログラム」についての研修を受けたので、まとめていきたいと思います。
本研修の内容は以下のようなものでした。
・テスト/設計についての簡単な講義
・ペアプログラミングでの実習
- 車窓からのTDD
- 円の面積を求めるプログラムをTDD
- emailアドレスの正誤判定プログラムをTDD
テストについての簡単な講義
テスト研修の目的
まず、なんでこんな事やるの？という事で、研修の目的について述べたいと思います。
研修の目的は「良い設計を覚える」、これだけです。
良い設計ってなんなの？
そこで、良い設計とは？となると思います。
疎結合？可読性？
色々あると思いますが
「経営的な要求・条件に応えられること」です！
経営判断としてスピードが求められる場合には可読性よりも開発スピードを優先する場合もあります。良い設計に重要なものはその時の状況によって変わるということです。
しかしながら、突然のメンバー変更や仕様変更などが往々にして発生し、保守しづらいコードでは何をしているのかよく分からなくなるため、結果的に保守しやすい設計の方が(引き継ぎなども含めて)開発スピードが早くなります。
なので今回の研修では「保守のしやすさ」に焦点を当てます。
いい（保守しやすい）設計方法
保守しやすい設計方法として、テスト駆動開発(test-driven development:TDD)を利用します。この手法では、大きく3段階の手順を踏みます。
- テストを書く
- テストを失敗させる
- 実装してテストを成功させる
この3つの手順を実施することにより保守しやすい設計になります。
TDDのメリット
メリットは以下の3点です。
・テストを先に書くので、テストしづらいコードを書けない
・テストしやすいコードは疎結合で副作用もなく分岐も少ない
・この作業をやっていくと自然に保守しやすい設計になる
ペアプログラミングでの実習
ここまでの講義内容をペアプロで実践しました！
(※ペアプログラミング: 2人でプログラミングすること。常に片方がレビューをやっているので様々なメリットがある)
車窓からのTDD
「車窓からのTDD」はweb上に公開されており、内容としても簡単なのでTDDを体験してみたい方はリンク先を確認してみてください！
http://objectclub.jp/technicaldoc/testing/stack_tdd.pdf
「車窓からのTDD」には対話形式でTDDのやり方が書かれており、手順通りに進めていくだけで良いため、手始めのTDDの理解にとても役立ちました。
「車窓からのTDD」はスタックを構築するだけの簡単な内容で、上記したTDDの流れの通り、テスト作成し失敗、実装、再度テストを実行させ成功、のサイクルで行います。これはTDDでは基本の流れになります。今回の研修では、各自経験のある言語(RubyやPythonなど)で作業を進めていきましたが、どの言語でも基本の流れを抑えれば大丈夫です。
テストを書いてから実装をするので、実装の目的が明確になることで無駄なコードが減り綺麗なコードになると感じました。
円の面積を求めるプログラムをTDD
この課題では、「標準入力経由で円の半径が渡されるので、円の面積を求め四捨五入して整数に丸める」というプログラムを書いていきました。
入力が外から入ってくるため入力値に対するテストが必要になります。
この課題の採点が一回しか行われないという条件だったため、絶対に正解するように多くのテストを書きました。
(テストケースをたくさん書いて置くことで途中でコードの間違いを素早く見つけることができました。間違いなく実装するという点においてもすごくテストが役に立ち、重要なんだと実感しました！)
また、今回の課題でのポイントは標準入力でデータが渡ってくるという点です。テスト(今回の場合ユニットテスト)はロジックだけをテストしたいので依存性がないものが理想です。標準入力に依存しないように、スタブやモックオブジェクトで切り離す方が良いでしょう。
emailアドレスの正誤判定プログラムをTDD
「emailアドレスが"RFC5312 addr-spec"の部分的な仕様として正当なものであればok、違えばng」のテストを作成しました。
今回の場合、大量のテストケース(ngになるメールアドレス、okなメールアドレス)が必要になります。
なので、どのテストケースで失敗したかを分かりやすくする工夫が必要でした。
テストの速度は上げつつ、どこで失敗したかを判別したいのですが様々な方法があるようです。Rubyの黒魔術的な方法もあるようですが、後日調べたところこのような書き方もあるようです。
(テスト書いててどんなテストケースあるかなってなったとき、キレイに書いてると「このケースもあったな」となりやすいので、保守性と速度が確保されると感じました)
まとめ
今回の研修ではテストの重要性について学びました。
保守しやすい設計で、引き継ぎの方や後輩達に、先輩はいいコード書くやろ？ってドヤ顔しましょう！！！！
新卒研修受講レポート～セキュリティ編～
こんにちは。2017年新卒エンジニアの追田と服部です。
本記事では、4月におこなわれた新卒エンジニア向けのセキュリティ研修の大まかな概要や感想を受講者の立場からお伝えしたいと思います。
講師はXFLAG事業本部 たんぽぽGの亀山さんです。
内容
研修は以下の3部構成で実施されました。
- セキュリティの必要性や脆弱性とその対策についての説明
- WebGoat(研修用やられサイト)を用いた実習
- スマートフォンゲームのチート事情についての解説
1. セキュリティの必要性や脆弱性とその対策についての説明
まず、企業が情報セキュリティ上の過失によって個人情報漏洩などの事故を起こしてしまった場合、どのような影響が考えられるでしょうか。
その企業の信頼の低下やイメージダウンを招いてしまうことはもちろん、それに伴う業績悪化や対応費用によって数百億円規模の損失を計上してしまう場合もあります。
本研修では過去に発生した実際のセキュリティ事故の事例を知るとともに、具体的な脆弱性の対策手法について学びました。
脆弱性の攻撃手法で最も有名なものと言えばSQLインジェクションが思い浮かぶかと思いますが、ウェブアプリケーションエンジニアが気を付けるべき脆弱性はこれ以外にも数多くあります。
IPA(情報処理推進機構)が公開している「安全なウェブサイトの作り方」によると、攻撃手法は以下の11種類に分類され、それぞれについて適切な対策をとる必要があります。
1. SQLインジェクション
2. OSコマンド・インジェクション
3. パス名パラメータの未チェック／ディレクトリ・トラバーサル
4. セッション管理の不備
5. クロスサイト・スクリプティング
6. CSRF(クロスサイト・リクエスト・フォージェリ)
7. HTTPヘッダ・インジェクション
8. メールヘッダ・インジェクション
9. クリックジャッキング
10. バッファオーバーフロー
11. アクセス制御や認可制御の欠落
次のセクションでは、研修用に用意された実際のWebサイトを攻撃することを通してこれら脆弱性を対策することの重要性を学んでいきました。
2. WebGoat(研修用やられサイト)を用いた実習
ここでは、WebGoatと呼ばれる練習用Webサイトを攻撃することで前述の様々な種類の脆弱性について手を動かしながら学びました。
攻撃手法についてですが、例えばBurp Suiteという脆弱性診断ツールを用いるとHTTP通信のキャプチャやリクエスト内容の書き換えを簡単に行うことができます。※悪用は厳禁です！
3. スマートフォンゲームのチート事情についての解説
ここからは、講師の亀山さんの専門分野でもあるスマートフォンゲームにおけるチートに関するお話を聞きました。
日本最大級のユーザー数を誇る、スマホアプリである「モンスターストライク」のチート対策について、実際にセキュリティエンジニアからお話を聞くことができるのはミクシィの研修ならではのことです。
資料の一部はXFLAGサイトのブログでも公開されていますので、興味のある方はぜひご覧ください。
スマートフォンゲームのチート事情（@ITセキュリティセミナー）｜XFLAG ケタハズレな冒険を。
当日の様子（感想）
当日印象的だったハプニングがあります。この研修ではWebGoatを使って脆弱性のあるWebサイトを攻撃してその防御手段を学ぶのですが、研修用のサーバがトラブルによってうまく動かなくなってしまったのです。
そんな時に同期がDockerのWebGoatイメージがあることを発見して、それぞれのPCにそのイメージを用いたDockerコンテナを立てることを立案しました。新卒同士助け合いながらそれぞれのマシンにWebGoatのDockerコンテナを立てて無事にトラブルを乗り切りました。その時は同期のチームワークを強く感じ、トラブルを通じて研修の士気が高まりました！
1.セキュリティの必要性や、脆弱性とその対策についての説明
Webサイトを作る上で脆弱性を意識して開発することの重要性はわかっていたつもりでした。しかし、これまでに起きたセキュリティ事故の事例やその被害規模を紹介されると、認識が甘かったなと感じると同時にどのようにすればセキュリティ事故を防ぐことができるのか俄然関心が高まりました！
中でもセキュリティ事故と株価の関係が紹介された時が一番盛り上がっていましたね(笑)。
2.WebGoat(研修用やられサイト)を用いた実習
Webサイトを攻撃するというのは本当なら犯罪ですが、今回はWebGoatという攻撃用のWebサイトなので安心して攻撃することができました(笑)。
このWebGoat、攻撃手法ごとに問題を解いていくようにできており、その問題量も膨大で研修時間で全て解くことは不可能なので、私は、
1.SQLインジェクション
2.XSS(クロスサイトスクリプティング)
の2つに絞って問題を解き進めました。
どちらも有名な攻撃手法ですが、実際に攻撃者側に立ってみて攻撃してみると、意外と簡単に情報の入手や改ざんができてしまうものだと感じました。
攻撃手法に詳しくなくてもネット上の情報があれば、意味を理解していなくても簡単にWebサイトを攻撃できてしまいます。攻撃が簡単にできてしまうからこそ、常に防御のことを考えてアプリケーション開発をしなくてはいけないのだなと改めて感じました。
3.スマートフォンゲームのチート事情についての解説
Webサイトに対する攻撃は多少なりとも知っていましたが、昨今のスマホゲームのチート事情がどうなっているのかは恥ずかしながら知りませんでした。
しかし、チートに利用できるツールが出回っており、メモリの値を書き換えたり通信内容を改変することによって簡単にできてしまうことがわかりました。ツールさえあれば中学生でも簡単にチートすることは可能です。だからこそ、しっかりと対策を練らなければいけないのだなと痛感しました。
ゲームの不正行為で狙われやすい箇所はおおまかに、
1.メモリデータ
2.ストレージデータ
3.ロジック
4.通信
5.操作
と分類され、データ改変や操作の自動化などが行われる可能性があります。
例えば、メモリデータの改変はチートでもメジャーな手法なのですが、今回弊社のモンスターストライク（以下、モンスト）を題材に考えてみます。
モンストでは、ガチャを引く際「オーブ」というアイテムを使用します。現在10個のオーブを所持しているとします。
不正ユーザはこのメモリ上の10という数値をプロセスメモリエディタというツールを使って数値を999に改変し、オーブを不正に増やそうとするかもしれません。
では、この場合どのような対策が考えられるでしょうか？
-メモリ上の値を暗号化する
-計算に利用する数量をクライアント側に持たない
など、考えられる対策はいくつかあります。
この時大切なのは、選んだ対策はそもそもの目的との折り合いがつく対策であるのか、などを考えしっかりと吟味することです。
また、サーバの処理はほぼ手出しができないので、近い将来クラウドゲーミングのように処理の大半をサーバ上で行うようになれば昨今のチート手法はほぼ無意味となるかもしれません。
しかし、現状はスマホ側でゲーム処理を行うケースも少なくないため、これらのポイントを押さえた対策が必要となります(操作の自動化は厳密にはチートではないが不正行為を目的に行われる事もある)。
また開発時は面白さや快適さを重視するので、Webアプリほどセキュリティに意識が向かないことが課題として挙がっていたことに納得すると同時に、難しさも感じました。
ゲーム開発者としてユーザに対してワクワク感を提供することを第一に考えたいけれども、そうするとセキュリティがおろそかになってしまうというジレンマは辛いものです。
まとめ
今回の研修では座学のみならず、実際に攻撃してみることでWebアプリを開発する上でのセキュリティの重要性を実感することができました。
また、昨今巷を賑わせているスマホゲームのチート対策も学ぶことができます。
アプリからゲームまで様々なセキュリティを取り扱う研修はなかなか珍しいのではないでしょうか。
Amazon EC2 リザーブドインスタンスの利用状況をDatadogで監視する（AWS Summit Tokyo 2017 で発表してきました）
はじめまして。北村です。
先日行われた AWS Summit Tokyo 2017 で、Datadog 様の EXPO セッション枠の一部を頂いて SNS「mixi」における Datadog 活用事例について紹介させていただきました。
ツールの概要
先にツールの概要を解説しますと AWS の API から得られた EC2 インスタンスの稼働状況とリザーブドインスタンス契約情報を集計し
- 稼働中のインスタンス数
- 有効なリザーブドインスタンス数
- オンデマンドインスタンス数
- 未使用状態のリザーブドインスタンス数
以上の推移を、Datadog 上でリアルタイムで可視化するというインスタンス集計プログラムとなります。
ここで、Datadog について簡単に紹介しますと「クラウド型のサーバ監視ツール」となっております。AWS 移行のタイミングで SNS「mixi」には導入しており、日々活用させていただいています。
Datadog は「多機能かつ柔軟なグラフ機能、ダッシュボード機能を持つこと」に加えて「カスタムメトリクスと呼ばれるユーザ定義のメトリクスを利用することで、自由な数値を簡単に可視化ができること」が非常に魅力的なサービスです。
今回のツールでも、その機能を利用し、集計した各数値をカスタムメトリクスで Datadog に送信することで可視化を実現しています。
Datadog で描画したサンプルグラフ（数値はダミーです）がこちらとなっています。
これは、t2.medium のインスタンス数の推移を可視化させた例となっており、以下の推移が分かると思います。
- Running Instances （稼働中のインスタンス数）
- Reserved Instances（リザーブドインスタンス数）
- Unused Reserved Instances（未利用状態のリザーブドインスタンス数）
- On-demand Instances（オンデマンドインスタンス数）
グラフ中央付近のタイミングで13台のリザーブドインスタンスを購入しているのですが、それによって各値が変動していることも分かると思います。
ツール作成のモチベーション
AWS で EC2 を利用されている方ならば、リザーブドインスタンスの利用検討を少なからずしているのではないかと思います。
オンデマンドインスタンスをリザーブドインスタンスに切り替えることで、最低1年の利用コミットが発生してしまいますが、オンデマンドインスタンスよりも最大75%引きの値段でEC2を利用することができるからです（詳しくは AWS のサイトを参照していただければと思います）。
SNS「mixi」は長年オンプレミスで運用してきましたが、2015年よりほとんどのサーバを AWS に移行を行いました。
オンプレミスからの移行ということもあり EC2 が非常に多く、リザーブドインスタンスを積極的に活用することで大きなコスト削減を実現しています。
しかしながら、移行が進むにつれてインスタンス数が増え、インスタンスタイプも増えてくるとリザーブドインスタンス契約の管理が煩雑になってきて
- 一体どれだけのオンデマンドインスタンスが存在しているのか？
- リザーブドインスタンス契約数は適切であるのか？
- 余っているリザーブドインスタンスはないのか？
を把握するのが苦しくなってきました。
中には AutoScaling であったり、平日昼間、逆に夜中にしか稼働させていないサーバも混在しており、1日の EC2 の台数の上下が激しくなっています。
これもリザーブドインスタンス契約の判断を複雑にしています。
リザーブドインスタンスの利用状況はAWSコンソールの「EC2レポート」を参照すると把握することができるのですが、以下のデメリットがあります。
- リアルタイムではない（1〜3日の遅延）
以下は「EC2レポート」で直近のインスタンス使用状況を表示させた例となっています。直近の2日間は値が完全に取れていないことが分かります。このため、リザーブドインスタンスの過不足状態を確認するまで時間がかかってしまいます。
- 時間毎の詳細な利用状況が分からない（利用状況が1日でまるめられてしまう）
- なので、未使用リザーブドインスタンスがあったとしても、まるまる1日余っているのか、一定時間だけ余っているのか分からない状態になっています
- AWS Detailed Billing Reports を参照すると分かりますが、別途集計処理が必要になってしまいます
そこで、AWS の API よりインスタンスの利用状況を取得、集計し、リアルタイムで Datadog で可視化してしまおう！というのが、今回の紹介させていただいたツール作成のモチベーションでした。
このツールを活用することで SNS「mixi」では複数のリザーブドインスタンス契約の管理に加え、リザーブドインスタンス契約判断を行っています。
おわりに
AWS Summit Tokyo 2017 のセッションでは以上のツール紹介に加えて、なぜ Datadog を選択し導入したのかについても紹介させていただきました。
当日は多くの魅力的なセッションがあるなか、足を運んでいただいた方もいらっしゃり、大変ありがたかったです！
また、最後になりましたが Datadog 様には、このような機会を与えてくださり、ありがとうございました。Datadog 様からは Datadog ロゴが刺繍されたパーカーをプレゼントしていただきました。American Giant というサンフランシスコのアパレルスタートアップ製のパーカーで自分も大好きなメーカーです。
セッション当日は、嬉しくて、パーカーを着るには暑い日でしたが汗をかきながら着用して発表させていただいたのもいい思い出です。
最後まで読んで頂きありがとうございました！
BFDをサーバで実装してみた話
※こちらの記事は過去のブログから転載したものです。
XFLAG™ スタジオの吉野です。普段は、ネットワークの設計・調達・構築・運用、インフラに関連したちょっとした開発やバックオフィス業務をしています。前回は、拠点冗長した話をさせていただきましたが、今回は、BFDをサーバで実装してみた話を書こうと思います。
システムを組むときは迂回手段や正常性確認手段を考えながら組んでいくと思います。サーバでのパケット処理基盤を作る上で、ネットワーク機器と協働しながらどのように上記手段を実装し安定したものにするかを考えた結果、サーバでのBFDの活用を実装してみました。
ToRまでレイヤ3で組む構成が流行っているかと思います。サーバのNICまでをレイヤ3で運用し、NICに入ってくるパケットを処理するプログラムが正常な時のみ、ネットワークからパケットが流入するような設計をしています。バージョンアップ等の作業も考慮し、GracefulなShutdownも可能にしています。
BFDとはなんなのか
BFDはBidirectional Forwarding Detectionの略です。これは1対1での正常性をチェックするプロトコルです。
ルーティングプロトコル等での処理は障害切り替わりのタイマーが数十秒と長いものが一般的なのに対して、CPUからハードウエアにオフロードしやすいプロトコルとして分離し、短い間隔（数百ミリ秒等）での切り替わりを可能にする技術です。RFCは、5880や5881、そこから関連するものや更新するものがいろいろ出ています。
ざっくり書くと以下のような挙動をするシンプルなプロトコルです。
自前のパケット処理するコードやアプリにBFDの機能を埋め込むと切り替え速度が大幅に向上させることができると期待できます。
ネットワーク全体の中でどう切り替わるのか
現在検証中の構成を下記の図で説明します。
図中のアドレスの用途を説明していきます。
- 203.0.113.0/24 サービスなトラフィックが流れるアドレス帯
- 198.51.100.0/24 BGPのプロトコル上のnext hopアドレス
- 192.0.2.0/24 ネットワーク機器とサーバが繋がり、BFDを話すアドレス（2つセグメントを書きたいために/25で分割しています）
ここからは各プロトコルの連携を説明します。ネットワーク機器は、OSPFとiBGPで経路を交換している。また、OSPFではstaticの経路をredistributeしている。BGPのprotocol next hopは再帰的にstaticの経路を使って解決されて、next hopにパケットを転送します。ポイントは、BFDがupではないときは再帰的解決が不可能になり、その経路は使われないことです。データベース等に入った情報をもとに、BGPの経路を生成するデーモンからネットワーク機器に経路を送ることで、全体としてパケットフォワーディングされるようになります。
この構成のメリットは以下のように考えています。
- BGPの経路情報には変動をなくすことができる
- staticとBGPでは、staticの方がプロトコルとして優先度が高いために、staticのみで実装すると迂回できないパターンが発生する
- パケット処理に必要な情報のロードが終わるまではBFDの応答をしないことで無駄に吸い込む事を抑制できる
- BFDの応答を止めた後に迂回完了までに入ってきたパケットも継続的に処理すればGracefulなShutdownができる
BFDの実装について
基本的にはRFCに沿って実装すればOKです。注意する点は、以下の点です。
楽をする手段として、IPv4のチェックサムの再計算をサボる方法があります。IPv4のチェックサムの計算は、送信IPと受信IPを入れ替えても、他のフィールドが変わらなければ値が変わりません。また、今回試した相互接続確認で、UDPのチェックサムも0としても受信してくれる実装もありました。
これを活用するとnetmap等のLinuxのプロトコルスタックを通さない開発を行う場合に楽ができます。
サンプルコードはこちら https://github.com/xflagstudio/network-bfd-sample にあります。Juniper Networks社の機器でBFDがUPすることを確認しています。RFCを忠実に実装したものではありません。
まとめ
今回は、BFDを実装し、サーバまでをL3での経路制御にする方法を紹介しました。XFLAG™ スタジオでは、様々なポジションで積極採用中ですが、こういったコードを開発したい人やこの基盤のマネージメントツールを書きたい人も歓迎しています。
━・ネットワーク・プログラマー採用中！・━
https://career.xflag.com/career/engineer/872/
https://www.wantedly.com/projects/93043
━━━━━━━━━━━━━━━━━━━━━
第2回「XFLAG アカデミー」開催！
※こちらの記事は過去のブログから転載したものです。
みなさんこんにちは！XFLAG アカデミースタッフです！
先日、西東京市立田無第四中学校の生徒さん6名をお迎えし、2回目となる「XFLAG アカデミー」を開催しました。
※「XFLAG アカデミー」の詳細はこちら
当日は雨が降り出し、足元の悪い中、当社までお越しいただきました！
みなさんを会議室にご案内すると・・・
会議室の中にはレッドリドラの被り物をしたアカデミーのメンバーが！
少しでも生徒さんの緊張を和らげようと、工夫してみました。
なごやかな雰囲気になったところで、まずは生徒の皆さんと、我々スタッフの自己紹介を行いました。
続いて、当社のエンジニア職の社員（先ほどのレッドリドラを被っていたスタッフ！）からは、中学生のみなさんにとっては、あまり馴染みのない「エンジニア」という仕事について、どのような役割を担い、どんな事をしているのかについて、詳しく説明。
さらに、モンスターストライクの人気キャラクター「ガブリエル」の友情コンボの作り方を、実際の開発環境を見せながら実演しました！
友情コンボが正常に動作するために、どのように考えていけばいいのか、順を追って説明。
社員からの「次はどうしたらいいかな？」という質問に対し、なかなか鋭い回答もありました！
また、説明の中では座標の話も出てきて、学校で勉強した内容が、将来役に立つ場面があるという事を知ってもらうことができました。
次に、実際にXFLAG スタジオから産み出されているゲームを体験してもらおう！という事で、2班に分かれてモンスターストライクをプレイしました。
初めて遊ぶ生徒さんもいましたが、モンストの「指で引っ張り、弾く」という操作にもすぐに慣れ、なんと2班とも無事にステージをクリア！
"友達と一緒にワイワイ楽しむ"という醍醐味を感じてもらえたかと思います。
また、今回は少し時間の余裕があったので、7階の休憩スペース（通称コラボ）を見学していただきました！
開放的なスペースを、わくわくした様子で見学している生徒さんたち。
リラックス出来る環境があるからこそ、良いアイディアも生まれてくる、そんな会社の一面も見ていただきました。
最後に書いていただいたアンケートには、「自分の将来を考えるきっかけにしたい」という感想もあり、今回の企業訪問がみなさんの未来に役立つ経験となっていればいいなと、アカデミースタッフ一同思っています。
生徒のみなさん、ご来訪ありがとうございました！
今後も、XFLAG アカデミーが開催されましたら、ブログにてご紹介させていただきます。
ここまでお付き合いいただき、ありがとうございました！
XFLAG アカデミーの詳細・申し込みについてはこちらをご参照ください。
「XFLAG アカデミー」開講！
※こちらの記事は過去のブログから転載したものです。
皆さんこんにちは！XFLAG アカデミースタッフです！
先日、広島県立呉三津田高等学校の生徒さん4 名をお迎えし、「XFLAG アカデミー」を開講しました。
XFLAG アカデミーって何？
まずは、XFLAG アカデミーについてご説明します！
XFLAG™ スタジオが属するミクシィグループでは、次世代育成の取り組みとして、「自分のキャリアを考えるきっかけにしてもらいたい、IT 業界の仕事に興味を持っていただきたい」という想いから、小中高生向けの企業訪問の受け入れを実施しています。
その一環として、モンスターストライクなどのスマホアプリをはじめ、エンターテインメント事業を提供するXFLAG スタジオの取り組みを学生の皆さんにお伝えし、理解を深めていただく「XFLAG アカデミー」を開講しています。
XFLAG アカデミーではどんなことしてるの？
ここからは、XFLAG アカデミー当日の様子をご紹介します！
2016 年10 月某日、やや緊張した面持ちで弊社受付にてお待ちいただいていた生徒さん達をXFLAG アカデミー関係者一同でお出迎えし、会議室にお通しして、スタート！
まずはじめに、生徒さん達に「好きなモンストのキャラ」を聞いてみた所、「アグナムートX」や「テキーラ」などの往年のキャラクターの名前が！
聞けば、リリース当時の「3 年くらい前からモンストをプレイしている」と言う生徒さんもいました！初期からプレイしてくれていて、とても嬉しく思いました。
さて、今回のXFLAG アカデミーでは、株式会社ミクシィやXFLAG スタジオの概要を聞いていただく「紹介パート」、ご希望の職種の社員から話を聞く「仕事を知ろう！パート」、社内紹介動画を見て実際に社内を見学いただく「探検パート」等を行いました。
最初の「紹介パート」では、株式会社ミクシィ・XFLAG スタジオのビジョンやミッション、プロダクト、職種や従業員の様子についてご説明しました。ミクシィグループ、ひいてはXFLAG スタジオが軸として考えていることや、どんな組織なのか、どんな人達がどんな環境で何をしているのかが、分かっていただけたかと思います。
次の「仕事を知ろう！パート」では、弊社企画職社員から、「企画ってどんな仕事？」や「企画の種類ってどんなものがあるの？」、「実際に行った企画って何？」をお話しました。
また、裏話として「キャラクターが進化していく上でのストーリー」をお話し、最近世に出たあるキャラクターの設定裏話もお伝えしました。
生徒さん達はメモを取って、真剣な眼差しで説明を聞いていました。
時には、社員から「この企画知ってる？」や「最近学校で何が流行ってるの？」といった質問をすることも。生徒さん達は急な質問にドキドキしつつ、教えてくれました。
Q&A のコーナーでは、生徒さん達から事前にいただいていた質問にお答えしました。
アクセス集中によるサーバーダウンを防ぐ技術のお話や、緊急メンテナンス後のお詫びの話などをし、XFLAG スタジオが、ユーザーの皆様が快適かつ楽しくプレイできるように努力していることをお伝えしました。「アイデアの生み出し方」の話では、企画職の社員が日々心がけていることを語りました。生徒さん達が企画職に興味を持ち、将来企画職をすることがあれば、参考になったらいいな、と思います。
続いては「探検パート」。
残念ながら時間の都合上社内見学はできなかったのですが、「XFLAG 超絶CAST」でおなじみのさなぱっちょやぱなえ、さしみ、りえっくすが社員や社内設備をご紹介する約5 分の動画を見ていただき、弊社の雰囲気を体感していただきました。
最後は生徒さんの1 人から、代表ご挨拶がありました。
感想や御礼の言葉を丁寧にお話ししてくれ、素晴らしいご挨拶でした！
お見送り時に、受付でアニメ版 「モンスターストライク」の焔レンくんのポーズで皆で記念撮影！
「XFLAG アカデミー」の開講ともなった今回の企業訪問を通して、生徒さん達の仕事に対する価値観の変化や、将来の職業選択の一助となれば嬉しいです。
生徒の皆様、ご来訪ありがとうございました！
今後も、XFLAG アカデミーが開催されましたら、ブログにてご紹介させていただきます。
ここまでお付き合いいただき、ありがとうございました！
XFLAG アカデミーの詳細・申し込みについては下記URL をご参照ください。
http://xflag.com/academy/index.html
