見出し画像

desknet'sからM365への移行で思った事をまとめてみる

いとぅ

M365を自社導入し約半年ちょっと経過しました。
コロナ直下での導入という事もあり、今まで利用していたdesknet's（以下DN）も連携機能がある事もあって、何となくやめるタイミングが見つからずに並行して使っていたのですが、コスト面や各種問題が発生した事もあり完全移行を決断する事になりました。

そんな中つぶやいた

　こちらの内容に思ったより反応を貰えたので、今回の移行に関して思った事を少しまとめてみようかなと思います。

１．移行を決断した決め手

　移行に踏み切った理由として、当然経営層から指摘された重複コストについてもあるのですが、今回の切替の決定打としてはM365⇔DNのスケジュール同期問題でした。
　Exchangeは他人へのスケジュールは『依頼するもの』であるのに対して、DN（というか国産グループウェアの大半）は他人へのスケジュールは『権限があれば登録する（できる）もの』という考え方なので予定の削除を行った際にどうしても同期トラブルが起きてしまう。

　例として予定の削除時にExchangeは依頼という性質上、予定のキャンセルというプロセスが発生するので、本人以外の予定はキャンセル削除するまではDNに残り続けてしまいます。
予定依頼という文化のない大半の人は作業が徹底できないのでキャンセルの度にスケジュールがどんどん重複されていく…なんて事が各所で起き、何とかならんのか？という声が多数出たなんて事がありました。
※予定の自動承認使えという意見もあると思うが、社外からの会議依頼の可能性も考えるとちょっと踏み切れないなぁという判断

画像1

　その他にも非公開スケジュールや登録・変更・削除権限等を完全にM365側と合わせるのは思った以上に難しいので、どうしてもDNとM365側との同期内容に権限齟齬が発生し、スケジュール同期されないケースなど結構トラブルは起きてしまうなぁという印象。
　後、権限次第では予定変更を行う度にDN側の所有者が変更されスケジュールが修正できなくなるなんてトラブルも散見された気がします。
　これはスケジュールだけではなく施設予約でも言える話なので会議室のダブルブッキング（実際は片方の登録が消失している）が発生する事があり、結果として完全な同期が出来ないので両方使える事が利点のはずなのにDNもしくはM365どちらかを正のスケジュールとして定義しなければならない変な運用が発生したのも今回の大きな課題でした。

２．M365にエイヤで移行できなかった理由

　前のセクションで散々に言ってしまったDNですが、ただ使い悪いだけであれば即移行出来るはずで、何故M365導入から半年以上も引き剥がせなかったか？と言われれば単純に一般社員には使いやすいからという側面があったからに他ならないわけで。
　これについては3つ実例を挙げて要因を振り返ってみます。

２－１.組織（施設）の週間スケジュール

　DNが週間のスケジュールを俯瞰的に見れるのに対し

画像2

　Outlookは標準で近しいのはグループスケジュール（ほぼ日別）しかない

画像3

　もちろん週間表示で重ね合わせる事も可能だが、社内の多数の施設を重ねわせると視認的にまぁ現実的じゃない。

画像4

　自社ではユーザの予定よりも会議室の空き状況からスケジュールを組むケースも往々にしてある（DNに慣れていたからかもしれないが）この部分についてはOutlookに物凄いアレルギーを感じた人間が多かった。

　この辺はM365用アドオンソフトで類似的な表記を補える訳ですが、結局余計なコスト増となるので良いか悪いかは会社次第な気もします（自社では一旦見送る予定です）

２－２．スケジュールと設備予約の同時予約

　凄く細かい部分だがDNの場合、スケジュール予約から同時間帯の空いている会議室を検索できる点も利用者からはM365移行に対して反発があった部分でした。

画像5

　でも標準では出来ないだけで、実はExchangeでも会議リソースをグループ化すればスケジュールアシスタント経由で同様の機能を実現できますのでこの点は知っていれば即払拭できる部分だったかもしれません。

２－３．ツリー型組織

　多分、ここが国産グループウェアと外資系グループウェアの大きな違いな気がしています。国産のグループウェアが本部＞部＞課にAさんが所属しているというツリー型の組織構造に当たり前のように対応しているのに対し
　M365等は基本的にはAさんは本部、部、課の3組織に個別に所属しているかのような動作をする部分が国産グループウェアに慣れきっていると、どうしても違和感があって受け入れられ辛いという声を多数頂きました。
　一例として部内一斉配信のメール送信時に、国産グループウェアが設定した組織ツリーに合わせた表記で検索できるのに対し、M365はALL Groupsで表示された各部署の羅列から検索することになるのでこの辺も丁寧に説明しておかないと、ユーザの不満を溜める要因になりがちな気がします。

