失敗しないためのグループウェア移⾏ガイド...Copyright © Copyright © CybozuCybozu 77 1. 現状把握利している機能や利している的の棚卸しをします

Copyright © Cybozu 1

失敗しないためのグループウェア移⾏ガイドサイボウズ株式会社

Copyright © Cybozu 2Copyright © Cybozu 2

⽬次

l はじめに

l グループウェア移⾏のタイミング

l 標準マイルストーンとサイボウズの推奨マイルストーン

l グループウェア移⾏マイルストーンの⼯程解説• 参考情報：グループウェアの⽐較⽅法の例• 詳細解説：移⾏する機能やデータの選定ポイント

• 詳細解説：⾒えないコストとクラウドライセンスの内訳• 詳細解説：データ移⾏の5ステップ• 参考情報：サイボウズGaroonへの移⾏事例紹介• 体験談：移⾏プロジェクト成功と失敗の境界線

l サイボウズGaroonへの移⾏問い合わせ先


はじめに

l グループウェアは、組織で利⽤するスケジュール管理や設備予約、掲⽰板、ワークフローといったアプリケーションを備えたソフトウェアで、企業での導⼊率は約8割※に及び多くの企業で社内情報インフラとして活⽤されています。⾃社の業務や⽂化に合わせて内製されるケースもあり、様々な形のグループウェアが存在します。グループウェアを⻑く運⽤していると、時代の変化、組織の変化、技術の変化など、多様な事情で利⽤中の製品・サービスから他製品・サービスへ移⾏を検討する場⾯も発⽣します。

l 本資料では、 17年間毎年数多くのグループウェア移⾏を実施しているサイボウズの経験から、グループウェア移⾏の場⾯で移⾏プロジェクトを推進していく担当者の⽅にとって、プロジェクトのスムーズな進⾏と成功のヒントになる情報を集めました。

※出典 2018年キーマンズネット調査結果 https://www.keyman.or.jp/kn/articles/1802/08/news137.html

https://www.keyman.or.jp/kn/articles/1802/08/news137.html


グループウェア移⾏のタイミング

l ⼀般的に、オンプレミス型の製品は、サーバーの⼊れ替えとあわせ 4〜5 年単位で⾒直しされます。近年はクラウド型の製品が主流となり、オンプレミス型からクラウド型への変更、企業内のコミュニケーションや情報共有のあり⽅、働き⽅改⾰の⼀貫でもグループウェア移⾏を考えるきっかけになっています。

グループウェア移⾏を検討する主な背景

• 利⽤中グループウェアの動作が遅い• 利⽤中グループウェアのメンテナンスコストが⼤きい• 利⽤中グループウェアのハードウェアの更新• 利⽤中グループウェアの開発終了• 社内の情報共有のあり⽅の⾒直し• 柔軟な働き⽅に対応できない。働き⽅改⾰の⼀環• グループ間でのグループウェア統合


グループウェア移⾏を実施した企業の担当者

Notesの影響で、当時社内のインフラでは古いWebブラウザを利⽤せざるを得ませんでした。⼀⽅、インターネットを利⽤する場合はセキュリティの観点から新しいWebブラウザを利⽤してもらう必要がありました。【株式会社テプコシステムズ様】

2011年から運⽤していた3世代⽬のグループウェアは約7年間の利⽤期間を経て保守終了となり、移⾏先グループウェアを検討することになりました。【⻑野市役所様】

以前のグループウェアは13年前に⾃社開発したものでした。⼀通りの機能はそろっていましたが、社外アクセスができないので、営業など外出が多い社員には使いづらかったんです。またブラウザのバージョン対応などメンテナンス⼯数もかかっていました。【ネグロス電⼯様】


⼀般的なマイルストーンの説明1. 現状把握利⽤している機能や利⽤している⽬的の棚卸しをします

2. 移⾏先リストアップ候補となる製品をリストアップします

3. 移⾏先候補⽐較移⾏先候補製品の製品HPや導⼊検討者向けセミナー等で情報収集し、⽐較します。

4. 移⾏概要定義移⾏に際して、必須となる要件から、できれば実現したい要件までを決めます。

5. オリエンテーションメーカー、ベンダーに連絡し、オリエンテーションを実施します。

6. 初回提案オリエンテーションを実施した各社からの提案を精査します。

7. 移⾏要件詳細定義各社の提案から実現可能ラインを⾒極め、⼯程４より詳細な移⾏要件を定義し、追加考慮が必要な部分を各社にフィードバックします。

8. 2回⽬提案フィードバックした各社からの、２回⽬の提案を精査します。要件のフィードバック、それに対する実現可能性の提案は、複数回実施されることもあります。

9. 移⾏機能・移⾏データ選定利⽤中のグループウェアから移⾏したい機能・データを選定します

10. フィット＆ギャップ調査機能の再現性、再現できない機能の代替え⼿段を検討します。

11. 社内評価移⾏後の使⽤感に近い状態のデモ環境を⽤意し（メーカー・ベンダーに依頼することもあります）エンドユーザーに触ってもらってフィードバックをもらいます。

12. 移⾏先製品決定移⾏先製品を決定します

13. 移⾏先製品導⼊移⾏先に決定した製品を導⼊し、必要な初期設定やカスタマイズ、連携を設計します。

14. 移⾏設計移⾏元のデータ出⼒形式、移⾏先のデータ⼊⼒形式を確認し、データ移⾏の設計を作成します

15. 移⾏シミュレーション本番と同じ環境を⽤意して、移⾏の予⾏練習を⾏います。

16. 本番移⾏シュミレーションでの修正を実施して、本番移⾏を⾏います。

17. 社内マニュアル作成⾃社のオペレーションにあわせて、操作マニュアルを作成します。

