『ニンテンドーeショップ』
2. 国による税率の違い
- 岩田
- 今回のeショップにおける、もうひとつの大きな変化は、
みんなのニンテンドーチャンネルの機能が統合されることです。
具体的にはゲームのプロモーション系の機能や、
お客さんからゲームの評価を集める機能、
レビューの高いソフトを探す機能が追加されましたが、
レビュー評価がWiiの点数制から5つ星制に変わることについて、
いろんな議論があったんじゃないですか? - 中谷
- はい、かなりありました。
インターネットの世界では5つ星というのが、
お客さんの評価を集めるうえでもっとも標準的な視点なんです。
だから100点満点で点数をこまかくつけるよりも
5つ星評価のほうが親しみやすいだろうと考えました。
一方で、いままでの評価方式を変えることに抵抗される方もいて、
各リージョンで別の評価方式をとろうかと
意見が割れそうになったこともありました。 - 岩田
- それぞれの国で、そんなに意見が違うんですか。
- 中谷
- はい。じつはいまでも若干、意見のくい違いはあります。
たとえば「星1つ」は、評価がすごく悪いのか、
そこそこいいのか、という評価の基準で割れたりしているんです。
最終的には、任天堂の評価システムを
世界統一で示す方向にまとまりそうなので、
開発者側も胸をなでおろしていますが・・・。
- 岩田
- 日米欧三局で異なる意見の調整が大変だったんですね。
また、日米欧ではそれぞれ税金の扱いが違うといった、
まるで悪夢のようなことが山ほどあるんですよね。 - 中谷
- いや、お金関係のことは・・・本当に大変なんです(苦笑)。
今回、ポイント制からキャッシュ制に変更になったことで、
プリペイドカードに各国の通貨単位が入ったり、
商品購入時にレシートに金額が記載されたりする関係で
いままで以上に扱う通貨が一気に増えたんです。
とくにヨーロッパの通貨がものすごく増えて、
はじめて聞く通貨単位もたくさん出てきました。
たとえば北欧などで使うクローネ(※3)だけでも
ノルウェー・クローネ、デンマーク・クローネ、
ちょっと発音が違いますがスウェーデン・クローナ、
それにチェコ・コルナ・・・と、
親戚のような名前がいくつも出てきました。
クローネ=北欧・中欧諸国の通貨。
- 岩田
- え? そんなにあるんですか?
- 中谷
- はい。クローネは“王冠”という意味で、
ヨーロッパのお金の単位としてはポピュラーな名前のようで、
“何とかクローネ”という通貨単位がたくさんあるんです。 - 岩田
- へぇ~、そうなんですね。
- 中谷
- そういうこまかいことが本当にいろいろあって、
どうしてこんなにお金のことばかり
考える毎日がつづくんだろう、と・・・。
じつはそれがいまでもつづいている状態なんです。 - 岩田
- eショップの対応国は何カ国くらいになったんですか?
- 中谷
- 25カ国でのスタートになる予定です。
- 岩田
- しかも、ひとつの国の中でも税率が変わることがありますしね。
- 中谷
- そうです。
そのあたりはアメリカのサーバーチームがつくっています。
ほかにも各国の財務の方や経理の方や法律の方など、
このプロジェクトはとにかく
各国に関係者が多いので、ひとつのことを決めるのに
ものすごく時間がかかってしまうんです。
いま、もっとも苦しんでいるのはアメリカの税率ですね。
アメリカは州・市・郡まで特定して、はじめて税率が決まります。
郵便番号が6万通りくらいあって、
普通は郵便番号がわかれば、それで税率が決まるんですが、
中には郵便番号だけでは税率が決まらない地域もあるんです。 - 岩田
- 郵便番号で決まらないんですか?
- 中谷
- はい、決まらないんです。
ちょっとこまかい話なんですが、いいですか?(笑)
アメリカには、同じ郵便番号なのに
州をまたいでいる地域があるみたいなんです。
どうやら郵便番号と州の境目が
一緒に決まったわけではないようでして・・・。
そういう地域は郵便番号だけで税率が決まらないため
その番号を入力したあと
「税率を決めるため、あなたの住所はどちらか選んでください」
といった選択肢も必要になるんです。
こういった各国のこまかい対応をずっとしています。 - 岩田
- ああ、そうなんですね。
ところで今回は、画面の切りかえを速くすることも
当初からの目標でしたよね。
DSiショップのときは“ブラウザーベース”といって、
ブラウザーに読み込ませる情報をサーバーでつくって
それを画面上で構築して画面を切りかえる方法でしたので、
画面遷移のスピードが軽快ではありませんでした。
今回、画面切りかえを速くするために
どんな工夫をしたんですか?
- 中谷
- “みんなのニンテンドーチャンネル”の方法と同じように
最初に、ある程度表示されるであろう
データベースをつくって先にまとめて読み込むという方法です。 - 岩田
- ネットワークのやりとりでは、パラパラ取りにいくよりも、
まとめてガサッとデータを取ってきたほうが速いんですよね。 - 中谷
- はい。あとはクライアント側のプログラマーが、
とにかくデータをなるべく節約するよう、
非常にこだわりを持ってやってくれています。 - 岩田
- そのケチケチ精神の積み重ねが、
画面遷移のスピードにつながるんですね。 - 中谷
- そうです。
こうしたいろいろなこまかくて地味な努力を
積み重ねています。 - 岩田
- eショップがつながっているバージョンの試作品を
わたしがはじめて見たときに、
「これ、本当につながっているんですか?」と
思わず聞きましたからね。
それほどサーバーアクセスを意識しなかったんです。
まるでダミーのデータのようにスムーズに動いていました。 - 中谷
- スピードの面では、
当初の目標は達成できたんじゃないかと思っています。
ただ・・・おそらく、岩田さんが最後に見られたものよりも
いまはいくつかの内部的な処理が追加されましたので
少し遅くなってきてはいると思いますので・・・
ちょっと、ドキドキしています。