３．その他にも移行に伴い検討した機能

　実際反発が多かったのは利用者のメイン機能であるスケジュール＆会議室予約がほとんどでしたが、他にもクレームが出る前に先回りで色々と配慮＆検討をした箇所を次にまとめてみます。

３－１．メール

　データの移行についてIMAPであればM365側のサーバ間移行で何とかなるのですが、POPだった場合は結構大変。単純なダウンロードでeml形式メールを各自アップロードだと、一度Outlook上で開封しないとメール詳細が見えないのであくまで応急処置にしかならない。
　後2-3でも書いたようにツリー組織での社内アドレス帳は厳しいので事前にしっかり説明しておかないと揉める(；´Д｀)

３－２．インフォメーション

　自社は結果Teams投稿で代用する事にしたけど、検索性の悪さを考えるとSharePointでポータルを作って運用するのもありかもしれない。
ただ、そこはITリテラシー次第でSharePointだとハードル高いと思ったら素直にTeams投稿の方が結果楽だと思います（でないとTeams以上にスキル次第でお知らせがシャドー化する）

３－３．回覧レポート

　地味に使われていた機能でしたが、Teams投稿にいいねを押すという運用を先回りで案内したのでここは問題なく対応できた。
　インフォメーションと交じるって点はチャネルを変える事で回避。

３－４．備品管理

　Teams（SharePoint）内にExcelシートを格納して管理に切り替えたがDN本来の使い勝手までには至っていない。こういう部分こそPowerAPPSの出番の気がしている（自分はまだ手を出せていないけど…）

３－５．安否確認

　何気に一番悩んだ部分。
　一斉連絡だけであればTeamsやOutlookでの運用も考えましたが、有事の連絡先として個人メールの登録という箇所をどうするか悩んだ結果、トヨクモの安否確認サービス2を別途契約することにしました。

　この他にもインフォコムのエマージェンシーコール等もありますが、機能面よりも必要最小機能があれば価格重視という部分で選定をしました。

　地震だけでなく特別警報時などの緊急警報発報時に自動で安否確認メールがエリアレベルで配送されるので機能としては概ね満足しています。DN時には実現できていた、災害時対処方法のサイト表示についてはまだ未実装ですがこの辺はSharePointにまとめてポータル表記する方向で調整。

３－６．その他の機能

　その他にもアンケート、議事録、電子会議室等他にも色々機能はありますがこちらは大半がM365の標準機能のほうが優秀なので、特に問題なく勝手に皆さん移行していった感じです。
　メニュー機能についてはこれもSharePointにリンク集まとめてTeams掲示していますが（マイアプリだと細かいリンク部分で不適）もう少しここはスマートな方法を検討したほうが良さそうと感じています。
　ワークフローは自社では使っていないので割愛しますが、この辺をガッチリ使っていると移行難度はより高いものになるんだろうなぁというのは容易に予測できますね…。

４．最後に

　色々書きましたが、自分もDNは現在のNEOになる前のStandardAjax版くらいからのユーザですので非常に思い入れもありますし、ここまで社内情報共有に無くてはならない基盤として活躍して頂いたことについては非常に感謝してます。

　そして前回のグループウェア移行と同じようなイメージで移行しようとした時にここまで物凄い反発があったという事は、国産グループウェアというものはやはり日本人の働き方に寄り添い、ブラッシュアップされてきたものだからこそだという事を嫌というほど感じさせられました。

　正直、制作元であるネオジャパンさんも提案しているようにスケジュールをDN側、メールをOutlook側と棲み分けて使うと割り切り、SharePointよりは編集ハードルの低いDN側に社内ポータル機能を寄せるなんて使い方なんかも自分はアリだと考えます（多少贅沢な使い方ですが…）

　後、最後に個人的な意見ですがスマホアプリ版のリリースはV4辺りで実現してほしかった…そうしていれば多分違う未来があったかもしれない…
※歴史的にDNはWEBブラウザベースに特化していたのでスマホなどのプッシュ通知に弱かった…ここはNEOになる際も、denbunアプリを上手い事継承してほしかった…。

以上です、最後まで読んでいただきありがとうございました。

この記事が気に入ったらサポートをしてみませんか？