18. 社内説明会エンドユーザー向けに操作勉強会を実施します。

19. カットオーバー移⾏前のグループウェアの利⽤を原則停⽌し、新グループウェアでの運⽤を全⾯開始します。


1. 現状把握利⽤している機能や利⽤している⽬的の棚卸しをします

4. 移⾏先リストアップ候補となる製品をリストアップします

5. 移⾏先候補⽐較移⾏先候補製品の製品HPや導⼊検討者向けセミナー等で情報収集し、⽐較します。

6. 移⾏概要定義移⾏に際して、必須となる要件から、できれば実現したい要件までを決めます。

7. オリエンテーションメーカー、ベンダーに連絡し、オリエンテーションを実施します。

8. 初回提案オリエンテーションを実施した各社からの提案を精査します。

9. 移⾏要件詳細定義各社の提案から実現可能ラインを⾒極め、⼯程４より詳細な移⾏要件を定義し、追加考慮が必要な部分を各社にフィードバックします。

10. 2回⽬提案フィードバックした各社からの、２回⽬の提案を精査します。要件のフィードバック、それに対する実現可能性の提案は、複数回実施されることもあります。

11. 移⾏機能・移⾏データ選定利⽤中のグループウェアから移⾏したい機能・データを選定します

12. フィット＆ギャップ調査機能の再現性、再現できない機能の代替え⼿段を検討します。

13. 社内評価移⾏後の使⽤感に近い状態のデモ環境を⽤意し（メーカー・ベンダーに依頼することもあります）エンドユーザーに触ってもらってフィードバックをもらいます。

14. 移⾏先製品決定移⾏先製品を決定します

15. 移⾏先製品導⼊移⾏先に決定した製品を導⼊し、必要な初期設定やカスタマイズ、連携を設計します。

16. 移⾏設計移⾏元のデータ出⼒形式、移⾏先のデータ⼊⼒形式を確認し、データ移⾏の設計を作成します

17. 移⾏シミュレーション本番と同じ環境を⽤意して、移⾏の予⾏練習を⾏います。

18. 本番移⾏シュミレーションでの修正を実施して、本番移⾏を⾏います。

19. 社内マニュアル作成⾃社のオペレーションにあわせて、操作マニュアルを作成します。

20. 社内説明会エンドユーザー向けに操作勉強会を実施します。

21. カットオーバー移⾏前のグループウェアの利⽤を原則停⽌し、新グループウェアでの運⽤を全⾯開始します。

サイボウズの推奨するマイルストーン

2.部⾨横断型移⾏プロジェクトの発⾜

3.移⾏ゴールの設定

⼯程１と２の間に２ステップ追加を推奨します


l 情シスがオーナーシップをとりつつ、部署を横断した移⾏プロジェクトメンバーを選定します。移⾏プロジェクトメンバーは、製品選定時やカットオーバー後も、それぞれの部署でグループウェア移⾏を成功に導く⼤切な役割をにないます。

サイボウズが推奨する、２つの追加マイルストーン

l 単に機能やデータを新しいグループウェアへ移⾏するだけでは、社内に新しい変化をもたらすことはできません。⽇々の業務オペレーションの効率化や情報共有のあり⽅について、組織や個⼈の理想の状態をイメージし、実⾏することで、より⼤きな移⾏効果が実感できます。

l 移⾏後の効果測定にも有効です。

部⾨横断プロジェクトのキックオフ

移⾏ゴールの設定


グループウェア移⾏マイルストーンそれぞれの⼯程について


l グループウェア移⾏のマイルストーンは⼤きく分けて「現状把握」「移⾏先選定」「移⾏要件定義」「機能とデータの移⾏作業」「運⽤準備」の5つカテゴリに分けられます。基本的には順に進めていくものですが、前半では全体感を把握して、進んだ先でさらに詳細を詰める、といった⼯程もあります。• 例えば「現状把握」では、運⽤中のグループウェアを「現状維持にする/利⽤中の製品を改修する/別製品へ移⾏する」のなかでどうするかを判断するための情報収集を⾏い、移⾏先を選定します。別製品へ移⾏する、となった場合には、機能移⾏やデータ移⾏の要件を詰める⼯程で改めて詳細な現状把握が必要になり、現状把握の⼯程が２回必要となります。

l 本資料ではP7のマイルストーンの順番で、カテゴリ別に解説します。

l 解説では、数多くのグループウェア移⾏案件を⼿掛けてきたサイボウズ株式会社の担当者の体験をもとに「実例から学ぶ移⾏プロジェクト、成功と失敗の境界線」をあわせてご紹介しています。

それぞれのマイルストーン解説


現状把握


l この⼯程では、利⽤中のグループウェアの利⽤状況を調査します。どの機能を・どんな⽬的で・誰が・どのくらい使っているか等の情報を集めましょう。

l 利⽤状況調査シートのイメージ

現状把握利⽤中グループウェアの利⽤状況調査


l この⼯程では、利⽤中のグループウェアをユーザー⽬線、管理者⽬線、経営者⽬線で現状の課題を洗い出します。ヒアリングシートを⽤いて話を聞きし、それぞれの⽴場でグループウェアに対して感じている情報を集めることで課題となっていることへの認識精度があがります。

l 課題洗い出しシートのイメージ

利⽤者の⽴場別に課題の洗い出し現状把握


l システム移⾏は情報システム部⾨主導で⾏うケースが多いですが、全社の情報インフラでありコミュニケーションプラットフォームとなるグループウェア移⾏プロジェクトは、部⾨横断でメンバーを集めることをおすすめします。「情報共有を推進したい」「⾵通しのいい組織にしたい」といった、組織の⾵⼟作りにも効果を発揮します。移⾏後の定着・活⽤をスムーズに進めるためにも、各部⾨に“グループウェアに詳しい⼈”が存在することが、移⾏プロジェクトそのものの成功に⼤きく貢献します。

