モンスターストライク システムオーバービュー

※こちらの記事は過去のブログから転載したものです。

こんにちは。XFLAG™スタジオの青山です。XFLAG™ スタジオの開発者ブログ一本めということで、モンスターストライクのシステムについてざっくりと書いてみます。細かなところはそのうち別の人が書いてくれると思いますっ。

スマートフォンゲームであるモンスターストライクは、スマートフォンアプリとして動作する"クライアント"と、ゲームのパラメーターや進行状況などの重要なデータを管理する"APIサーバー"、最大４人のマルチプレイにかかるリアルタイムなデータ通信を中継する"TURNサーバー"の、大まかに３つの要素で構成される情報処理システムです。

ほかにもサーバーやネットワークの監視系システムや、解析系システム、カスタマーサポート系システムなどなど、"ゲーム事業"を滞りなく遂行するための様々なサブシステムを内包しています。

今回は主要３要素のうち、スマートフォンアプリからは見えないAPIサーバーとTURNサーバーを簡単に取り上げます。

APIサーバー

APIサーバーはゲーム進行に必要な情報をクライアントに提供・管理するWebアプリケーションサーバーです。

A10のロードバランサー配下に約300台超のLinuxサーバーを配置してクライアントと通信しています。APIサーバーは一般的な基盤ソフトウェアを土台として、XFLAG™ スタジオが開発しているサーバーアプリケーションを実行しています。

APIサーバーのロジックはRubyで記述しています。Web Application FrameworkはPadrinoを使用し、RDBMSの操作にはActiveRecordを使用します。

永続化が必要な情報はMariaDBで管理します。MariaDBはActive-Standbyのペアを基本として、要求の増大に対してはまずはクエリ改善をしたり、頻繁に参照される同じデータについてはmemcachedに保存したりしています。必要に応じてスケールアップをしたりテーブルセットごとに別のActive-Standbyペアに分割したり、さらに要求の高いテーブルについてはシャーディングして対応しています。なんやかんやでMariaDBのサーバーは200台以上動いています。

頻繁に使用するホットデータはmemcachedで保持します。memcachedは2つのキャッシュプールを同時更新することで、データ構造を変更する際にもスムーズな移行とパフォーマンス低下を防いでいます。

処理時間の大きく遅延しても問題のない処理は、Resqueのジョブキューに投入して複数のワーカーノードで分散しつつ非同期処理します。

ちなみにモンスターストライクのシステムは複数のデータセンターにサーバーを配置しています。

仮にデータセンターがまるごと1つ停止して長時間利用できない状況となったとしても、残ったデータセンターに切り替えることでゲームを提供し続けられる構成をとっています。

TURNサーバー

スマートフォンは携帯電話キャリアや家庭のWi-Fiなど様々なネットワークから利用されます。ほとんどの場合ネットワークのレイアウトによる制約からクライアントどうしは直接通信できませんが、インターネット上に配したTURNサーバーが仲介することで仮想的なpeer-to-peer通信を実現しています。

モンスターストライクのTURNサーバーはTURN - Traversal Using Relays around NAT プロトコルを実装したオープンソースソフトウェアをベースに、大規模なマルチプレイ環境の安定提供に必要な様々な改良を加えて利用しています。

TURNサーバーは一台あたりピーク時で約30,000セッションを同時に処理するよう調整しています。ちなみにTURNサーバーはゲームの"状態"を保持しない単純なTCPリレー装置として振舞うので計算機資源への要求は少なく、大量のセッションを同時に扱うことができます。もちろん全てのマルチプレイセッションを1台でまかなうのは不可能なので、複数のTURNサーバーをクラウド上に並列配置しています。

とりあえずモンスターストライクのサーバサイドのシステムのサワリとしてはこの辺になります。引き続きモンスターストライクをはじめとしたXFLAG™ スタジオで扱う技術要素や、スタッフの愚痴が少しずつ書かかれていくと思いますので、以後お付き合いのほどよろしくお願いします。

総行数57,000の巨大CSS群をLessに書き換えた軌跡

こんにちは！フロントエンド闇祓いの Kuniwak です。
この投稿はmixiグループ Advent Calendar 2015の20日目の記事です。

今年の9月に、スマートフォン Web ブラウザ版 mixi「mixi Touch」の巨大 CSS を Less （CSS プリプロセッサー）でビルドする環境へと移行しました。 書き換えた CSS の行数は、なんと 56,725行 です。😵

ということで、今回は弊社の大規模 CSS → Less 移行事例についてお話しします。

背景

スマートフォン版 mixi は、2010年5月に始まりました。 この頃のスマートフォンは、iPhone 端末であれば iPhone 3GS、Android 端末であれば Nexus One という時期です。 また、スマートフォンの世界では、Webkit ベースのブラウザーが席巻していた時代ということになります。

そのため、当時の CSS は Webkit ベースのブラウザーのみを考慮した書き方が多く見られました。たとえば、次のような -webkit- プレフィックスを使った書き方です：

/* 非標準の CSS プロパティ fuga を使う場合の書き方 */
.hoge {
  -webkit-fuga: moge;
  fuga: hoge;
}

この -webkit- プレフィックスは非標準（または実験段階）の機能などを先行して利用するためのものです。 ただし、実験段階の機能ということだけあって、標準化される過程で CSS プロパティの名前が変わったり、別仕様に取り込まれてしまったりするリスクがあります。

そのため、-webkit- のようなベンダープレフィックスを使うためには、変更されたときの影響を小さくしたり、書き換えを楽にするような工夫が必要とされます。

