Notes移行はなぜ進まない？脱Notesを成功させる進め方と移行先選定のポイント

長年にわたり、メールやスケジュール管理、申請・承認、文書管理、顧客管理など、さまざまな業務でNotesを活用してきた企業は少なくありません。しかし、利用中のバージョンによってはサポート終了への対応が必要になるほか、保守担当者の不足やアプリケーションのブラックボックス化、改修コストの増加といった課題が顕在化するケースもあります。

一方で、Notesには長年の業務運用で蓄積されたデータや、複雑な承認ルート、独自の業務ルールが組み込まれていることがあります。そのため、「どのNotes DBから移行すべきかわからない」「現在の機能をどこまで再現すべきか判断できない」「移行先にどのような機能が必要なのか」と悩む担当者も多いのではないでしょうか。

そこで本記事では、Notesとは何か、Notes移行が必要とされる理由、継続利用で発生しやすい課題、移行先の選定ポイント、移行を進めるステップ、注意点について解説します。サポート終了への対応や、脱Notesをきっかけとした業務改善を検討している方は、ぜひ参考にしてください。

Notesとは

Notesとは、1989年にロータス社がリリースし、1995年にIBMが買収してIBM Notesとして提供を続け、現在はHCL Softwareが提供しているグループウェアおよび業務アプリケーション基盤です。

Notesは、メール、スケジュール管理、掲示板、文書共有といったグループウェア機能に加え、申請・承認、問い合わせ管理、顧客管理、案件管理、帳票管理など、企業固有の業務アプリケーションを構築できる点が特徴です。多くの企業では、標準機能だけでなく、Notes DBと呼ばれる個別アプリケーションを作成し、長年にわたって業務を支えてきました。

一方で、長期間の利用によってNotes DBが増えすぎたり、開発・保守を担っていた担当者が不在になったりするケースも少なくありません。そのため、近年ではNotesをすべて一度に置き換えるのではなく、利用状況を整理したうえで、必要な業務から段階的に移行する「脱Notes」を検討する企業が増えています。

 

Notes移行が必要な理由

Notes移行が必要とされる理由は、単純に「Notesが古いから」ではありません。長年利用してきた業務アプリケーションやデータを、今後も安全かつ効率的に維持できるかを見直す必要があるためです。

特に確認したいのが、利用中のNotes/Dominoのバージョンとサポート状況です。HCL Notes/Dominoは現在も製品提供・更新が続いていますが、旧バージョンの一部はすでに通常サポートの対象外となっています。例えば、HCL Notes/Domino 9.0.xおよび10.0.xは、2024年6月1日に通常サポートが終了しました。一方で、HCLはこれらのバージョンを対象とした延長サポートを2030年6月30日まで提供する方針を案内しています。利用中のバージョンや契約内容によって受けられる支援範囲が異なるため、現在の保守契約やサポート条件を確認することが重要です。

サポート終了後もシステム自体を直ちに利用できなくなるとは限りません。しかし、通常サポートや延長サポートの対象外となった場合は、新たな脆弱性への対応や障害時の技術支援を受けにくくなるリスクがあります。また、OSやブラウザ、周辺システムの更新にNotes環境が追随できず、将来的に利用できる機能や連携方法が制限される可能性もあります。

特に、顧客情報、従業員情報、契約書、申請・承認履歴などをNotes DBで管理している場合は、セキュリティや内部統制の観点からも注意が必要です。サポート対象外の環境を使い続けることで、脆弱性への対応遅れや監査対応の負荷増加、障害時の復旧難易度上昇につながるおそれがあります。

 

Notesを使い続けることで発生する課題

Notesを継続利用すること自体が問題になるわけではありませんが、古いバージョンの利用、保守体制の弱体化、アプリケーションの複雑化などが重なると、業務運用やDX推進に影響が出る可能性があります。ここでは、Notesを使い続けることで発生する代表的な課題として、以下の4点について解説します。

• 専門家不足
• 運用コストの高騰
• ブラックボックス化
• DXの大きな障害

専門家不足

Notesは長年にわたり多くの企業で利用されてきましたが、Notes/Dominoの開発や保守に精通した人材を確保しにくくなっている企業もあります。特に、LotusScriptや独自のNotes DB設計に詳しい担当者が異動・退職すると、既存アプリケーションの改修や障害対応が難しくなる場合があるでしょう。

また、社内に技術者が残っていたとしても、複数のNotes DBを少人数で保守しているケースでは、業務部門からの改善要望に十分対応できないことがあります。小さな改修でも影響範囲を把握する必要があり、調査やテストに時間がかかることも少なくありません。

脱Notesを進める際は、移行先の技術だけでなく、現在のNotes環境を理解する人材や支援パートナーをどう確保するかも大切です。既存資産の調査・棚卸しを行い、業務知識と技術知識を早めに引き継ぐ必要があります。

