掲載日:2016年9月9日 | |||||||||
執筆:森 大樹 | |||||||||
皆様こんにちは。ITコーディネータの森 大樹(もり ひろき)です。
大変なブームとなっているスマートフォン向けゲームアプリの「ポケモンGO」ですが、先行リリースされたアメリカでも同様に大ブームとなっています。
マンハッタンにあるニンテンドー・ワールド周辺は有数の「ポケスポット*」密集地となっており、またニンテンドー・ワールド内には無料のWiFi充電スポットが用意されており、沢山のプレイヤーが「ポケモンGO」をプレイしていました。
*ポケスポット : ゲーム内で使用するアイテムや、ポケモンを捕獲出来る場所
<ニンテンドー・ワールド>
この「ポケモンGO」を運営するNiantic社は元々Googleの社内ベンチャーから発足しており、位置情報を初めとしたGoogleの技術が至る所に活用されています。運営サーバには当然GoogleのCloud platformが用いられています。
米国では「ポケモンGO」のサービスイン直後に人気が集中した事によるトラフィック急増の為、一時的にサービスが不安定になったりもしましたが数日で解消されサービスは安定しています。これはトラフィックの増加に合わせる形でClouldサーバが大幅に増強されたという事は想像に難くありません。まさにクラウドの柔軟性が発揮されたといえるでしょう。
ポケモンと言う非常に強力なコンテンツに、Niantic社のアプリケーション技術、Googleのプラットフォームという最強の組合せが実現された「ポケモンGO」はゲームのみならず、Cloudビジネスのロールモデルとしても注目が集まりそうです。
|
|||||||||
|
|||||||||
|
|||||||||
さて、今回は海外にシステムを導入する際の注意点にフォーカスしてお伝えしたいと思います。基本的なシステムの導入方法には、日本でも海外でも大きな差はありません。一般的にウォーターフォールと言われる顧客要件を仕様に落とし、設計・開発・テストを進めていくという流れが主流を占めています。
ITコーディネータとしては、日本企業が海外拠点へシステム導入する際の導入支援に携わるケースが多くなるかと思います。その中で私が実際に経験したトラブルや事例を元に、まとめてみたいと思います。
|
|||||||||
◆注意点1 日本との時差を考慮する | |||||||||
時差を甘く見ていた(時差が大きく・WEB会議でのコミュニケーションがメンバーの負担に) | |||||||||
海外拠点とのコミュニケーションには、WEB会議システムを使う事はもはや当然と言えます、ただし、WEB会議の実施にあたり、時差が大きな拠点との会議開催については、その時間設定に留意が必要です。 例えば、ニューヨークと東京の時差は夏時間で13時間。冬時間では14時間です。つまり、夏時間における東京の午前9時はニューヨークの20時となります。一般的な企業の定時業務時間は東京もニューヨークも9時~17時ですから、東京とニューヨーク間でWEB会議を設定した場合には、両拠点の定時時間内にWEB会議を開催することが出来ず、どちらかの拠点が早朝出勤や残業をしてWEB会議をせざるを得なくなります。システム導入プロジェクトの期間中など、週次でWEB会議の定例会を組むときにはこの時差を考慮に含める必要があります。 私の経験によれば、ニューヨーク側が残業をして対応する事が多かったのですが、プロジェクトメンバーに毎週固定的な残業を強いるのは無闇な負担を増やす事になりますので、双方拠点が少しずつ時差出勤をして負担を分散したり、会議の開始時間を交代制にする、出席者を絞る、報告の簡潔化など、負担低減に向けた工夫をする事が求められます。 |
|||||||||
◆注意点2 導入先国の連休・休暇の違いを予め考慮する | |||||||||
各国独自の連休・休暇を予め考慮に入れたスケジューリングをする | |||||||||
多国籍のメンバーが参画する所謂「グローバルプロジェクト」では、プロジェクト計画時に各メンバーや関係者の連休を考慮する必要があります。お隣の中国では1月中旬から始まる旧正月の風習が日本でも知られていますが、米国および中南米各国にも同じように独自の休暇や連休があります。
例えば米国では7月4日の独立記念日、12月のクリスマス休暇の連休が有名です。米国の他にも南米のチリにおいては、9月18日(独立記念日)・9月19日(陸軍記念日)と連休がありますし、ブラジルなどでは、毎年3月下旬に聖金曜日と復活祭が重なった連休があります。こういった連休には日本のゴールデンウィークやお盆休みと同様に、当地にいるメンバーやその出身国のメンバーがその時期に合わせてあらかじめ休暇を計画している可能性が高くなります。
そのため、プロジェクトメンバー・取引先・関係会社やユーザのスケジュールを事前にヒアリングした上でプロジェクトの計画を立てておかないと、主力メンバーやキーユーザが連休に入ってしまって進捗がストップするという事態にもなりかねません。
このときに、グローバルプロジェクトではプロジェクトメンバーの休暇取得に対する感覚の違いも考慮に入れておくべきです。例えばプロジェクト稼動の一ヶ月前等のいわゆる「追い込み」の時期にも、海外拠点のプロジェクトメンバーは長期休暇に入ることがあります。
海外においては我々日本人が考えている以上にワーク・ライフバランスは重視され、特に家族との時間を大切にする傾向が強いです。その価値観を正しく理解しないまま、「この時期はプロジェクトの追い込みなので、休暇は取らないだろう。」という思い込みのままにプロジェクトをスケジューリングしてしまうと、思わぬ事態に直面する事になりますので、こういった事態を避けるためにも、プロジェクトメンバーや関係者と必ずコミュニケーションを取って確認しておく事が求められます。
|
|||||||||
◆注意点3 日付や通貨の書式(ロケールを考慮) | |||||||||
日本と異なる書式に注意を払い、事前に仕様を詰めておく | |||||||||
日本では日付書式に年月日 (YYYY-MM-DD)をを用いるのが一般的ですが、米国においてはそれが月日年 (MM-DD-YYYY)での記載となります。 そのため、国をまたぐデータ交換を実施する際などは、国や地域に依存する書式設定(ロケール)の考慮が必要になります。 また欧州や南米では日月年 (DD-MM-YYYY)で記載するケースが見られます。 (2016年08月12日の表示例) 表示例の欧州(英式)で書かれた日付を米国式で読んでしまうと、8月12日が、12月8日と解釈できてしまい、大きく日付がずれてしまいます。国際化対応されたアプリケーションを使用している場合は、自動で日付のコンバージョンが実施されるのでこの問題が顕在化する事は殆どありませんが、拠点間でファイル交換等を行う場合には、拠点間や国毎にコンバージョンのルールを事前に決めておかないと、日付の取り違いが発生し、思わぬ障害に直面する可能性があります。 また、数字の区切り文字も国毎に使い方が異なるケースがあります。 (数字の区切り文字の例) 日本や米国等では桁区切りにカンマ(,)、小数点以下はピリオド (.)を使いますが、イタリア、スペイン等では、使い方が逆になりますので注意が必要です。 システムの導入範囲が広がる程にこういった国ごとのロケールの違いに直面する可能性が高くなりますので、可能な限り導入の初期段階で書式の共通ルール化を策定しておく必要があります。 |
|||||||||
◆注意点4 デファクトスタンダードの違いに注意 | |||||||||
国毎に異なるデファクトスタンダードを理解しておく | |||||||||
上述の日付書式にも関連すると言えますが、日付書式以外にも海外では日本とデファクトスタンダードが異なるケースがあるので、事前に調査・理解をしておく必要があります。 |
|||||||||
◆注意点5 インフラ整備状況の違い(電気・交通・通信ネットワークなど) | |||||||||
日本のインフラ整備状況とは大きく異なる事を覚悟しておく | |||||||||
システム導入先の国のインフラ整備状況の事前確認も必要になります。国によっては電力インフラが安定しておらず、頻繁に停電に見舞われて作業が予定通りに進まないと言う事態もあり得ます。 |
|||||||||
◆注意点6 マネジメントスタイル | |||||||||
日本的なマネジメントが通用しないケースに注意 | |||||||||
最近は残業時間を短くする風潮がかなり浸透してきたと感じていますが、それでもまだ一部には現場で遅くまで頑張るというワークスタイルが残っているのでは無いでしょうか。特にプロジェクトの進捗遅延時などに見られる「遅くまで残業」して挽回すると言う残業策ですが、日本とはワークスタイルが大きく異なる海外では、上手く機能しない事が多いです。そもそも会社に遅くまで残って働くと言う事に対して、日本以上に抵抗を感じる人が多い事を理解しておくべきです。 実際のプロジェクトにおいて進捗遅延の発生時に、安易に残業による挽回を選択した場合に、現場の理解・協力が得られないばかりか、メンバーのモチベーション低下や、コミュニケーション悪化など、更に傷口を広げる事態に繋がることも起こり得ます。こういった事態を避ける為にも、遅延が発生した場合は遅延原因の分析を進め、問題の本質的な解決をメンバーと共に目指すと同時に、事前に策定しておいた代替案の実施やスコープの変更・スケジュールの再設定など、現場の理解が得られる形での施策実施が要求されます。 |
|||||||||
◆終わりに システム海外展開時にITCに何が求めらるのか | |||||||||
今回は海外にシステムを導入する際の注意点を中心にまとめてみました。もちろんここで記載したものが全てではなく、ほんの一部になります。これらの注意点に共通するのは、日本的なプロジェクト実施方法をそのまま現地に適用した結果として、問題に繋がる事が多いということです。 |
|||||||||
|
|||||||||
ITCニューヨーク支局通信 Vol. 2 米国での人工知能動向 はこちら | |||||||||
|
|||||||||