ICTの右耳・ブログ ~ジャンクねた~

仕事や趣味でICTに関わった事柄を、ボソボソと・・・

中国VPN規制の行方

VPNサービスを提供するGreenVPNが、7/1からサービスを停止した。

監督官庁から通知を受けた」としているらしいが、中国政府によるインターネット閲覧の規制強化の見せしめである事は疑いようのない事実。

Bloombergの報道によると、中国政府は通信事業者各社に対して、VPN接続の規制を強化するように要請したらしい。

www.bloomberg.co.jp

これにより、2018.2.1までに、当局が未認可のVPNサービスは、グレートファイアウォールにより順次ブロックされる可能性が高い。

f:id:ict33:20170920140616p:plain

≪≪企業のリスク≫≫

国外の(中国にとって)有害なサイトとの接続をサービス化している「違法なVPN業者」に対する取り締まりが目的とは言え、通信を遮断する方法によっては、適正な事業者のサービスにも影響を及ぼすリスクはある。

通信が自由な通常の国での感覚では、VPNと言えば、事業拠点間を固定的に接続する時や、「リモートアクセス」時のセキュリティ強度を高める為に用いられる技術というイメージなのだが、こと中国に於いては、何かと規制の厳しい国内網から逃れ、安全/自由な海外事業者を中継して規制対象サイトへアクセスする為に用いられる。

(一般的には『内を固める』のが目的だが、中国では『外へ安全に逃げる』用途に使われる)

 

例えば自営でVPN-GWを稼働させている企業の場合、通常は中国電信当局への認可申請など行なわないであろうから、China Mobile(中国移動通信)、China Unicom(中国聯通)、China Telecom(中国電信)などのFW設定により、運悪くVPN通信を遮断される可能性だってある。

通信事業者の国内VPNサービスを使ったところで、中国当局未認可のインターネットVPNサービスである事は、自営VPN-GWと同じだ。

認可済み国際VPNサービスを利用し、中国国内は当該国際VPNサービスのアクセスポイントまで専用線接続すれば、(金盾を迂回するので)問題なく全てのサイトへアクセス出来るが、コストが馬鹿にならない。

 

国内キャリアの海外担当者とも相談したが、2018.2.1までは違法VPN事業者のみが規制対象に絞られるであろうから、当面 早急な対応は不要だと考えられるとの事だった。

ただ、2018.2の規制強化の対応で、当局がVPN接続の実態を新たに把握する事項も多々あるだろうから、次のフェーズとして、正規VPN事業者への規制が強化される可能性は残る。

ネットワーク速度計測結果

Pingコマンドを使った、経路(閉域型VPN、Internet-VPN)別・拠点別の簡易レスポンス計測ツールを作成した。
当該Batchファイルを各拠点のサーバに仕込んで、タスクスケジューラで1時間ごとに実行するようにスケジューリングした。

2週間程度ログを採取したので、回線種別ごとの平均値を掲載する。
(足回りがベストエフォート回線なので拠点(地域)によって若干のばらつきはあるが・・・)
 
SmartVPN/ファイバーコネクト(100M)* 約12~18Mbps
 
SmartVPN/光アクセスプランF(200M)* 約8~11Mbps
※アクセス回線は フレッツ光ネクスト

Internet-VPN/OCN・フレッツ光ネクスト 約40~66Mbps
※ベストエフォート 最大200Mpbs
 
Internet-VPN/OCN・フレッツ光ネクスト 約68~71Mbps
※ベストエフォート 最大1Gbps
 
Internet-VPN/K-Opt・インターネットHG 約2.5~3.0Mbps
※タイプS(ベストエフォート型・最大100Mbps)

Skypeの企業利用(2)

Skype 及び Skype for business に関して、再度 情報収集した。
 
(a)Skype(無料版)は、各機能ごとに通信方式をP2Pからクラウド・サーバ型へ移行しているが、全ての機能が完了したという情報は見つからなかった。ただし、大半の機能が最新バージョンでないと利用出来なくなってきている模様。
 
(b)Skype for Business(以下SFB)は、正規のクラウド・サーバ型のビデオ会議システム(マイクロソフト・旧Lync)。
 
(c)SFBを利用する場合、Skypeクライアント(PC側にインストールするソフト)は最新バージョンでなければならない。
 
(d)Skype(無料版)からSFBに通話する場合、Skype(無料版)クライアントは最新バージョンでなければならない。

f:id:ict33:20170331002747p:plain

上記より、Skype(無料版)の企業内利用時には、以下のような懸案事項が残る。
 
(1)通信方式の問題(P2P)
一部の機能が「旧Lync」サーバーに吸収されていないのではないか。この移行を積み残している機能について、P2P方式で通信される懸念がある。
 
(2)社内ネットワークのトラフィック抑止
音声・映像・画面共有のみの機能であれば、UTMなどの機器を経由させなくてもセキュリティ上の問題はないと考える。が、ファイル添付機能などの機能がある場合、セキュリティ対策は必須となる。トラフィック抑止の為に社内ネットワークを迂回させたい場合、ビデオ会議システムの機能はシンプルな方が良い。
 
(3)利用者を限定出来ない場合のリスク
以下の様な機能・条件の場合には、リスク回避の為、社内ネットワーク接続デバイスからの利用は避けたい。
 ①社外の不特定多数と接続可能
 ②ファイル添付などの機能がある
 ③意図せぬ相手から接続されてしまう危険性のあるP2P方式の通信 など

