「AWS EC2からHyper-VへのVM移行を試してみました – その1」をお読みいただき、ありがとうございます。
今回は、以下の「ステップ1：AWS EC2を構築」について、EC2 仮想マシン(VM)の移行検証環境として、移行元のEC2インスタンスを構築してみます。
・ステップ1：AWS EC2を構築
・ステップ2：AWS EC2にバックアップ保存用ボリュームを追加
・ステップ3：AWS EC2をバックアップ
・ステップ4：バックアップから直接Hyper-V上に仮想マシン作成
・ステップ5：移行後の処理
具体的には、以下の構成概要図の[VPC(Virtual Private Cloud)]と[EC2(Elastic Compute Cloud)]を作成して、リモートデスクトップ(RDP)から接続するまで進めてみたいと思います。また、どなたでも試していただけるように、詳細にまとめてみました。
続きを読む…
一度クラウド化したものの、利用コストが当初見込みを大きく上回ったりするなどの理由で、「オンプレに戻すことを考えている」というお客様の声をお聞きすることがあります。
「どげんかせんといかん」と勝手に思い込み、クラウド初心者の私が AWS EC2 から Hyper-V への VM 移行を「ActiveImage Protector」の「バックアップ」と「仮想化」機能を使って試してみましたので、その話をしようと思います。
試す前に、AWS EC2、VPC、EBS・・、意味不明な用語について、得意のインターネットからググり何とか理解？して、試行錯誤の末に以下の検証環境を構築しました。
・移行元: AWS EC2インスタンス（Windows Server 2016 (x86_64) t2.micro）
・バックアップ保存先：追加ストレージボリューム（Amazon EBS）
・移行先: Hyper-V（Windows 10 Enterprise）
検証概要は、こんな感じです。
悩みましたが、簡単、確実、且つローコストで移行できる方法ではないかと、いつものごとく勝手に思い込んでいます。
EC2 の移行と書くと凄そうですが、単にバックアップ保存先を EC2 のローカルボリュームに配置することぐらいです。失敗談として、バックアップ保存先の追加ボリュームが別リージョンに作成されていたため、バックアップ検証毎にデータ転送料金「DataTransfer」が加算されていました。
最後に、実際試してみて「ActiveImage Protector」の「バックアップ」と「仮想化」機能を利用すれば、クラウドからオンプレへの移行が簡単にできます。今回の検証方法について、全部一気に書くととても長くなってしまいますので、今後、以下のステップで紹介していきます。
次回は、「AWS EC2インスタンスを構築」についての話をしたいと思います。
・ステップ1：AWS EC2 を構築
・ステップ2：AWS EC2 にバックアップ保存用ボリュームを追加
・ステップ3：AWS EC2 をバックアップ
・ステップ4：バックアップから直接 Hyper-V 上に仮想マシン作成
・ステップ5：移行後の処理
By Oki
[仮想化設定の画面]
[Hyper-V 上に変換された直後の仮想マシン]
2月14日金曜日のバレンタインデー、ダイワボウ情報システム（株）様主催の「DIS ICT EXPO 2020 in 名古屋」に出展しました。
会場はウインクあいち7Fの展示場でした。
新幹線の止まる名古屋駅から近いのが良いですね。
少し迷っても、そこまで時間がかからずにたどり着けます。
私たちは、バックアップツール「ActiveImage Protector 2018 Update」やキッテイングツール「ActiveImage Deploy USB」を展示しました。
今回は新型コロナウイルスの問題がある中での開催だったのですが、非常に多くの方が会場まで足を運んでくださっていました。
最後になりますが、当日私たちのブースへお立ち寄りいただいた皆様、ありがとうございました。
今年度の「DIS ICT EXPO」は今回でラストになります。
来年度も機会がございましたら、よろしくお願いします。
新型コロナウイルスやインフルエンザ等、体調にはお気をつけください。
SY
1月29日（水）、ダイワボウ情報システム（株）様主催の「DIS ICT EXPO 2020 in 関西」に出展しました。
会場は「グランフロント大阪B2F ナレッジキャピタル コングレコンベンションセンター」です。
大阪は不慣れで、電車を降りてから会場までの道のりで少し迷ってしまうんですよね。
慣れていない土地は、いつも以上に早め早めの行動が大切ですね。
私たちはバックアップツール「ActiveImage Protector 2018 Update」やキッテイングツール「ActiveImage Deploy USB」を展示しました。
今回は会場が大阪ということで、来場者の方がとにかく多かったです。
この写真内に並べてあるカタログは、すべてお配りしてしまいました。
その疲れからか、帰りの新幹線では2時間30分ノンストップで爆睡してしまいました。
マスクをしていたので、口が開いているなどの間抜けな姿は見られていないはずです。
最後になりますが、当日私たちのブースへお立ち寄りいただいた皆様、ありがとうございました。
SY
HyperBootをリリースしました。この製品はActiveImage Protector のユーザー向けに無償配布していたImageBootの後継製品です。
HyperBootはActiveImage Protector のバックアップイメージファイルを直接仮想マシンの仮想ディスクとしてアタッチして起動し使用できます。
通常はバックアップイメージを利用するためには、物理にしろ仮想にしろ実際に復元作業をする必要がありました。ディスクの実体を作成してそこから起動というのが通常の手順です。
これを直接イメージファイルをディスクとしてシステムに認識させることで復元作業をせずに、即時起動できるようにしたのがImageBootでした。
ImageBootでは、VMware Workstation,Player,VirtualBox,ローカルのHyper-Vで利用が可能でしたが、イメージファイルの物理ディスク化のためにローカルマシン上で動作するデバイスドライバを使用していたのでローカルマシン上の仮想環境アプリケーション、ハイパーバイザーのみという制約がありました。
iSCSIはその名前の通り、インターネットを介したSCSIプロトコルの接続です。
ActiveImage Protector のアップデートにはiSCSI対応の開発が含まれており、完了しました。ActiveImageのバックアップイメージをiSCSIのターゲットとして公開し外部から接続できる技術です。
最近のハイパーバイザーではiSCSIのディスクを仮想ディスクとして扱うことができるので、iSCSI接続のディスクを使った仮想マシンの起動が可能です。もちろん起動するまでにはイニシエーターの設定から始まり、仮想ディスク、仮想マシンの設定、アタッチが必要なので詳しい人ならできる、という状態でした。
そこで、この技術をImageBootでも採用し、GUIを含めてすべて見直して作り直すことにしました。リモートのハイパーバイザーを使ってバックアップイメージからの仮想マシンの直接起動が簡単にできるようになりました。
操作は非常に簡単です。イメージファイルから起動した復元ポイントを選択して起動するだけです。
バックアップイメージファイルを保存したフォルダを指定すると、ソースのコンピューター名（クライアント名）最新の復元ポイントが表示されます。各クライアント毎の復元ポイントを個別に指定することもできます。
HyperBootの起動に使用する仮想マシンの設定を行います。起動確認だけでなくしばらく運用したい場合にはリソースを多めに取っておきます。
起動後に変更した部分は差分ファイルとして保存されます。一時的な運用を行った場合でも、その間のデーターを失うことはありません。停止後に再開もできますし、差分ファイルから復元を行えば作業内容も含めて復元できます。
さて、せっかく起動したのでそのまま実運用にしてしまいたくなる気持ちが湧いてくるのではないでしょうか？正直なところ起動した状態そのままの運用はイメージと直接やりとりをしているのでリソース的にも速度的に推奨というわけにはいきません。
一方で、イメージファイルから即起動して運用を再開、しばらくしたら自動的に本番環境の復旧が終わっている、そのようなソリューションがあればと思います。
以前からのActiveImage Protectorユーザーなら実際にそうした機能を実現していた Hyper-V版のReZoom™ it! ライブや、SHR(シームレスホットリストア）機能を思い出すかもしれません。即起動してバックグラウンドで復元を行ってしまう。そのような機能をリモートのハイパーバイザーでも実現できないでしょうか？残念ながら現在のHyperBootではまだそこまでカバーはしていません。
しかし、ESXi限定になりますがvMotionのストレージ移動機能を使えば実現できます。
vMotionは仮想マシン、仮想ディスクの実体を物理ホスト間で仮想マシンを起動したままの状態で移動できるESXiの機能です。ストレージ移動する時に移動元としてiSCSI経由でアタッチしたディスクも対象にできます。つまり、HyperBootで起動した状態でvMotionを使ってストレージを本番環境に移動すれば仮想マシンを復旧したのと同じ状態になりますので、そのまま継続して使用可能になります。
vMotion自体は簡単で、ESXiの管理コンソールから仮想マシンを指定して、移動するだけです。
HyperBootでは内部的にiSCSI接続をしていますが、ActiveImage Protector の最新版ではiSCSI Target 機能があるので汎用的にiSCSIディスクとしてバックアップイメージを利用することができます。また、バックアップ直後に起動を確認するBootCheck機能もあります。起動確認からさらにアプリケーションなどの復元確認を行う必要がある場合にはHyperBootを使うことで運用段階での動作確認が可能です。
昨年12月、 ActiveImage Protector の台湾の販売代理店 GATI（General Advanced Technology Inc.）が台湾高雄で「予算を50％削減すると同時に、災害復旧パフォーマンスを50％向上させる」と題した ActiveImage Protector のセミナーを開催しました。
本セミナーでは、エンドユーザー様を対象に、ActiveImage Protector のバックアップの運用により、予算目標とパフォーマンス目標の双方を現実的に達成できることについて、事例を踏まえて分かりやすく解説しました。
いつも通り、映画館の劇場ホールを丸ごと貸切り、資料を映しながら迫力あるプレゼンテーションを行いました。
セミナー終了直後、ユーザー様が講演者に質問する様子に皆さまの関心の高さを感じました。
限られた予算内で、バックアップのコストパフォーマンスの良い成果を期待されるお客様は ActiveImage Protector にお任せください！
年末の繁忙期にセミナーにご参加いただきました皆様、ありがとうございました。
YBS
明けましておめでとうございます。
本年も弊社 ActiveImage シリーズを何卒宜しくお願い申し上げます。
年明けから大阪で挨拶まわりを行っておりましたが、１日勉強会を行いました。
いつものように、HDMIにモニター接続して、今日はP2Vの仮想化についてのご説明をさせて頂こうと思い、VMware Workstation のWindows Server 2019を起動しようとすると、何も起きません。
下図のような画面のままです。
他のゲストOS（Windows 10など）も同様です。
「これでは勉強会は？」と冷や汗をかいているとESXは正常起動。そして、Windows Server 2016 は正常起動だったので、なんとか当初より寂しい環境でしたが、勉強会を進めました。
ホテルに帰ってからPCの再起動など色々としたのですが、もうどうにもなりません。
色々調べていると下記に情報がありました。
https://communities.vmware.com/thread/608636
ふと考えると、昨年の仕事納めの時にWindows Update が動作して、結構な時間をかけてのUpdate 後、仮想マシンを起動していませんでした。
私のマシンは
どうもこの問題のようです。
VMware Workstationの Updateまで、仕事の予定を考えるととても待てません。内容をみると、仮想プリンタと仮想ネットワークアダプタの問題のようです。
ちなみに「OSを再インストールすれば良いか！」と安易に考えて、ISOから新規マシンでインストールを行うと、各種設定後マシンが自動で起動し、通常はコピーが開始されるのですが、ここでも上記の起動しない状況と同じくブラックアウトのままで、強制的に電源をOFFしても結局は VMware 側の exe でつかんだ状態のようで、再起動しても、サービスを落としても、何をしても実際の仮想ディスクを作成したフォルダ内のファイルは削除も出来なくなり、繰り返すとどうにもならない仮想ディスクを大量生成していました。ちなみに起動できなかった OS も電源投入してしまうと、削除など出来なくなりました。
この仮想ディスク関連を削除するには、VMware Workstation を一度アンインストールしてからでないと削除出来ませんでした。VMware 関連のISOもディスクに入っていたので、ライセンスを削除しないで、アンインストールも行いました。
下記は私のケースでの復旧方法です。
〇既存ディスクの起動
Windows 10については起動させない状態で、仮想マシン設定を開きます。
この仮想プリンターを削除します。そして”OK”を押してから仮想マシンの電源を投入するだけです（仮想プリンターを使用したい方の回避方法は、VMware のUpdate 待ちしかないかもしれません）。
Windows 2019についても同じく起動させない状態で、仮想マシン設定を開きます。
同様に仮想プリンターを削除しますが、その時に一緒に現在使用していた仮想ネットワークアダプタを全て削除します。
削除後”OK”を押してその後電源投入を行います。
OS起動後に必要になる仮想ネットワークアダプトを再度作成します。
その後は私のマシンでは正常に動作を行っています。
新規マシンのインストール
その後うっかりして、忘れてまた VMware Workstation を再インストールしたくないので（実際いつも流れでその後も失敗していますが）、OSをインストールするための各種設定後の下図の最後の画面で”完了”を押す前に必ず”ハードウェアをカスタマイズ”をクリックして下さい。
デフォルトでは下図のように仮想プリンターが入ってしまいます。
これを必ず削除してから”完了”をクリックしてインストールを進めてください。
慌てている時はまたやってしまいそうですが、早くVM側のUpdateがされる事を祈るばかりです。
新年早々自分の検証環境のトラブルでの仕事始めとなりました。
同じような環境の皆様も回避して、是非弊社の ActiveImage シリーズを使ってみて頂ければ幸いです。
本年も何卒宜しくお願い申し上げます。
長きに亘りお読みいただき、ありがとうございます。
働き方改革的PCキッティングは今回が最終回となります。
本ブログをお読みいただきましたエンジニアの方の作業が、少しでも楽になれば本望です
（弊社の Active Image Deploy USBを使用していただければ私は本望です）。
今回は、前回作成した応答ファイルの実行について記述します。
SysprepはC:\Windows\System32\Sysprepにあります。
このフォルダに作成した自動応答ファイルをコピーします。
通常のSysprepの実行は、そのまま管理者権限で起動させたコマンドプロンプトでタイプして実行すれば実行は可能です。その場合は下記のようにUIが表示されます。
今回は作成した応答ファイルを使用しますので、コマンド入力は下記のようになります。
Sysprep /oobe /shutdown /generalize /unattend:Untitled.xml
(“ / ”の前はスペースが入ります)
（上記は作成した応答ファイルの名前はデフォルトとして保存された事を前提としています。）
毎回タイプが面倒なため（入力ミスもあるので）、バッチファイル化する事をお勧めしています。
後は実行してシャットダウンした状態でマスターイメージとして活用可能です。
もちろん弊社のActiveImage Deploy USBで作成したUSBメモリで起動して１クリック下図UIで
「作成」をクリックすれば、マスターイメージはUSBメモリの中に作成されますので、後は展開したいマシンをこのUSBメモリで起動して「復元」を１クリックのみで、それはそれは凄い速さで展開する事が可能となります。
是非下記より評価版をダウンロードして実際にお試しいただければ幸いです。
https://www.netjapan.com/jp/try/activeimage-deploy-usb
追加情報ですが、実際に作り込んでいった方で、キッティングしたPCの初回起動時にバッチを実行したい方は、下記の設定を追記頂ければ簡単に可能です。
Shell-Setupをパス7のoobeSystemに追加して以下のように設定することで、初回起動時のログオン後にプログラムなどを動作させる事が可能となります。
下図のように、名前の通り“ FirstLogonCommands”という項目で設定します。
今まで設定した項目と異なり、Windows システム イメージ マネージャーのプロパティ上で設定は行いません。
この項目の設定方法は、下図のように“ FirstLogonCommands”で右クリックし、
“新しいSynchronousCommandの挿入”をクリックします。
動作コマンドラインの入力設定画面が追加されます。（応答ファイルとプロパティ共に）
後はプロパティの”CommandLine”の項目に、動作させたいプログラムなどを記述します。
例えばメモ帳を起動する場合、”c:\windows\notepad.exe”とフルパスで記入します。
説明が必要なければ”Description”の記入は不要です。
”Order”は実行の順番です。複数のプログラムを動作させる場合には、上記と同様に右クリックで項目を追加していきます。
追加していくと下図のようになります。
他のプロパティ設定とは異なり、項目追加といった方法となりますので、ご使用方法をご注意ください。
以上で働き方改革的PCキッティングブログは終了となります。
今後は不定期となりますが、また別の情報を掲載する予定です。
来年に向けてはP2V、V2V、クラウドホスティング、他最新の技術情報を営業目線で苦労しながら記述していきたいと思います。
ご質問などはお気軽に営業本部（sales@actiphy.com、電話：03-5256-0877）までご一報頂ければ対応させていただきます。
弊社 ActiveImage Protector シリーズ製品を宜しくお願い申し上げます。
By Sato
12月も半ばを過ぎ、師走の慌ただしい時期となりました。インフルエンザの予防注射も接種して、仕事納めまで無事過ごしたいと思う今日この頃です。
さて、今回は自動応答ファイルの設定について記述します。設定方法は人によって異なりますが、あくまで私個人ではこのような設定をしています。
動作自体は「コルタナを飛ばして自動ログインする」までの設定となります。
前回までに項目を5個、応答ファイルに追加していますので、その追加した項目の設定となります。
今回は少し長めのブログとなります。
amd64_Microsoft-Windows-PnpSysprep_neutral （3 generalize）
・DoNotCleanUpNonPresentDevices
Windows セットアップにドライバー構成を保持するようにします。
物理的なスイッチのあるデバイスのON/OFFができる場合、OFFの時にデバイス情報は一般化中に削除される可能性があるので、削除されないようにします。
“ true “ にする事により検出されないプラグアンドデバイスはインストールされたままとなります。
・PersistAllDeviceInstalls
“ true “設定にする事により、一般化構成パスの動作中にプラグアンドプレイデバイスがインストール先コンピューターにインストールされたままになるようにしています。
結果として各ドライバーの設定情報を保持します。
amd64_Microsoft-Windows-Security-SPP_neutral （3 generalize）
・SkipRearm
Sysprepの実行回数を減らさないで実行可能にします。
以前は回数が少なかったのですが、現在のWindows 10では1,000回行えますが、一応設定しています。
設定 0 アクティベーション関連のライセンスとレジストリデータは全て削除またはリセットされ、猶予期間タイムもリセットされます。デフォルト設定のようです。
設定 1 アクティベーション関連のライセンスとレジストリデータは全て保存され、リセットはされません。猶予期間タイムもリセットされます。
amd64_Microsoft-Windows-Shell-Setup_neutral （4 specialize）
・ComputerName
“＊”を入力しておくと自動的に設定されます。ここは後で変更するので“＊”としています。
・CopyProfile
ユーザープロファイルの設定の保持を行います。
カスタマイズしたユーザープロファイルをデフォルトのユーザープロファイルとして使用できます。Windowsはデフォルトのユーザープロファイルをテンプレートとして各新規ユーザーにプロファイルを割り当てます。但し、Sysprepの一般化を実行する時に使用する個別の応答ファイルが必要になる場合もあります。ドメインアカウントは使用できません。
“ true ”にする事によりカスタマイズを行ってデフォルトのユーザープロファイルを変更します。
・ProductKey
Windows 10のオープンライセンスのアクティベーションキーを入力します。
・TimeZone
日本国内なので、”Tokyo Standard Time”を入力します。
AutoLogon
・Enabled
必ず “ true ”を入力してください。
入れ忘れた場合、Sysprep実行後初回起動でループ状態となり、OSの再インストールになります。
・Username
Auto Logonで使用したいユーザー名を入力します。ここでは「user」としています。
・Password
必要に応じて入力してください（設定した場合のみ）。
amd64_Microsoft-Windows-International-Core_neutral （7 oobeSystem）
・InputLocale
日本の設定は “ 0411:E0010411 “と設定してください。
・SystemLocale
ロケーション設定です。日本は“ ja-JP ”と入力してください。
・UILanguage
Windowsのインターフェイスの言語設定です。日本は“ ja-JP ”と入力してください。
・UserLocale
使用ユーザーのロケーション設定です。日本は“ ja-JP ”と入力してください。
amd64_Microsoft-Windows-Shell-Setup_neutral （7 oobeSystem）
・RegisteredOrganization
登録したい会社名などがあれば入力してください。
・RegisteredOwner
登録したい所有者があれば入力してください。
・TimeZone
一応ここでも日本時間の設定を行います。“ Tokyo Standard Time”を入力します。
OOBE
・HideEULAPage
“ true”にする事により「Windowsへようこそ」のマイクロソフト ソフトウェアライセンス条項ページを表示しない事を指定します。
・HideLocalAccountScreen
エンドユーザーがOOBE中に表示される管理者パスワード画面を設定する必要があるか指定します。
この設定はWindows Serverの各エディションにのみ適用されます。
“ false”にするとOOBE中に管理者パスワード画面を非表示にしません。この設定はデフォルト設定です。
・HideOEMRegistrationScreen
これは、OOBE中にOEM登録ページを表示するかどうかを指定します。
この設定を行った場合、oobe.xmlの値に関係なくページはOOBE中に表示されません。
“ true “にする事によりOOBE中にOEM登録ページを非表示にします。
また1703以降についてはこの設定はWindowsプロビジョニングパッケージでは使用できなくなりました。
・HideOnlineAccountScreens
これはOOBE中にユーザーがサインインを要求されるかを指定します。
主には使用者が電子メールアドレス名をユーザー名として使用したくない場合に使用するようです。
“ true ”にする事によりOOBE中にサインインページを非表示にします。
・HideWirelessSetupInOOBE
これは「Windowsへようこそ」中に表示される「Wi-Fiネットワークに参加」画面を非表示にするかを指定します。
“ true ”にする事で「Windowsへようこそ」中に「Wi-Fiネットワークに参加」画面を非表示にします。
・ProtectYourPC
これはExpress設定を以下の目的で使用するかどうか設定します。
連絡先と予定表の詳細を他の関連する入力データと一緒にマイクロソフトに送信する事で音声などの入力をカスタマイズします。
Windowsとアプリが一履歴を含むユーザーのローカライズを要求して、デバイスのエクスペリエンスをパーソライズするようにします。
悪意あるWebコンテンツからの保護をONにしてページ予測を使用してWindowsのブラウザにサイトをプリロードします。観覧履歴がマイクロソフトに送信されます。
マイクロソフトへの問題報告。
設定：１（Express設定をON） 2（Express設定をON） 3（Express設定をOFF）
今回はOFF設定としています。
・SkipMachineOOBE
これは「Windowsへようこそ」をスキップするかどうかを指定します。
MSDNには重要事項として、この設定はWindows 8では推奨されないとかWindows 7ではスキップされるがユーザーアカウント作成、言語、タイムゾーンの設定は構成されないなど一部の機能が機能しない可能性があると記述されています。
“ true ”にする事により「Windowsへようこそ」をスキップする事を指定します。
但し、この値はテスト目的でのみ使用する事をMSDNでは記述されていますが、今回のテスト環境ではこの項目を設定しないと安定動作できませんでした。
このため今回は設定を行っています。ただこの設定を行う事によりWindows システム イメージ マネージャーのメッセージ欄に下記のワーニングが表示されます。
最後に設定を行っていない項目については全て削除を行います。
削除しない場合、全てエラーとして表示されます。削除後に保存を行い、応答ファイルが完成となります。
下記のようなxmlファイルが出来ていると思います。
いよいよキッティングブログも次回が最終回です。
ブログではわかりにくいと思われた方は、お気軽に営業本部（sales@actiphy.com、電話：03-5256-0877）までご連絡頂ければ幸いです。
By Sato
2019年11月27日（水）～11月28日（木）の二日間、昨年4月から ActiveImage Protector の取り扱いを開始したシドニーの販売拠点 NetJapan ANZを初めて訪問しました。
10時間のフライトのあと、11月27日朝7時頃、ようやくシドニー空港に到着しました。訪問の２週間ほど前に、オーストラリア東部ニューサウスウェールズ州の数カ所で大規模な山火事が起きました。シドニーでは、有害な煙が上空を覆い、大気汚染レベルがにわかに上昇したというニュースもありましたが、空港に出た瞬間はそれほど感じませんでした。
空港からホテルまでの移動は渋滞のピークの時間にぶつかってしまったため、大変でした。お昼頃、ホテルに到着。NetJapan ANZとの会議は午後からなので少し時間に余裕があり、ホテルの周りをぐるぐると散歩して気分転換をしました。
シドニーはヨーロッパの移民がオーストラリアに初めて到着した都市であり、建築物などにヨーロッパの文化が大いに影響していて、現在のシドニーの中心部でもヨーロッパ風の建築物が街中に目立ちます。
都市部で活躍している路面電車です。青空の下、路面電車はゴトゴト。
ホテルから徒歩15分圏内のチャイナタウン。
とても小さな通りなので、日本の横浜のような中華街を想像するとちょっと拍子抜けしてしまうかもしれません。
お昼はチャイナタウンで簡単に済ませて、午後１時に、NetJapan ANZとの会議がスタート。
NetJapan ANZの皆さんとは、これまで行ってきた ActiveImage Protector のマーケティング、販売活動の結果共有やこれからのネットジャパンのビジネス計画、製品 Roadmap などについてディスカッションし、お互いの理解をより深める場となりました。また、オーストラリアの市場状況を分析しながら、売上をアップさせるための方法を話しました。
初日のミーティングが終わった後、シドニーハーバーで人気のレストラン（Quay）で夕食会を行いました。仕事の真面目な話をしたり、プライベートの話をしたり、とても有意義な時間となりました！
夜のオペラハウスとハーバーブリッジの景色は、やっぱり素晴らしい。
二日目の会議で、引き続き販売戦略・方針、具体的な行動について、一緒に検討しました。
これから、NetJapan ANZの皆さんと協力して、オーストラリアのお客さまの抱えている課題解決のお役に立てるソリューションをより広く、より多くの企業に提供することを目指します。
いつも Skype を使った電話会議で Face to Face の会議を積み重ねてきたつもりでしたが、やはり、直接顔を合わせ、意見を交換し、議論し、食事を共にしたことで、しっかりコミュニケーションを取れたことが大きな収穫でした。
日本では、従来の販売方式や顧客向けのサービスを変更する際に、その変更に伴う混乱を避けるべく、既存のやり方を踏襲した上で新しいものを導入する傾向があるようです。しかしオーストラリアでは、新たなものに変えることへの抵抗感が薄いようで、新しい販売方式やサービスなどへの変更はより容易だと感じます。例えば、日本で MSPは未だに大規模な導入を進めていませんが、オーストラリアでは、MSPの市場シェアは85％になっているそうです。日本よりオーストラリア市場の方が成熟度が高いのではないかと考えています。
その市場の成長限界を打破するため、今回の訪問の経験を活かし、オーストラリアの市場に合うような営業力を強化し、売上を上げるために NetJapan ANZ と協力して頑張っていきたいと思います。
YBS