ソフトウェア > Lotus > Lotus Developer Domain >

SE関のノーツ/ドミノ徒然草

第21回エンドユーザー開発の行きつくところ

ノーツが爆発的な人気を生んだそのひとつの理由にRAD(Rapid Application Development)、つまり簡単にアプリケーションが短時間に開発できるというメリットがあったかと思います。そのため多くのエンドユーザー部門がノーツデータベース開発に手を染めました。あるユーザーでは何年かのノーツ運用でアプリケーションの数のほうがユーザー数を上回っているという実態もでてきました。このように花開いたノーツのエンドユーザー開発。いったいこの先どこまで行くのでしょうか。

今回はこのノーツのエンドユーザー開発について考えてみましょう。

ノーツのエンドユーザー開発のメリットは確かに多くのユーザー部門に多くのメリットをもたらしたようです。今までは情報システム部門に依頼して待たなければならなかったようなバックログと呼ばれるアプリケーションの一部が、ノーツ上でしかも自分たちの手で実現できたのです。その迅速なアプリケーション構築とそしてそれによってもたらされた業務の改善。確かに多くの満足をユーザーに残してきました。

ところが一方では、メリットとともに多くの問題を新たに残しているのも事実です。あまりに多くのアプリケーションが開発されたため、画面などの操作性はまちまちで使いにくく、またリリースや環境が違うユーザーからそのアプリケーションがアクセスできないなどの問題。またユーザーの自由奔放なそして巨大な開発による、システム面での負荷の増大によるレスポンスの悪化、さらにそれによるサーバーの不調という問題。これらは広くは第18回の『自由と束縛の中の開発』で取り上げたデータベースの標準化の推進という課題を我々に突きつけています。

また標準化という枠を一歩越えて、さらにそれでは解決できないいろいろな問題もでてきてきます。例えばユーザー部門の開発者が配置転換になったために重要なアプリケーションのメンテナンスができないといった問題、そして同じような種類のアプリケーションが至る所で開発されているといった状況などです。これは言いかえれば中央の情報システム部門で責任をもって開発してきた旧来のものではないからと言えるかもしれません。

見渡せば部門ごとに、似たような業務だけれどフィールドの名前から何から全部異なる掲示板。簡単な文書管理の仕組みがほしいだけなのに、個性豊かなバリエーションにとんだ文書管理データベース。果てはほとんど同じ報告書業務をお互い連絡のない部門が独自に開発してしまった2つの異なる報告書データベース。業務としては差異は僅か、またはほとんどなくとも独立したエンドユーザー開発によって全て違うバリエーションにされてしまうのです。同じアプリケーションを重複して見えないところで開発して無駄を生じさせている、これはまさに今、世の中で問題にされているTCO(Total Cost of Ownership)の問題の開発版といったところでしょう。

ではこんなエンドユーザー開発の無駄を減らすのにはいったいどうしたらいいのでしょう。昔のようにエンドユーザー開発ではなく全てを中央の情報システム部門で開発してもらうべきなのでしょうか。もちろん答えはノーでしょう。ユーザーの数よりも多く存在するようなアプリケーションを情報システム部門にまかせたらその完成を見る前に業務は大きく変化していることでしょう。

1つの答えは情報システム部門のようなユーザーに対して中立的な立場の部門が、エンドユーザーの開発の調整役を果たすことでしょうか。例えばある部門でこんなアプリケーションを開発したいというニーズがあがったとします。技術的な観点も含めて情報システム部門にアプリケーションの相談にくることでしょう。情報システム部門は開発者の教育、相談に乗るとともに、もう一歩踏み込んで既にあるテンプレートや他の部門での同様のアプリケーションの転用について提案することもできます。またユーザーが開発後はそのアプリケーションの運用管理を請け負うとか、または何処かに委託するとかで、アプリケーションの長い役割を保証することもできます。言わば社内のアプリケーションプローカー的な役割と言えるでしょう。

またもう一歩レベルの高い1つの答えとして、その会社独特の汎用アプリケーションテンプレートを提供するということも情報システム部門の挑戦できる仕事です。つまり事前に社内で共通に使えそうな汎用掲示板データベース、さらに汎用文書管理データベースなどを構築し、それを利用してもらい、さらにそのフィードバックでその汎用性をレベルアップするとともに維持していくような役割です。もちろん汎用的であるということはかなりアプリケーションを抽象化させることが必要ですし、また場合によってそれぞれのユーザー部門の業務そのものをアプリケーションに合わせて変えるという大胆なことも必要になるでしょう。似たような業務だけど異なる設計のアプリケーション。こんな無駄の多い開発はこの情報システム部門のアプリケーションコンサルタント的な活躍で減っていくことでしょう。さらには設計が同じですからデータベースの設計だけでなく中身の標準化にもつながります。将来全社規模での情報の大々的な共有化というような大きな目標に対してもたいへん重要な準備と言えるかもしれません。

エンドユーザー開発とダウンサイジングという嵐によって力を失いつつある情報システム部門。しかし一方ではエンドユーザー開発の行きすぎが、逆に中央の役割の見直しにつながりそうな気配がこのノーツのエンドユーザー開発から垣間見れると言えるでしょう。アプリケーションのプローカー的役割、アプリケーションのコンサルタント的役割、いずれも情報システム部門のアプリケーション部分での復権につながるようなことかもしれません。ただそこで要求されているスキルは、大型コンピューターの時代に行っていた、ユーザー部門の要求しているアプリケーションをとにかく作り上げるという労働集約的作業ではありません。むしろ業務というものをより汎用化してユーザーに提案したり、もっと踏み込んで業務を変えさせるというような高度なもののような気がしています。

歴史は繰り返すといいます。一度集中化したものが分散し、また逆もどりして集中する。この諺は情報システム部門のアプリケーション分野における復権を勇気づけてくれるような気もします。しかしそのもう一度戻った集中は、過去の集中とはまったく違う高度なものを要求していることでしょう。エンドユーザー開発が行きすぎ始めている今、情報システム部門の新しい役割をノーツでも期待したいものです。

T. Seki, ts@jp.ibm.com

上に戻る