LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

脱ノーツが求められる背景——ライセンス費と保守体制、属人化したアプリの限界

HCL Notes/Domino(旧IBM Lotus Notes)は、Lotus Development社が1989年に開発したグループウェアです。IBMは1995年にLotus社を約32億ドルで買収しましたが、その主目的はNotesの獲得だったとされています^*1。2018年12月、IBMはNotes/Dominoを含むソフトウェア製品群をHCL Softwareへ約18億ドルで売却すると発表し、2019年7月に譲渡が完了しました^*1。

現在の最新版はHCL Domino 14.5で、2025年6月にAI機能「Domino IQ」などを搭載して公開されました^*2。一方で稼働中の環境には、v9.0.xやv10.0.xといった旧バージョンも数多く残っています。これら旧バージョンの拡張サポート終了時期は、当初2022年12月とされていたものが2024年6月、2025年6月2日、2026年6月2日と幾度も見直され、現在は2030年6月30日が最終期限として示されています^*2。延長が続いているとはいえ、拡張サポートには追加費用が発生し、対象は既知の不具合修正が中心で新規に見つかった欠陥には対応しない点も公式に説明されています^*2。

ライセンス費や保守要員の確保という運用コストに加え、長年の内製開発で積み重ねたアプリケーション資産が課題になる企業も少なくありません。承認フローや台帳管理を担うアプリは、開発を手掛けた担当者の異動や退職とともに仕様が分からなくなる「属人化」が進んでいる、という声もよく聞かれるところです。こうした背景から、情報システム部門ではMicrosoft 365などクラウド標準への移行を検討する動きが広がっています。ただしNotes/Domino特有の技術的な壁を理解せずに移行計画を立てると、想定外の手戻りにつながるおそれもあるでしょう。次章以降では、Notes/Dominoならではの構造的な特徴を順に整理します。

NSFデータベースの特殊性——非リレーショナル構造とLotusScript・式言語が移行を難しくする理由

NSFという文書指向データベースの仕組み

NSF(Notes Storage Facility)は、Notes/Dominoが採用する文書指向型のデータベース形式です。アプリケーションの設計情報(フォーム・ビュー・エージェントなど)と、実際のデータを1つのファイルに同時に格納する点が、テーブル定義とデータを分けて管理するリレーショナルデータベースと大きく異なります^*1。

NSFはスキーマレスな構造を持つため、文書ごとに項目(フィールド)の構成が異なっていても保存できます。この柔軟性は業務側の要望に応じて現場主導でアプリを増やしやすい一方、統一的なテーブル定義が存在しない点が特徴です。移行先でリレーショナルなテーブル構造やSharePointのリスト構造に落とし込む際には、項目の洗い出しからやり直す作業が発生しやすくなります。

NSFファイルにはODS(On-Disk Structure、ディスク上の保存形式)というバージョンの概念があり、Dominoは古いODSを自動では変換しません。ローカルデータベースであればNOTES.INIファイルにNSF_UpdateODS=1を追記するなど、明示的な操作を経て最新のODSへ更新する仕組みになっています^*4。この設計自体が、長期間運用されたNSFには複数世代の保存形式が混在し得ることを示しており、移行前の現状棚卸しでは各アプリのODSバージョンや設計の更新履歴まで確認しておく必要があります。

LotusScript・式言語によるロジックの移植

Notes/Dominoのアプリケーション開発では、LotusScriptというVisual Basicに近い構文の言語が広く使われてきました。Notes環境をモデル化した専用のクラス群を備え、Java・JavaScriptと並ぶ開発言語の一つと位置づけられています^*1。LotusScriptに加え、ボタンや列の計算式などに使う「式言語(Formula Language)」も、Notes/Domino固有の記法として広く使われてきました。承認フローの分岐条件やビューの表示条件など、業務ロジックの多くがこの2つの言語に分散して実装されているケースは珍しくありません。

移行先がPower AutomateやWebアプリケーションの場合、こうしたロジックはそのまま持ち込めません。一度、業務要件として言語化し直し、移行先の仕組みで再構築する工程が求められます。NSFのデータをそのままコピーするだけでは業務が回らない、というのがNotes/Domino移行の難しさの核心にある部分です。

Reader/Author項目とACL——文書レベルの権限管理が移行を複雑にする

Notes/Dominoのアクセス制御は、データベース単位で設定するACL(Access Control List)が土台になります。ACLではユーザーやグループごとに、マネージャー・デザイナー・エディター・作成者・リーダーといったアクセスレベルを割り当てます。