インターネットアクセスなし/CAPI2-ID4101エラー

随分前から、タスクバーのネットワークプロパティが「インターネットアクセスなし」となっており、(おそらく同時期から)イベントログに大量の「CAPI2-ID4101エラー」が出力されていた。
NetshコマンドでWinHTTP通信にProxyを設定して逃げていたが、原因が分かったので・・・

f:id:ict33:20170512021345p:plain

【事象】
(1)「インターネットアクセスなし」の状態になっている(インターネットアクセスは問題なく出来る)
(2)CAPI2-ID4101『ルート証明書の自動更新ができませんでした』エラーが頻発する(ルート証明書が古い訳ではなさそう)
※各APL処理に於ける実害は不明。(ルート証明書確認のタイミングに、WWWアクセスが遅くなる?)

f:id:ict33:20170512015936p:plain

【影響範囲】
社内の全Clientパソコン(除 ファイアウォールで直接通信を許可しているPC)
 
【環境】
(1)一般Userのブラウザはインターネットへの直接通信は出来ず(UTMのFirewallポリシーで通信拒否設定)、必ずProxy(Squid/RHEL)を経由せねばならない
(2)社内標準ブラウザ:IE11(ERP系業務など)、Chrome(SaaSや通常のWWWアクセス等)
(3)Proxy設定:冗長化対応の為に以下の設定にしている
 ①PACファイルを資産管理ソフトで各Clientに配布(PACファイルはローカルを参照)
 ②ADグループポリシーで「自動構成スクリプトを使用する」に設定
(4)WSUSを使用している(ルート証明書の更新は対象外→MSサイトに直接アクセスするはず)
(5)Client-OS:Windows7(近々Windows10に上げる予定) Windows10移行計画 http://ict33.com/migration.php
 
【原因】
IE11で、自動構成スクリプトのアドレスに、fileプロトコルでアドレスを指定する事がサポートされなくなった為。

blogs.technet.microsoft.com

fileプロトコルについて・・・
・標準的通信モジュール"WinInet"では有効
・WinUpdateなど用通信モジュール"WinHTTP"ではサポート対象外
 
Windows7のIE11では、自動構成スクリプトのPACファイルパスには fileプロトコルでアドレスを指定しているが、正常に動作している。
2015/秋頃から、「CAPI2-ID4101エラー」が頻発するようになった。
上記時期頃からWinHTTPモジュールが、「fileプロトコルでのアドレス指定」をサポートしなくなったと思われる。
Windows7のIE11では、まだ「fileプロトコルでのアドレス指定」をサポートしてくれているようだ。
 
【処置】
(1)WebサーバにPACファイルを配置
(2)DNS/DHCPサーバで、WPAD(Web Proxy Auto-Discovery)を有効にする
(3)ブラウザのProxy設定を、「設定を自動的に検出する」にする
 
【対策】
マイクロソフトに文句を言う ^^;

ネットワークの速度計測

Pingコマンドを使った、経路(閉域型VPN、Internet-VPN)別・拠点別の簡易レスポンス計測ツールを作成した。(といっても、単純なBatchファイルだが・・)
Expingが送信バッファサイズを4,096byteまでしか指定出来ないので、仕方なく。。

--------------------
:start rem 開始
echo 開始日時、 %date%,%time% > temporary.log
echo 【閉域型VPN】、 >> temporary.log

:Entry-VPN1 rem 閉域型VPN・主要拠点
ping "本社・閉域網WAN側グローバルIPアドレス" -l 20712 >> temporary.log
ping "支社・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
ping "研究所・閉域網WAN側(G)IPアドレス"-l 20712 >> temporary.log
ping "PrivateクラウドDC・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log

:Entry-VPN2 rem 閉域型VPN・工場
ping "A工場・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
ping "B工場・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
(省略)
:Entry-VPN3 rem 閉域型VPN・営業所
ping "A営業所・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
ping "B営業所・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
ping "C営業所・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
(省略)
echo 【Internet-VPN】 >> temporary.log

:Internet-VPN1 rem Internet-VPN・主要拠点
ping "本社・アクセス回線WAN側(G)IPアドレス" -l 1426 >> temporary.log
ping "支社・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
ping "研究所・アクセス回線WAN側(G)IPアドレス" -l 1426 >> temporary.log

:Internet-VPN2 rem Internet-VPN・工場
ping "A工場・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
ping "B工場・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
(省略)
:Internet-VPN3 rem Internet-VPN・営業所
ping "A営業所・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
ping "B営業所・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
ping "C営業所・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
(省略)
echo 終了日時、 %date%,%time% >> temporary.log
:end rem 終了
find "、" < temporary.log >> response.log
--------------------

【Batchファイルについて】
ping、echo、find の3コマンドのみの使用
メインはpingコマンド
echoコマンド:ログを見やすくする為、コメント/区切り行を挿入
findコマンド:ping出力結果(=>temporary.log)の、必要な行のみの抽出・累積(=>response.log)
※抽出行の対象となる文字列は "、" とした

【通信速度の算出】
通信速度=送信データサイズ×8×2÷1,000,000÷(ping応答時間÷1,000)
 通信速度:単位が Bits per Second なので、データサイズ(Byte)に8を乗じる
 送信データ:Pingはデータを上り下りで送受信した結果の時間を返すので、2倍する
 百万で除す:単位をMbpsにする為
 応答時間÷1,000:単位が Milli-Sec なので、Secにする

