Notesから移行する7つのメリット―その7:Notes技術者の退職でメンテナンスが困難になること、自社に合わせたカスタマイズで開発コストがかかることを考える

IBM Notes/Domino(以下、Notes)における7つの課題について紐解いていきながら、その解決策となる「サイボウズ ガルーン(以下、ガルーン)」のメリットを連載形式でお伝えする第七回目。最終回となる今回は、アプリケーション開発基盤であるNotesだからこそ必要な開発人材の確保や開発コストの課題について見ていきます。


専門的な人材の確保やアプリケーション開発コストが必要なNotes

アプリケーション開発基盤であるNotesを利用する場合、自社の業務要件に合わせてシステム開発が必要です。メールやカレンダー機能など標準で活用できるアプリケーションも備わっていますが、ディレクトリ機能やデータベース機能など、アプリケーション開発を前提に実装された機能が多く、業務に活用できる環境を整備するにはアプリケーション開発が伴ってきます。このアプリケーションは情報システム部門のみならず、業務部門であっても知識を持っていれば開発することが可能です。まさに、エンドユーザコンピューティングのツールだといえます。

ただし、Notesでアプリケーション開発を行う場合、一般的なWeb技術に関する知識よりも、Notes専門の知識やノウハウが欠かせません。Notes DBの考え方やIBM Domino Designerを用いての開発など、専門的なスキルが必要になります。そのため、アプリを開発した本人が異動や退職をしてしまうと、その業務を引き継いだ人ではメンテナンスが難しくなり、機能改修ができなくて困っている、というケースが散見されます。仕組み自体が完全に属人化しており、ちょっとした改修も難しくなってしまうというのが現実のようです。

一般的なシステム開発ならいざしらず、Notesの場合は業務部門が作成したアプリケーションも多く、結果として仕様書が存在していないケースがよくあります。誰が見てもわかるような作りにはなっておらず、実際には作った本人でないとそのアプリの構成も把握できないのです。Notesアプリを使い続けるためには、貴重な専門人材をわざわざ確保し続けなければなりません。市場の変化が激しい今の時代にあって、柔軟に改修できないような仕組みは避けたいところでしょう。また、Notesアプリは自社に合わせたカスタマイズをしながら開発を進めていくことになり、どうしても開発コストがかかります。業務プラットフォームとしてNotesを利用するのであれば、自社の運用に合わせたカスタマイズが必須です。必要な機能を開発するための期間も必要となり、初期に導入したときには想定されてない開発工数が、メンテナンス時に必要になることも。業務の基盤として利用するからには、長期的な視点でメンテナンス工数も含めたトータルの費用をしっかり考えておきたいところです。

パッケージ製品のメリットを生かしたガルーン

業務で利用する標準的な機能が豊富に備わったガルーンであれば、現状の業務に必要な基本的機能はパッケージとして提供されており、わざわざカスタマイズすることなく日々の業務に役立てることができます。専門的な人材を確保し続けることもなく、定期的な機能改修やパッケージそのもののバージョンアップはベンダー側で対処してくれるため、無駄なコストが発生しにくい環境にとなるはずです。

ガルーン主な機能.png
ガルーンには、業務に必要な機能が豊富に備わっています

ただし、自社内の運用に合わせてどうしても改修しなければいけない場合もあることでしょう。そこでガルーンでは、基本的な機能を生かしたうえで、必要な機能を外部と連携して実現するなど、いくつかの方法が選択できるようになっています。実際の事例では、ガルーンが提供している標準のAPIを使って連携を行う方法や、ビジネスアプリ作成プラットフォーム「kintone」を使って必要な業務アプリを実装する方法、そしてサイボウズに直接依頼してパッケージ内に手を入れる有償カスタマイズという3つの方法が挙げられます。

○ガルーンAPIカスタマイズ

ガルーンのAPIを使ってカスタマイズする場合は、一般的なWeb標準として用いられているSOAP形式のインターフェースで外部プログラムとの連携が容易に行えます。この場合、標準的なWeb技術を用いるため、技術者の確保も容易で、メンテナンス時にも使っているAPIを見ればどういった動きをしているのかが容易に想像できます。専門的な人材を確保したり多くの開発工数が必要になるということは起こりにくいはずです。当然ですが、運用上必要なアプリケーションをスクラッチで開発したり、ほかのパッケージを利用するといったことは必要です。

○kintone連携

kintoneを使って必要な機能を実装し、ガルーンと連携させる場合も同様です。Web標準のインターフェースを用いてkintoneと連携するため、特定アプリケーションに特化した人材が必要になることはありません。また、kintoneを用いれば、専門的な知識がなくとも容易に業務アプリケーションが作成でき、クラウドサービスであるがゆえにサーバの手配など運用管理面でも手間がかかりません。必要な機能をkintoneで構築し、ガルーンと連携する事例が増えている状況です。実際にNotesからのリプレースに成功した企業の実例では、Notesよりもガルーンとkintoneの組み合わせのほうが安価になるという試算も出ています。Notesにて開発するよりもコスト的にメリットが出ている一例です。

img_3_4.png
中野製薬株式会社導入事例より

○ガルーン有償カスタマイズ

そして最後の方法が、パッケージそのものに手を入れる有償カスタマイズです。運用上どうしても必要な機能を実装しなければならない場合の手段ですが、メンテナンスやバージョンアップを考えると、あまりお勧めできない部分もあります。確かに自社に最適な形で手を入れることはできますが、ガルーンそのもののバージョンアップ時には検証作業が必要になり、トータルで見ると費用もそれなりに発生します。パッケージ製品という点を生かすのであれば、使える機能はパッケージ標準で、それ以外にどうしても手を入れる必要のある一部の機能は、APIなどを用いて柔軟に連携するといった方法がお勧めです。

今回の課題は、アプリケーション開発を前提としたプラットフォームであるNotesと、パッケージ製品であるガルーンの違いに起因する部分だとも言えます。専門的な知識とスキルによる開発が伴うNotesを利用すると、確かに自社に合わせた仕組みは作りやすいでしょう。しかし、環境変化の激しいビジネスにおいてNotesをプラットフォームに使い続けるには、改修にも対応できるよう専門的な人材確保と、それなりのコスト負担を覚悟しておく必要があります。本当に業務上必要な機能がNotesでないと実現できないのか改めて考えたうえで、パッケージ製品を選択することが業務基盤の構築には必要なことではないでしょうか。

まとめ

Notesにおける課題とガルーンのメリットをお伝えしてきた本シリーズですが、今回をもって最終回となります。連載を通じて注目してきたのは、日々の業務を支援するグループウェアという製品カテゴリに属している2つの製品ではあるものの、その性格は大きく異なるという点です。開発前提のプラットフォームであるNotesと、必要な機能がすべてパッケージング化されているガルーン。確かにいち時代を築いてきたNotesではありますが、変化の激しい今のビジネス環境に追随することが難しくなっており、Notesに対して多くの企業が課題を感じている状況にあるのです。
今後数年先を見据えたうえで業務基盤となる仕組みをどう整備すべきなのか、このコンテンツがその第一歩を踏み出すきっかけになれば幸いです。

■Notesからの移行個別相談会も随時開催中!

てんとまる社 酒井 洋和