ネットワークサービスのシステム開発と運用を担当。
ネットワーク開発運用部は、ゲーム用のネットワーク系機能の基盤システムの開発と、ゲームソフトのダウンロード販売などのインターネットを使ったお客様向けサービスのシステムの開発、およびそれらの運用業務に携わっている部署です。ゲーム用のネットワーク系機能は、たとえばオンライン対戦/協力ゲームのマッチングやランキング集計、ゲーム中での決済やオンラインストレージなどがあります。サーバー系のエンジニアが多い部署ですが、Webフロントエンドのエンジニア、ゲーム機側のプログラムを担当する組み込み系エンジニア、ディレクターなどもいて、連携しながら仕事をしています。たとえば「マリオカートTV」というWebサイト。Wii U専用『マリオカート８』の投稿動画や、フレンドのタイムアタックの結果などをPCやスマートフォンで見ることができるサービスなのですが、HTML5/CSS3/Ajaxを駆使したリッチなUIもすべて部内のエンジニアで実装しています。私はこれまでWiiショッピングチャンネル、3DSのニンテンドーeショップ、Wii Uのニンテンドーeショップといった、ゲームソフトのダウンロード販売サービスの、サーバー側のアプリケーション開発を担当してきました。
入社早々から携わったWiiショッピングチャンネルのシステム開発。
最初に関わったのは、Wiiショッピングチャンネルの「手助けポイントキャンペーン」対応の開発です。自分がチームに加わったときにはすでにWiiショッピングチャンネルの機能はほとんど完成していましたが、キャンペーンの仕様に沿って、条件を満たした対象者が特定の商品を購入しようとするときだけ無料になる、といった仕様に沿って個々の処理の追加実装を行いました。技術的にはJavaのJSP/Servletといった一般的なものが使われていて、個人的によく知っている技術でもあったので、実装方式や開発環境についても意見を出して積極的に改善していきました。私は大学時代にWebアプリケーション開発のアルバイトをしていたこともあり、その経験を初めての仕事にうまく活かすことができたと思っています。
ニンテンドーeショップのバックエンドのシステムを設計。
入社から1年が経とうとする頃、ニンテンドー3DS向けのニンテンドーeショップのプロジェクトに加わりました。クライアントとサーバーで大まかにチームが分かれていたのですが、私はサーバーのチームで、ニンテンドーeショップで扱う商品やプロモーション素材の登録ツールや配信サーバーなどのバックエンドのシステムの設計や実装を担当することになりました。Wiiではゲームを購入できる「Wiiショッピングチャンネル」と、プロモーション映像が見られる「みんなのニンテンドーチャンネル」というアプリケーションが別々になっていて、前者ならゲームの価格や税率、後者なら大容量の動画、のように、それぞれのシステムで扱う情報にも違いがありました。そのため、情報を配信するサーバーの仕組みも、キャッシュの有効期限やクライアントサーバー間の通信を行うタイミング等、設計思想が大きく異なる部分がありました。ニンテンドーeショップでは、販売とプロモーションの2つの機能を1つのアプリケーションにまとめたかったので、これらの既存のシステムの特徴と背景を理解しつつ、ニンテンドーeショップのための新しいバックエンドの仕組みをどのように作るか、といった感じで検討が始まりました。
商品やプロモーション情報を登録する管理ツールを、登録する人にとって扱いやすいものにすることも私の仕事でした。たとえば、日本での販売だけを考えると1国1言語の価格やテキスト情報を登録するだけで済みますが、Nintendo of Europe（NOE）では複数の通貨での価格設定と、最大8言語のテキスト情報の登録を行います。どういう手順でどのように入力させれば、間違いが少なく楽に入力ができそうか、なども考えながら管理ツールのUIを決めていきました。配信サーバーに関しては、キャッシュを使った体感速度の向上と情報更新のタイムラグのトレードオフの問題もありました。たとえば販売価格は時間によって改定される場合があり、価格の変更が画面にすぐに反映されないと、お客様はもちろん、関係者に迷惑をかけることになります。キャッシュを入れる箇所や有効期間は、サーバー負荷に配慮しながら注意深く検討して対応していきました。このときに幅広い仕事に関わったことが、現在の業務のベースになっています。
アメリカの開発関係者と頻繁にやりとり。
ニンテンドーeショップの開発・運用は、Nintendo of America（NOA ）のサーバーエンジニアのチームとも密接に協力して行っています。NOAはシアトルを拠点にする任天堂のアメリカ現地法人で、NOA側メンバーとは週1回の電話会議で話し合うほか、メールやインスタント・メッセンジャー (IM) で頻繁にやりとりしています。ただ、言語だけではなく時差の違いもあって、コミュニケーションには苦労します。日本の深夜の間、NOAの営業時間中に解決してもらおうと不具合などの対応をお願いしていても、重要性や緊急性、依頼内容がうまく伝わらないと、対応してもらえなかったり不十分な対応になってしまったりして、場合によっては翌日も問題を抱えたままで1日過ごさなければならないことになります。そういう問題をできるだけ起こさないように、コミュニケーションの改善はいつも考えていて、IMやタスク管理システムなどの環境面の整備を進めたり、NOA側で少し遅くまで残って対応できる当番を立ててもらったり、アメリカに出張して担当者とフェイス・トゥ・フェイスで集中的に話し合ったりと、さまざまな試みを行っています。コミュニケーションの積み重ねで相互理解が深まり、今では意志疎通もスムーズになってきていると思います。
すべてのプラットフォームに対応するシステム構築。
ニンテンドー3DS に続き、Wii Uのニンテンドーeショップにも携わることになり、以前から考えていたシステムのアーキテクチャについて提案しました。今まではWii、ニンテンドーDSi、ニンテンドー3DSと新しいゲーム機がリリースされるたびに新しいショップとして作り直さなければならない部分が大きすぎると感じていました。ハードウェア・OSの仕様や性能なども考慮して実装が決まるので仕方がないことではありますが、今後いろいろなサービスが立ち上がることを考慮して、再利用可能な部分を大きくして、新しいサービスのチャレンジにより多くの力を割けるように、アプリケーションドメインの整理と機能のレイヤー化を行い、複数のWeb APIサーバーを中心としたアーキテクチャの設計をしました。基本的なビジネスロジックが共通モジュールとして実装されていれば、実装やテストの効率は飛躍的にアップすると考えたからです。Wii Uのニンテンドーeショップをリリースした後に、ニンテンドー3DSとWii Uのニンテンドーeショップ残高を共有させたい、ということになったのですが、ニンテンドー3DS専用のサーバーを使っていた部分について、後からWii Uと共通のWeb APIサーバーを使うように3DS側のクライアントアプリケーションの内部実装を変更して対応しました。このとき、3DSとWii Uの2つのニンテンドーeショップで内部実装が共通化され、新機能にもまとめて対応しやすい、ということが実感できました。システム全体のつくり方を提案したり、実現したりできる役割ができていたことも、私にとっては大きな意義がありました。
リリース後も終わりのない機能追加、運用対応。
Webサービスはリリース後もさまざまな要望が入ってくるので、機能追加、変更を繰り返しています。ビジネス部門等からの要求仕様通りに作るだけではなく、開発チームからのアイデアを提示して実現することもあります。たとえばWii Uのニンテンドーeショップでバーチャルコンソールを販売開始する際、Wii版を持っていたら割引価格で買えるようにしたい、という話が来ました。商品詳細のページにだけ割引価格を表示すれば十分要件は満たせましたが、商品一覧のページでも割引価格を見られるようにすればもっと便利になると考えて提案しました。一覧画面では多くのゲームに対して割引対象になるのか判定しなければならないので、処理が多くなって動作が遅くなる懸念がありましたが、最終的にはいろいろ工夫して効率の良い方法で実現することができました。
可能性に満ちた任天堂のネットワークビジネス。
任天堂はゲームの会社としてもネットワークサービスの会社としても似たような会社がほかにない、独自のポジションがある気がします。プラットフォームを活用したネットワークサービスの領域においては、任天堂はまだまだ進化している途中です。「もっと良くしたい」というところがあるから、やりがいがある。これから任天堂のサービスがどう変わっていくのか予想しきれるものではありませんが、先が見えない方が、見えているより面白いと私は思っています。
