2018.05.11

NotesからShare Point Onlineへの移行が失敗する3つの要因と、成功のための処方箋

【この記事のポイント】
ノーツからシェアポイントの移行が失敗する要因
・ノーツに最適化された社内業務、ノーツの使用を前提とした職場の文化
・ノーツとシェアポイントの設計思想の違いに対する理解不足
・シェアポイントの設計思想を無視した開発
NotesからShare Point Onlineへの移行を成功させるには
・基本機能で簡単なサイトを作成し、テスト運用で不都合な点をつぶしていく
・モデルとなるサイトを公開して、「SPOでできること」をユーザーに理解してもらう
・教育・研修と多様なコミュニケーション施策で、システム変更の背景を伝える

「ノーツマイグレーション」という言葉を初めて聞いたのは、もう10年ほど前のことだっただろうか。カスタマイズ性に優れたグループウェアとして長年多くの企業で使われてきたIBM Notes（旧Lotus Notes 以下ノーツ）だったが、IBMによるサポート終了予告やユーザー企業側のコスト削減、働き方改革やデジタルトランスフォーメーションの波に押され、時代遅れとなりつつあるノーツから他のグループウェアへの移行を検討する企業が増えている。特にこのところ相談が多いのは、ノーツからMicrosoft 365（旧 Office365）に含まれるShare Point Online（シェアポイントオンライン以下、SPO）への移行の相談だ。

その背景には、業務で使用するMicrosoft Office製品を従来のパッケージ型からクラウド型のMicrosoft 365に切り替える企業が増えていることがある。常に最新版のOffice製品が複数の端末で利用でき、ストレージサービス（One Drive）やWEB会議システム（Skype）なども利用できるMicrosoft 365は企業にとってメリットが大きい。そこで、従来ノーツで使っていたメールやスケジューラー機能をMicrosoft 365のExchange Server/Outlookへ、文書管理や掲示板の機能はSPO/Yammer/Teamsへ切り替えようという選択肢が出てくるのだ。
ところが、この移行は往々にして失敗する。専門のSIベンダーに相談したが費用が高すぎる、移行しようとしたが話がまとまらず結局SPOとノーツを並行して利用している、移行を行ったが使いにくいと社内の評判が悪い、大幅なカスタマイズが必要で保守費用がかさんで困る・・・。相談する相手がみつからず困り果てた企業のご担当者から、専門のSIベンダーではない弊社にご相談いただく機会も多い。ノーツからSPOへの移行が失敗する背景には、一体どのような要因があるのだろうか？

なぜNotesからShare Point Onlineへの移行は失敗するのか？

1.長年にわたって培われた社内のノーツ文化

ノーツは非常にカスタマイズ性が高いため、自社の大規模システムのベースとして使用されたり、社内申請などあらゆる業務フローに密接に組み込まれていることが多い。長年社内でノーツが使われる中で、企業では業務に合わせてノーツがカスタマイズされ、あるいはノーツに合わせて業務が最適化され、「ノーツ文化」ともいえるものが形成されていくのである。
さて、ここでいうノーツは、掲示板とデータベースの機能を指しているが、SPOはもともと掲示板でもデータベースでもなく文書管理システムである。設計の思想も「できること」「できないこと」も両者では全く異なるため、「ノーツをSPOにそのまま移行する」というのはそもそも無理がある。データ構造もインタフェースも異なるノーツからSPOにすべてを移行しようとすると、それはつまりSPOを改造してノーツ化することになってしまう。本来はSPOを使ってできることをベースに業務を再設計する必要があるのだが、業務フローの変更は現場にとっては負担であり、メリットが理解されにくい。そして「SPOに移行したら不便になった」、「ノーツの代用になるようにSPOをカスタマイズしてくれ」という現場からの不満につながっていくのである。

2.ノーツとシェアポイントの違いやメリット・デメリットを理解できない経営層と現場