これに加えて、フォームに「Readersフィールド」「Authorsフィールド」を設定すると、文書ごとにさらに細かい閲覧・編集の制限をかけられます。公式ドキュメントによれば、Readersフィールドに登録した内容は、データベースのACLで許可された範囲を超えて権限を広げることはできず、あくまで「さらに絞り込む」方向にのみ働きます^*3。ACLで「アクセス権なし」とされたユーザーは、Readersフィールドに名前が載っていても該当文書を読めません^*3。

逆にAuthorsフィールドは、ACLでエディター以上の権限を持つユーザーであっても、Readersフィールド・フォームの読み取りアクセス一覧・Authorsフィールドのいずれにも名前がなければ、その文書を読めなくする働きを持ちます^*3。つまり「データベース全体の権限」と「文書ごとの権限」という二層構造で、しかも上位のACLが上限を決める設計になっているわけです。

この二層構造は、特定の申請者と承認者だけが該当文書を見られるようにしたい承認フローアプリなどでよく使われる仕組みです。移行先でSharePointの権限グループやPower Platformのセキュリティロールに置き換える際は、ACLの割り当てとReaders/Authorsフィールドの組み合わせを1件ずつ確認し、どの権限がどの階層で効いているかを整理してから移行先の設計に反映する作業が欠かせません。対象アプリの件数が多い環境では、この権限の棚卸しだけでも相応の工数を要します。

移行先の3つの選択肢——Microsoft 365、Webアプリ再構築、ワークフロー製品

Notes/Domino環境からの移行先は、大きく3つの方向に整理できます。1つのアプリ群にどれか1つを当てはめるのではなく、アプリの特性に応じて組み合わせを検討する進め方が実務的です。

(A)Microsoft 365(SharePoint・Power Platform・Teams・Exchange Online)

メール・カレンダーはExchange Online、文書管理やワークフローの土台はSharePointとPower Platform(Power Apps・Power Automate)、コミュニケーションはTeamsという組み合わせに寄せる移行先です。Microsoftは管理者向けに、Exchange Onlineへのメール移行やSharePointの設定を含む導入ガイドを公式に提供しており、標準的な手順を踏みながら移行を進められる点が特徴です^*6。

Microsoftはレガシーアプリケーションの近代化について、廃止(Retire)・置換(Replace)・以前のまま移す(Rehost)・改修(Refactor)・再構築(Rearchitect)という選択肢を整理しており、すべてを一度に作り直すのではなく、段階的に進める入替アプローチを推奨しています^*5。Notes/Dominoのワークフローアプリも、この考え方に沿って優先度の高いものから順に置き換える計画が立てやすくなるでしょう。一方で、LotusScript・式言語で実装された分岐条件をPower Automateへ自動で移植する仕組みは用意されていません。ロジックの読み解きと組み直しは、人手を介した作業として計画に含める必要があります。

(B)Webアプリケーションへの再構築

業務要件を洗い出したうえで、スクラッチ開発またはパッケージ製品でWebアプリを新たに構築する選択肢です。NSFの文書指向構造から離れ、リレーショナルデータベースを土台にした標準的なアーキテクチャへ移れるため、長期的な保守性を重視する場合に選ばれます。反面、要件定義から開発・検証までの工程が発生し、移行対象のアプリ数が多いほど検討すべき範囲も広がります。

(C)ワークフロー製品への置換

承認フローや申請業務が中心のアプリであれば、Notes/Dominoに依存しないワークフロー専用製品やクラウド型の業務アプリ基盤へ置き換える選択肢もあります。個別のロジックをゼロから作り直すのではなく、製品側の標準機能に業務プロセスを合わせ込む発想です。既存のNotesアプリが長年の運用で個別の分岐処理を積み重ねている場合、標準機能でどこまで代替できるかの見極めが検討の起点になります。

3つの選択肢を整理すると次のようになります。

移行の進め方——アプリ棚卸しから仕分け、データ移行まで

移行先を選ぶ前提として、まず自社にどれだけのNotesアプリが存在し、どのように使われているかを把握する必要があります。ここでは基本的な進め方を5段階に分けて整理します。

ステップ1は棚卸しと利用実態調査です。部門ごとに保有しているNSFデータベースを一覧化し、利用者数・更新頻度・LotusScriptや式言語の使用状況などを調べます。この段階で、情報システム部門が把握していなかった「野良」のNotesアプリが見つかることも珍しくありません。

ステップ2は廃止・凍結・移行への仕分けです。利用実態調査の結果に基づき、利用者がほぼいないアプリは廃止、読み取り専用で保管すれば足りるアプリは凍結、業務継続に必須なアプリは移行、というように振り分けます。すべてのアプリを移行対象にすると工数が膨らむため、この仕分けが移行規模を大きく左右します。