送信データサイズについて】
Ethernet(有線LANで最も使用されている規格だが..)に於いては、
1フレーム(データ送受信)の最大値は1,518Byte。(制御部:18Byte、データ部:1,500Byte)
※下記の(3)~(8)は、イーサネットにおけるデータ部を使用
これを超えるサイズのデータを送出する場合は、パケットに分割されて送信される。
パケットは各レイヤ(階層)で制御の為のヘッダー情報が付加される。
つまり、最上位レイヤでは 1,500-(各レイヤでのヘッダーサイズ) が実質のデータ部となる。
※これが MTU(Maximum Transmission Unit)となる。

各レイヤでのヘッダ情報は下記の通り。
(1) 8 Byte:プリアンブル…ディジタル・データ伝送で付加される、データ開始の同期符号
(2) 18 Byet:Ethernet(OSI第2層=データリンク層、ヘッダ&トレーラ)
(3) 20 Byte:IP(Internet Protocol:OSI第3層=ネットワーク層)
(4) 8 Byte:ICMP(OSI第4層=トランスポート層) ※1
-----以下はWANで付加されるヘッダ情報 ※2-----
(5) 16 Byte:L2TP(OSI第2層=データリンク層)
(6) 2 Byte:PPP(Point to Point Protocol:OSI第2層=データリンク層)
(7) 20 Byte:IP(OSI第3層=ネットワーク層)
(8) 8 Byte:UDP(OSI第4層=トランスポート層)

通信速度の算出に於いては、pingで指定した送信バッファサイズ(フレームサイズ)に、以下の通りヘッダーサイズを加算した。
 想定MTU=1,500ー{(3)~(8)の合計}
 パケット分割数=Round-Up{(送出フレームサイズ)÷(想定MTU,0)}
 実質のデータサイズ=送出フレームサイズ+{ヘッダーサイズ(1)~(8)の合計}×パケット分割数

※1) ICMP(Internet Control Message Protocol)
pingTCP/IPプロトコルではなく、ICMPというプロトコルで動作する。
ICMPはIPの上位層(トランスポート層)のプロトコルだが、ネットワーク層プロトコルであるかのような特別の処理がなされる。
TCP/IP通信の場合、ヘッダー情報は40Byteとなる。
 TCP(Transmission Control Protocol:OSI第4層=トランスポート層):20Byte
 IP(Internet Protocol:OSI第3層=ネットワーク層):20Byte

※2) PPPoE(Point to Point Protocol over Ethernet)
Ethernetヘッダーに加えて、PPP(データリンク層)ヘッダー:2Byte、PPPoE(データリンク層)ヘッダー:6Byte が付加されるが、
ヘッダー情報のサイズはL2TPの方が大きく、MTUは最小値の指定が推奨されているのでL2TPのMTU値とした。

Skypeの企業利用

f:id:ict33:20170331002747p:plain

事業部門から企業内でのSkype利用についてのリクエストをもらった。
これまでの限定的利用と異なり、一般的な社内PCでの利用のリクエストだった為、詳細に課題事項も説明してお断りした。
ご参考までに、その内容を掲載したいと思う。

====================
研究所)○○GLさま
ict33.comです。お疲れ様です。

申し訳ありません、Skypeの一般的なご利用はNGです。
Skypeが企業利用に適していない理由は、以下の様なものが挙げられます。(問題点の詳細は、本メールの後半に記載します)
1.通信方式に問題がある
2.様々な形式のファイルが添付出来てしまう
3.設定を当方にてコントロールできない
4.社内ネットワークの通信トラフィックの抑止

事情をご理解頂き、ご協力・ご支援頂けると幸いです。

【詳細な情報】
・・・・・・・・・・・・・・・・・・・・
1.Skypeの通信方式の問題点
Skypeの通信方式は、P2P(ピアツーピア)方式という、1対1の通信方式です。
(情報流出で悪名を馳せた「Winny」も使用している方式です)
一般的なビデオ会議システムは、データセンターのビデオ会議用サーバに対して、各デバイス(PC、スマホタブレット)が共通のIDで接続し、仮想的な会議室で複数名(デバイス)がコミュニケーションを取るという方式です。
しかしSkypeP2Pでは、任意のPCをリレーしながら、1対1でも複数名でも接続する方式を取っています。
このP2Pのリレー方式には、情報セキュリティ上の様々な問題があります。
(下記リンクのページ、項2にちょうど良い図があります。よろしければご参照下さい)
http://www.neuronet.co.jp/blog/marketing/2011/06/skype.html

なお、「Skype for Business」という企業向けSkype(有料)がありますが、こちらはデータセンターのサーバへ接続する通常の方式です。
ソフト自体は全く別物で、旧スカイプ・テクノロジーズ社がマイクロソフト社に買収され、マイクロソフトの「Lync」というビデオ会議システムが単にサービス・ブランド名を変更したものです。(現在では、PC側のソフトは統合されているようです)
マイクロソフトSkypeP2Pからクラウド型(データセンターのサーバへ接続する方式)へ移行と云っていますが、おそらく現状では
Skype」のアカウントで「Skype for Business」のアカウントの会議へ接続する時だけクラウド型接続となるだけで、
無料の「Skype」どうしの接続は相変わらずP2Pだと考えられます。
こちらが「Skype for Business」でも、相手が古いバージョンの個人向けSkypeの場合、間違いなくP2Pで通信すると考えられます。

