ノーツからSharePointへ移行する際の気を付けるべきポイント

先日表題の内容で社内勉強会をやったので、そのとき話した内容をこちらにも一部記載します。
本記事は、どちらかというとSIerやコンサル会社向けです。

ここ1年ほど、ノーツからの移行案件が増えてきた感があります。
ノーツからSharePointへの移行は、ノーツのバージョンアップやリース切れのタイミングで検討されるため、数年おきに波があるのですが、今は非常に多い時期と言えます。

弊社も大型の移行案件含め、いろいろとお手伝いさせていただきましたが、
移行する際に気を付けるべきポイントが、ある程度見えてきました。

・ノーツからSharePointへの移行は”超”大変である

国内だけでも数多くの事例はあるものの、実際にはこれが現実です。
Exchangeへの移行は比較的すんなりいくものの、SharePointはとても大変です。
ちなみに、企業がノーツではなくSharePointを採用するという意思決定をするまでには、
機能的な比較やROIなどが重視されますが、
導入が決まると機能的な部分は実はあまり問題にならないと考えています。
それよりも何が大変かというと、以下の3点に集約されると考えています。

①現状のノーツ環境の調査
②エンドユーザーとの調整
③プロジェクト管理

この3点は独立した問題ではなく、すべて関連し合っています。
詳細を1つ1つ解説します。

①現状のノーツ環境の調査

移行先や実装案を検討するうえで、現行のノーツ環境の調査が必要です。
これを行ってはじめて、SharePoint標準機能でいけるのか、開発しないといけないのか、
といった切り分けができます。
ところが、ノーツの場合多いのは、
・各DBの設計書、仕様書が存在しない
・各DBを作った人がすでにいないため、誰も仕様が分からない
という2つの事態です。

これにより、現状調査は結局1つ1つ実機で動作確認をする必要があります。
これには非常に時間がかかります。
なんせ、ビジネスロジックが分かっていない状態でアプリを触っても、
何から手をつけていいか分からないからです。
中にはエンドユーザーが懇切丁寧に教えてくれるケースもありますが、
移行対象DBが多いとそんなことまでやってくれません。
逆に適当に調査すると、ノーツは隠れDBや隠れロジックが潜んでいる可能性が高いため、
非常に重要な機能要素を見逃して後で大問題になる可能性が出ます。


②エンドユーザーとの調整

移行にあたっては、エンドユーザーとコンセンサスをとっていくことが必要となります。
これは企業によってその必要性の度合いが変わってきます。
一般的に、エンドユーザー部門の意見が強い場合は、この調整は大変です。
逆に情報システム部門側の発言力が強く、イケイケ状態であると、比較的楽です。
ごくまれに、エンドユーザーもシステム部門も両方イケイケの場合があり、この場合はとても楽です。

とはいえ、大なり小なりエンドユーザーに対しては、
移行する目的や現状の要望、移行後のイメージや負担してもらうことを説明しなければいけません。
その際には以下のような点で非常に苦労します。

・ノーツの言葉とSharePointの言葉は、中国語と日本語くらい違う
・エンドユーザーはSharePointのことはまるで知らないので、理解してもらうために根気強く説明と大量のサンプル作成が必要
・現行業務に変更が生じる場合、当たり前だが拒否反応を示される
・エンドユーザー目線でいうと、SharePointは非常に融通の利かないシステムに見える

まず、ノーツとSharePointは全く違う製品である、という大前提が、エンドユーザーには通用しないことがあります。
エンドユーザーからすると利用システムがなんであれ、自分たちの業務が効率よく遂行できれば良いわけですから、これは当然の反応です。

通常の業務アプリ開発の場合は、エンドユーザーの現行業務を洗い出し、要望を吸い上げながら、
より良いシステムを一緒に作っていくことができます。
が、移行案件の場合は、1つ1つそんなことはやっていられないケースが多いため、
まずは最低限現状維持でまとめて移行する、という大雑把な選択肢になりがちです。
これはこれで仕方のないことではあるものの、実際には現状維持どころか、
大幅に機能落ちすることも少なくありません。
ノーツはExcelのマクロやAccessのアプリのように、EUCで業務密着型のアプリを作りやすくなっており、
この柔軟性にはSharePointは太刀打ちできません。
この機能差を埋める3rdパーティ製品は多々あり、こうしたもので解決できることもありますが、
製品紹介はちょっと本題からずれるので割愛します。
（また別の機会にまとめたいと思います。）

もちろん、SharePointならではのメリットは多々あるものの、
エンドユーザーからは「できないこと＞できること」に見えるため、なんでこんなシステムに移行するんだ、という大変雰囲気の悪い状態になることは少なくありません。


③プロジェクト管理

個人的な経験から言うと、
ノーツからの移行プロジェクトは当初計画より、コスト増、スケジュール遅延になる可能性は非常に高いです。
これは①、②がしっかりできずに、後になって大きな問題が発覚したり、
エンドユーザーからの要望で追加開発が増えてしまったり、調整に時間をとられることに起因していることがほとんどです。
プロジェクト計画は、当初想定できる範囲で書くため、
開発が大変とか、データ移行が大変とか、そういうある程度計算できる領域よりも、
予想外の部分でのリスクが大きく影響します。
何度か移行案件をやっているプロジェクトマネージャならまだしも、
そうでない場合は非常に難しいプロジェクトになります。

また、SharePointはノーツと違い、多層アーキテクチャになっているため、
インフラからアプリまでのサブプロジェクトがパラレルで走ることもよくあります。
この進め方は悪いわけではないですが、
サブプロジェクト同士の連携を密に行わないと大きな問題を見逃す可能性が高くなります。



以上3点については、こうしたらうまくいくよ！という単純な解があるわけではありません。
が、こうした困難な移行案件でも、うまくこなしている事例はあります。
細かい要素は無数にありますが、共通して言える大きなポイントとしては、
・移行する目的、プロジェクトのゴールが明確になっている
・移行するスコープ（そもそものプロジェクトスコープ）を限定している
・情報システム部門がSharePointのことをある程度理解している（自分でサイト作ったり、サイト管理ができる）
・プロジェクトチーム内の情報共有が着実に行われている
という点かと思います。
どれも難しいですけどね（笑