SQLWorld★大阪#24での発表資料です。 Office365サービスの特徴を踏まえ、導入に向けてすべきことを具体例含めて紹介します。

1. MVP - Office365
genkiw（渡辺 元気）
SQL World 大阪#24
2014.06.21

2. 名前：渡辺 元気（わたなべ げんき）
職業：通信事業者でクラウドサービスの開発
twitter/Facebook：genkiw
MVP Office365 2012.10-
blog：日々徒然 http://blog.o365mvp.com/
（Office365の技術ネタを中心に公開）

3. 本資料については、個人で準備した環境において、個人的に実施した検証結
果を基に記載しております。
あくまで個人の意見・見解であり、所属する会社・組織及びマイクロソフト
社とは一切関係はございません。
また、本資料の内容ならびに閲覧により生じた一切の問題及び不利益につい
て、発表者は一切の責任を負う事はできませんのでご了承ください。

4. Office365のサービスの内容、特性を理解する
Office365の導入に必要な環境を理解する
Office365に適した運用について理解する

5. 価格が安い１
運用が楽で常に最新２
導入が早い３

6. 要件定義 基本設計 詳細設計 テスト 移行
従来のコミュニケーションシステム基盤導入
• 約半年～1年以上（導入規模とカスタマイズ度合いによる）
環境調査 トライアル 計画立案 環境整備 移行
Office365導入
• 約1ヶ月～半年以上（導入規模と既存環境の適合具合による）

7. • ディザスタリカバリを意識した高い可用性環境
香港
シンガポール
• 常に最新バージョンのソフトウェア
オンプレミスで実装するのは困難

8. EXCHANGE SERVER EXCHANGE ONLINE
0
330
200
500
150
100
100
50
サービス利用料 ライセンス 物品費工事費
保守費 NW DC
※過剰なスペック（例えばメールボックスサイズ）を削ってサイジングした
モデルケースでのオンプレミスとOffice365の参考価格比較
【参考】中堅企業モデルケースにおけるExchangeのユーザー単価比較

9. SIで作ると1億が
月額50万に
コスト削減
今使ってるOSが
サポートされてる
99.9%のSLAと
24時間365日の
日本語サポート
試用版は今の
社内NWのままで
利用できた
いつも使ってる
Sierが導入してく
れるらしい
あの会社も
入れたらしい

10. Office365の費用に、移行費用積んでもコスト
を1/3に削減できた。
導入もいつもの会社に依頼して、マニュアル
作成や説明会も実施した。
スマホからもスケジューラーを利用できて、
役員のウケも上々。
めでたしめでたし

11. インターネットのトラフィックが増えてインターネット回線や
Proxyサーバがパンクした。
IE9使えなくなる？すぐにバージョンアップ
なんてできないよ。
いつのまにかメニューが変わってる…マ
ニュアル作り直し？ユーザー教育は？
今朝からメールが使えなくて、問い合わせがばんばん来てる
けど、障害状況が全く分からない。社長からはベンダ呼んで
こいと言われたけど来てくれるの？
何か先週のメンテナンス後から一部のメ
ニュー表示がおかしい。でもモバイル回線
からだと上手くいくから社内NWの問題？
Office365サービスを良く理解し、運用フェーズ
の事まで考えた上で導入しましょう。

12. 【従来】
自社のシステムの予算と償却に
合わせたサイクル
【Office365導入後】
マイクロソフトの開発サイクルに
合わせる

13. 導入 機能追加 更改
システムへの期待度
（機能やコスト）
システムでの実現
仕様を満たす
のが必須条件
トップダウン
や外的要因等
更改時期になる
と上がる要望
固定資産の償却期間を考慮し、長いスパンで
の運用。良い意味で言うと安定している。

14. 導入
システムでの実現
たまに
ディグレ
頻繁な機能追
加や仕様変更
2-3年周期の
ﾒｼﾞｬｰUpdate
いつ止めて
もいい
常により良い物にしようと頻繁にアップデート
アップデートの時期や内容はコントロール出
来ないが、代わりにいつ止めてもいい