部⾨横断でプロジェクトメンバーを集めよう部⾨横断型移⾏プロジェクトの発⾜

同じ部署でも業務が異なる部署からもメンバーを集めたい

部⾨横断のプロジェクトメンバー


l 移⾏プロジェクトチームができたら、グループウェア移⾏に向けた議論をはじめます。他製品へ移⾏か利⽤中のグループウェアをバージョンアップや改修かの輪郭が⾒えている段階です。この⼯程で「移⾏後の成功イメージ（理想の状態）」を設定することで、移⾏の必要性を判断したり、今後の⼯程での各種判断を⾏うときの基準となります。他にも、移⾏プロジェクト終了後の効果検証にも役⽴ちます。

ゴールは移⾏による業務改善移⾏ゴールの設定

理想の状態（例）

• スマホからもアクセスしたい• 予定調整にかかる時間を削減したい

（メールでの時間伺い無くしたい）• 備品購⼊申請をペーパーレスにしたい• 社内メーリングリスト無くしたい• 今ある◯◯は移⾏後も必須

移⾏後の効果検証

できた or できない◯◯を◯時間削減できたミスが◯％減った必ずしも数値で測れるようにする必要はありません。⾵⼟の変化を実感できることも⽴派な効果！

利⽤者が喜ぶゴール設定を


プロジェクトメンバー選び、成功と失敗の境界線実例から学ぶ成功と失敗の境界線

情シス部⾨だけですすめたら、カットオーバー後に社内から苦情が相次いで、移⾏そのものよりもカットオーバー後の社内対応が⼤変だった。

グループウェアは全従業員が使うことが前提のシステムなのに活⽤率が低かった。移⾏の機会に、活⽤率をあげようと、移⾏プロジェクトに他部署の⼈を巻き込んだら、社員が積極的に使ってくれるようになった。

全社プロジェクトで移⾏成功！ネグロス電⼯株式会社様

情報システム部だけで進めてしまうとユーザーの考えや思いが伝わりにくくなってしまうので、各本部から⼈を集めてプロジェクトを組み、要件の洗い出しから製品選定まで全員で進めました。


移⾏先選定


l 現状の課題を解決し、⾃社にとって理想のグループウェアとなる製品を、機能や運⽤管理コストの⾯を考慮しつつ、予算と照らし合わせて移⾏先候補製品をリストアップします。

グループウェア市場はクラウドサービス全盛移⾏先リストアップ

＜参考情報：2020年最新グループウェア市場動向＞

市場シェア※1

1.サイボウズ※3 38.1%2.Microsoft 365 30.1%3.ネオジャパン 14.6%4. Gsuite 10.5%

顧客レビュー評価※2