ステップ3は移行先の選定です。前章で整理した3つの選択肢の中から、アプリごとのデータ量・ワークフローの複雑さ・利用部門の要望に応じて個別に選びます。1つの移行先にすべてを寄せるのではなく、アプリごとに適した先を割り当てる考え方が現実的です。

ステップ4はデータ移行と権限の再設計です。NSFのデータを移行先の形式に変換し、ACL・Reader/Authorフィールドで表現されていた権限構造を移行先のアクセス制御に置き換えます。前章で触れた二層構造をそのまま把握できていないと、この工程で権限の抜け漏れが生じやすくなります。

ステップ5は検証と切替です。移行後のデータ・権限・ワークフローの動作を業務部門とともに確認し、Notes環境からの切替タイミングを調整します。メールのように利用者数の多い機能ほど、切替時の周知や並行運用の計画が重要になります。

外注で確認すべきポイント——委託範囲と技術者のスキル

Notes/Domino移行を外部のパートナーへ委託する場合、確認しておきたい点がいくつかあります。第一に、棚卸しから検証までを一括して依頼できるかどうかです。部分的な工程だけを請け負う委託先の場合、アプリの仕分け判断や権限設計の見直しといったNotes固有の知見が求められる工程を自社側で担う必要が出てきます。

第二に、LotusScript・式言語・NSF構造を理解した技術者が委託先に在籍しているかどうかです。Notes特有の言語やデータ構造を読み解ける人材は限られており、事前に体制を確認しておくことが判断材料になります。

第三に、移行先の設計経験です。Microsoft 365・Webアプリ・ワークフロー製品のいずれについても、技術に精通しているだけでは十分ではありません。Notes側の事情を理解していない委託先だと、権限設計やロジックの解釈で見落としが生じる余地があるでしょう。両方の知見をあわせ持つ委託先かどうかを見極めることが判断材料になります。

第四に、段階移行の計画です。メール・スケジュールなど影響範囲の広い機能から着手し、個別業務アプリは優先度に応じて順次移行するなど、段階を分けた計画を提示できるかを確認します。移行対象のアプリ数や権限構造の複雑さによって必要な工数は変わってくるため、現状の棚卸しから始めて内製・外注の切り分けを検討することが実務的な進め方になります。

まとめ：脱ノーツ・Domino移行で押さえる3つの判断軸

本稿ではHCL Notes/Dominoからの脱却について、Notes/Domino特有の技術的な壁を中心に整理しました。要点は3つに集約できます。第一に、NSFデータベースは非リレーショナルな文書指向型で、アプリ設計とデータを同一ファイルに格納する構造がリレーショナルDBへの移行を難しくしています^*1。第二に、Reader/Author項目はデータベースのACLが許可した範囲を超えて権限を広げることはできず、二層構造で権限が決まる仕組みになっているため、移行先の権限モデルへ置き換える際は1件ずつの確認が欠かせません^*3。第三に、移行先はMicrosoft 365・Webアプリ再構築・ワークフロー製品という3つの選択肢に整理でき、アプリごとの特性や棚卸し結果に応じて組み合わせを検討することが、内製と外注の判断材料になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Wikipedia「HCL Domino」（https://en.wikipedia.org/wiki/HCL_Domino）
2. *2　出典：The Register「Old HCL Notes and Domino versions supported until 2030」（2025年9月23日）（https://www.theregister.com/2025/09/23/hcl_notes_domino_support/）
3. *3　出典：HCL Software「About restricting access to specific documents using a Readers field」（HCL Domino Designer Help）（https://help.hcl-software.com/dom_designer/11.0.1/basic/H_ABOUT_RESTRICTING_ACCESS_TO_SPECIFIC_DOCUMENTS_USING_A_READERS_FIELD.html）
4. *4　出典：HCL Software「Domino On-Disk Structure」（HCL Domino Administration Help）（https://help.hcl-software.com/domino/10.0.1/admin/inst_dominoondiskstructure_t.html）
5. *5　出典：Microsoft「Modernize applications with Power Platform」（Power Platform | Microsoft Learn）（https://learn.microsoft.com/en-us/power-platform/guidance/adoption/application-modernization）
6. *6　出典：Microsoft「Advanced deployment guides for Microsoft 365 and Office 365 products」（Microsoft 365 Enterprise | Microsoft Learn）（https://learn.microsoft.com/en-us/microsoft-365/enterprise/setup-guides-for-microsoft-365?view=o365-worldwide）

Tweet