ノーツからSPOへの移行は、例えるなら「馬車」から「自動車」への移行だ。馬車と自動車は「荷物や人を運ぶ」という機能だけを見れば同じようなものだが、動く原理も形状もまったく異なる。日常的に馬車を使っているが「自動車」は見たことも聞いたこともない時代の人に対して、断片的な情報だけで自動車の利便性やリスクを説明するのは難しいだろう。
同様に、SPOの導入前に、ノーツとSPOの違いやメリット・デメリットを経営層や事業部門に十分に理解してもらうことは容易ではない。なぜなら、それを行うためにはSPOの仕様を熟知しておかなければならないからだ。
例えば、ノーツでは当たり前にできる「未読と既読」の管理。これはWEBシステムをベースとするSPOでは難しい。同様にノーツでは当たり前にできる「発信文書への返信機能」もSPOには思想として存在しない。なぜなら発信された情報に対して返信を行うという行為はMicrosoft 365ではソーシャルネットワーク機能として位置付けられているため、ツールとしてはSPOよりもYammerやTeamsが推奨されているからだ。Microsoft 365はSPOをはじめとしてYammerやTeams、FlowやFormsなど目的の異なる複数のアプリケーションで構成されているため、用途に応じて使い分けが必要になるケースもある。こういったノーツとSPOとの違いを十分に把握できていないがゆえに、機能やカスタマイズ、メンテナンス、費用、さまざまな面において、導入後「こんなはずじゃなかった」「聞いていない」というトラブルになりがちなのである。

3.魅惑の「開発」をめぐる、IT部門とベンダーの共犯関係

企業がMicrosoft 365を導入する背景には、デジタルトランスフォーメーションの波がある。消費者の生活環境がどんどんデジタル化され、企業と消費者の関係や社会のあり方がめまぐるしく変化する中、企業もその変化により速く、より柔軟に対応するために、ビジネスモデルの変換を迫られている。デジタルトランスフォーメーションに向けた施策の1つとして業務システムのクラウド化やモバイル対応を進める企業が増えており、Microsoft 365はそうした企業のニーズにマッチしているといえる。
多くの企業が今まで使ってきたノーツやオンプレミス型（自社運用）のSharePointをはじめとする一世代前の社内システムは「自社の業務に合わせて開発して使うもの」という前提があった。ところが、モダン・ユーザー・インターフェイスを採用したSPOはモバイルに最適化されており、開発を伴わない設定のカスタマイズ程度のことしかできない。開発がまったくできないということはないが、開発することによってモバイル機器からアクセスした際に不都合が生じたり、SPO自体がバージョンアップされた際に開発内容が引き継がれない（バージョンアップできない、またはバージョンアップのたびに開発が必要になる）といった問題が出てくるのだ。
前述のように、そもそも設計の思想が異なるので、SPOをいくら開発してもノーツにはならない。そのため本来なら、「開発せずSPOの標準設定のカスタマイズ内でできること」をベースに業務を見直す等が必要になってくるのだが、IT部門にとっては膨大な手間をかけて社内を説得し、教育して回るよりも、現場からの要望通りに開発した方が楽である。

さらに、多くの企業がSPO移行時に相談するベンダーであるSIerは本来、「開発すること」を主業務としており、SPOの設計思想や仕様とユーザー企業の業務を考慮して用途開発を行うことは業務の範疇外だ。SIerにとっては、開発することで本業での売上につながり、バージョンアップのたびに運用保守も請け負うことができるので、顧客の抱える課題に対して「開発を行う」以外の提案はなかなか出てこない。
こうして「開発」をめぐるIT部門とベンダーの共犯関係ができあがる。そして、この「開発」は、長期的に見れば決して会社のためにはなっていないのである。

NotesからShare Point Onlineへの移行を成功させるには？

それでは、Notesから他のシステムへの移行をスムーズに行うにはどうしたらいいのだろうか？以下に、弊社の経験で有効と感じている3つの処方箋を紹介する。これは、SPOに限らずノーツから他のシステムに移行する際には有効な方策であると考えている。

●処方箋１：プロトタイピングとスモールスタート