サイボウズ Garoon 3.5ptサイボウズ Office 3.5ptGoogewprkspace(rakumo） 3.4ptSharePoint 3.0pt

※1 出典元ノークリサーチ2020年版中堅・中⼩企業のITアプリケーション利⽤実態と評価レポート※2 出展元 2 IT Review グループウェアカテゴリ（⼤企業絞込み）2020年11⽉現在※3 サイボウズ Office とサイボウズ Garoonの合計値


l ⼀般的にソフトウェアを⽐較する場合の⽐較ポイントをまとめました。

l 段階的に⾃社にとって重きを置くポイントを決め、細分化していくと、最終判断をする時にも「⾃社が抱えている課題が◯◯で、この製品その課題解決に効果があるから評価した」といった社内への説明もしやすくなります。

l ユーザー機能だけでなく、管理機能、かかりそうな管理⼯数、だれが管理を実施するか、誰が管理を請け負うかも検討のポイントです。管理を請け負うユーザーのリテラシーを考慮し、権限移譲できる、権限移譲しても問題なく使えるわかりやすいシステムを選びましょう。

主要グループウェア⽐較移⾏先候補⽐較


l 配点式による⽐較⽅法の⼀例をご紹介します。

l ご紹介している例では、⼤項⽬で合計100点となる配分してから、各項⽬内で重要となるポイントを中項⽬で、⼤項⽬の得点をもとに配分します。

l 企業毎に判断基準は異なるので、⾃社の優先順位で項⽬や配点を変更してください。

100点満点で採点する⽐較⽅法移⾏先候補⽐較：参考情報「グループウェア⽐較⽅法の例」

⼤項⽬中項⽬

企業 10企業の安定性事業の持続性導⼊実績

4 3 3

提案 20課題認識解決提案技術⼒レスポンス体制

5 5 4 3 3

システム・機能 50

標準機能データ移⾏操作性拡張性容量稼働率

6 6 9 9 8 8

コスト 20初期費⽤ライセンス料運⽤社内教育保守・サポート

3 4 5 3 5


l 「企業」の項⽬では、提供元企業の企業体⼒や事業に対する投資姿勢などから安⼼して取引ができるか、⾃社と同じ企業規模や業界での導⼊実績を持っているか、などを⽐較します。

l 「提案」の項⽬では、顧客が抱えている課題に対し、ベンダーは正しく認識しているか、課題を解決するのに現実的でありながら、コストバランスのよい提案ができているかを判断します。また、提案時だけでなく、導⼊運⽤後も頼れる取引先であるか、といった観点も考慮します。

l 「システム・機能」の項⽬では、製品・サービスそのものを評価します。昨今主流のクラウドサービスの場合、標準機能も⼤切ですが、他製品との連携拡張性も重要な判断ポイントとなります。

l 「コスト」の項⽬では、⾦額で⾒えにくいコストのことも考えます。運⽤コストには、運⽤する⼈材の採⽤・教育といったコスト、運⽤中に発⽣した改善要望に対して、追加で発⽣するコストなどを含みます。教育コストの⾼い製品であれば、活⽤浸透度を⾼めるためのコストが⾼いともいえます。

配点項⽬のそれぞれの⽐較ポイント移⾏先候補⽐較：参考情報「グループウェア⽐較⽅法の例」


l 本社⽇本、流通・卸売・⼩売業、従業員1,500名、12年運⽤したNotesからの乗換検討した企業を例として作成しています。

⽐較の実例移⾏先候補⽐較：参考情報「グループウェア⽐較⽅法の例」

ライセンス費⽤容量運⽤コスト（移⾏後の）機能の再現性

Notes ☓ ☓ ☓ ◎

Microsoft365 ◯ ◎ ◯ ☓

GSuite ◯ ◎ ◯ ☓

Garoon ◯ ◯ ◎ ◯

（追加オプション）

（追加オプション）


スケジュール設定、成功と失敗の境界線実例から学ぶ成功と失敗の境界線

利⽤中のグループウェアの保守期限が迫っていたので、短期間で急いで移⾏しようとしたら、移⾏データの精査や設計に思いの外時間がかかって、予定通りにいかなかった。

旧グループウェアの利⽤期間が10年以上あったので、移⾏計画策定には⼗分な時間を確保した。1年がかりのプロジェクトになったが、社員にとっても⼼の準備期間にもなっので結果的にはよかった。

Q.平均的なスケジュール感は？

A.3ヶ⽉〜12ヶ⽉が⼀般的。

移⾏スケジュールは、移⾏する機能の要件とデータの容量に影響されます。利⽤期間が⻑かったり、機能の再現性やデータ移⾏の必要性を強く求められそうな場合は、⻑めに設定しておくことをおすすめします。

サイボウズ株式会社システムコンサルティング担当


移⾏要件定義


l 移⾏先候補のリストアップで、最新のグループウェア市場についての情報キャッチアップができます。グループウェアは、⼀⽅通⾏の情報伝達ツールという従来の役割だけでなく、製品内で、オンラインコミュニケーションをしながら業務を回したり、社内に流通している様々な情報の交通整理を⾏ったり、業務プラットフォームになっていることが分かると思います。

l この次の⼯程である、メーカー、ベンダーへのオリエンテーションには、既存グループウェアからスライドさせたい機能や役割の他にも、グループウェア内で実現したいこと、連携させたいデータなども盛り込みましょう。メーカー、ベンダーの課題認識能⼒や課題解決能⼒といった提案⼒を⾒極める材料にもなります。

必須要件から、できれば実現したい要件まで移⾏概要定義


l メーカー、ベンダーの初回提案で、解像度の⾼い内容をもらうために、稼働中グループウェアの運⽤状況、必須要件、希望要件の情報は可能な限り提供しましょう。

l 稼働中グループウェアにライセンス期間による稼働期限や保守期限が決まっている場合は、移⾏プロジェクト全体のスケジュールに影響します。時間がなくて、駆け⾜でプロジェクト進⾏とならないためにも、明確な稼働停⽌期限が決まっている場合は、期限の1年前から移⾏に向けて動き出しましょう。

情報提供が多いほど、提案の解像度があがるオリエンテーション、初回提案


l 各社の提案内容から、現実的な移⾏要件へと落とし込んでいきます。提案のフィードバックをまとめる過程で、移⾏要件の優先順位がよりクリアになってきます。部⾨ごと、職種ごとに優先すると要件が異なるので、社内調整ボリュームの⼤きい⼯程です。

l 提案へのフィードバック→再提案は何度か実施する場合もあります。

l 要件決めで迷った時は、前⼯程で考えた「理想の状態」に⽴ち返ります。

l 「できれば実現したかったこと」が要件落ちする可能性がありますが、グループウェアは移⾏導⼊後も運⽤が続くので、第1フェーズ・第2フェーズという段階的要件として残しておくこともできます。

優先順位の判断に迷ったら理想を思い出す移⾏要件詳細定義、2回⽬移⾏の提案


l 「利⽤中のグループウェアで使っているから…」という理由で、移⾏先グループウェアに100%の機能の再現性を求めたり、「いつか必要になるかもしれないから… 」という理由で全データを移⾏しようとすることは、単に利⽤中のグループウェアをコピーしているに他なりません。全機能・全データ移⾏は移⾏プロジェクトの⼯数を肥⼤化させる原因にもなります。

l グループウェアの移⾏を実施する時は、各部署が⽇頃どのようなオペレーションで業務を⾏い、データを共有・保存・利活⽤しているかを知る絶好の機会です。情報システム部⾨としては、各部署にITによる業務改⾰を提案できる絶好の機会でもあります。

移⾏選定作業は「業務の棚卸し」でもある移⾏機能・移⾏データ移⾏選定


l グループウェアは社会の変化に応じて求められる役割りが変化し、各社ともアップデートを重ねて機能もリッチになっています。現状と⽐較して「できる」「できない」だけで判断するのではなく、テクノロジーの進化や業務オペレーションの⾒直しも含めて移⾏機能およびデータを選定することで、グループウェアの⼊れ替えの効果をより確実に実感できます。

l 実際に、グループウェア移⾏した企業では既存機能やデータの引き継ぎよりも移⾏後にユーザーの使いやすさを最も重視しています。

⼤切なのは移⾏後の「ユーザーの使いやすさ」移⾏機能・移⾏データ選定：詳細解説「移⾏する機能やデータの選定ポイント」

71.43

57.14

28.57

ユーザーが使いやすいか

既存データの引き継ぎ

既存機能の再現

グループウェアの移⾏で重視したポイント

※サイボウズ調べ


l 「どの機能を」「どこまでの再現性で」移⾏するかを決めます。

l 利⽤頻度も重要ですが、利⽤頻度は低いが業務調整や進⾏における必要性があるか、といった側⾯でも⾒極めます。

l 機能移⾏の⾒極めするときに役に⽴つのが「移⾏対応マップ（機能編）」です。

機能の⾒極めは、利⽤頻度だけではない移⾏機能・移⾏データ選定：詳細解説「移⾏する機能やデータの選定ポイント」

Lv.1

Lv.2

移⾏しない（旧グループウェアで使っていない）

Lv.3 新グループウェアではカスタマイズ・連携ソリューションを使って再現する

Lv.4 新グループウェアでも標準機能で再現する

移⾏対応マップ（機能編）

新グループウェアでは運⽤でカバーしながら再現する


l 「どのデータを」「どの状態で」移⾏するかを決めます。

l 移⾏先のグループウェアで、この先も利活⽤される現役データなのか、閲覧や検索ができれば⼗分なのか。保存性・閲覧性・継続性の3つの観点から、データ移⾏の仕分けを実施します。

l 仕分けのときに役に⽴つのが「移⾏レベルマップ（データ編）」です。

データ移⾏は、⽬利きが⼤事移⾏機能・移⾏データ選定：詳細解説「移⾏する機能やデータの選定ポイント」

Lv.1

Lv.2

Lv.3

移⾏しない不要データとして消去する

移⾏しない既存グループウェアに参照⽤として残しておく

ファイルに出⼒して保存しておくPDF等にして、必要な時に⾒えるようにしておく

Lv.4 他システム・サービスに移⾏して保存しておく安価なシステム・サービスをデータの格納庫として活⽤する

Lv.5新グループウェアに参照⽤として保存する移⾏先グループウェア上で参照できる状態にする

Lv.6 新グループウェアに編集可能状態で移⾏する移⾏先グループウェア上で現役データの状態にする

移⾏レベルマップ（データ編）


l この段階になると、2~3最終候補に絞り込まれている頃です。製品Aでは◯◯はできるけど△△ができない、製品Bでは△△はできるけど移⾏費⽤が⾼額で・・・といった、候補製品を⽐べても⼀⻑⼀短になることも多々あります。

l 実際に使うことを想定して各機能を紐解いていきますが、そもそも現在利⽤中のグループウェアとは別製品に移⾏する場合、異なる製品である以上、全てのギャップを回避することはできません。

l 候補製品を実際に触って製品の使⽤感を確認します。エンドユーザーの利⽤率が⾼いアプリケーションでは機能の再現性も気になります。

製品が変わればギャップは不可避。代替の選択肢も重要フィット＆ギャップ調査


ギャップがうまれたらどう対応するか？

ギャップの度合いやギャップをカバーする⽅法フィット＆ギャップ調査

（例）紙のような⾒た⽬で電⼦ワークフローを運⽤中

同等の機能がある100%フィット

近しい機能がある50%フィット同等・近しい

機能はない100%ギャップ50%ギャップ

代替機能やカスタマイズでカバーする、連携製品や他製品併⽤でカバーする、運⽤でカバーする等、ギャップを埋める⽅法は複数存在する可能性がある


l ギャップがある場合でも、そこで評価をやめずに代替⼿段が存在するかを確認しましょう。昨今のグループウェアはクラウドサービスが主流で、オンプレミス製品と⽐べ他製品との連携の敷居が低くなっています。「標準機能では実現できないが、カスタマイズや他製品連携により可能」となるケースも多く、メーカーも情報を提供しています。ギャップがあっても諦めずにメーカーやSIerに問い合わせしましょう。

ギャップの回避⽅法はメーカーやSIerに相談するのが近道フィット＆ギャップ調査

ギャップの回避⽅法は専⾨家に相談を

◯◯ができなそうだから、□□の製品は検討からはずそうかな。別の⽅法を調べなきゃ・・・。

そのギャップは、カスタマイズで解決できますよ。同時に、運⽤ルールを△△にすることで、現製品での課題点も解消できます。


移⾏機能選定、成功と失敗の境界線実例から学ぶ成功と失敗の境界線

エンドユーザーからの要望で、旧グループウェアの機能の再現性にこだわっていたら、移⾏プロジェクトが初期段階で停滞してしまいました。

グループウェアは古いシステムのリプレイスだけではなく、業務改善だということを繰り返し説明しました。習慣でやっている業務の効率化や電⼦化による利便性の向上させることを⽬指したら、機能の再現に縛られることがありませんでした。

Q. 機能移⾏で意識したほうがいい点はどこでしょうか。

A. 業務オペレーションの効率や情報共有⽅法利便性の⾯から、機能の必要性について考えましょう。これまでのやり⽅をただ引き継ぐのではなく、改善しながら引き継ぐ⽅法を前提にして考えると、移⾏後の成功実感も感じられます。

サイボウズ株式会社マーケティング担当


移⾏データ選定、成功と失敗の境界線実例から学ぶ成功と失敗の境界線

移⾏後に必要になるかもしないし、とにかく全部もっていけば安⼼と思って計画たてたら、移⾏スケジュールがどんどん肥⼤化してしまいました。

移⾏レベルマップを使って移⾏データを整理しました。あと旧グループウェアは、移⾏後も参照⽤として最低ライセンス数の運⽤で残しておくことで「探そうと思えば探せる状態」にしておいて、社内合意をとりました。

Q.データ移⾏でのNGパターンはありますか？

A、ずばり、全データ移⾏です。移⾏データの仕分け作業は、担当部署に判断を依頼する必要があって、根気のいる⼯程ですが、機能移⾏同様、この機会にデータの棚卸しをすることで移⾏プロジェクトの肥⼤化を防ぎ、過去のデータの整理整頓もできます。

サイボウズ株式会社営業本部


l 移⾏後に必須となる機能要件もだいたい出揃っているので、候補製品の実際に試して操作感を体験してみます。同じ機能でも、操作感の違いによって製品の導⼊浸透スピードや活⽤度に影響します。従業員のITリテラシーには幅があるので、全社員が利⽤することを前提にエンドユーザー参加型の製品テストを実施します。

エンドユーザー参加型の製品テスト社内評価


l 機能やデータの移⾏可能範囲がクリアになり、即効性のある導⼊効果や導⼊後にじわじわと期待できる改善効果の将来性が判断できます。移⾏費⽤やライセンス費⽤などのコスト⾯の最終調整が終わると、移⾏先製品を決定する段階です。

移⾏の実現性・業務改善の将来性・コストのバランス移⾏先製品決定

グループウェア移⾏

再現性

業務改善コスト

グループウェア移⾏

再現性

業務改善コスト

どの項⽬を重視するかは企業によって異なる

A社の判断軸

B社の判断軸


l 移⾏先決定時「コスト＝⽀払う費⽤」は重要な判断ポイントになります。

l ⽬に⾒えて分かりやすく⽐較しやすい項⽬ですが、コスト⽐較で注意したいのは導⼊後に発⽣する「⽬に⾒えないコストの試算」です。

l 例えば、クラウドサービスのライセンス費⽤には、サービスが安定稼働するための各種対策や、それを実⾏するための⼈件費が含まれています。今後、IT⼈材の獲得が困難になってくる労働⼈⼝減少社会において「システムの⾯倒を⾒る業務」は、専⾨ベンダーに任せる選択が懸命といえます。

⾒えないコストの落とし⽳移⾏先製品決定：詳細解説「⾒えないコストとクラウドライセンスの内訳」


クラウドサービスのライセンス料に含まれるもの移⾏先製品決定：詳細解説「⾒えないコストとクラウドライセンスの内訳」

クラウドライセンス料

サーバー

サーバー設置場所

バックアップ

BCP対策

マルチデバイスアクセス

ネットワーク整備

セキュリティ対策

バージョンアップ

設定・運⽤・管理する⼈←出来る⼈を採⽤したり

育てることも必要


l 国産サービスと外資系サービスを⽐較する時には、サポート体制と仕様変更の頻度、変更ギャップについても確認しましょう。

l 例えば、活⽤⽀援やトラブルサポートに関する情報提供が不⾜していたり、提供されていても⽇本語には対応していないケースが多々あります。また、製品バージョンアップが頻繁なのはクラウドサービスの利点ですが、事前に⼗分な情報提供が無いままにバージョンアップが実施され、エンドユーザーへの説明コストや最新バージョンへのカスタマイズ追加対応コストが発⽣することもあります。

サポート⾔語や仕様変更のリスクも忘れずチェック移⾏先製品決定：詳細解説「⾒えないコストとクラウドライセンスの内訳」

0 5 10 15 20 25 30 35 40 45 50

使わない機能やアプリが多い

バージョンアップの度にUIや使い⽅が変わる

使い⽅が分からない機能やアプリが多い

使いづらい、操作が難しい

参考：Microsoft365とGsuiteの利⽤状況調査（2020）/後編 ‒ 出典：キーマンズネット

44.9%


l グループウェアにカテゴライズされる製品・サービスには、サイボウズ製品のように必要アプリケーションがパッケージ化されたものと、Microsoft365やGoogleworlplaceのように電⼦メール、表計算、⽂書作成といったビジネスソフトに付随して⼀部のグループウェア機能が搭載されているものがあります。

l それぞれの得意と苦⼿を知ることで、ひとつの製品を選ぶのではなく、複数の製品を併⽤する⽅法もおすすめです。複数製品の併⽤は、⼀⾒ダブルコストに⾒えることもありますが、パッケージされていないアプリケーションの追加購⼊・追加開発やメンテナンスコストが必要になるため、結果的にはコストに⼤きな差はないこともあります。

l サービストラブル時における、双⽅の緊急代替え⼿段としても有効です。

製品サービスには得意と苦⼿がある移⾏先製品決定：詳細解説「⾒えないコストとクラウドライセンスの内訳」


ひとつの製品で全⽅位をカバーするのは難しい移⾏先製品決定：詳細解説「⾒えないコストとクラウドライセンスの内訳」

Share pointで開発

プロジェクト管理

無料・有料各種アドオン

マルチレポートワークフロー

ポータル掲⽰板

OneNote メモタスク ToDoリスト

OneDrive ファイル管理ドライブ連絡先アドレス帳連絡先予定表スケジュールカレンダーメールメールサーバー必要 Gmail

Microsoft Office MS Office必要ドキュメント・スプレットシート・スライド

Microsoft365 サイボウズGaroon Google workplace


製品選定、成功と失敗の境界線実例から学ぶ成功と失敗の境界線

コスト⾯を重視して製品を決めたら、運⽤後に使い勝⼿の改善を実施しようとする度に、追加コストがかかるようになって結果的にコストが上がってしまった。

グループウェアは、導⼊したら最低でも5年は継続して運⽤する想定にして、運⽤にかかるメンテナンス費や⼈件費も換算。社内での活⽤度も導⼊効果として計算できるようにしたことで、上層部をうまく説得できました。

Q. 選定の決めては？

A. サンコール株式会社様国産メーカーであれば、使い勝⼿の⾯でも現場に浸透しやすく、何かあっても柔軟な対応が期待できると考えたから。

A. ゼブラ様業界スタンダード、シェアNo1、導⼊実績、サポート体制を評価。特にシステムのメンテナンスや、BCP対策を⼀任できるという点は重視しました。


l 移⾏先製品を導⼊し、各種設定・構築を⾏います。

l 例えば、ログイン認証をグループウェア単体で⾏うのか、他システムと共通認証（シングルサインオン）を利⽤するか、ログイン後に最初に表⽰する画⾯設計はどのようにするか、各アプリケーションの利⽤者や利⽤範囲のアクセス権設定はどうすか、といったシステム全体に関わる設定から、スケジュール機能では何分単位で登録を可能にするか、といった各アプリケーション単位の細かい設定まで、必要な設定を⾏います。

⾃社の業務や⽂化にあわせて初期設定移⾏先製品導⼊

クラウドサービスは突然変わる！？

クラウドサービスはバージョンアップが⾃動的に適⽤され、常に最新版が利⽤できることが利点ですが、反⾯「今朝ログインしたらボタンの位置が変わっていた」「⾒慣れない機能が急に搭載されている」といったケースが発⽣することもあります。サイボウズGaroonは、定期アップデートの内容を事前にユーザーに告知することはもちろん、新機能の適⽤はお客様⾃⾝のタイミングでご実施いただます。


機能とデータの移⾏作業


l 移⾏要件をもとに、移⾏元製品の仕様と移⾏先製品の仕様を確認し、移⾏先製品の設定範囲やカスタマイズ範囲、データ移⾏範囲とデータ移⾏⽅法の設計をします。

l 利⽤中と移⾏先のグループウェアの、データの⼊出⼒に関する仕様を確認し、データ移⾏設計を⾏います。製品間でデータ移⾏ツールの有無、⼊出⼒⽤のAPIの有無、CSVファイルなどのファイル形式による⼿動の⼊出⼒⽅法や対応している項⽬などを確認します。

新グループウェアへの引っ越し準備移⾏計画


l 移⾏レベルマップ（データ編）を使って、どのデータを移⾏するかは検討済なので、次はプロセスにそってその⽅針を決めていきます。⼀般的に移⾏ステップは5つのステップで考えます。

データ移⾏のプロセス移⾏計画：詳細解説「データ移⾏の5ステップ」

データ出⼒・⼊⼒⽤のインターフェースを確認する

データ出⼒・⼊⼒の⽅法を確認する

出⼒項⽬と⼊⼒項⽬の対応づけを⾏う

既存システムのデータ量を調整する

データ出⼒・⼊⼒の処理単位を確認する

STEP1 STEP2 STEP3 STEP4 STEP5データ移⾏の5ステップ


データ移⾏のプロセス移⾏計画：詳細解説「データ移⾏の5ステップ」

STEP1 データ出⼒・⼊⼒⽤のインターフェースを確認するスケジュールや掲⽰板といった機能単位でデータの⼊出⼒インターフェースがあるかどうかを確認します。

STEP2 データ出⼒・出⼒の⽅法を確認するブラウザーやクライアントソフトウェア、コマンドライン、APIによる開発など、データの⼊出⼒⽅法について確認します。中には⼿動で移⾏する必要がある部分もでてきます。

STEP3 出⼒項⽬と⼊⼒項⽬の対応づけを⾏う例えば、移⾏元製品の掲⽰板機能から「タイトル・作成者・本⽂」の情報が出⼒できたとしても、移⾏先では「作成者」が取り込めない、といった事態が発⽣することがあります。そこで、出⼒できる項⽬と⼊⼒できる項⽬の対応づけを⾏います。データ形式やフォーマットが異なる場合は変換作業が必要になり、簡単なものならExcelでも可能ですが、複雑なものであれば交換⽤のプログラムを開発する必要があります。

STEP４既存システムのデータ量を調査する移⾏作業の時間に⼤きく影響するデータ量を調査します。データ量が少なければ⼿動でも取り込めますが、データ量が多い場合は取り込むための専⽤プログラムの作成が必要な場合もあります。

STEP5データ出⼒・⼊⼒の処理単位を確認するユーザー単位や組織単位など、データ⼊出⼒が可能な処理単位を確認します。⼀括で出⼒できない場合は、ユーザー⾃⾝にデータの出⼒作業を依頼します。

(参考)Garoonのデータ⼊出⼒形式API

ブラウザー経由 CSV

コマンドライン※ CSV※パッケージ版のみ


l 実際の本番環境で移⾏するまえに、リハーサルを実施します。

l リハーサルでは、次のことを確認します。• 本番移⾏にかかる⾒込み時間の算出• 移⾏後の使い勝⼿（エンドユーザーにも確認してもらいましょう）• 移⾏したデータの参照⽅法（エンドユーザーにも確認してもらいましょう）• 事前に計画したイメージとの差異がないか

l リハーサルは必ず本番と同じ環境、同じ⼿順で実施します。リハーサルで変更した環境や⼿順は、本番でも忘れず適⽤しましょう。

リハーサルは本番の気持ちで移⾏シュミレーション


l リハサールを終え、必要な修正を加えたらいよいよ本番移⾏です。

l 本番移⾏では、次のことに留意します。• 余裕をもったスケジューリング（例えばリハーサルで3時間かかる計算だった場

合は、倍の6時間は⾒積もっておくことをおすすめします）• 切り戻しの判断基準を決めておく。万が⼀、順調に移⾏作業がすすまなかった場

合「どの時点・誰が・何を」判断するかの基準を決めておきます。

l 本番は必ずリハーサルと同じ環境、同じ⼿順で実施します。

時間と気持ちに余裕をもって本番に挑む本番移⾏


運⽤開始準備


l 「前のグループウェアのほうがよかった」といった移⾏ショックを最⼩限に抑えるためにも、カットオーバー前のエンドユーザーへの説明は重要です。使い⽅の説明だけでなく、グループウェア移⾏実施の背景も合わせて説明しましょう。

l 各部署から移⾏プロジェクトに参加してもらったメンバーがいるので、社内説明会後も⾝近に質問できる⼈がいることで活⽤定着へと貢献します。

エンドユーザーの移⾏ショックを和らげる社内マニュアル作成、社内説明会

社内説明会の実地回数（参考例）

・ユーザー規模約2,000名、メーカー系グループウェアからGaroonへ移⾏

500名に向けて実施1回20名

1⽇5回 5⽇間

⾃社の運⽤にあわせた操作マニュアル作成＆移⾏切替え後の3週間は特設ヘルプデスクを設置

=


l 本番移⾏作業が無事に済んだら、全社展開のカットオーバーとなります。

l カットオーバーのスケジューリングは、年度頭や⽉初といった区切りがいい時期に設定したくなりますが、その時期は業務のスタートや締切が集中する⽇でもあるので、あえて避けて設定したり、プレカットオーバーの期間を設けることで、ゆとりをもったカットオーバーを迎えることができます。

l 新旧グループウェアを併⽤する期間を設置する場合は、1ヶ⽉程度が適切です。

忙しい時期は避けて、あえて節⽬をずらしたスタートカットオーバー

移⾏リハ本番移⾏社内説明会プレカットオーバー

新旧グループウェア併⽤期間（2ヶ⽉くらい）

カットオーバー

2⽉下旬 3⽉上旬 3⽉下旬 4⽉15⽇3⽉中旬

プレカットオーバーを設置すると、移⾏初期のエンドユーザーのつまづきポイントが事前収集できるのがメリット！

カットオーバーに向けたスケジュール（例）


グループウェア移⾏プロジェクトの成功は業務改善へとつながります。


l サイボウズ Office から移⾏• 九州産交グループ様 https://garoon.cybozu.co.jp/mtcontents/cases/kyusyu/• バーニーズジャパン様 https://garoon.cybozu.co.jp/mtcontents/cases/barneys/

l Notesから移⾏• ゼブラ様 https://garoon.cybozu.co.jp/mtcontents/cases/zebra2/• フジ様 https://garoon.cybozu.co.jp/mtcontents/cases/fuji/

l ⾃社開発グループウェアから移⾏• 明電舎様 https://garoon.cybozu.co.jp/mtcontents/cases/meidensha/• ヒメプラ様 https://garoon.cybozu.co.jp/mtcontents/cases/himepla/

l 複数グループウェアから統合移⾏• 阪急阪神ホールディングス様 https://garoon.cybozu.co.jp/mtcontents/cases/hankyu-hanshin/• SBSホールディングス様 https://garoon.cybozu.co.jp/mtcontents/cases/sbs/

l 各種他社グループウェアから移⾏• ⻑野市役所 https://garoon.cybozu.co.jp/mtcontents/cases/nagano_city/• ⽇⼯様 https://garoon.cybozu.co.jp/mtcontents/cases/nikko/

GaroonにはNotesや他社グループウェアからの多数移⾏実績あり参考情報「サイボウズGaroonへの移⾏事例紹介」

Garoonの製品サイトで詳しくご覧いただけます

https://garoon.cybozu.co.jp/mtcontents/cases/kyusyu/

https://garoon.cybozu.co.jp/mtcontents/cases/barneys/

https://garoon.cybozu.co.jp/mtcontents/cases/zebra2/

https://garoon.cybozu.co.jp/mtcontents/cases/fuji/

https://garoon.cybozu.co.jp/mtcontents/cases/meidensha/

https://garoon.cybozu.co.jp/mtcontents/cases/himepla/

https://garoon.cybozu.co.jp/mtcontents/cases/hankyu-hanshin/

https://garoon.cybozu.co.jp/mtcontents/cases/sbs/

https://garoon.cybozu.co.jp/mtcontents/cases/nagano_city/

https://garoon.cybozu.co.jp/mtcontents/cases/nikko/


l Garoonへの移⾏をご検討場合は、以下の窓⼝までご相談ください。

Garoonへの移⾏をご検討の際には

製品サイトの導⼊相談フォームからお問い合わせ

お取引のあるパートナー企業へ

お問い合わせまたは


l この資料は2020年11⽉時点の情報で制作しています• 2021年1⽉⼀部内容更新しました

• 2021年2⽉誤字を修正しました

l 制作：サイボウズ株式会社

l 問合せ先：Garoonプロモーションチーム [email protected]

本資料について


l この⽂書内における掲載情報の⼆次利⽤においては、ご⾃⾝の判断と責任の下に⾏ってください。サイボウズ株式会社は、それらの情報をご利⽤になることにより発⽣したあらゆる商業的損害・損失を含め⼀切の直接的、間接的、特殊的、付随的または結果的損失、損害について責任を負いません。

l 本⽂書を⼀部引⽤して作成した⽂書には、次のような当社の著作権表⽰⽂を記載してください。• 「この⽂書は、サイボウズ株式会社による『失敗しないためのグループウェア移⾏ガイド』を⼀部引⽤しています。」

l 本ファイルに編集を加えて⼆次利⽤する場合には、次のように修正箇所と修正者を明記してください。• 「本ファイルの（修正箇所）は、（修正者）が編集しました。」

本⽂書の取り扱いについて

Documents

失敗しないための グループウェア移⾏ガイド...Copyright © Copyright © CybozuCybozu 77 1. 現状把握 利 している機能や利 している 的の棚卸しをします

失敗しないためのグループウェア移⾏ガイド...Copyright © Copyright © CybozuCybozu 77 1. 現状把握利している機能や利している的の棚卸しをします