文書管理フレームワークとしてのNemakiWare

こんにちは。またすこし空いてしまいましたすぎもとです。

弊社がオーナーとなって開発を進めているオープンソースの NemakiWare ですが、いまはUIの差し替えを行っています。これまで Rails で書かれていたUIですが、インストール時や将来のバージョンアップなどで、いろいろ問題が出ている/出そう、という判断もあり、また、海外に行っていた同僚が帰ってきてふたたびジョインしてくれたこともあり、UI もふくめて Java 環境で動くように書き換えているところです。

普通ならUIの差し替えはけっこう大変かと思われるかも知れませんが、こと NemakiWare についていえば比較的簡単に進められています。NemakiWare が CMIS という標準規格の API の固まりであり、現在提供している機能のほとんどがこの標準 API だけで書けているというメリットがあって、まさにこのUIの差し替えのコストの低さはそこにあります。そもそも、Rails を最初に選択したというのも、サーバ側の言語に依存しないかたちで UI を書けることもひとつ理由としてはあったのです。

まあ、API がちゃんとついているという点だけ言えば、モダンなWebアプリであればそれほど珍しい点ではなくて、NemakiWareのうりは、上述のうち、UI側の機能提供がほぼ標準規格の中でできている、というところでしょう（なお、API の定義が規格上存在しないユーザ管理の部分などどうしても独自 API になっちゃうぶぶんも少しはあります）標準規格はそう簡単に変わりませんから、API の寿命も最初から長いことが担保されています。

最近、引き合いを頂いてお話しさせて頂くと、NemakiWare は当初の想定以上にいま書いたようなことが意味のあるつくりになってると思っています（あ、これは自画自賛と言うより、当初のコンセプトがちゃんと実感をもって感じられている、というところでしょう）。というのも、ECM ぽいことをしたい、というおはなしを頂いて、詳細を聞いてみるとけっこうシンプルな要件が多いのです。

これを従来の ECM でやるとしても、100%要件は満たすと思います。ただ、余計なものが多すぎて、たぶんそのまま導入しただけではユーザは「やりたいこと」に集中できません。このばあい「メニュー項目の隠蔽」とか「UIを要件に寄せたかたちに変更」みたいなことが絶対発生します。ひとくちにメニューの隠蔽と行っても結構多岐にわたったりしますし、UI の差し替えもそう単純ではありません。

いっぽうで、NemakiWare の標準UIでは、たぶんやりたいことに「少しだけ足りません」。この場合は、「追加でUIを要件にあわせて作成する」になります。けっきょくどっちもカスタマイズや新規開発が必要になるわけです。

となると、そこでのコストに大きな違いはないように思います。となると、使いもしない余計な部分までくっついてきてるECMがいいのか、使わない機能はほとんどない NemakiWare みたいなシンプルなものが良いかというと、それはシンプルな方が良いと思いませんか。使わないといってもそこに存在しているわけですから、当然バグが存在する可能性はありますし、それが使う部分に悪影響を与える可能性もあります。セキュリティ上の問題が発覚したとしたらそこに対してもパッチなどのケアが必要になるかも知れません。バージョンアップなども、使わない部分の影響は決して無視できないはずです。

シンプルに作ってある上に、ほどんどの機能が標準規格で完結している NemakiWare はその点ではかなりアドバンテージがあると思います。もちろん機能面で足りない、というケースであれば、従来の ECM 製品のほうがマッチするケースは大いにあって、適材適所だというのは当たり前の話なのですが、案件からするとシンプルなケースはけっこう多い。これまでは大仰な ECM くらいしかなかったので、適材じゃなくても使わざるを得なかったところがあるんじゃないかと思ってます。

弊社は Alfresco という大きな ECM （のコミュニティ版）のお仕事もしています。もちろん NemakiWare でビジネスをはじめるときに、いま書いたようなことはちゃんと検討した上で、Alfresco とうまく棲み分けできると判断してはじめたわけではあるのですが、それが頭の中だけじゃなくて、じっさいに実感としてわかってきたというのが最近の成果なのでした。

まじめな話を書いてしまいましたので秋雨前線さんにお気を付けください。では。