しかし、当時の弊社の CSS では、次のような悪い書き方が散見されました:

/* 潜在的な問題を抱えたコード */
.something {
  -webkit-background-size: 8px 8px;
}

このコードは、当時のモバイルブラウザーであれば意図通り表示されることでしょう。 しかし、この書き方には3つの潜在的な問題があります。

1. 非 Webkit ベースのブラウザーを考慮していない
2. -webkit- つきのプロパティが標準になったときの書き換えが大変
3. -webkit- つきのプロパティが非標準になったときの書き換えが大変

当時から問題は認識されていたものの、問題への対処は見送られていました。
そして、5年経った今になって、この3つの問題が顕在化したのです。

この問題の解決のために、HTML コーダー（マークアップエンジニア）2名 + 技術支援1名 + テスター1名の体制で対応作業を始めました。

問題1: 非 Webkit ベースのブラウザーを考慮していない

-webkit- プレフィックスをつけたプロパティは、非 Webkit ベースのモバイルブラウザー（Android 版 Firefox や Windows Phone の IE など）では解釈されません。 しかし、これらのシェアが小さいためか、-webkit- プレフィックスのみの CSS が世に溢れています。

そこで動き出したのが Mozilla です。 Mozilla には WebCompat Team なる部署があり、-webkit- のみの CSS を使っている Web サイトへの啓蒙活動をしているそうです（Mozilla の方による記事 WebCompat）。 mixi に対しても Mozilla からのコンタクトがありましたが、あまりの -webkit- プレフィックスの多さから見送られた、苦い記憶があります。😢

また、啓蒙活動とは別に、Firefox のコード側にも動きがありました。 それは、特定のドメインの CSS では、-webkit- プレフィックスを外して解釈するというものです。 つまり、ドメインによって CSS の解釈が変わることになります。 この動きについては Mozilla 側の対応チケットを見ると何がおこなわれたのかわかります。

実は、この Mozilla 側での動きが、Less 化の強い動機になりました。 これは、弊社のステージング用の環境では専用のドメインが使われていることに起因します。 そのため、本番環境とステージング環境での CSS 解釈に差が出てしまうのです。 これではステージング環境の意味がありません。

つまり、非 Webkit なブラウザーに注意を払わなかった結果、ブラウザーベンダーがお怒りになり大変なことになったのでした。

問題2: -webkit- つきのプロパティが標準になったときの書き換えが大変

ベンダープレフィックスつきのプロパティは、そのまま標準化されることがあります。 この場合、-webkit- をつけたままのものは廃止予定（deprecated）になります。 そのため、「最後にプレフィックスなしのプロパティを付け加える」ことで、標準化されたものを優先的に利用する書き方が推奨されています。

.something {
  -webkit-background-size: 8px 8px;
  background-size: 8px 8px;
}

しかし、弊社の CSS には、プレフィックスなしのプロパティを併記しないものが多く見られました。 このような CSS がおよそ 57,000 行もあるのですから、推奨されている書き方に直すのも大変です。

つまり、推奨される書き方に従わないままコードが育っていった結果、推奨の状態に戻すことが困難になっていました。

問題3: -webkit- つきのプロパティが非標準になったときの書き換えが大変

ベンダープレフィックスつきの機能が標準化される過程で、CSS プロパティの指定方法が変わったり、機能自体が削除されることがあります。

たとえば、mixi の CSS には、相当前に非標準となった box 仕様のプロパティが使われていました。 この件は Mozilla でも問題になっていたらしく、「mixi.jp Mobile version is using the old-old CSS webkit flexbox syntax」というチケットがつくられており、個人的にはとても恥ずかしい気持ちでいっぱいでした。

このような機能は廃止予定になることが多く、何かの拍子に取り除かれてしまっても文句は言えません。 そのため、廃止予定になった時点で書き換える必要があります。 しかし、既に行数が膨らんでしまった CSS を仕様変更の都度に書き直すのは大変です。

まとめると、非標準な機能を多用すると、非標準の機能が消されることに怯える日々を過ごすことになることがあります。

問題への対処の軌跡

救世主 Autoprefixer

これらの問題に対処するために、Autoprefixer というツールを使うことにしました。 Autoprefixer は、指定した環境に合ったベンダープレフィックスを自動的につけてくれるツールです。