自動車が走っていない国に住む人が自動車の活用法や交通量の予測、事故防止の対策を立てるのは至難の業だ。実際に使ったことのないものについて、その使い心地やメリット・デメリットを想像することは難しい。移行を成功させるには「SPOを使ってできることをベースに業務を再設計」することが必要だが、いくら事前に多くの部門を巻き込み、長い時間と費用をかけて検討し、大規模な開発をしたとしても、結局使いにくいものができたら元も子もない。
「SPOで何ができるのか」「SPOをどう活用すべきか」が伝わらないときに、一番手っ取り早いのは「まず使ってもらう」ことである。

例えばSPOでは「サイトコレクション」や「ライブラリ」などの言葉が出てくるが、ノーツにはそもそもこうした機能・概念が存在しない。そのため、大枠を絵で書いて説明することで何となくは理解してもらえるが、実際のところ大きな思い違いをしてしまっていることも多々ある。むしろそれらの機能を、勝手に頭の中でノーツの仕様に置き換えて理解してしまうと、大きなボタンの掛け違いが発生する。
それを回避するために、まず基本機能で簡単なサイトを作成し、テスト運用して不都合があれば対策を考える。それを繰り返すことで、全社で導入する際に必要なコミュニケーションも明らかになってくるだろう。

●処方箋２：フラッグシップアプローチ

SPOではノーツの機能は再現できないので、長年「ノーツの使い方」をインプットされた人が初めてSPOを使うと「前にできたことができない、不便だ」と感じることがある。人は、使ったことがなく使うメリットも明確でないものを積極的に利用しようとはしない。しかし、身近な人が「これを使って良かった」と言っているものは使ってみたいと思う。
スモールスタートともつながるが、全社導入の際に有効なのは、モデルケースとしてSPOの基本機能のみを使用したサイトを一部門で作成し、全社に公開することである。そこで「具体的にどんな場面で、どのように活用でき、どんな成果が出たのか」ということをできるだけわかりやすく、魅力的に伝えていく。そして実際に使ってもらう中で「今までよりも便利だ」という驚きや「これは使える」という納得感を形成していくのである。

これまでノーツでできたことがSPOではできなくなる場合がある一方で、これまでノーツでできなかったことがSPOでできるようになることも多い。利用者である社員の多くは、日常生活の中でFacebookやブログ、TwitterといったWEBサービスを利用している。ノーツを再現するという考え方をやめさえすれば、日常使い慣れたWEBサービスとも共通点があるSPOならではの「できること」に対して、多くのユーザーは抵抗を感じないはずなのだ。

●処方箋３：教育・研修と多様なコミュニケーション施策

ケーススタディを含め、新システムの導入にまつわる教育・研修や、社内報などの社内メディア、Face to Faceの機会を使ったコミュニケーションは、システム導入時だけでなく継続的に行う必要がある。その際に大切なのは、自社の理念やビジョン、市場の動向などを踏まえ、新システムの導入とそれに関連した業務の見直しが、自分たちの仕事にどのようなメリットをもたらすのかを丁寧に説明することである。

業務の変更は現場にとっては負荷であり、「顧客のための時間が削られる」と敵視されかねない。しかし、この変更がデジタルトランスフォーメーションという市場の変化に対応する戦略の一環であり、最終的には働き方改革による従業員満足度の向上、ひいてはサービス向上と顧客満足度・企業価値の向上につながるということを理解してもらうことで、納得感と目的意識を持って現場の受容につなげることができる。システム変更をきっかけに社内のデジタルトランスフォーメーションへの意識を向上させることができれば、一石二鳥ではないだろうか。

現在は、社内で独自のシステムを構築してIT部門が運用する従来のオンプレミス文化から、社内システムをクラウドに置くのが主流になっていく端境期に位置している。経営者、そしてIT部門自体、さらには各部門の現場の社員もデジタルに対する意識変革が求められている。
システムを入れ替えればデジタルトランスフォーメーションが前に進むというものではないが、ノーツの移行は社内の意識変革のひとつのきっかけにはなるだろう。私たちがクライアント企業のシステム入れ替えや運用支援を行う中で得た経験が、今後システム移行を考えている企業のご担当者にとって、少しでも参考になれば幸いである。