ワークフロー基盤としてのNotes/Dominoの圧倒的優位性

■今日、仕事でJ2EEのアーキテクチャ(商品名で言うと「intra-mart」)とユーザインターフェースにリッチクライアントとしてFlashを利用したグループウェアのデモを見た。グループウェアとしての機能は、サイボウズやデスクネッツなどWeb型グループウェアと大差なく、Webメール、スケジュール管理、会議室予約、ToDo管理、掲示板、電子会議室などといったところだ。確かにFlash利用のリッチクライアントは、単純なDHTMLのグループウェアより使い勝手はよいのだが、本質的な機能の差異はない。
また、今日見たパッケージはワークフロー機能を備えていたが、社員マスタと役職マスタとワークフロー定義から、社員一人ひとりについて、すべての承認フローについて静的に経路データを生成するという仕組みだった。これでは社員が1,000人いて、ワークフローのパターンが10通りあると、1,000×10=10,000の経路データが生成されるという非効率なデータの持ち方になってしまう。
普通、ワークフローパッケージは、ワークフローにのせる申請フォームを作成した時点で、動的に承認経路を生成し、その申請フォームにひも付けるという動きをする。経路データは個々の申請フォームを処理するための、単なる使い捨てのトランザクションデータにすぎないというのが、一般的なワークフローシステムの仕組みである。
また、今日見たパッケージは、独自にワークフローにのせる申請フォームを開発したい場合は、いちいち販売元に開発を依頼する必要があり、パッケージの機能として簡易作成できる申請フォームのデザインは、項目名1列と入力欄1列の2列の縦長テーブルに限定されてしまうため、実用性に乏しい。しかも項目どうしの計算ができないのでは、「単価×数量」といった簡単な合計欄をもつ申請フォームさえ独自に作成できない。
なお、デスクネッツも同様のワークフロー申請フォームの簡易作成機能を持っているが、デスクネッツのワークフロー機能の最大の弱点は、最終承認が終わった後の申請フォーム管理のずさんさにある。つまり、承認が完了した申請フォームは、HTML形式の添付ファイルとして「文書管理」機能の「ワークフロー」フォルダに、分類もされずどんどん蓄積されるだけといったおそまつさだ。
本当なら承認後の申請フォームは、カンマ区切り形式のファイルで書き出して、人事システムや会計システム、基幹業務システムなどと連携したいところである。それがHTML形式で申請フォームのレイアウトのまま保存されたのでは、承認済み申請フォームに入力されているデータの再利用がまったくできない。
このように、最近販売されているWeb型のワークフロー・パッケージを見るにつけ、いかにNotes/Dominoがよくできていて、「枯れた」技術であるかが分かる。Notes/Domino用のWeb対応ワークフロー・パッケージのカスタマイズのしやすさに比べると、上述のような製品は足元にもおよばない。
Notes/Domino用のワークフロー・パッケージは、ワークフロー・エンジンが「サブフォーム」という再利用可能なプログラム部品として実装されている場合がほとんどで、申請フォームは普通のNotesフォームとして、かなり複雑な設計ができる。項目間の計算はもちろん、入力値のチェックや、項目間のクロスチェックも可能だし、ODBC接続で基幹業務システム内のリレーショナルデータベースから選択項目を表示させることもできる。
しかも、このような独自申請フォームの開発は、一定のNotes開発スキルがあれば、いちいち業者に依頼することなく社内でできてしまう。
Notes/Dominoの持っているディレクトリシステムや、「サブフォーム」といったプログラムの部品化の考え方、入力欄(Notesの世界ではフィールドと呼ぶが)の入力値チェックの仕組み、蓄積されるデータの外部への取り出し(Notes/Dominoデータベース自体にODBCで接続することさえできてしまう)など、「枯れた」技術の集積によって、Notes/Dominoはワークフローを非常に作りやすい開発環境になっている。
サイボウズやデスクネッツのような歴史の浅いグループウェアに比べると、Notes/Dominoは基本性能のレベルがまったく違うと言っていい。
あとはIBMがNotes/Dominoのリッチクライアント版であるリリース8を日本国内で発売するのを待つだけである。そうすればクライアント・サーバ版のNotesクライアントの使いやすさをWebブラウザでも享受でき、サイボウズやデスクネッツの活躍する余地は、ほぼなくなってしまうだろう。