15. • クライアントのスペックやOS、アプリをサポートされる物に保つ
（バージョンアップや更新プログラム適用）
クライアント
• 必要とされるネットワーク要件を満たす
ネットワーク
• ユーザー教育やマニュアルの整備
教育
• 連携システム（ADFS/ディレクトリ同期/ハイブリッドのExchange
Serverなど）をサポートされる物に保つ（OS変更が必要な場合有）
関連システム

16. • 原則として、クライアントはインターネット接続
が必要
• 名前解決（DNS）、ルーティング、Proxy（バイパ
スリスト含む）、Firewallなどを考慮する必要
• インターネットトラフィックは確実に増大
• 同時接続セッション数も増加
インター
ネット上に
存在
• 膨大なIPアドレス空間と、増加し続けるサー
ビスネットワーク
• 全ユーザーとも単一のURLを利用。URLフィ
ルタリングへの影響への考慮が必要
共有型の
サービス

17. The Internet
VPNサービス
SMTP Relay
Mail
DC 本社DMZ
内部SV
従来 Office365導入後
The Internet
VPNサービス
本社

18. 当初(2011.6)
約50個程度
更新頻度も高く、IPでの制御は
既に限界に来ていると考えられる
※RSSによるIP/URLの変更通知

19. *.aadrm.com
*.activedirectory.windowsazure.com
*.glbdns.microsoft.com
*.live.com
*.lync.com
*.microsoft.com
*.microsoftonline.com
*.microsoftonline-p.com
*.microsoftonline-p.net
*.microsoftonlineimages.com
*.microsoftonlinesupport.net¹
*.msecnd.net
*.msocdn.com
*.msn.com
*.msn.co.jp
*.msn.co.uk
*.onmicrosoft.com
*.office.com
*.office.net
*.office365.com
*.officeapps.live.com
*.outlook.com
*.phonefactor.net
*.Sharepoint.com
*.Sharepointonline.com
ev-secure.verisign.com
evsecure-ocsp.verisign.com
evsecure-aia.verisign.com
evsecure-crl.verisign.com
sa.symcb.com
*.amazonaws.com
*.cloudfront.net
*.cotssl.net
*.edgekey.net
*.yammer.com
*.yammerusercontent.com
*.assets-yammer.com
https://activation.sls.microsoft.com
http://crl.microsoft.com/pki/crl/products/MicrosoftProductSecureServer.crl
http://crl.microsoft.com/pki/crl/products/MicrosoftRootAuthority.crl
http://crl.microsoft.com/pki/crl/products/MicrosoftProductSecureCommunicationsPCA.crl
http://www.microsoft.com/pki/crl/products/MicrosoftProductSecureCommunicationsPCA.crl
https://odc.officeapps.live.com
https://ols.officeapps.live.com/olsc
http://officecdn.microsoft.com
go.microsoft.com
office15client.microsoft.com
sls.microsoft.com
※http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh373144.aspxにて最新情報。（RSS配信あり）
制御が必要な場合はMicrosoftもURLを推奨するように

20. • IPアドレスでの制御は既に限界。MicrosoftもURLを推奨
• インターネット抜けを許容できない場合、URLを認識できるアプリ
ケーションFirewallでの対応が今後の主流
L3SW/Firewall
• 認証Proxyは一部アプリが対応していない（要バイパス）。アプリ
ケーションがProxy自体を認識しない物も有り。
• Outlook利用時の予定表でのセッション枯渇のトラブル事例多し
• 問題発生時はバイパスして試験して切り分ける必要あり
Proxyサーバ
• デフォルトルートが設定できるタイプの物を利用。できない場合は
Proxyしかないが前述の通り制約あり
VPNサービス

21. • サービス利用契約を中心としたサービス
• 集中管理によってサービス品質向上。日本に
窓口はあるが、調査・バグ修正などの対応は
米国にて実施
米国企業
による
サービス
• 全世界での「公平な」サービス
• ユーザー環境依存の問題や技術者のオンサイ
トでの派遣、優先的なエンジニアのアサインは
含まれない
パブリック
クラウド
サービス