・・・・・・・・・・・・・・・・・・・・
2.不特定多数とのP2Pによるファイル添付のリスク
悪意ある相手からダイレクトに不正なプログラムなどを受信してしまうリスクが非常に高いです。
利用者が意図しない相手とも、バックグランド(水面下)で接続してしまうケースもあり得ますので。。。
当社が採用しているビデオ会議システムは、(1)添付ファイル機能がない (2)社内ユーザーのみの利用 ですので、リスクは比較的低いと言えます。

・・・・・・・・・・・・・・・・・・・・
3.当方にてコントロールしたい事項
(1)通信環境の設定
Skypeはネットワーク環境を自分で調べて動作します。
  ### 後から読んでみて、さすがにこれは大げさな表現だなァと反省
  ### 今どきProxy設定の自動検知など、
  ### どこのソフトでも持ってる機能だし・・・
接続環境を利用者側で設定する事も可能ですが、この設定はSkypeを一旦インストールしてしまえば、利用者で自由に変更出来てしまいます。
以前のバージョンでは、ファイアウォールで通信がブロックされてしまった場合、自らファイアウォールに空いている穴を探し回るという、ハッカー(正しくはクラッカー)のような挙動をしていました。
この動作で、社内ネットワーク上をSkypeの探索の為の通信トラフィックが飛び回り、業務システムが突然通信不能となる騒ぎを起こしてしまった事があります。
  ### これ、ホントのはなし
  ### 当時、とんでもないソフトだなァと感じた。
  ### まぁ、試験的にとはいえ 導入推進したのは誰やねん!
  ### と言われれば、私ですけど・・・
現在はこのような仕様は無くなっているようですが、もともと無料版Skypeはコンシューマ向けに作られたコミュニケーション用ソフトウェアで、企業での利用には不適だという思いが未だ拭えません。
(2)アカウントの管理
無料版Skypeの場合、管理出来ません。

・・・・・・・・・・・・・・・・・・・・
4.社内ネットワークの通信トラフィックの抑止
現在、PCやタブレットスマホでの様々なデータ通信(グループウェアや稟議/精算/勤怠などの各種業務システムや、販売管理/生産管理/財務会計などのERP)のトラフィックが、社内ネットワーク上を行き交っております。
映像のデータは、このトラフィックの中でも比較的大きな通信データとなります。
各PCにSkypeのようなコミュニケーション・ソフトがインストールされていれば、利便性はきっと向上するのでしょうが、通信インフラが追いつけていないのが現状です。
G-Suite(Googleグループウェア)にも、「ハングアウト」というコミュニケーション機能があるのですが、上記の理由などから現在は利用出来ないように設定させて頂いております。
コスト面も睨みながら、社内ネットワークの強化は鋭意検討中です。

長文メールで恐縮です。
以上のような諸事情もあり、今回はお断りさせて頂いた次第です。
ご理解の程を、どうぞ宜しくお願い致します。
====================

www.freshvoice.net

当社では、スマホタブレットは(VPN接続も含め)一切社内ネットワークに接続させていない。
昨今ではクラウド化も進んできており、部分的にではあるが社内の業務システムもスマホタブレットで使ってもらっている。
今回は、どうしても各人が個々に利用出来るようにしたいという事であれば、スマホタブレットを買って下さい、で逃げようと思っている。
コストのかかる話になってしまうが、情報セキュリティ面を考慮すると、ここは譲ってはいけないところだと判断した。

フィールドバス 計装からFAへ

かつて、プラントや工場設備の計測・制御(計装と言うそうです。語源は「計測装備」らしい)に於けるM2M通信では、アナログ電流信号が標準規格として用いられていた。
(DC4-20mA、現在でも多くのセンサー・コントローラ・アクチュエータがこのI/Fを装備している)
巨大プラント(装置産業)の自動化(PA:Process Automation)を先駆けにして進んだ計装技術だが、続いて工場機械の自動化(FA:Factory Automation)が活発になっていく。
やがて情報通信技術の進展に伴い、ディジタル化の波が訪れる。

プラントや工場のインテリジェント化を目的として、M2M通信:センサー・アクチュエータ~コントローラ間の伝送信号をディジタル化する国際統一規格(IEC61158)が制定された。
フィールドバス規格である。
現在、メーカー各社の連合等により様々な協会・団体が形成され、この規格に則った多くの方式が提唱されている。

f:id:ict33:20170331002600j:plain

RS-485ベースの代表的な規格/方式でも、
・PROFIBUS(Profibus&Profinet協会/ドイツ/1989年~)
・DeviceNet(ODV協会/米Rockwell/1990年代~)
・CC-Link(CC-Link協会/三菱電機/1990年代~)
・MECHATROLINK(Mechatrolink協会/安川電機/1995年~)
・Modbus(運用組織なし/米Modicon/1979年~)
など多くの方式がある。
なかでも Modbus(通信プロトコルのみの定義)は、仕様公開、利用料無料、実装が容易 等の理由から、実質のデファクト・スタンダードとなっている。

また、"PROFINET"や"FL-net"など、Ethernetをベースとした規格/方式も数多く提唱されている。
Ethernetベースの方式では、昨年4月にトヨタ自動車が自社で使うFAネットワークの標準規格を、これまでの"FL-net"を止め、"EtherCAT"を採用すると決めた。

いまだフィールドバスの規格/方式は林立状態だ。
ITネットワークのように、一日も早い 規格/方式の統一・収斂を期待したいところだ。

自律飛行するスマート・ドローン

