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

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

第6回型の理解が重要なノーツアプリケーション開発

ノーツを展開し利用が始まると、いつのまにかクライアントのワークスペース上にはたくさんのDBアイコンで埋まりはじめます。多くの場合、テンプレートを元にしたDBアプリケーションがほとんどなのですが、リリース4(R4)の登場もありその新機能を駆使して開発したかなり複雑なアプリケーションも見られるようになりました。ただその中に、『これがノーツアプリケーション?』と聞きたくなるようなものも見受けられるようになりました。もちろん快適に動作して、役にたつアプリケーションであれば別に問題はないのですが、多くの場合そのアプリケーションはパフォーマンスも悪く、使い勝手もいまいちで、誰も二度と直せないようなたくさんのスクリプトコードが書き込まれていたりします。皆さんの中には身近にそのようなアプリケーションの心あたりがある人がいることでしょう。

ノーツはR3のころに出ていた開発環境の不満、プログラミング言語が未成熟だとか、自由度が少ないとかと言った問題点を解消すべくロータススクリプトの機能などかなりの拡張がR4で行われました。確かにそれで開発できるアプリケーションの幅も広がりました。ただその代わりと言ってはなんですが、パフォーマンスが悪く、ノーツらしくないアプリケーションも増えてきたような気がします。

表として一覧を見たいからと言って、フォームの上でビューのような文書のサマリーを表として毎回作って遅くなっているアプリケーション。フィールドが変更された時に関係する文書の同じフィールドを全て探して変更するようにエージェントをゴリゴリ作り上げて遅くなったアプリケーション。雛形の文書を決めてカーボンコピーのように文書を作成し、項目を編集するのに標準の引継ぎを使わずにスクリプトでゴリゴリ仕組みを作っているアプリケーション。ともかく色々なアイデアで昔のノーツでは考えられなかったアプリケーションが開発され、時としてパフォーマンスや使い勝手で問題を起こしています。

確かにそんなアプリケーションを開発した人の気持ちもわからないではありません。プロトタイピングでユーザーに見せながらアプリケーション開発をするため、ユーザーのあまりに自由なアイデアをインターフェースとして実現してしまった場合。また一人一台のPCにノーツを導入した場合、『できるかぎりノーツでアプリケーション開発しよう』と言った意見がでてきて、とにかく色々なアプリケーションをノーツで開発しなければならなくなった状況など。ただこれでは大変です。元々ノーツが想定していないような機能のアプリケーションを無理にノーツに押し込めるのはやはり無理が生じます。無理を承知で、データベースの使い方を限定してそのアプリケーションを使うならば良いでしょうが、無理になんとか実現して、最後には『これができないのはソフトウェアとしておかしい』とか『これができないのは仕様のバグではないか』とまで言われてしまう始末です。

ところでスポーツの世界には型とかフォームというものがあります。テニス、スキー、そして一見自由に見える陸上や相撲でも型があります。人間はかなり自由な動きをできると思われていますが、それぞれのスポーツに適した型が定義され使われています。型は人の動きを制約しますが、型に近い形でプレーすればそれは最適な結果をもたらします。十分に型を練習したあとで、経験に基づいた限定的な型やぶりは効果的ですが、型に基づかない型やぶりは決して強いものではありません。

ノーツもいわば昔から培われてきた型を持っています。フォームとビュー、独立した文書とその親子関係、フィールドの独立性、さらに独特の複製の仕組みとR3のころから変わらない普遍のものがあります。これは電子キャビネットという最初のアイデアに始まった一つの型です。確かにリリースアップによって自由度は増えて型というものが拡張されていますが、どこまで拡張されても、リレーショナルデータベース(RDB)やトランザクションシステムにはなり得ませんし、また通常の言語のような自由なプログラミング環境にはなりません。開発者はこの型を十分知って体得していることが、良いノーツアプリケーションを開発する第一歩だと言えるでしょう。

プログラミング環境でも型を持ったものは昔からありました。帳票系のプログラムをたいへん生産性高く開発できたRPG言語。最近ですと決まった部品から効率よく画面を開発できる各種ビジュアル系ツールなど。これらは自由度は失っているものの、ある型を持つことですばらしい開発生産性というメリットを獲得しました。ノーツもそう言えばRAD(Rapid Application Development)の一つ呼ばれ、高い生産性を誇っているのは同じような理由からでしょう。

またノーツの型の存在は開発者のみならずユーザーにもメリットはありました。どのデータベースを使ってもビューやフォーム、そして文書という概念は同じで、その飾り付けやちょっとした機能が違うだけです。つまりほとんど教育がなくとも、一つ典型的なデータベースを利用していれば知らず知らずのうちにどのデータベースも使いこなすことができるわけです。ノーツのようにアプリケーションの数がどんどん増えていくような環境ではこれもたいへん重要なことです。

型のあるものですから、アプリケーションを開発する前からその型を意識しなければならなくなるでしょう。ノーツの型を意識せずに自由な発想でアプリケーション設計をやられたら、いくら名プログラマーでも身動きはとれません。また要件定義の段階でさえも、ノーツが何ができて何ができないのかを知った人間が入らないと、例えば全てのサーバーでのデータの即時反映とか言った、大きな理想を要件として決められてからでは先が思いやられます。建築の世界で例えて言えば、木材という材料を前提で与えられていながら10階建てがほしいという要件では完全なお手上げです。要件によっては、例えばRDBと言った他の道具を使うという判断もしなければならないことでしょう。いずれにしてもノーツという道具の型を理解している人の要件定義段階での参加が必要でしょう。

今までの自由なプログラミング環境とはまったく違うノーツという型の世界。型は開発生産性を向上するのにたいへん重要な役割を果たすでしょうが、同時に開発者の開発というもののやり方に関するマインドを大きく変えることを要求してきます。自由なプログラミング環境とは違い、要件とその設計を忠実に開発することはノーツのような世界では美徳とはならないでしょう。むしろ要件に近い形でどのようにノーツの型を使うかというアイデアを出し、時には型にはめ、時には型の例外的な使い方を考え出すような技術が求められることでしょう。それが短時間でパフォーマンスの良いアプリケーションの開発につながり、最終的にはユーザーに満足されるアプリケーションになることと思います。

あるお客様で大量のデータベースが展開されかなり使っているようでした。そこでユーザーに『どのデータベースが最も有効ですか』という質問をしてみると、『テンプレートから作ったもの』とか『ディスカッションを少し書きかえたもの』といった答えが戻ってきました。テンプレートなども一つの大きな型であることはいうまでもありません。そこには難しいプログラミングなどはなく開発量は微々たるものですが、ノーツの良い意味で型にはまった普通のアプリケーションが確実にユーザーの満足を得ている姿がありました。

T. Seki, ts@jp.ibm.com

上に戻る