運用コストの高騰

Notesを利用し続ける場合、ライセンスや保守契約に加え、サーバー運用、バックアップ、障害対応、セキュリティ対策、アプリケーション改修などのコストが発生します。特にオンプレミス環境で長年運用している場合は、サーバーや周辺機器の更新、OS・ミドルウェアの保守なども必要です。

また、Notes DBごとに個別改修を繰り返していると、同じような機能を複数のアプリケーションで保有する状態になりがちです。例えば、申請・承認、マスタ管理、通知、文書保管といった機能が各Notes DBに分散していると、改修のたびに複数のシステムへ対応しなければなりません。

移行を検討する際は、単に新しい製品の導入費用と比較するのではなく、Notes環境を今後も維持するために必要な人件費、保守費、インフラ費、改修費を含めて評価することが大切です。

ブラックボックス化

Notes環境で特に課題になりやすいのが、業務アプリケーションのブラックボックス化です。長年の改修によって機能が複雑になり、設計書や運用マニュアルが最新化されていない場合、誰も全体像を把握できない状態に陥ることがあります。

また、承認ルートや権限設定が複雑化していると、組織変更時にどこを修正すべきか分かりにくくなります。現場がExcelやメールで補完運用を始めると、正式な業務フローと実際の運用がずれ、統制上の課題につながる可能性もあります。

Notes移行では、既存アプリケーションをそのまま再現するのではなく、業務目的や利用状況を確認することが重要です。不要な機能を廃止し、似た業務を統合し、業務ルールを標準化することで、ブラックボックス化の解消につながります。

DXの大きな障害

DXを進めるには、業務データを活用しやすい状態にし、他システムやクラウドサービスと連携できる環境を整える必要があります。しかし、Notes DBが部門ごとに分散し、独自仕様で運用されている場合、データを横断的に活用することが困難です。

また、モバイル対応や外部ユーザーとの連携、クラウドサービスとの接続、生成AIの活用などを進める際にも、既存のNotes環境が制約になることがあります。もちろん、Notes/Dominoを活用して最新技術と連携する方法もありますが、既存アプリケーションごとに改修が必要になる場合は、コストや保守負荷が増える可能性があります。

DXを目的にNotes移行を検討する場合は、データ連携、承認プロセス、権限管理、業務変更への対応力まで含めて、将来の業務基盤を設計することが重要です。

 

Notesの移行先に必要な機能

Notesの移行先を選ぶ際は、現在の業務課題を解消し、将来的な業務変更やシステム連携にも対応できる基盤を選ぶ必要があります。

まず重要なのが、柔軟なワークフロー機能です。Notesで利用されているアプリケーションには、申請、承認、差し戻し、回覧、通知といった業務プロセスが組み込まれていることが多くあります。移行先には、組織や役職、申請内容、金額、条件などに応じて承認ルートを分岐できる機能が求められます。

次に、ローコード・ノーコードを含む開発機能も重要です。Notesの強みの一つは、業務要件に合わせてアプリケーションを作り込めることでした。移行先でも、業務部門の要望に応じて変更できなければ、再び個別開発へ依存する可能性があります。

また、既存システムやクラウドサービスとの連携性も確認しましょう。基幹システム、ERP、CRM、会計システム、人事システム、文書管理システムなどとデータを連携できれば、二重入力や転記作業を減らしやすくなります。API連携やファイル連携、認証連携など、既存環境に合った連携方法を選べるかが大切です。

さらに、権限管理、監査ログ、履歴管理、検索性、モバイル対応、拡張性なども移行先に必要な要素です。特に、承認履歴や更新履歴を残す必要がある業務では、内部統制や監査への対応を考慮する必要があります。

移行先を選ぶ際は、現行Notes DBの機能を一覧化し、「そのまま再現すべき機能」「標準機能へ置き換えられる機能」「業務を見直して廃止できる機能」に分けることが重要です。この整理を行わないまま製品選定を進めると、必要以上に複雑な要件を抱え込むおそれがあります。

 

Notes移行の進め方

Notes移行は、調査、計画、移行の3段階に分けて進めると整理しやすくなります。特に重要なのは、移行対象を早期に確定しようとしすぎず、現状把握と優先順位付けに十分な時間をかけることです。ここでは、Notes移行の進め方として、以下の3段階それぞれについて解説します。

1. 調査
2. 計画
3. 移行

調査

最初に行うべきことは、Notes DBの棚卸しです。利用しているアプリケーションの数、利用部門、利用者数、更新頻度、データ量、外部システム連携、権限設定、保守担当者、業務上の重要度などを確認します。

調査の結果、すでに使われていないアプリケーションや、別のシステムで代替できるアプリケーションが見つかることもあります。一方で、利用頻度が低くても、特定の時期だけ必要となる重要業務が含まれている場合もあるでしょう。そのため、利用回数だけで移行・廃止を判断しないことが大切です。

