「社内に HCL Notes/Domino のアプリが何本あるのか、実は分からない」「誰が使っているのかも、はっきりしない」。継続利用・Web 化・移行のどれを選ぶにしても、こうした状態では判断を始められません。この記事では、判断の前に行う Notes アプリの棚卸しについて、何をどこまで把握すればよいかを整理します。
※ 本記事の対象は、社内で Domino サーバーを運用している情報システム部門の方です。確認する画面や項目は Domino 12 / 14 を想定しています。画面の名前は版によって違うことがあるため、お使いの版の HCL の公式ドキュメントで確かめてください。
棚卸しは、「移行する・しない」を決めるためのものではありません。継続して使う場合の保守体制の見直しにも、Web 化にも、移行にも、アーカイブや廃止にも、最初に要るのは現状の把握です。この記事も、どの道を選ぶかには触れません。
先に「何のための棚卸しか」を決める
Notes アプリの棚卸しは、一度に全部を詳しく見ようとすると終わりません。先に目的を決めると、必要な深さが決まります。
| 目的 | 先に知りたいこと | 必要な深さ |
|---|---|---|
| 保守体制の見直し | 何本あるか、誰が担当か、止まると困るのはどれか | 全アプリを浅く |
| Web 化・移行の検討 | 業務への影響が大きいアプリの中身（設計の規模、他システムとのやり取り） | 重要なアプリを深く |
| アーカイブ・廃止の判断 | 実際に使われているか、最後に更新されたのはいつか | 全アプリを浅く＋利用状況 |
進め方は 2 段階です。第 1 段階で全アプリを浅く一覧にし、第 2 段階で重要なアプリだけを深く見ます。
第 1 段階: 全アプリを一覧にする
まず、Domino サーバー上にあるアプリ（データベース）を、すべて一覧にします。ここでは中身には踏み込まず、次の項目を集めます。
| 項目 | 何のために見るか | どこで確かめられるか |
|---|---|---|
| タイトル・サーバー・ファイルパス | アプリを特定する | Domino Administrator の「ファイル」タブ |
| 設計の継承元テンプレート | 標準テンプレート由来か、独自の作りか | データベースのプロパティ（設計タブ） |
| 最終更新日 | 動いているか、止まっているか | ファイルの一覧、データベースのプロパティ |
| 文書数・サイズ | 規模をつかむ | ファイルの一覧、データベースのプロパティ（情報タブ） |
| レプリカの有無 | 複数のサーバーにあるか | データベースカタログ |
| ACL の管理者と主な利用者 | 誰のアプリか | データベースの ACL |
| 業務の担当部署 | 相談先を決める | 業務部門への聞き取り |
集めた結果は、1 アプリを 1 行にした表にまとめます。
「どこで確かめられるか」の列は、使える機能のおおまかな目安です。画面の作りや項目名は、Domino の版や設定によって変わることがあります。
サーバーが複数台あるときは、データベースカタログ（catalog.nsf）が一覧づくりの助けになります。カタログはサーバーごとに作られるため、台数が多いときは各サーバーのカタログを集める必要があるかもしれません。カタログを使うには、サーバー側で作成の設定が要ります。設定の有無は、各サーバーで確かめてください。
実際に使われているかを確かめる
一覧ができたら、次は使われているかどうかです。最終更新日が古いだけでは、使われていないとは言えません。参照専用のアプリは、更新されなくても毎日読まれていることがあります。
そこで、次の 2 つを両方使います。
- 利用状況の記録を見る。 Domino が記録する、データベースの利用状況の情報を確かめます。どの程度の期間さかのぼれるかは、サーバーの設定に左右されます
- 業務部門に聞く。 記録に出ない使われ方（年に 1 回の決算期だけ使うなど）は、聞かないと分かりません
使われていないと分かったアプリは、アーカイブや廃止の候補として分けておきます。ただし、この時点で結論は出しません。候補として分けるだけにします。
第 2 段階: 重要なアプリの中身を把握する
業務への影響が大きいアプリについては、中身まで見ます。ここは時間がかかるので、第 1 段階で絞り込んだものだけにします。
| 項目 | 見るもの |
|---|---|
| 設計要素の数 | フォーム、ビュー、エージェント、スクリプトライブラリの数 |
| スケジュール実行のエージェント | 動く時刻、動かすサーバー、止まったときの影響 |
| 他システムとのやり取り | 他の Notes データベースの参照（@DbLookup など）、メールの送信、外部システムとの連携 |
| 文書単位のアクセス制御 | Readers フィールド・Authors フィールドの有無 |
| XPages | XPages を使っているか |
Readers フィールドと Authors フィールドは、あとから作り直すときにも、保守の引き継ぎでも見落としやすい部分です。仕組みは別の記事（公開予定）で解説します。
人手だけでは進まないときは
ここまでの進め方は、アプリの中身を人が見て確かめられることが前提です。実際には、アプリが複雑になっていて、見られる技術者が足りないこともあります。作った担当者がすでに離任していて、中身を知る人がいない場合もあります。こうしたアプリは、棚卸しの第 2 段階に進めません。
ケートリックの Notesアプリ再構築アセスメント では、AI がアプリの設計情報から仕様書を作ります。仕様書があれば、棚卸しの一覧づくりだけでなく、アプリごとの難易度や不具合の兆候、ハードコードされた値など、移行や再構築のときにつまずきやすい要素も洗い出せます。人が 1 本ずつ読み解く時間が取れないときの、手がかりになります。
この仕様書は、特定の移行先に向けたものではありません。継続利用、Web 化、移行のどの道でも、判断の材料として使えます。
アセスメントでは、現状をうかがうための「Notesアプリ再構築アセスメント_ヒアリングシート.xlsx」も用意しています。ご希望の方には提供できますので、お問い合わせからお申し付けください。
つまずきやすい点
棚卸しは、アプリの数が多いほど、また担当者が替わっているほど手間がかかります。
- 設計書がない、担当者がいないアプリ。 中身の確認に時間がかかります。第 2 段階の対象になったときに備えて、早めに見つけておくと安心です
- 結果が散らばる。 担当ごとに別のファイルで管理すると、あとで比べられません。第 1 段階・第 2 段階の結果は、1 つの表にまとめます
- 優先度を技術の側だけで決める。 業務への影響の大きさは、使っている部門にしか分かりません。表にまとめたら、業務の担当者と一緒に優先度を付けます
まとめ
- 先に目的を決める。目的によって、必要な深さが変わる
- 第 1 段階で全アプリを浅く一覧にする
- 使われているかを、記録と聞き取りの両方で確かめる
- 第 2 段階で、重要なアプリだけ中身を深く見る
継続利用でも、Web 化でも、移行でも、棚卸しの結果はそのまま次の判断の材料になります。
移行先を決める前に、まず現状を見えるようにしませんか。ケートリック株式会社の Notesアプリ再構築アセスメント は、移行先を特定の製品に決めず、現状の整理から進める診断です。アセスメントの無料トライアルのご相談は、お問い合わせ（種別「再構築アセスメント・無料トライアル」）から承ります。
