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

第7回 関数式かスクリプトかそれが問題だ

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

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

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

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

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

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

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

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

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

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


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

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