22. 日本Microsoftにサービス正常性ダッシュボー
ドを大きく上回る精度・速度での情報提供を
求める事は難しい。
SLA返金の他、5日以内のPIR（事後インシデン
トレビュー）の開示が保証されているが根本
原因が特定できない場合も有る。
保守契約内容に関わらず、障害が発生したらベンダの人間を呼び出
したり定期報告を要求。直った後も営業担当者経由で報告書を提出
させ、納得のいくまで調査報告をさせるなどの
日本式(?)の障害対応は通用しないと考えた方が良い
【参考】マイクロソフトはいかに顧客をサポートしているのか
http://www.itmedia.co.jp/enterprise/articles/1305/29/news016_2.html

23. 【範囲外と判断される事例】
ユーザー環境に依存する問題（インターネットに直接接続さ
れた別の端末から利用可能）
関連したオンプレミスのシステム（ADやADFS、Exchange
Server）に依存する問題
開発に関連する問題（バージョンアップ後、特定コードが動か
なくなったなど）
オンサイトでの調査や報告の依頼
MSの定める深刻度レベルを越える対応
必要に応じてPremierサポートなど有償サポートを
別途契約する必要がある
【参考】Premier Support for Office 365
http://www.microsoft.com/ja-jp/services/premier/Office365.aspx

24. • Office365を利用する上で周辺予算についても必要で
あることを認識し、確保する
• 特にメジャーバージョンアップに際してのPC入れ替え
やユーザー再教育など
予算取り
• 契約上、障害時の救済は基本的に返金のみ
• 環境依存の対応が別途有償であることを認識
• 営業やSEなどに対しての人的な対応を求める事がで
きないことを認識
サービス内容の理解
サービス費用の他、下記を加味した上で、経営的な判断として決定する

25. 障害・サービス更新などどうしても自社で制御できない部分がある事を認識
Outlookが使
えない
OWAを利用する
Exchange
Onlineに障害
携帯メールやFax、Lync、SharePointなど別手段で
の連絡手段を確保しておき、利用する
障害で移行が
失敗
延期する（元から1%くらい失敗する可能性が有る
ことを考慮に入れておく）
手順書と見た
目が違う
とりあえずやってみるか延期する。
もしくは知ってそうな人に聞く。

26. 多くのユーザーが同じ物を利用していることを前提に複数確保する
• Office365サービス正常性ダッシュボード
https://portal.office.com/ServiceStatus/ServiceStatus.aspx
• Office365コミュニティ
http://community.office365.com/ja-jp/default.aspx
• Facebook Office365コミュニティ
https://www.facebook.com/groups/Office365Com.jp/
• Twitter
MS公式アカウントや「Office365 障害」などで検索
• その他
勉強会やユーザーグループなどでの横の繋がり

27. 故障申告時に環境依存かどうかを自身で切り分けられるようにする
【必要な物】
インターネットに直接接続できるNWとPC
PCは極力アプリがインストールされていない物。アンチ
ウィルスソフトは手動で切ることができる様に。
回線はスマートフォンのディザリングでも良い
テスト用の別テナント
試用版でも良い。切れたら再度取る。
「インターネット直接接続でも出るか」
「他のPC/アカウントでも出るか」
「他のテナントでも出るか」
を故障申告時に出せると、対応の迅速化につながる

28. サービス側がどんどん変わっていくので、極力柔軟に対応できるようにする
公開方法
静的コンテンツとして作成して一方的な公開ではなく
コメントが返せるサイトなどでの公開にする
マニュアル
紙での配布やPDFなどで作成せず、
Webサイトでの公開にする
利用者教育
集合型の説明会などではなく、Lync会議での開催
や各部門での若手の人間にやらせるなど

29. ☑クライアント環境の常時アップデートが可能な体制・環境
これだけは必要
☑有事の際は代替手段に切り替えるなどで、直るまで待つと
いう運用に耐えられる
最悪お金か気合いで切り抜けられる
☑インターネット直接抜け環境、もしくはAP-Firewallの導入
☑トラブル時の切り分けはできるレベルのIT管理体制
☑社内マニュアルの更新ができるレベルの社内体制もしくは
マニュアル不要な社員のリテラシー