このところ大手モバイルキャリア各社の、通信サービスやモバイルデバイス以外の新技術への取り組みが活発だ。
KDDIの、モバイル通信を活用した自律飛行するスマートドローン・プラットフォーム開発、
NTTドコモの、5Gを活用した自動車遠隔制御の実証実験や、需要エリアを予測するAIタクシーの開発、
ソフトバンクは ご存知ロボティクスや、IoT事業を睨んだARM社の買収など、といった具合だ。

通信技術革新による新たなサービスの創出と、活気付くモバイルデバイス市場との相乗効果によって、通信業界全体が急速に発展してきた。
ここへきてスマートフォンの後続を担う革命児も見当たらず、MVNOSIMフリーバイスの登場により、価格競争のフェーズが色濃くなってきたように感じる。

これは、導入・成長・成熟・衰退の製品ライフサイクルで言えば、間違いなく成熟期にある。
革命的なデバイスが登場するのか、画期的な付加価値サービスが打ち出されるのか、次なるイノベーションの波は近いのか。

しかし、2次元の限られた区域内の決められたルートを巡行するバスなんかでも、まだ実証実験段階なんだけど、
ドローンの自律飛行って・・・、3次元だし、まだまだ高いハードルがいっぱいありそう。。


成熟期:製品が市場の潜在的購入者のすべてに行き渡り、成長期での販売の伸びに比べて減速する。利益は安定的に得られるか、または競争の激化によって減少。(Wikipedia:製品ライフサイクルより)

ソーシャルメディアのビジネス活用(2)

昨日、ソーシャルメディアサービスとして、SNSにカテゴライズされる著名なサービスを挙げたが、国内のSNSの雄「LINE」よりも多くの人が利用するサービスがあった。

f:id:ict33:20170331001529p:plain

YouTubeである。
再生による広告収入によって生計を立てている人もいるほどの(YouTuberというそうです)、動画共有のソーシャルメディアサービスだ。
企業でのYouTube活用の一例をご紹介しよう。

うちの会社はG-Suiteユーザだ。コーポレートアカウントでGoogleの各サービスにログインしている。
最近は、製品・サービス紹介カタログや各種マニュアルにも、動画が用いられるようになってきた。
営業ツールとしてのこれらの動画を、YouTubeを用いて統制しながら管理したいというニーズをもらった。
そこで、個人のアカウントとは別に企業のアカウントで管理出来るYouTubeチャンネルを作り、このチャンネルに各種動画をアップしてもらう事にした。
これなら、いちいちVPNで社内ネットワークに入ってもらったり、都度々々動画用のメディア(DVDなど)を準備してもらう煩わしさから解放してあげられる。
手順は概ね以下の通り。

(1)ブランドアカウントの作成
Google+ から、左パネル下部の「ブランド向けGoogle+」で、ブランドアカウントを新規作成。
Googleマイビジネス への新規登録でも、ブランドアカウントの作成は可能。

(2)ブランドアカウント ユーザー権限の管理
オーナー:ユーザー管理/制御まで出来る
管理者:YouTube動画投稿、フォトでの写真共有など

(3)ブランドアカウントで新規チャンネル作成
管理者以上の権限のユーザーならば、マイチャンネルに登録可能

(4)登録されたユーザーのマイチャンネル登録
YouTubeを利用するアカウント」を尋ねられるので、「ビジネス名などの名前を使用」を選択
自分のアカウントとブランドアカウントが表示されるので、ブランドアカウントを選択
※ログイン前に、ユーザー登録に対する「招待」への応答が必要

以上で複数名で管理できるYouTubeチャンネルの登録が完了。

ソーシャルメディアのビジネス活用

本サイト「ICTの右耳」の記事「ICT戦略」に挙げた「SMAC」で、「S:ソーシャル」はまだ企業内で有効活用出来ていないと書いた。・・・が、
最近各メディアのメールマガジン等で、脱メール、社内SNS・ビジネスチャットの有効活用といったセールス・プロモーションをよく目にするようになった。
そろそろ企業向けSNSやビジネスチャットの導入も、まじめに考える時が来たのかな。

SNSインスタントメッセンジャーの長所・利点を踏まえ、ビジネスシーンでの有効活用を考えてみたい。

その前に、ソーシャルメディアに関する利用状況などの、総務省の調査研究報告を見てみたい。

f:id:ict33:20170314185844p:plain

総務省 情報通信政策研究所(IICP/Institute for Information and Communications Policy)
「平成27年 情報通信メディアの利用時間と情報行動に関する調査」

  最近のブログでは、「いいね」ボタンが当たり前になり、
  面白い記事ならば、
  Twitterでツイートし、
  Facebookでシェア、
  はてなブックマークに追加して、
  Google+でフォローする、
  といった読者の姿が目に浮かぶ。

インスタントメッセンジャー系のLINE、ブログ系のTwitterSNSFacebookGoogle+
これらのビジネスでの利用シーンをイメージすれば、効果的なビジネスSNSのカタチも見えてくるか。。

Twitter

f:id:ict33:20170331001341p:plain

ミニブログとカテゴライズされたりもするSNSの一種。リアルタイム性とパブリック性が最大の特徴と云える。
その拡散力の大きさと速さから、不特定多数への情報発信に向くだろう。
直ぐに頭に浮かぶのは、自治体などが災害時に用いる情報インフラとしての用途。
ニュース、天気、公共交通機関、災害緊急情報など、公共性の高い情報発信に最も力を発揮するのではないだろうか。
ビジネス用途としては、ツールを企業内情報システムに組み込んで得る効果は、殆どイメージが浮かばない。
タイムライン上に流れる大量のツイートを、自然言語処理を用いたビッグデータ・アナリティクスで、マーケティングに有効活用するなど、データの有効活用に用途があるだろう。