また、Notes DBに蓄積されたデータの扱いも確認します。現行システムに移すデータ、アーカイブとして保管するデータ、廃棄できるデータを分類し、保存期間や検索要件を整理しましょう。

計画

調査結果をもとに、移行の優先順位とロードマップを作成します。すべてのNotes DBを一括で移行しようとすると、対象範囲が大きくなり、要件整理やテストが長期化する可能性があります。業務への影響や技術的な難易度を踏まえ、段階的な移行計画を立てることが重要です。

優先順位を決める際は、業務上の重要度、保守リスク、利用者数、改修頻度、他システムへの影響、移行難易度などを評価します。一方で、複雑なアプリケーションを最初に移行すると、プロジェクト全体が停滞するおそれがあります。最初は比較的シンプルで、成果を測りやすい業務から始め、移行方法や運用ルールを確立してから対象を広げる方法も有効です。

この段階では、移行先のアーキテクチャ、開発方針、データ移行方式、テスト計画、教育計画、移行後の保守体制も検討します。現行業務をそのまま再現するのか、標準機能へ置き換えるのか、業務フローを見直すのかを業務部門と合意しておくことが重要です。

移行

移行フェーズでは、要件定義、設計、開発、データ移行、テスト、利用者教育、運用を進めます。

データ移行では、移行対象のデータ範囲、文字コード、添付ファイル、文書の関連性、履歴情報、権限情報などを確認します。

テストでは、通常の操作だけでなく、例外処理、承認ルートの分岐、権限による表示制御、外部システムとの連携、移行データの整合性などを確認します。特に、月末・年度末など特定時期に発生する業務や、組織変更時の承認ルート変更などは、事前に確認しておく必要があるでしょう。

移行後は、利用者からの問い合わせ対応や改善要望に対応できる体制を整えます。移行直後は、想定していなかった運用課題が見つかることもあるため、業務部門と情報システム部門が連携し、改善を続けながら定着を図ることが大切です。

 

Notes移行の注意点

Notes移行では、機能や費用だけでなく、利用者が使い続けられるか、移行後に十分な支援を受けられるかを確認する必要があります。ここでは、Notes移行時に特に注意が必要な操作性やサポート体制について解説します。

操作性やUI

移行先のシステムが高機能であっても、利用者にとって操作しにくければ定着しません。移行先を選ぶ際は、実際の業務シナリオを想定して操作性を確認することが重要です。申請者、承認者、管理者など、それぞれの立場で必要な操作を行い、入力のしやすさ、検索性、進捗確認のしやすさ、スマートフォンでの利用可否などを確認しましょう。

また、利用頻度の低い項目や複雑な入力画面を整理し、現場が迷わず使える構成に見直すことが大切です。移行前に利用者へのヒアリングやプロトタイプ検証を行うことで、定着しやすいUIを設計できます。

移行先のサポート体制

Notes移行では、移行先製品の機能だけでなく、導入から運用までを支援できる体制があるかを確認する必要があります。

移行支援会社やベンダーを選ぶ際は、Notes移行の実績、業務アプリケーションの再構築経験、データ移行の支援範囲、テスト支援、教育支援、運用開始後の問い合わせ対応などを確認しましょう。単に開発を請け負うだけでなく、業務整理や移行計画の策定から相談できるパートナーが望ましいといえます。

また、移行後の保守体制も重要です。業務変更や組織改編、制度改正が発生した際に、誰がどのように改修するのかを決めておかなければ、移行先でも再び属人化が進む可能性があります。内製で対応する範囲と外部へ依頼する範囲を整理し、継続的に改善できる体制を整えることが大切です。

 

まとめ

本記事では、Notes移行の必要性や進め方、注意点などについて解説しました。

Notesを使い続けることで、専門家不足、保守・運用コストの増加、アプリケーションのブラックボックス化、DX推進の遅れといった課題が顕在化する可能性があります。一方で、すべてのNotes DBを一律に移行する必要はありません。利用状況や業務の重要度を調査し、廃止、統合、再構築、アーカイブを適切に判断することが重要です。

移行先には、柔軟なワークフロー、ローコード開発、外部システム連携、権限管理、監査対応、業務変更への対応力などが求められます。現行のNotes環境をそのまま再現するのではなく、業務プロセスを標準化し、データを活用しやすい状態に整えることで、移行後の業務改善につながります。

intra-martは、ワークフロー、ローコード開発、システム連携、BPMを組み合わせ、Notesからの業務アプリケーション移行を支援できるプラットフォームです。Notes DBの棚卸しから、業務プロセスの見直し、移行後の継続的な改善までを見据えて脱Notesを進めたい場合は、intra-martのサービス内容や導入事例をぜひご覧ください。

intra-martに関する詳細はこちら