/* Autoprefixer 適用前 */
.example {
   background-image: linear-gradient(#e87451, #c42f02);
}

/* Autoprefixer 適用後 */
.example {
   background-image: -webkit-gradient(linear, left top, left bottom, from(#e87451), to(#c42f02));
   background-image: -webkit-linear-gradient(#e87451, #c42f02);
   background-image: -moz-linear-gradient(#e87451, #c42f02);
   background-image: linear-gradient(#e87451, #c42f02);
}

この Autoprefixer を使うと、問題の1と2を解消できます。 問題3についても、Autoprefixer が可能な限り標準の書き方へと変換してくれます。

ただし、Autoprefixer は既にベンダープレフィックスがついているプロパティに対しては何もしません。 そのため、前作業として CSS のベンダープレフィックスを外すように書き換える作業が必要になります。

CSS:fixme で Autporefixer の下ごしらえ

前述の通り、Autoprefixer の下ごしらえとして、既存の CSS からベンダープレフィックスを取り除く必要があります。

このために、CSS:fixme というツールを使いました。 このツールは Mozilla の方が開発しているオープンソースのツールで、ベンダープレフィックスつきの古い記法を、Autoprefixer にかけられるような記法へと変換してくれます。

ただし、巨大なファイルで作業するにはコマンドラインによる変換の方が便利だったため、魔改造をおこないました（魔改造後のコードは MPL ライセンスにしたがって公開しています）。

また、CSS:fixme で変換されないものもありました。 変換されない理由は、未標準だからか、変換対象から漏れていたかのどちらかです。 この部分は、マークアップエンジニアの方と細かく結果を確認しながら作業を進めました。

このベンダープレフィックスを外す作業が、全体のおおよそ半分を占めています。

Less 導入

さて、救世主 Autoprefixer を使うためには、CSS をビルドする必要が生じます。 そして、どうせビルドするならということで、CSS の表現力を補う CSS プリプロセッサー Less を導入しました。 つまり、Less 移行は、Autoprefixer 導入のついでという側面が強かったのです。😜

さて、CSS から Less へ移行すると変数が使えるようになります。 これによって、保守性を格段に向上させられます。

たとえば、カラーレギュレーションの色を変数にしておくだけでも、管理しやすいことは明らかです:

//- `@basicTextColor`: 基本のテキストカラー
@basicTextColor: #333;

//- `@subTextColor`: 基本よりすこし弱め
@subTextColor: #666;

// ...

カラーレギュレーション以外にも、アイコンフォントのコードポイントを変数によって集中管理しています。また、私個人としては z-index についても変数で管理することを目指しています。

さて、Less の他にも Sass という有名な CSS プリプロセッサーがあります。ここで Sass ではなく Less を採用した決め手は、それぞれの提供されているエコシステムにあります。 Sass は Ruby のエコシステムで提供されていますが、Less は Node.js のエコシステムで提供されています。 そして、Node.js の方が、Perl と同居させるのに都合がよかったのです。

-webkit-box との格闘

これで平和が訪れるかと思いきや、-webkit-box という厄介な問題が立ちはだかりました。

この -webkit-box は、横並び/縦並びの要素の表示制御に関する機能です。 これと同等の機能を実現するためには多大な労力が必要なため、非標準だった当時から重宝されていました。

ただし、この仕様は box（2009年）→ flexbox（2011年）→ flex（現在の最終草案の仕様）と 3 度大きく変更されました（仕様の変遷については flexboxの旧仕様、改定仕様、現行仕様の一覧 « LINE Engineers' Blog という素晴らしいまとめ記事があります）。 そして、-webkit-box はこのうち最も古い仕様で、Autoprefixer が適用できる状態にするには大幅な書き換えが必要です。

たとえば、CSS:fixme は可能な限り -webkit-box を最新の仕様である flex に書き換えてくれます。 しかし、display: -webkit-box があたっている要素の子要素の width に問題が生じます。

-webkit-box 仕様では、width が指定されていれば flex-basis 指定と同等の効果がありました。 しかし、flex を使う時には明示的に flex-basis を記述しなければなりません。

すると、CSS:fixme が width プロパティに遭遇したとき、これが flex-basis に相当するのか、それとも通常の width なのかを区別する必要があります。 このような書き換えは、セレクタの対象の親子関係を考慮できなければ実現できません。

/* ... */

.moge {
  /* 
   * この width の意味は、親要素に display: -webkit-box が
   * あたっているかどうかで変わってしまう
   */
  width: 10px;
}

/* ... */

つまり、BEM のような命名規則で CSS から親子関係を推測できない限り、機械的な検証は困難です。 この問題は、2人がかりでのコードレビューと、凄腕テスターによるステージング環境での動作確認で洗い出しました。

このような QC（品質管理）作業に、残り半分の作業時間が費やされています。 この甲斐あって、57,000 行に渡る書き換えにもかかわらず、不具合報告はきていません。

Less 化における QC への技術的支援

これまでの作業で、Autoprefixer による問題解決が実現できました。 しかし、このままでは、まだ Less の機能を活用できていません。 宝の持ち腐れの状態になっています。

そこで、次のフェーズとして、Less の機能を利用するようにリファクタするフェーズがはじまりました。

このフェーズでは、生成される CSS が変わらないことを期待できます。すると、CSS の AST（抽象構文木）による比較が可能になります。AST による比較では、CSS 内の改行位置や空白の取り方に左右されないため、よりブラウザーの CSS 解釈に近しい結果がえられます。この AST がリファクタ前後で変化していなければ、表示に差異がでないことが期待できます。

ただし、Less のような CSS プリプロセッサーを使えば、AST に差は出てしまうものです。 この AST の差で重要なのは、セレクタ・プロパティの過不足と、ルールの記述順序の2点です。

ここで重要なのは、この2点の深刻度に違いがあることです。 たとえば、セレクタ・プロパティの過不足は、記述漏れの可能性を強く示唆します。 これに対して、ルールの記述順序の差は、スタイルの上書きの可能性を示唆するものの、影響はごく軽微です。 この2つを混同してしまうと、深刻度の高い警告が深刻度の低い警告に埋もれてしまうといった問題が生じてしまいます。 ようするに、この2つは分解して観察することが重要なのです。

そして、既存の CSS の AST 比較ツールには、プロパティの過不足とルールの記述順序を分解して比較できるツールが存在しませんでした。 そこで、css-semdiff というツールを開発しました。

たとえば、css-semdiff を使うと、次のようにプロパティの過不足が発見できます。 このプロパティの過不足は、ルールの記述順序に影響されません。

$ css-astdiff a.css b.css --verbose
extra:
        #header ul {
          display: -webkit-box;
          display: -webkit-flex;
          display: -moz-box;
          display: flex;
        }

missing:
        #header ul {
          display: -webkit-box;
          display: -webkit-flex;
          display: flex;
        }
23 extra rules and 23 missing rules between a.css and b.css

また、ルールの記述順序の差異のみを発見することもできます:

$ css-orderdiff a.css b.css --verbose
order changed: #footDisplay
        become to be higher than:
                .error #mainDisplay,
                .webView01 #mainDisplay

order changed: .error #mainDisplay
        become to be lower than:
                #footDisplay

このフェーズでは css-semdiff を活用した結果、複数の不具合を未然に防止できました。 この css-semdiff は、MIT ライセンスで公開しています。 ぜひ、QC 作業にお役立てください！

後日談

この話は、私が新卒だったころに諦めた Firefox 対応を、1年越しに達成した話でもあります。それだけに、個人的にも思い入れの深い仕事です。

ちなみに、この作業を終えたところ、Mozilla の方からお礼のお返事 をいただきました。

This is fixed. \o/
Thanks to Mixi team and their hard work.

With a lot of love from Mozilla.

この仕事に携われてよかったと思えた瞬間です。😝

まとめ

弊社のスマートフォンページでは次の3つの問題が生じていました。

1. 非 Webkit ベースのブラウザーを考慮していない
2. -webkit- つきのプロパティが標準になったときの書き換えが大変
3. -webkit- つきのプロパティが非標準になったときの書き換えが大変

そして、これらの問題を次のようなツール/活動で解決したという話でした。

1. Autoprefixer
2. CSS:fixme
3. コードレビューなどの QC 活動
4. css-semdiff

次は esugita さんの「Find Job!っていう求人メディアに関わってるので、採用とかとか。」です。

宣伝

ミクシィでは、技術を駆使して負債に立ち向かう闇祓いエンジニアをいつでも歓迎します！ 闇祓いスキルをつけておくと、光環境/闇環境を選ばない技術力がつくことでしょう。

ともに闇祓い、してみませんか？

#師弟登壇2015 でミクシィの新卒研修について発表してきました

side_tana です。年の瀬も押し迫ってまいりましたが、みなさまいかがお過ごしでしょうか。

さて、12月6日に行われたGMOペパボさん主催の勉強会、師弟登壇2015でミクシィの新卒研修について発表をしてきましたので、本日はそのご報告です。
pepabo.connpass.com

師弟登壇という名の通り、講師側と新卒側の人間が二人一組となって発表する勉強会です。弊社からは 師匠 kuniwak とその弟子 side_tana というコンビで発表を行いました。

発表では、ミクシィの新卒技術研修の方針である「現場がおしえる・自分でそだつ」を軸として、

• 新卒研修全体のフロー
• 技術研修に対する考え方
• ミクシィの公開している教材の作成過程・教材を公開する意義
• 研修を受けてみて感じたこと

といったテーマについて話しました。

speakerdeck.com

speakerdeck.com

参加してみての感想ですが、各社の新卒研修の内容から、それぞれの会社の特色や、新卒採用に対する考え方の違いなども透けて見えるようで非常に面白かったです。

ところで弊社では2017年度の新卒採用活動をスタートさせております。ミクシィならではの研修を準備するつもりですので、弊社に興味のある方は以下からエントリーしていただければと思います。

mixi.co.jp

See Also

発表資料中で紹介している資料と、資料公開時のブログポストです。

alpha.mixi.co.jp

alpha.mixi.co.jp

また、githubのmixi-incではその他の教材や、先日行ったgit challengeの問題の一部も公開していますので、ぜひご覧ください！

github.com

第1回git challengeの出題内容を一部公開します

2015年11月15日、ミクシィ渋谷オフィスで git challengeという学生向け技術イベントの第1回を開催しました。#mixi_git

この git challenge とは、問題がおきている Git リポジトリを、次のようなお題に沿って解決していく競技です。

• うまく merge してください
• バグが埋め込まれた場所を特定してください
• push できない原因を特定してください
• ...…

第1回の当日は、このような問題が18問出題され、4時間の競技時間でどこまで解けるかを競いました。ここで出題された問題の難易度は、以下の4段階に設定されています。

• EASY: 調べなくても解ける
• NORMAL: 調べれば解ける
• HARD: 調べた上で考えれば解ける
• VERY HARD: 考え尽くした上で最善の手を選び続ければ解ける

この記事では、このうち実際に出題された問題を 2問 (EASY, NORMAL) 公開します。

ぜひ、チャレンジしてみてください。

問題

なぜか新しいファイルを追加できないリポジトリ（難易度: EASY）

学生向けgit謎解き技術イベント「git challenge」のご案内

第6回git challengeを開催します!

2017/9/2に、第6回git challengeを開催します!
開催にあたってのスタッフへのインタビュー、および参加エントリーはこちらからどうぞ!

開催においては、チームごとに問題数だけ必要なprivate repos, およびノベルティなどGitHub Japanさまのご協力がありました。ありがとうございます!

はじめに

人事 & イノベーション・センター 森本です。

株式会社ミクシィ (ミクシィグループ) では、皆さんにおもしろいスキル体験をしていただくため、そして意欲やスキル・センスある学生さんたちとの出会いのために、さまざまな学生向けイベントを企画・実施しています。

セキュリティ・バグをわざと入れたSNS mixiを攻略していただく「Scrap Challenge」や、スクラム・アジャイルのフレームワークであるインセプション・デッキを体験いただく「Inception Challenge」、あるいはUI改善のデザインプロセスを学べる「Prototype Challenge」など、エンジニア志望、総合職志望、デザイナー志望といったさまざまなスキル志向の学生さんたちに、面白く価値ある体験を提供しようと、取り組んでいます。

そして、来たる11月、また新たな「チャレンジ」イベントを開催します。
git challenge (ぎっと・ちゃれんじ) です。

#mixi_git

gitのテクを体験し競えるイベント

git (ぎっと) は、世界中で広く使われている分散型バージョン管理システムです。技術系の方であれば既にgitが手に馴染んでいるかたも多いと思いますが、あらためてgitについて簡単に振り返ってみます。

複数人でデジタル作業を行う場合、作業結果のすり合わせは常に重要です。

「せっかく編集したファイルを同僚に上書きされちゃった」
「人の作業を待たず、別の編集もとっととやりたい」
「先週のバージョンに戻りたいけど、もう戻れない……」

こんなの嫌ですよね。

そんな、現場の込み入ったコラボワークを助けてくれるのがファイルのバージョン管理システム(Version Control System)です。古くからさまざまなVCSがありますが、その中で最も強力で、性能や実績、普及度でも優れるのがgitです。いわゆるプログラム開発だけでなく、電子書籍の共同執筆校正など、一般的なデジタルコンテンツの共同作業にも、いまや広く使われています。

もちろんミクシィでも、モンスターストライク、SNS mixi、ほか各種サービスやアプリの開発でgitを大規模に活用しています。高品質なプログラムやコンテンツを大人数で速やかに手がけていく現場では、gitの使いこなしも一段と本格的。時には、込み入ったバージョン分岐や後戻り、マージを解決しなければならないこともあります。そんな、今の現場ならではの解決スキルをうまくチャレンジ課題としてイベントし、みなさんに体験して学んでいただき、そしていつか一緒に課題解決できる仲間として出会いたい。

git challengeは、そんな1 dayの技術体験イベントです。

応募要項

開催日: 2015.11.15(日) 11:00-19:00
会場: 株式会社ミクシィ本社(東京・渋谷)
〒150-0011 東京都渋谷区東1-2-20 住友不動産渋谷ファーストタワー7F
http://mixi.co.jp/company/#access

ほか詳しい情報、そしてエントリーは、ミクシィグループ新卒採用サイト から
「【1 day技術イベント】git challenge」をご覧ください。

応募締め切りは2015.11.4(水) 23:59 JSTです。
興味お持ちのかたは、ぜひお誘い合わせのうえどうぞ!

git challengeの舞台裏

Scrap Challenge, Inception Challenge, Prototype Challengeと、ミクシィのワークショップイベントは、企画も実施も手づくりです。そのほうが、ミクシィならではの技術やノウハウをユニークにお伝えでき、体験していただけると思っているからです。このgit challengeも、若手エンジニアが「何かおもしろいyet another foobar challengeはないかな……」と考えて産み出してくれたものです。

そんな彼らはというと。

おっ、先日オープンしたばかりの、ミクシィの新たなコラボスペースの奥にある通称「ファミレステーブル」で、ちょうど彼らがお昼休みに、git challengeの設問についてコミュニケーションしているところではありませんか(棒)。

今回、git challengeの企画発想から、設問やシステム構築に至るまで技術的立ち上げのコア部分を担当してくれているのが、彼ら3名のコアメンバー。全員2014年の新卒入社です。

森本 (github.com/mrmt): おつかれさまです。まず、簡単な自己紹介から教えてください。

村山 (github.com/oppai): 2014年新卒入社の村山です。仕事は、モンスターストライクのサーバまわりの新機能の開発や、運用まわりを担当しています。

菊池 (github.com/kikuchy): 同じく2014年新卒入社です。いまは株式会社Diverseに出向して、YYCのAndroid版クライアントの開発をしています。

国分 (github.com/Kuniwak): 2014年新卒入社です。仕事は、SNS mixiのフロントエンドの闇払いをしています(笑)

mrmt: 闇払いとは……

Kuniwak: たとえば、mixi.jpでは生で直接CSSを書くのをやめてLESSに移行したんですが、対象コードサイズが6万行だったりしました。あとは例えば, gulp.jsのビルド時間が2分かかっていたのを10秒に短縮したりしました。基本的にはincremental buildを作るんですが、加えて自分でplug-inを作ったり。

mrmt: 仕事人感ある…… ありがとうございます。

mrmt: そもそも皆さんには、「次の新たなチャレンジ・イベントを創ろうよ」というレベルから相談に乗っていただいていて嬉しい限りです。このgit challengeのアイディアが降りてきたのって、どんなタイミングでした?

Kuniwak: ちょうどその一ヶ月ぐらい前、gitで死ぬほど苦労した覚えがあって、「あっ、これ問題作れるレベルだな」と思ったのがきっかけかも。

oppai: 業務で共同開発していくと、Kuniwakくんが言っていたように、やっぱりいろんな(バージョン管理の)課題にぶつかります。このレベルの課題は学生の頃は体験できなかったので、ならばgithubやCIを組み合わせて、攻略型のイベントに仕立てたら面白いんじゃないかと。

kikuchy: 学生のうちに、ここまで体験したり教えてもらえたら嬉しかったな…… というのはありますね。

mrmt: なるほど。では、git challengeの仕掛けを作り始めてみて気づいた難しさは?

kikuchy: そうですね…… まず問題を作って、その問題が果たして自分の意図したレベルで解けるものになっているかな…… という難しさがひとつ。
次に、それ(問題となるようなgitのややこしい状態)を再現するために自分で手を動かして作るのが大変で、ただ、それを自動化しようと思うと、それもなかなか大変。改めて、他のVCSと比べるとgitのマージ性能の高さはまさに圧倒的。日頃使っているツールのメリットについても再発見できました。

Kuniwak: 問題を作っている本人ですら、今が(git的に)どんな状態なのかよく分からなくなるような難しい問題を作り出してしまったり。これも、実際に問題を作ってみてわかった難しさですね。

mrmt: 問題の難易度を調整するチューニングにもかなり苦心してらっしゃる……

Kuniwak: 苦心してますね。すぐに分かる問題にしちゃうと面白くないので、ひとひねり加えたりとか。

oppai: 参加者には「gitの困難」に立ち向かってみてほしいので、例えば特定のプラットフォームや言語に依存したプログラムやスクリプトといったものは課題としていません。

mrmt: 実際、入社前にもgitやgithubは使ってました?

kikuchy: いちおう使ってはいました。が、一応commitができて, mergeができて, remote repositoryにpushができる。という程度の技能しか持っていなかったので、reflogを見たり、refspecいじったりとか、そういうことまでは学生当時はやらなかったです。

oppai: 僕はアルバイトでsvnをずっと使ってて, gitは個人開発でしか使ってなかったです。subversionはどうしてもcommitの粒度が大きくなるので、そのぶんtrunkを常にきれいに保とうというインセンティブが働きます。その点、gitは分散VCSなので、commit粒度は仮に細かくてもpullやmergeの大きさが違うなど、文化の違いも感じました。

Kuniwak: 学生のころ、大学のゼミで、論文のテンプレートをみんなで管理したくて、githubへの移行を呼びかけたんですが、結局自分ひとりで使っていたという……

mrmt: 「みんなに使ってもらう」ところが一番難しいんですよね…… わかります。

ラスボスのキャラ

mrmt: では、その後に入社して、職場で出会ったgitやVCSの難しさにはどんなものが?

一同: それは…… そのへんのエッセンスが今回の問題になっているので、ネタバレが…… (笑)

Kuniwak: 恐らく、git challengeの中で一番むずかしい問題は、自分が体験した、その1ヶ月前の体験です。

mrmt: 最後の、ラスボス的な……

Kuniwak: ラスボス的なやつですね(笑) 詳細は明かせませんが、「過去に雑なことをすると、あとで面倒なことになる」というのが、最終問のテーマです。

mrmt: なるほど。それを解いて体験することで、git共同作業での良き考え方や姿勢も身につくぞと。

Kuniwak: そういうことです。

commitlogを解き明かせ

mrmt: git challengeには、どんなかたに来て欲しいですか?

Kuniwak: 個人で使うだけではわからないgitの難しさがあります。複数人で作業を重ねていくとどうなるか。それを体験できます。

kikuchy: 仕事として働く際のgitの実活用を知りたい人かな? 今回の課題まわりをちょっと知っただけで、ぐんとgitを扱いやすくなる。

oppai: ほかにもCI連携や、Slackに通知させたりとか、そんなチーム環境も学んで体験できると思います。

Kuniwak: このgit challengeの参加者にとって、またgit上級者にとって最も重要な資質は、gitを知っていることではなく、gitのcommitlogを解き明かすこと。この部分について、とても実力がつくと思います。

git challengeの開催は2015.11.15(日)です。現場から生まれたgit問題を解き明かしていくことで、本場のgit力 (ぎっとりょく)が身に付く体験を、ぜひ楽しんでください!
エントリーはミクシィグループ 新卒採用からどうぞ。

再掲

git challenge 第2回を2016/3/5(土)に開催します!
詳細と応募はこちらをごらんください!

では、会場の渋谷ミクシィでお会いしましょう!

Lightning Talk for Over 18 #0 参加レポート

はじめまして。ミクシィグループの株式会社Diverseでマッチングアプリを開発している徳永です。

友達作りから結婚相手探しまで、様々な出会いをサポートしています。

生き生きと、人と人との出会いのお手伝いをしています！

そんな私にぴったりな、大人の社交場イベント《Lightning Talk for Over 18》（以下LTO18）が、2015年8月3日にミクシィ社7Fコラボルームにて開催されました。

私はスタッフとして当イベントに参加しましたので、イベントの概要と雰囲気についてご紹介させていただきます。hashtagは #LTO18 です。

LTO18とは?

イベント告知ページの説明にはこんな説明が載っています。

18歳以上向けの情報共有のための社交場です。
真面目に取り組んだけど発表できそうな場がない人に、
LTO18は発表内容にとらわれない系イベントで、
ニッチな知見を技術を発信、共有できます。
本質的な時間を過ごしましょう。

なるほど。説明文を見ただけで唯ならぬ雰囲気を感じます。

約束事も書いてあります。

• 真面目に技術や知見を共有しましょう。
• 健全化のために利用できないか考えてみましょう。

どうやら、一見すると怪しいイベントですが、内容はいたって真面目なイベントです! 今回は #0 とのことで、第0回めの試験開催ということでした。

発表タイトルと概要

登壇者と発表タイトルの一覧がこちらです。タイトルだけで内容が気になるものばかりです！

時間	登壇者	タイトル
19:50~20:00	kiy0p0nさん	会場説明とLTO18の概要について
20:00~20:20	Takuya Iwamotoさん	日本の出会いが歩んできた道、そして今
20:20~21:00	ブラックキャットさん	商業作品におけるトランス状態の重要性
21:00~21:20	shimaさん	ホール素子を使って 紳士的なデバイスを作ってみた
21:20~21:30	kuniwakさん	ポルノリワードの力
21:30~22:30	懇談会

開会前

会場につくと何やら怪しげな動画が流れています……

これから何が始まるのかワクワクさせられます！

LTO18について

LT大会の始まりです。はじめにLTO18運営のkiy0p0nさんから会場の説明と、LTO18についての説明が始まりました！

肌色やモザイクの検出をしてみたけれど、発表する場所が無く、夜な夜な枕を濡らしているそうです……

きわどい表現が入った画像を出しながら、ここぞとばかりにその裏側の技術があることを熱弁するkiy0p0nさん。LTO18がエロメインではなく、技術や知見をメインにしていることが伝わってきます!

日本の出会いが歩んできた道、そして今

続いてTakuya Iwamotoさんから、日本の出会い系の歴史についての発表です。

Iwamotoさんは大学、研究機関で恋愛とITについて研究しており、男と女のためのシステムを主に開発している方です。活動は http://takuyaiwamoto.com/ にまとめられています。

発表の中でも、「口臭を利用したシューティングゲーム」、「妊娠をリアルに体験するデバイス」、「ポッキーゲームをするデバイス」などの個性的な活動が紹介されました。

そして、本題の出会いが歩んできた道が濃い…！

• 出会い系の語源は個人情報誌じゃマ〜ル（という説が有力）
• 最初の出会い系はテレクラ
• 「伝言板ダイアルには同性愛の符号などがあった。例を見てみましょう。1130。これはイイサオですね」
• 「ご近所さんを探せ」出会い系webサイトの走り
• 出会い系が風営法に潰される
• 05年の大学男子と大学女子は約40%ぐらいは合コンをして出会っていた
• 出会い系規制法で、デーティングによる被害児童数は下がったが、別の場所に移っただけ
• 未来のマッチングサービスは「出会っちゃった系サイト」

発表では研究機関のデータを用いた説得力のある仮説が繰り広げられました。

参加者の中からは「俺のために研修してくれ！」という熱い声が起きました！

商業作品内におけるトランス状態の重要性

次にプロフェッショナル心理のブラックキャットさんから、クリエイターが製作において気をつけたいことを心理面から解説していただきました。

発表はなんと…… 事前録音された音源による発表！！！

「なんだこれは！（ざわざわ）」と戸惑う参加者を尻目に淡々と発表が進みました。

発表の中で重要とされたことは、「変性意識*1を作ること」とのことでした。

顧客に対して変性意識状態をつくってからメッセージを与えることが作品を効果的に伝える方法であるとのことです！

発表では、どのようにして変性意識を作るか、身近な変性意識を作る具体的な例を紹介してもらいました。参加者全員でサンプル動画を並んで見るといったように、始まりから終わりまで独特な雰囲気でした。

ホール素子を使って紳士的なデバイスを作ってみた（仮）

続いてshimaさんの発表です。

タイトルの「ホール素子」ってホール形状の大人のデバイスのことなのか？と、ざわつくスタッフたちを尻目に発表がスタート！

shimaさん「嫁（抱き枕）を抱きしめたい人向けのデバイスを作ろうかと思って」

参加者（うんうん、わかるわかる）

shimaさん「なんかこう、ぎゅっと抱きしめたい」

参加者（おっ、発表に熱がはいってきたぞ）

shimaさん「ホール素子（電子）使って胸部デバイス作ってみました！」

参加者（常軌を逸している…！（褒め言葉））

というような欲望目標から、シリコンパッドとガチのホール素子を使った電子工作で胸部のデバイスを披露していただきました。揉み具合でモニタ上のLive2D*2キャラクターが様々な反応してくれるという夢のようなデバイスでした！

きちんと服を着せられた胸部デバイスと出会ってしまい、笑顔がとまらない様子。

Porn Rewardsのチカラ

最後にkuniwakさんから、実例に沿ってポルノリワードのパワーについて発表していただきました！

簡単に発表内容をまとめてみました。

• えっちなご褒美でキャプチャを解かせる Turing Porn Farm について
• ポルノ画像でパスワードを強くするツール Naked Password
• フリーで使えるポルノ素材の紹介 

ポルノを報酬に出せば人はこんなにも簡単に難題を克服してしまうことを実感させてからの、

kuniwak「エロのもつチカラを世の中のために使おう！」

という清清しい言葉で綺麗に締めていただきました。

ポルノを真面目に利用することを発表するLTO18らしい発表でした。

懇談会

長丁場の発表が終わり、ピザを囲んで懇談会のスタートです。

お腹を満たしながら参加者同士で大人の会話を楽しみました。

また、ブラックキャットさんのサンプル動画を見直す人、shimaさんの胸部デバイスを実際に触ってみる人など、気になるコンテンツを思うがままに堪能していました。 

おわりに

発表資料は色々な理由で表に出せないことが惜しまれます。

イベントの様子はtogetterでまとめて頂きましたので気になる方はぜひご覧ください。

当イベントは、参加しないと体験できないものが多いですが、とても本質的で面白いものでした！今回は第0回めとしての試験開催でしたが、つづけて正式に第1回を開催させていただくあかつきには、皆さまもぜひご参加いかがでしょうか。ハッシュタグ #LTO18 をウォッチよろしくお願いします!

*1:日常的な意識状態以外の意識状態のこと。変性意識であるとき、人はとても影響を受けやすい。

*2:Live2D公式 http://www.live2d.com/

体験とイノベーション: トライアウト・ランチ, SWLT

イノベーションセンター 森本です。

ミクシィでは、社内からの新規事業アイディアをすくいあげ、プロダクトにしていくフレームワークがあります。それが「ミクシィ イノベーションセンター」です。今年は「きみだけLIVE」をローンチし、振り返って既に独立したものも加えるとDeployGateやノハナ、そしてminimoや家族アルバム みてねといった新規アプリサービスのプロジェクト群も仲間として動いています。

アイディアの敷居を下げる

アイディアをプロダクトにするには、しっかりした仮説とその裏付け、マーケット検証などが必要です。しかし、そこまでプロットを固めていく前の「思いつき」状態にあるものも大事です。まずは過去の先入観やサンクコストなくアイディアを和気あいあいと検討し、その中のいくつかは経営会議にかけられるまで育てていく。そんな「アイディアの最初の持ち込み場所」として、イノベーションセンターでは「トライアウト・ランチ」という昼休みのブレイン・ストーミングを、渋谷オフィス7Fコラボルームでグループ社内の自由参加者を相手に毎週開催しています。

今年2015/4に入社したばかりの新卒のみなさんも参加してくれてます。フレッシュなかたほどフレッシュです。こういう場に加わってみたい、とお思いのあなた、2016/3あるいは2015秋卒業予定のかたでもいらっしゃい!

アイディアとの出会いを作る

新しいアイディアは座っていても出づらいものです。人に会ったり、旅行したり、あるいは新しいデバイスやガジェットで遊んでみたり。体験してみることも重要です。

今年の春のガジェット系のひとつの潮流だったのがスマートウォッチです。特にApple Watchの登場がこの流れを加速したことは間違いないでしょう。

この手の生活ガジェットは、カタログスペックだけでは推し量れない、「暮らしてみてどうか」という、生活でのスペックや課題解決がポイントです。通勤の朝、仕事中やランチ、そして自宅でのくつろぎやお掃除・お台所仕事など。そんなユースケースでどのようなメリットの芽が見えてくるか。

とはいえスマートウォッチはまだまだそう安いものではありません。ごく真面目に「いま、それ、要るものなの?」と彼氏や奥さんに目を見て問い詰められたら、思わず ゴクリ…… と反応してしまうこともあるでしょう。そんなあなたに。ミクシィ(およびミクシィリクルートメント)では社員を対象に、この春にスマートウォッチ購入補助制度を走らせていました。スマートウォッチ購入額の半額を会社から補助する制度です*1

「技術と利用シーン両面に変化をもたらすデバイスをタイムリーに体感してもらうことで、価値創造の質とスピードを高める一助とする」これがこの制度の狙いです。

アイディアの交換場所を作る

制度が走りだし、そして2015/4/24にApple Watchの発売が開始され、社内に徐々にスマートウォッチのユーザを見かけるようになりました。私も含め、Apple WatchのTaptic Engineの「コツコツ」「ぶるぶる」の魅力を体感した者も増えてきました。

体感して分かった「いいところ」、あるいは「イマイチなところ」を情報交換ようよ。やろうよ。ということで、いつものミクシィ7Fコラボルームで、スマートウォッチをテーマとしたライトニング・トーク「Smart Watch Lightning Talk」(略称SWLT) を開催しました。自分の手元のスマートウォッチの画面を会場に見せながらプレゼンターが説明できるよう、カメラやスクリーンも工夫しました。

  

さて、どんな情報がやりとりされたのか。

このLTでは、あえて技術論やAPIのあれこれにはテーマを置かず、「生活とスマートウォッチ」に着目して敷居を低く展開したお陰で、楽しいぶっちゃけ話が多くなりました。

  

公開可能なスライドから2点あげておきます。

SWLT: Smart Watch Lightning Talk

最初のスライドは、イベントとしてのキーノートに加え、私がApple Watchと生活してみての気づきです。

Apple Watchは「他人に見られない情報通知領域」として極めて有効です。パソコンやスマートフォンやタブレットは、他人の目から情報を守る手段として

• 積極的には: ユーザ操作による画面ロック
• 消極的には: 最終操作以降の時間発動による画面ロック

を採り入れています。ですが前者は習慣としての努力が必要ですし、lazynessこそがイノベーションの鍵だとしたら「習慣づけ努力」は悪です。後者は「一定時間操作が途絶えた場合、画面がユーザ管理下にあるとはかぎらない」という根拠の薄いロジックに立っています。
さらにスマートフォンではユーザ利便のため積極的にロック画面にも情報通知を行いますし、それが手元にある情報機器の価値です。しかし、それが常にmy eyes onlyになっている担保はありません。このジレンマ。

Apple Watchは、腕につけている間はロックにならず、情報通知が常に行われます。そしてこの画面は常にmy eyes onlyです。腕から外すとロックされ、通知はもう出ません。この切り分けは生活してみると大変快適です。Android Wearの、素直にAndroidアプリに通知機能を実装するとスマートウォッチにも現れるという思想は綺麗ですが、生活とプライバシーの面ではWatch OSに一日の長がありました。本当は、ウォッチにだけメッセ内容を通知するという切り分けができたら最高なんですけどね。

ActivetéPopを使ってみた

「スマート体重計」で知られているフランスのWithings社が出したスマートウォッチです。デザインは美しく、やはり健康方向への眼差しをしっかり持っています。なんと水泳の履歴まで取れるそうです。

ほか、いろいろおもしろいLTがありましたが、公開は割愛させてください。特に最後の「とあるゲームアプリをより便利に遊べるApple Watchアプリ」の試作品は、腕に付けて動いているところの写真にとどめておきます。

続けて次回は、ガジェットというには大柄ですが「電気自動車を借りてきた編」をお届けしようと思います。

*1:補助額には上限があります。2,180,000円のApple Watch Editionを購入すると、会社が1,090,000円出してくれるわけではありません