Facebook

f:id:ict33:20170331001359p:plain

匿名性が前提のインターネットの世界に於いて、実名が原則のFacebookは特異な存在と云える。
実名制のSNSという事で、やはり思いつくのは、企業採用サイトとしての活用だろう。
情報発信サイトとしても機能するし、学生との双方向コミュニケーションも容易だ。

LINE

f:id:ict33:20170331001421p:plain

インスタントメッセンジャーにも分類されるSNS。特定の相手との双方向コミュニケーションが最たる用途。
グループウェアの機能として最も有効活用出来そうなのが、LINEのようなグループディスカッションの機能ではないだろうか。
しかし、LINEが流行ったのは、スマホの電話帳との連携機能によるだろう。
だがこれはセットアップが容易だと言うだけで、インストール後も使い続けられこれだけ利用者が増えたのは、ポップアップ通知機能があったからだと思う。
つまり、使い勝手の容易さ、手っ取り早く使える事が、流行の最大の要因だと言える。

うちではG-Suiteを使っているが、モバイルデバイスではセキュアブラウザでしかG-Suiteは使えなくしており、ログインしないと未読メッセージの有無も分からない。
セキュリティ対策の一環として、ここは外せない。
外したとしても、そもそもポップアップ通知はしてくれないだろうし。。

また、メッセンジャーやチャットでは、統制されたグループ管理だと不便で、利用者が臨機応変にグルーピング出来る事も使い勝手の良さの要因の一つではないだろうか。
自由闊達なディスカッションは、利用者側から発生する寄り合いの中からこそ起きるような気がする。

現状のメールベースの仕事の手順の中で、もう一度困りごとを整理し、それを解決する手段としてどの様なものがあれば良いのかを整理する必要がありそうだ。

Windowsという壁

ビジネスシーンに於けるクライアントデバイスの環境は、WindowsというOSの壁がなかなか崩れない。
うちの会社でも、業務システムの動作保証の制約という1点で、クライアントデバイスの利用環境はWindowsから離れる事が出来ない

f:id:ict33:20170331000919p:plain

営業を中心としたモバイル利用者や管理職にはiPadを貸与しているが、利用出来るサービスは限定されてくる。
結局ノートPCとの2台持ちという運用で辛抱してもらっている。
iPadの導入には別の目的もあり、タブレットというデバイスへの慣らしや、会議のペーパレス化など、副次的ではあるが一定の効果を見た。

かつては、業務システムとMS-Office(とのデータ互換性)が、最大のネックとなっていた。
MS-Officeとのデータ互換の問題は、Office for iPadやOffice for Macの登場で、一気に解決した。
しかし、業務システムの問題は、MSやApple主導で牽引出来るものではなく、各SIerの対応如何による。

上記問題や、業務システムが持つOffice関連のAPIの問題なども考慮すると、やはりVDI環境の構築を考えなければならないのかと思う。

企業向け有料カスタム検索サービス「Google Site Search」終了

Googleが有料の企業サイト内検索サービス「Google Site Search」の新規受付を2017.3.30で終了する。

f:id:ict33:20170331000820j:plain

既存顧客は契約期間終了後、Googleロゴや広告が表示される無料の「Custom Search Engine」に自動移行される。

www.itmedia.co.jp

Googleは、切る時はいとも簡単にバッサリやめてしまう。ドライだ。
使っている企業は多いのではないだろうか。
うちの会社も、サイト内検索結果より上位に広告が出てしまうのが嫌で、使っていたのだが。。

かつては、オープンソースの「Namazu」なんかを使ってサイト内検索を作り込んでいたが、GoogleCSEは本当に手軽で、重宝していた。
検索結果に他社の有料広告が出るくらいなら、検索窓そのものをやめてしまおうかなぁ・・・

Windows10アップグレード

Windows10で、リリース初版(TH1)からのメジャーアップデートである"TH2"がリリースされた。(2015.11.12公開)
※"TH"は、Windows10の開発コードネームである"Threshold"の略称なのだそうである

www.itmedia.co.jp


開発コードの第2版なので、"Service Pack"だと思えば、そろそろ安定して来たのだと判断出来る・・・かな?

japanese.engadget.com

(開発コードネーム:Redstone)
この間にメジャーアップデートはないようなので、そろそろWindows10にアップグレードしても問題なさそうだ。

というわけで、昨年暮れに とうとうWindows10にアップグレードしてしまった。
もう1台WIndows8.1PCはあるし、ボリュームバックアップもしているので、大丈夫だろう。
「Windows10アップグレード勧誘」のポップアップもウザいし。。

Windows10 TH2 の不具合&トラブル情報(2015年11月版)
※"Windows10 TH2 不具合"でググってみれば、最新情報が探せる。

1.インストールは概ね以下のような流れだった。
(1)ダウンロード(0:31-0:32):約1分(すでにバックグラウンドで実行済みだったようだ、勿論ネットワーク環境による)
(2)Windows10の更新の構成(約9分) & 再起動(約3分):約12分
(3)Windowsアップグレード:約40分
 ①ファイルコピー(約19分) & 再起動・ドライブスキャン(約4分)
 ②機能とドライバーのインストール&再起動(約10分)
 ③設定の構成(約7分)
 (この間には別段の操作はなく、PCは放っておける)

