Notes/Domino の新しいバージョン導入、新しいアプリケーションのモダナイズの試み、場合によっては新しいプラットフォームへの移行。チャレンジングなプロジェクトが皆さんを待ち構えています。いづれの試みにせよ、またボリュームの大小に関わらず、これまでの Notes/Domino 資産を有効に活用したいと考えるとき、まず最初に私たちの頭に浮かぶのは「いったいこのアプリケーションは本当に使われているのか？」であったり「本当にビジネスに価値あるものなのか？」であったりします。これには疑問の余地はありません。しかし、そのように使用状況だけを頼りにしたデータベースの選定だけを頼りに開始したプロジェクトが今なお破綻を来しているかのごとく、先の見えないエンドレスなプロジェクトとなり、それに関わるリソースもコストも疲弊してしまっています。何故こんなことが起きたのでしょう。いったいなにが悪かったのでしょうか。

そこには使用状況だけを鵜呑みにするだけではいけなかった何かがあったはずです。現にどのようにアプリケーションを選定しているかを尋ねると、Notes データベースの使用状況から読み込み書き込みの数が多ければ、「おそらく」大事なものだろうぐらいの調査と選別しか行われていません。これはベンダーにお願いするコンサルティングから得られる情報もこの程度に過ぎないことが多いと聞きます。しかし、これだけの情報だけでは、後々プロジェクトが炎上を迎えるのは自明の理と言わざるを得ません。

実はプロジェクトの概要すら把握できずにプロジェクトがスタートしているケースが多い

ほとんどのモダナイズ／移行プロジェクトでは、データベースの分類分けからスタートしているはずですが、その分類分けが実は想像の世界で繰り広げられています。昨日まではもう捨てるはずのデータベースの部類に入っていたのが今日になって、「これは絶対要るぞ」と変わってみたり、「これもしかたらあの部門では重要なものじゃないの、よく設計の内容を精査してみないと」などと変わってみたり。プロジェクトが前進すると思いきや後退し始めることも。

データベースの使用状況と設計の複雑さはセットで考える

モダナイズにしろ、他のプラットフォームにしろ、複雑なデータベース設計をもつデータベースの対応には相当な人的リソースやコストを割く必要があります。はっきり言えば、データベースの使用状況だけの選定だけではプロジェクトは頓挫してしまいます。あなたのビジネスに深く関わっているデータベースは、深く関われば関わるほど、複雑な設計で、ビジネスロジックがたくさん記述されているケースがほとんどです。従って、設計の複雑さはビジネスに必要かどうかの良い指標となり、より精度の高い選定に必ず貢献するはずです。設計の複雑さは、ここでは単に設計の数だけを言うのではなく、実装されたコードの行数も考慮すべきではないでしょうか。

テンプレートから派生したデータベースを把握する

Notes を長く使っている企業ほどかつて流行したエンドユーザーコンピューティングによるアプリの乱立が見られます。文書ライブラリテンプレートから作成されたデータベースがいくつもあるという企業は少なくありません。もしテンプレートからの設計の引継ぎがあれば、それを頼りに同じ設計だと判断もできますが、そんなに整理された環境ではなく今では無法地帯と化している企業もあることでしょう。

でも設計間の類似性がもし把握できたらどうでしょう？98% はテンプレートと同じだと指標がでれば、ユニークで独立したアプリとしか評価できなかったプロジェクトが、一気にアプリケーション群をいくつかに集約し整理することが可能になるはずです。

コード解析の必要性

一度始まったプロジェクトでよく起こるのが、これは簡単に移行できるデータベースだと思っていたら、設計をよく調べたらとんでもないコードが紛れ込んでいたといった類いです。他データベースとの参照やメールシステムに依存しているもの、サーバー名やファイル名がはハードコーディングされていて統廃合できないものなどなど。

panagenda iDNA Application はプロジェクトの全体像を明確に浮き彫りにし、なにから手をつければよいのか、どう対処すればよいのかをビジュアルで確認できす。これからプロジェクトを計画する際はもちろん、プロジェクト途中で頓挫しそうな場合にも説得力のあるデータで次の打開策が必ず見つかるはずです。