created at: Fri, 09 Feb 2018 01:51:50 GMT updated at: Fri, 09 Feb 2018 02:15:55 GMT
DeNA TechCon 2018 『『Nintendo みまもり Switch』を支える技術』 の内容紹介と感想
そういうわけで https://techcon.dena.com/ にいってきました。
表題の発表は、撮影および SNS での内容共有の禁止ということになっていたので、内容を個人サイトで共有致します。その場にいなかった方でこの記事を読んだ方であればこの記事およびその内容を SNS で共有することは一切禁じられないかと思いますのでよろしくお願いします。
発表者
公開されたスケジュールでは堀および平賀による発表ということになっていたが、任天堂の何者かが急遽参加したということだった。おそらく技術者ではなく広報の人。
サービス紹介 (任天堂の人)
サービス内容については検索すれば分かることを普通にしゃべり、クッパがサービスを使うあの動画を流すだけ。(ssig33 の感想: なにしにきたんだコイツ)
開発体制 (堀)
任天堂は企画、ディレクション、 Switch のサーバーなど
DeNAは企画サポート、サービス固有のサーバーやアプリなど
実際にはぱきっと分かれてたわけでもなく相互にいろいろやってた。
開発プロセス (堀)
Switch の開発がいるのがプロセスとしての特徴的な点。 FW のケツがはやかったので配慮が必要だった。
プロトタイピングはかなり気合入れた。機能をほぼ作り込んでユーザーテストを実行。
検証とフィードバックは開発中繰り返した。
開発のハードル
- コンセプトの共有は難しい。
- 親にACアダプタ隠されたとかない人に伝えるのは難しい。
- ゲームやる時間とか自分でコントロールできてた人もいる。
(ssig33 の感想: この辺悪ガキだった経験ない人にはたしかにめっちゃ難しそう、そしてそういう優等生タイプの人がチームにたくさんいたのだという部分について意外に思う、が今の DeNA はそういう会社ということなのだろう)
行動分析、ペルソナ設計などなどやっていった
利用者の多様性という問題
Switch はグローバルに売られるもの。法律、文化は国ごとに違う。成人年齢ももちろん国によって違う。概してペアレンタルコントロールについて海外のほうが日本よりキツい。
デバイス間のペアリングというのは一般的にかなり難しい作業。非パワーユーザーにここ理解させるのは難しい。
ドックフーディング会を多々開催。任天堂海外ブランチがあるのでそこにも協力してもらった。 QA 部門からのフィードバックも受けた。
多拠点
任天堂は京都、 DeNA は東京、任天堂海外ブランチも関与という体制。
プロトタイピング期間は合宿を開催。開発中はテレビ会議を多用するほか出張も多々あり。合宿も続けて定期的に開催した。
開発プロセスにおいて銀の弾丸はないというのを改めて実感したとのこと。
Switchとアプリの連携 (平賀)
おもにサーバーサイドの話。
(ssig33 の感想:この話をしたエンジニアの話し方が異様にすっトロくて時間も大幅にオーバーしていた上に内容も「まあそりゃだれがやってもこうでは、、、」というものでかなり悪印象。)
嫌がらせ(この記事を書く行為)のために聞いていたのだが、この辺からもうだるくなってきたので以下適当な箇条書き。
- スマホからみまもり設定をするのだが、どのデータをマスターとすべきだろうか? => サーバーということになった。
- アプリはサーバーに設定を送りつけ、 Switch はなるべくすみやかにサーバーから拾ってきて適用する
- Switch には Switch 用の通知機構があるので、それで設定更新を通知している
- 本当にシンプルにつくって以下のような課題があった
- なるべく即時反映してほしいがそうならない
- おそらく当初の「シンプル」な実装には通知機構の利用が含まれていなかったものと思うがそのあたり言及なし
- オフラインの Switch には設定を反映させられない
- (ssig33 の感想: 前段において「サーバーをマスターにする」云々の話をわざわざしたというのは、ユーザー家庭内のネットワーク(WiFi や BT)で Switch とスマホを直結してみまもり設定を更新するという実装にすればオフライン問題は解決する。一方で利用難易度や典型的な状況での可用性は悪化するだろう。このあたりにいろいろ仕様決定の上で葛藤があったのだと思う。)
- 反映状況をユーザーに見せたいが難しい
その上で最終仕様は以下の通り
- 保存ボタン押されると反映中とアプリに出る、しばらく出る、Switchにデータ行ったらその場で終わったと出す
- 規定の時間が経過して反映されなかったら「ダメだった」とアプリに出す
- Switch がオンラインとなり設定が反映されるとスマホにプッシュ通知
以下のような実装
- サーバーには「設定」というリソースと「設定反映ステート」というリソースが定義されている。
- アプリは「反映中」と出してる間ステートリソースをポーリングする
- Switch は通知が来たら設定リソースを取りにいく
- 「デバイス(Switch)」というリソースもあるのだが、これ更新をフックしてステートリソースは「同期済み」というステートになる。
- ポーリングしていて「同期済み」になったら「反映完了」がでるという仕組み
- 一方で規定時間が過ぎて「ダメだった」と出したタイミングでステートは「ペンディング」になる
- 「ペンディング」から「同期済み」になったタイミングでプッシュ通知をする
各種の操作された時間とかを E-Tag でやり取りしているとのことだった。 (ssig33 の感想: REST っぽい API 用意してやるほうが遥かに簡単そうだがなぜこうなったのか、、、)
「遊んだ時間」 という機能は GCP の Cloud Dataflow を活用しているというおはなし
Switch 側は以下のようになっている
- Switch が各種ログをサーバーに送る
- ソフトの起動
- 今日これまでの起動時間
- 暗証番号ミスった
- などなど
それを用いて「デバイスごと」「ソフトウェアごと」に起動していた時間を記録する。
初期実装は以下のようなもの
- エンドポイントは GAE
- タスクキューを経由して BigQuery に保存
- MapReduce で集計する
この実装の問題点は以下
- MapReduce の性質上即時更新できない
- MapReduce がリソースバカ食いする
- MapReduce のサポートが GAE で終了
そこで Cloud Dataflow のストリームパイプラインを使った
- エンドポイントは Google Cloud Pub/Sub
- Pub/Sub から Dataflow のストリームパイプラインに
- パイプラインは BigQuery に全データを入れつつリアルタイムに集計
- 何故集計もするのに BigQuery にもデータを入れるのか?それは全データが BigQuery にあるとデバッグや開発になにかと便利であるのと、バックアップストレージとしても有用だから
これでやってみて
- セッションウィンドウが便利だった
- 結果的にほぼリアルタイムに集計されるようになった
- 使用リソースは激減、ワーカーが 1 個になった
- 処理プロセスが可視化された
- シーケンシャルな時系列データの処理は Cloud Dataflow とマジでマッチしていた
- ストリームとバッチでコード共有できるのもよい
- モニタリングコストも削減された
アプリの話 (堀)
サーバーサイドの話が大幅に時間オーバーしたためかなりかっとばし気味。
- ロジックはサーバーに寄せてる
- 認証は内製 SDK
- ライブラリの管理とかも普通
- CD に fastlane
- クライアントは直接 Switch 見ない
- Switchの状態で通知とかはあるよ
- MVVM で RxSwift 使った
(ssig33 の感想: アプリについては「とにかく普通」という印象。「普通です」というようなことも実際言っていた)
ローカライズの話
- 10言語とか対応した。ローカライズは業務フローから設計する必要あり。
- 翻訳は任天堂が対応、任天堂に翻訳作業の環境があった。
- SVN に独自フォーマットの XML が入ってて、その XML をいじる Windows アプリがあるというもの。
- それ使うにしてもアプリでは？その XML に記載されているものをどのように読めばいいのか?
- ゲームではマスターをサーバーからロードとかがありがち
- 今回はアプリのバイナリに入れた
- 実用アプリでロードがはいるのは UX を毀損する、またデータ読み込みがエラーをおこして欠損があったときにダルい。
- rubygem 作って xml パースして各種モバイルアプリ用のリソースにするものを作った
実機検証の効率化には以下のような工夫が
- いちいちビルドするのがタルいという問題意識
- ライブラリ作った
- ランタイムでリソース入れ替え
- ユーザーが見えるとこにリソース吐いて書き換えられるようにした
- iTunes 経由とかでその場で書き換えながら作業してたとのこと
- ローカライズ作業専用ビルド作って翻訳者に渡した
- リリース版アプリでリソース入れ替えて遊ぶとかはできないようだ。
画像のローカライズの話
- 画像に書かれてるものは↑の手法が適用できないので言語ごとに画像を作った
- 画像は大きいので webp をつかった。
- (ssig33 の感想: ウェッピーってちゃんと発音してて好印象)
- png の 1/15 とかになってすごい
- 300KB の画像が 20KB になるのって意味あるの? => とにかく画像が多いので全体では効いた
発表全体の感想
正直これらを誰が作ってもこうなるだろうというもので「SNS 共有禁止」とするのは謎すぎる。
また「SNS 共有禁止」というのも謎。俺がこうやって個人サイトに書いて、その内容をさらに別の人が SNS に共有すれば問題ないし、そのように共有された場合内容がさらに劣化されて市中に流布することになる。
普通に公開可能とするか、一切外部で共有禁止とすべきなのではないか。
任天堂の広報はクソ。頭悪すぎると思う。
イベント全体の感想
この発表を行なった平賀氏以外にも特に新卒 2-3 年目の技術者を中心に発表の練習不足が目立つ。内容どうこう以前の問題。部署内の勉強会とかで事前に一度でも発表してればあんなことにならないだろうと思う。正直 DeNA 内部での教育にはかなり不安を感じる。
DeNA においていわゆるトップ層の技術者がそこまで層が薄くなっているという話はあまり聞いていないのだが、裾野はかなり荒廃している可能性があると感じるイベントだった。この内容で「おっしゃ DeNA に転職するか!!!」とはならないんではないか。 LINE の開発者イベントとか見習ったほうがいい。
back to index of texts
Site Search
Update History of this content