(4)Windows10にようこそ:「次へ」 → 「ライセンス条項の承諾」 →
 → 「簡単設定を使う」 → 「Cortanaを使う」 →
 → 新しいWindows用のアプリ:「次へ」 → 再起動 & ログオン
(5)構成の編集(ガイダンス画面が流れる。約4分)

PCと環境のSpec.は下記の通り
 CPU:Celeron N2940 CPU 1.83GHz
 MEM:8.00 GB
 SSD:203 GB(未使用領域 139.5 GB)
 OS:Windows8.1 Home Edition (64bit) バージョン6.3 ビルド9600
 ネットワーク(理論値):WLAN 144.4Mbps, WAN 100Mbps(光、Best Effort)

2.アップグレード後の状態としては・・・
(1)GoogleドライブとDropboxの同期プロセスが、PC再起動後に正常に起動されなかった。
(2)プリンタドライバが正しく認識されなかった
※上記オンラインストレージ、プリンタドライバについては、もう一度Windowsを再起動すると、正常に認識・プロセス起動された。

3.上げてみての使用感はと言うと・・・

(1)良いところ(ちょっと良くなったな…程度)

■"Cortana"(コルタナ)…音声対応パーソナルアシスタント(仮想アシスタントサービス)

techtarget.itmedia.co.jp

(以下引用)
Cortanaはインターネットもローカルのデータも検索可能だ。例えば、Windowsに標準装備の「メモ帳」を使いたいが、新しいスタートメニューのどこを探せばよいのか分からないとする。Cortanaに「メモ帳」と入力すると、このデジタルアシスタントは、クリックすればメモ帳を起動できるショートカットを提示する。加えて、「Windowsストア」からダウンロードできるメモ帳と類似のアプリケーションを含めた検索結果を表示する。

■"Edge"…標準ブラウザ
特に目立った良い所が印象に残っている訳ではないが、利用出来るブラウザが増えたのは若干助かる。
よく見るページ、読み掛けや読み返したいページ、製作中のページやHTML-Tagリファレンスなど、タブを開きっぱなしにしておきたいサイトが沢山あるので、これまでもChrome、IE11、Firefoxを使っており、もう一つ増えるのは有難い。

(2)悪いところ(かなり悪い印象)

■フォント
最悪。フリーソフトを使って、MeiryoUIに戻した。
読み辛い「MSゴシック」から「メイリオ」になって喜んでいたのに、「游ゴシック」という 書体がつぶれててさらにチラつく最悪のフォントになってしまった。。

システムフォントを変更出来るフリーソフトがあるので、ご入用の方は下記からどうぞ
Meiryo UIも大っきらい!!

■スタートメニュー
使いづらい。Windows7までの仕様に戻して欲しい。Windows7までの標準的なスタートメニューとWindows8.1のだめだめスタートメニューの間みたいな感じだ。

以下の記事に詳細に記載されている。

itpro.nikkeibp.co.jp

Notesマイグレーション グループウェア ワークフロー

オンプレミスのグループウェア・プロダクトの代表格と言えば、やはり一番にNotes/Dominoが挙げられるのではないだろうか。

f:id:ict33:20170331000721p:plain

私の会社でも、ご多分に漏れず Notes/Domino→Google Appsという いわゆるNotesマイグレーションを、昨年の夏に実施した。

業務システムのIE対応の兼ね合いで、IE8→IE9→IE11と段階的にバージョンを上げて行った。この間にGoogle Apps導入となった為、標準ブラウザをChromeとして、グループウェアやネットサーフィン(死語?、基 インターネットブラウジング)はChromeで、IEは業務システム(ERPなどの基幹系システム)専用とした。

Notes/Dominoマイグレーションに際しては、概ね以下の機能群ごとに検討する事になると思われる。

Notes/Dominoの機能
(1)グループウェア機能
①電子メール、②スケジュール管理、③施設・会議室管理、④各種掲示板、⑤社内ポータル など
(2)ドキュメント共有(審査・承認機能付き各種データベース)
(3)ワークフロー系アプリ(SFA、人事考課、稟議申請、与信管理、その他各部門固有業務もろもろ)

各機能の移行は以下の通りとなった。
(1)グループウェア機能
 ①電子メール → Google Appsメール
 ②スケジュール管理 → Google Appsカレンダー
 ③施設・会議室管理 → Sカレンダー(サテライトオフィス社のGoogle Appsアドオンソフト)
 ④各種掲示板、⑤社内ポータルなど → Google Appsサイト
(2)ドキュメント共有 → Google Appsサイト/Googleドライブ/ファイルサーバ(用途・目的による)
(3)ワークフロー系アプリ → ノンプログラミング系開発ツール(ワークフローエンジン付き)やSaaS・・・これだけは、グループウェアに含む事は出来ないと思う

www.keyman.or.jp


なぜOffice365ではなかったのか・・・

