SE関のノーツ/ドミノ徒然草: 第7回 関数式かスクリプトかそれが問題だ

ノーツのR4が出荷される直前、多くの開発者はきっとこう思ったでしょう。『やっとまともなプログラミング言語のロータススクリプトがついてくるのだから開発がやりやすくなる。関数式とはもうおさらばできる』。実は私も密かにそう思っていた1人でした。さて本当のところどうだったでしょうか。開発者は本格的なプログラミング言語であるスクリプトで気分よく効率的に開発できるようになったでしょうか?

ICS クライアント テクニカル プロフェッショナルズ, ソフトウェア事業, 日本アイ・ビー・エム株式会社

ICS クライアント テクニカル プロフェッショナルズ, ソフトウェア事業, 日本アイ・ビー・エム株式会社



2008年 5月 11日

確かにR3のころに比べるとできることは増えました。スクリプトを使うと、エージェントではいろいろな条件で別のデータベースに古い文書を移すアーカイブが簡単にできたり、全ての文書を何回でも複雑な処理をできたり。またユーザーの操作にあわせていくつかの処理を自動化できたり、その裏では自由に繰り返しをしたり分岐したりするプログラムを書いたり。でもその一方でR4での開発では、時としてなぜかパフォーマンスの悪い、また複雑でユーザーが使いこなせないようなノーツアプリケーションが増え、そして効率的に開発できるという期待は裏切られ、開発の期間が伸びていると感じるのは私だけでしょうか?

最近R4以降のアプリケーションを見ていると数千行ものスクリプトコードが書き込まれているものに出会います。確かに話しを聞くと、なるほどそんなに処理をすると確かにそのくらいのコードが必要だと思われるものもあります。ところが一方では開発者が関数式を知らないので、とにかく全部スクリプトで書いたなどという話しも聞きます。またあまりにアプリケーションが遅いので、関数式を知っている開発者に見てもらったら数十行のスクリプトを数行の@DbLookUpなどの関数式に書き換えてくれて、たちまち数倍速くなったなどという話しもあります。

技術的に見れば関数式とスクリプトは、両方でできることもあれば、それぞれでしかできなこともあります。繰り返しの処理や外部にデータベースを作ったりACLを操作するのはスクリプトでしかできません。また選択式は関数式でしか書けませんし、ECLなどの操作は関数式でしか用意されていません。ただ多くの部分は共通していたりもします。実行速度に関してもケースバイケースのようで関数式が速い場合もあれば遅い場合もあります。これでは開発者は関数式の上にスクリプトを覚えることが増えただけかもしれません。

ところで前回ノーツアプリケーションの型という話しをしました。フォームとビューそしてデータベースから形作られているノーツのある一定の枠組みとでも言えるノーツの型。考えてみればこのノーツの型はR3からR4になっても、ほとんど変わっていないのは多くの人が気が付いていることです。つまりスクリプトが加わったからと言ってノーツという型は同じなのです。

型はプログラミング言語の側面から見れば、いろいろな機能を持つ大きな部品の集まりと言いかえることができるかもしれません。関数式ではそれらの部品を直接操作できなかったり、また操作できてもつなぎあわせたりするのがかなり大まかで、一連の作業を部品を組み合わせてやるとかは苦手でした。しかしスクリプトになってから木目細かく部品操作でき、つなぎあわせも楽になり、一連の作業を部品の組み合わせでうまくできるようになった、そんな風に見えてきます。つまりできることは部品が変わっていないのですから以前と変わりはないのですが、手動でしかできなかった作業をよりスマートに自動化したり、木目細かくできたりすることができようになったのがスクリプトと言えるかもしれません。

そうは言っても開発の現実は思わぬ方向に動いているように見えます。例えば、ノーツの文書は他の文書と連携がほとんど自動的には取れないので、リレーショナルデータベース(RDB)のようにあるフィールドを変えて、それを参照するレコードの内容を自動的に変えるようなことはできません。そこでスクリプトで文書を保管するときに、文書上のあるフィールドが変更された場合に、関係する文書をデータベースから探しだしてその変更を反映する。良いプログラマーほどスクリプトを使ってこういったプログラムを編み出してくれます。確かに実現できるでしょう。ただこのようなことをRDBはシステムで半ば自動的にやっているのに、ノーツでは開発者が全部書き込まなければならないのです。確かに何百文書程度であれば問題なく動くでしょう。ところが千文書を超えさらに文書が増えていくと、たちまちそのパフォーマンスは低下し使いものにならなくなってきます。いくら速くしてくれと言われても成すすべはありません。何故ならそれはノーツが想定していない仕組み、つまりノーツの型破りだからです。数十件や数百件であればそれは前回お話した経験に基づいた限定的な型破りで有効と言えるでしょう。しかし数千件を超える本格的なものではノーツでは使い物にならない型破りなのです。

『スクリプトと関数式とどちらを使えばいいでしょうか?』と尋ねられたときに、私は1つの基準として次のようにお話しすることがあります。『まず関数式だけでプロトタイピングしてみませんか。あとは本番開発でスクリプトを使ったりして本格的なものにしましょう。』と。この話のねらいは、できるだけノーツの型を守ってもらうためには、できるだけ型破りをし難い環境、つまりそれが関数式だけでプログラミングすることだということです。関数式だとよほどのことをしない限りノーツの部品を飾りなく素直に使うことくらいしかできず、プログラミングの量は僅かになります。あとはそのプロトタイプをベースにして、ユーザーとのやりとりをしながらある程度必要な自動化の機能や飾りの機能を本番開発でスクリプト開発するというものです。もちろんはじめからスクリプトでなければできないアプリケーションもあるでしょう。でもそれは多くのノーツアプリケーションの中では、例えばRDBの複雑なアクセスを含んだりするようなものなど、ほんの一部であることがほとんどです。これらは十分経験のある開発者にやってもらえばよいのです。

『ノーツでは投資対効果が平均で400%も期待できる』というようなふれこみで特に欧米のビジネスの世界で爆発的な人気を獲得したノーツ。その根本にはリエンジニアリングなどの効果などもあるでしょうが、それを支える技術的な背景としては『開発が短期間でその量も少ない』というノーツの道具としての特性があったのです。関数式のプログラミングのし難さは逆にプログラムを書かせないという不幸中の幸いとでも言える逆説的な効果があった、というのは言い過ぎでしょうか?

ノーツの展開が本格的に進んでいるお客様ではみるみるうちにデータベースの数が増え、メールを除いても全ユーザー数と同じくらいの数のデータベースがあるというのも珍しくはありません。それはまさにビジネスの情報共有ニーズの反映でもあります。これだけ増えたデータベースを一つ一つ昔のアプリケーション開発のように大量のスクリプトのプログラミングで開発していたら、そのメインテナンスはいったいどうするのでしょう。関数式に限らずスクリプトであっても同様に少ないプログラミングのメリットはやはりあるはずです。『プログラムをできるだけ書かないことがノーツ開発者の美徳』という文句を支持してくれる開発者はどのくらいいるでしょうか? これは決して開発者だけのためでなく迅速なアプリケーション開発と提供という本来ユーザーが望んでいることへの答えであることも重要な観点ではないでしょうか。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=339001
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第7回 関数式かスクリプトかそれが問題だ
publish-date=05112008