SE関のノーツ/ドミノ徒然草: 第18回 自由と束縛の中の開発

前回のユーザー教育についての話の中で、それぞれのアプリケーションであるデータベースの雰囲気を同じようにする標準化のような考え方も必要かもしれないということについて触れました。今回はそのデータベース開発の標準化について考えてみましょう。

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

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



2005年 8月 15日

ノーツを展開すると、みるみるとデータベースの数が増えていくのはどこの会社でも見られる典型的な姿です。先日、ノーツをかなり使い込んでいるお客様のところにお邪魔してアプリケーションのデータベースの数を数えたところ、なんとメールデータベースを除いても、ほぼユーザーの数だけデータベースが存在していました。ユーザーが万単位のところですからこれはたいへんなことです。

そんなにたくさんのデータベースが各々の開発者の自由なアイデアで作られているとすると、ユーザーにとってはかなりの負担かもしれません。例えば小さな例ですがウィンドウを閉じるためのアクションボタンが、あるものは左端に、あるものは右端に、そしてあるものはなかったりしたらどうでしょう。最近よく見るデータベースとして、初心者向きと考えてか、ほとんどのオペレーションを何枚もの全画面のナビゲーターを行き来することで実行するものがあります。最初の何回かは便利と思われるのですが、ユーザーが慣れてくるとかなりしつこく面倒に感じるものです。また些細なことと思われがちですが、画面のフォントや色などもデータベースによって極端に違うとユーザーにとっては疲れてしまいます。

一つ一つのデータベースは開発者のアイデアや好みで良かれと思って作られているのでしょうが、ノーツのようにアプリケーションがかなりの数になり、ユーザーは日常それを渡り歩くような場合はかえってその自由なアイデアが仇になるでしょう。このようなデータベースの操作性や見た目についてのある程度の標準化、名づけてGUI標準とかLook&Feel標準がノーツの展開の範囲、つまり会社のような単位で必要になると思えます。

どのデータベースを開いても標準的なボタンの配列は予測でき、フォントや色の感じ、そして操作性の感覚まで似ているとなると、小さな積み重ねではありますが、あきらかにユーザーの生産性の向上につながるでしょうし、さらにユーザー教育も一回教えれば済むことが多く負担も減ることでしょう。これは丁度、車がどんな車種であっても大抵すぐに慣れて運転できるという世界と同じようなものです。

さて開発の標準化というと、大型の汎用計算機の世界では生産性向上と称してコーディングの細かな名前標準や書き方標準などが思い出されます。複数の開発者が、互いのプログラムを長い期間に渡って参照する必要があるような大きなシステムを構築する場合は、確かに開発の標準化は開発の生産性、メインテナンスの効率化に関して必要に思えてきます。

ノーツに関してはあまりそう言った標準の話は聞かれません。確かに大きなシステム構築と違い1つのデータベースが1人の開発者によって開発されるのが普通で、しかもそんなに膨大なコードを書かないノーツのデータベースでは、そう言った標準は必要ないかもしれません。ただノーツのリリース4以降LotusScriptの採用により徐々にライブラリー等によって他人のプログラムコードを利用したりすることも増えました。またプログラムのコード量も以前に比べてかなり増えていてメインテナンスの労力も無視できなくなりつつあります。そろそろ先人の知恵に習い、ノーツのプログラミング上の名前標準や書き方標準などを決めて利用してもよいのではと思う今日このごろです。

まあ本格的なプログラミング標準といったものでなくとも、データベースの設計変更をしても他のデータベースに影響を与えないようにするビューなどの別名の採用、また他のデータベースから参照されたりするときの効率のよいビューの定義などパフォーマンスを良くするアイデアなどはそろそろ整理して標準化としたいところではあります。今後はこのようなプログラミング系の標準の必要性はノーツの世界でも増えることでしょう。

さて標準ということで、ユーザーにメリットのあるGUI標準、そして開発者にメリットのあるプログラミング標準と、その必要性は結構ありそうです。これらは言わばデータベースの設計の標準です。ではデータベースの中身である文書の標準というのはどうでしょう。会社によっては社内で流通する文書には内容によってセキュリティーレベルを社外秘、部外秘などといくつか決めているところがあります。また社内で流通する文書には必ず、発信人の名前と部署、そして作成日などを必ず書くべしとしているところもあります。これは言わば文書の書き方などというエチケットを超えて、文書の中身の扱い方、つまり業務の情報をどう扱うべきかというビジネスの本質的な問題に関わる標準化です。

ノーツの文書も紙のときと同様にビジネス文書ですから、当然同様の社内文書標準を取り決めることで、貴重な業務の情報を効果的にかつ安全に取り扱えるようになると思われます。ただ紙の上でのルールをそのまま持ち込んでよいか、情報共有が目的なのでその目的に沿った今までのルールの緩和というようなことも当然考えなければならないでしょう。例えば『必ず上司の印鑑があること』なんていう紙のルールは場合によって是非取り除きたいものではあります。

設計から文書までいろんな標準化の可能性と必要性があることが見えてきました。元をただせばユーザーや開発者の生産性や会社としての利益などに貢献するためのものですから、ぜひともそれらを決めたら守ってほしいものです。ただ特に開発者が絡む部分では、標準などに縛られずに自由に自分のやりたいようにプログラムしたいと思うのが開発者の悲しい性ではあります。ましてここはどんなフォントを使って、ボタンはここに何を置くなどとやられたら、開発者はどうも息苦しく感じてしまうかもしれません。

欧米のノーツ展開を見るとかなり束縛された標準というものが、ものすごい文書の数でまとめられている会社があります。確かにそれを守ることの利益はありそうなのですが、そこまできっちりやられると日本では開発者からどうも反発されてしまいそうです。実際すでに展開がはじまっているところでは、データベースの標準化の話を出したところ開発部門から猛反発を受けたという話もあります。

あいまいな状態がよしという日本人にとっては、何か厳しいルールを振りかざされると反発してしまうのは日本的な反応かもしれません。そんなとき、例えば標準に沿ってディスカッションや掲示板など幾つかのテンプレートデータベースを開発し、それを開発者やユーザーの教育に自然に使っていくなどという方法は、じわじわと"そんな雰囲気のデータベース"が標準という風習のようなものを作りあげる、日本的な一つの試みとして面白いかもしれません。

束縛のない自由が好きなのがプログラマー。プログラマーあがりの私にも確かにそれもよく分かります。ただユーザーや他の開発者のことを考え、一歩深い意味での"良いプログラム"は標準を守った上でのさらなるアイデアが加わったものだというのも、より上級のプログラマーとしては必要な認識でしょう。

ノーツの展開が進み、かなりのデータベースが存在するノーツドメイン。さて、さらなる進化したノーツ文化を育てるためには、この標準化という課題はやはり超えなければならない大きなハードルであるような気がしています。

参考文献

コメント

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=338992
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第18回 自由と束縛の中の開発
publish-date=08152005