Office365にした場合、Officeスイートを最新にする必要が生じ、業務システムとのAPIで種々の問題が生じる恐れが大きいと判断した。
業務システムではExcelなどのOffice製品とAPIがある。当社ではOfficeはボリュームライセンスでの購入だが、Office365では突然バージョンアップせねばならなくなると、ユーザ企業が登壇するセミナーで聞いた。(バージョンアップしなくても利用可能なのだろうが、ドキュメントデータの互換性に問題が生じるのは頂けない)
Outlookだけ最新バージョンにし、Excelは業務システム対応完了まで据え置くといった煩雑なコントロールが生じるのではないかと考えられた。バージョンを上げなければOutlookで各サービスが利用出来ず、これがブラウザ利用となるのであれば、Exchangeの使い勝手の良さが生きないように感じた。
また、突然ブラウザが最新バージョンでないと駄目と言われても、Web系業務システムの対応はそんな俊敏には取れないし・・・
(検討当時はまだIE8のサポートも切れておらず、社内はWindowsXP/IE8だったので・・・。今となってはこの心配は杞憂に終わったのだが・・・)

では、サイボウズDesknet’sは?・・・
基本料金で提供される容量が少な過ぎた。これに尽きる。追加のデータ容量は従量制なので、コストが試算し辛かった。

・・・冒頭に紹介したキーマンズネットの記事中で、「実は最近増えているのが、Google AppsからOffice365へのリプレイス」だって…(- -;  トホホ (T-T)


ワークフロー系アプリケーションについて

ワークフロー機能に関しては、もともと切り離して考えていた。
グループウェアマイグレーションの2年程前から、いずれやって来るNotes/Dominoとの決別の日の為、そのXデーを迎えるに際して最大の足かせとなるであろうワークフロー系アプリだけは事前に対処しておこうと考えていた。

Notes/Dominoでは、フロー制御部もLotusスクリプトでコーディングする必要があった。i-Notes(Domino Web Access)も利用する場合、Javaスクリプトとの2元管理となった。当然、製作したアプリのバグる率は高くなる。
フロー制御はGUIで簡単にデザインしたかった。

GUI設計の出来るワークフローエンジンを備えた、ノンプログラミング系の開発ツールを探した。
SharePoint Designerでの個々のワークフローアプリ作成は、Lotusスクリプトによる開発と同じくらい手間っぽい

SharePoint 2013 ワークフローの概要

採用したのは、キャノンITソリューションズ社の「Web Performer +ワークフローオプション」。
最後まで検討のテーブルに残っていたのは、住友電工情報システム社の「楽々Framework」&「楽々Workflow」だった。
私は「楽々~」を気に入っていたが、製作担当者は「Web Performer」の方に良い感触を持っていた。
自社で必要とする機能や使い勝手、導入後の教育・支援メニュー、提供価格など、自社の体力(人員、資金など)にフィットするものを選べば良いと思う。

しかし、Notes/Dominoだけで実現できていたサービスを、ワークフローアプリとグループウェアに分けて考え 段階的に切り替えていくとなると、単年度内で収束せずに予算上の問題が生じる。
実際 先行して開発ツールを導入する為にはそれなりの説明が必要で、納得を得られるような作文には随分と骨が折れた。

かくして現在では長らく愛用してきたNotes/Dominoとも無事別れる事ができ、(それなりに不便な所もあるものの) 運用負担も軽減出来て幸せな日々を過ごしている・・・かナ?
とは言え情報システムにゴールなどなく、今後もマルチデバイス対応やクラウド化など、悩みの種は尽きないのです。。

グループウェア シェア

愛読メルマガの一つ、キーマンズネットより「グループウェア シェア」が公開された。
ID数による国内利用者数シェア(2015年度予測値)だそうだ。
メーカ(ベンダ)シェアしかわからないので、ノークリサーチ社のプレスリリースも参考にして、サービス/プロダクト情報を付加した。

出典:キーマンズネットグループウェア シェア情報アーカイブ」(富士キメラ総研・2015年市場調査レポートより)、ノークリサーチ「2015年中堅・中小企業における『グループウェア』の利用実態とユーザ評価」

29.7% ○マイクロソフト(Office365など)
25.3% ○Google(Google Appsなど)
9.3% ○IBM(Connections Cloudなど)
7.4% ○サイボウズ(cybozu.comなど)
7.3% ●IBM(Notes/Dominoなど)
5.5% ●マイクロソフト(Exchange Serverなど)
5.2% ●サイボウズ(Office,Garoonなど)
3.5% ●ネオジャパン(DesknetsNEOパッケージなど)
1.0% ○ネオジャパン(DesknetsNEOクラウドなど)
1.0% ○富士通Mkt(WebOfficeなど)
1.0% ●NEC(StarOfficeなど)
2.1% ●その他プロダクツ
1.7% ○その他クラウドサービス

○:SaaSパブリッククラウドサービス
●:オンプレミス向けプロダクト(パッケージソフトウェア)
※全体で875万5千IDと見込んでいるとの事だが、グループウェアの利用者は総人口の1割未満という事になり、これは意外と少ないという感触だ。

今年度中に、75%以上がクラウドサービスへシフトを終える事になる。
8割近くが外資系の製品となり、なんと全体の過半数を"Office365"と"Google Apps"が占有する。
グループウェアと言えば"Exchange Server"や"Notes/Domino"といったオンプレミスタイプだったのは、既に過去の話となった。

私の会社でも、マルチデバイス/マルチプラットフォームや、OS(Windows)・ブラウザ(IE)のバージョンアップへの追従の煩雑さを考慮し、モバイルシーンでの利用が主体となる業務スタイルのアプリケーションは(グループウェア、経費精算、考課、SFA、稟議申請など)、オンプレからクラウドへの移行を進めている。

もはや「クラウドファースト」は流行語ではなく、ビジネスシーンの現状を表す言葉となった。