SE関のノーツ/ドミノ徒然草: 第38回 何がアプリケーション開発を長期化させているか

ノーツ/ドミノも最近はインターネットやイントラネットのアプリケーション開発プラットホームとしての色を強めています。そんな傾向もあってかアプリケーション開発は、勢い複雑なアプリケーション開発が行われエンドユーザーでやるというよりは情報システム部頼みか、または外部ベンダーへの依存を高めているのが現状でしょう。それとあいまって本来短期間で開発できるというふれこみのノーツ/ドミノのアプリケーション開発が、工数はさておき、多くのクライアント/サーバーのアプリケーション開発とそう大差のない期間かかったりもしています。今回はそのあたりの現実を少し考えていきましょう。

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

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



2004年 4月 11日

まずノーツ/ドミノのアプリケーション開発でも比較的時間をかけたほうがよさそうな分野はどのあたりでしょう。最近よく聞く基幹連携などはその一つかもしれません。厳密なデータ定義、データの正当性チェックのロジックの必要性、データ更新などのタイミングなど、ノーツ/ドミノと基幹系のシステムとのやりとりには細かくかつ厳密にならざるを得ない事情がありそうです。ノーツ/ドミノだから非定型なデータで、などと言うわけにはいけないでしょう。しかしよく考えるとこんな分野はたくさんのノーツ/ドミノのアプリケーションの中ではほんの一部であることも事実です。なのにあたりを見回すと開発が長期化しているものがたくさんありそうです。

長期化している開発をちらっと覗いてみると例えばこんな様子がみうけられます。一つはどんなアプリケーションを作るべきか、その要件がアプリケーションが開発されている途中でもどんどん追加や変更されていく様子です。特にノーツ/ドミノ上ではそのプラットフォームの性格上、今まで存在しなかったか、またはシステム化の考えられたことがなかった業務のアプリケーションを開発することが多いでしょう。この状況は確かにアプリケーション要件の定義をより困難にすることは確かでしょう。あげられた要件がその業務にとってどの程度本質的で、またどうしても必要なものなのかどうかなど、その判断はかなり困難になります。実際、要件のとおり開発してはみたものの使いはじめると、いらなかった要件、足りなかった要件など出てくるのは、業務の新規性から当然と言えば当然です。一方、アプリケーション開発の立場からは、いつまでも不安定な要件に対して、『動くものは随分前からできているのに』と愚痴が出てきたりします。

一般に要件の不確定さに対しては昔からプロジェクト管理的にいろいろなアプローチが試みられてきました。フェーズを区切って後戻りをしないようにプロジェクト管理するというようなウォーターフォールのアプローチは有名でしょう。しかし今まで存在しなかったか、またはシステム化の考えられたことがなかった業務のアプリケーションを開発するような場では、多少の効果は得られても不確実なことが多く最終的にユーザーに満足されるシステムになるには、そう厳密に管理するのが得策でない場合も多々ありそうです。

その他に長期化している開発でよく見られるのは、例えば繰り返されるユーザーインターフェースの変更です。『使い勝手が悪い』、『もっと簡単に入力できるように』というユーザーからのフィードバックをもとに何度も何度もユーザーインターフェースを変更するようなことがよくあります。中にはユーザーからの厳しい要求により、かなりアクロバット的に画面を切り替えたり、大量のコードを駆使したりするユーザーインターフェースなども見受けられます。そして場合によっては評価するユーザーが変わったために更なる変更が発生するような場合もあります。

もう一つ長期化している開発でよく見られる例として自動化の追求があります。ある文書のお客様データが変更されたら、関連する文書はすべて探して変更するとか、組織が変わったら過去の文書はすべて新しい組織で表示されるように変更するとか、文書の管理は人手がかからないようにすべて自動化するとか、自動化の追求はとどまるところを知りません。確かにLotusScriptでいろいろなロジックを書けるノーツ/ドミノでは、やろうと思えば力任せにプログラムを書いて実現できることがたくさんあります。

こうして見てくると、確かに開発期間の長期化はそれなりの理由があります。それがアプリケーション要件の可能な限りの実現、ユーザーインターフェースの使い勝手の追求、データの完全性や管理者の負荷軽減のための自動化実現と、すべてもっともな理由と言えるでしょう。これらは全て今までのシステム開発の実現すべき目標でもあったわけです。ではやはり開発期間の長期化は止むをえないのでしょうか。

『動くものは随分前にできているのに』、という冒頭紹介したアプリケーション開発者の嘆きは一つのヒントを与えてくれます。要件追加や変更がある前から、ユーザーインターフェースの改善をする前から、自動化をする前から、実はそのアプリケーションはユーザーが使える程度に動くものとして完成していたという事実です。たとえ要件をすべて満たさなくとも、インターフェースや自動化が不十分でも、もしその時点でアプリケーションをユーザーに使ってもらっていたらどうなのでしょう。

もちろんユーザーから『使いにくい』、『ここが使えない』、『こういう機能が欲しい』、といろいろな意見が出てくるでしょう。しかしそれでも彼らのビジネスの基本的ニーズを満たして使うことができれば、それらのマイナスをすべて帳消しにするだけのメリットがあるのではないでしょうか。その中から次に実現すべき本当の機能、また使いにくかったユーザーインターフェースへの慣れ、そして必要だと思っていた自動化機能の優先度の低さなどが明らかになってくる可能性があります。

実際、新規の開発などほとんどしないで、基本的な、または他のアプリケーションのテンプレートなどを使って、使いにくいまでも新しいアプリケーションを業務として利用している例もエンドユーザーによく見られます。ここには完成度は高いながらも開発期間のかかるアプリケーションよりも、完成度は低くとも基本的な業務要件を満たしている短期開発のアプリケーションの業務に対する大きな価値がうかがえます。

競争が激化するビジネスでは、その環境も同時に変化していきます。そしてそれに関連した業務自身も変化しつづけなければいけないでしょう。その変化のサイクルはややもするとアプリケーション開発の期間より短い可能性があるでしょう。『動くものはすぐできる』。80年代、表計算ソフトが情報システムの中で大きなセンセーションをもたらしたときも同じことが言えました。完璧なものより、すぐに使えるアプリケーションを作れる環境は本質的にアプリケーション開発のイメージを変えます。90年代、ノーツ/ドミノもまさにグループウェアという環境において新たなセンセーションをもたらしたと言えるでしょう。アプリケーション開発の長期化という現実の傾向に対して、もう一度原点を振り返ってみるのは決して無駄ではないでしょう。

参考文献

コメント

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=339100
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第38回 何がアプリケーション開発を長期化させているか
publish-date=04112004