連載：グループウェア徒然草（9）

グループウェア的アプリケーションのシステム化（下）
「どこまでをシステム化するのか!?」

関 孝則
2002/3/16

　前回は、グループウェア的アプリケーションの持つ不定形な要素からなるあいまいさと、それを把握するための要件定義の困難さ、そして方向性を見極めるための経営的視点での目標について考えました。さて、これからシステム化となるわけですが、やはりここでもグループウェア的な特徴が随所に見られます。

■システム化のポイント

　グループウェア的アプリケーションのシステム化の観点で、基幹の業務と異なる点といえば、「いずれ早いうちに変更される可能性がある」ということではないでしょうか。もちろん、ワークフローにおける出張精算などの総務／経理系の処理は、そうは変わらないものです。しかしグループウェアで扱うような営業報告書／業務報告書のたぐいは、関連するビジネスの変化や多様化により、その内容や関連する人の範囲が変わってくるものです。そのような観点から、仕様変更に強いアプリケーションがグループウェアでは求められることが多いでしょう。基幹系に比べ、その数、その変化の度合いはかなり高いと思われます。アプリケーションがかなり作り込まれており、変更が容易でないとしたら、それはビジネス・スピードにもかかわる、由々しき問題のように思えます。

　もう1点、グループウェア的アプリケーションのシステム化でポイントとなりそうなのは、「どの例外や慣例までシステム化するか」という観点ではないでしょうか。前回も述べたように、グループウェア的な社内業務は、もともとその定義がややあいまいな部分があります。これを、きちんとユーザーにインタビューし調査することで実態を明らかにすると、かなりの例外や慣例がその業務を取り巻いていることが分かります。これらをすべてシステムとして扱うとなると、そのアプリケーション自体はかなりの複雑度を持つことでしょう。

　もちろん、例外や慣例をすべて切り捨てるというのでは困ります。その中で業務として本質的に必要であるものは、きちんと取り込む必要があるでしょう。また、システム化はその多様さから困難であるものの、人間が介在してその処理をできるようにしておくという部分もあるでしょう。さらに、本質的に業務としてふさわしくない部分は、関係者の合意を得て切り捨てることも必要となるでしょう。

　このように、一概に例外や慣例といってもその扱いは慎重に分類したうえで、最終的には、業務の目標や今回のシステム化の狙いとを照らし合わせ、判断しなければならない部分でしょう。

Illustration by Sue Sakamoto

■人手を残すシステム化

　変更に強く、いろいろな見えないプロセスもシステム化され、例外や慣例への自由度を残し、さらに本質的でない部分は排除する。こんなシステム化とは、どんなものなのでしょう。ワークフローで簡単な例を挙げておきましょう。よく稟議的な申請で、複雑な業務の流れを要件として挙げられることがあります。例えば、途中の承認者の判断で新たなフローを動的に追加し、別部門の人の意見を求めるという要件が出ることがあります。また、根回し的に文書の概要の部分だけでも電話でほかの人に伝え、コメントをもらうことが行われたりするため、文書の概要のみ指定した人に送り、その返事を元の文書に追加する……という仕組みを作るような要件も挙がってきたりします。

　まじめなエンジニアとしては、これらをフローの途中でも変更できるような設計にしたり、その業務文書の概要をメールで送信でき、かつ返答を自動的に業務文書のコメント欄に追加するような仕掛けを考えることでしょう。場合によっては大掛かりなものとなります。もちろん、業務としてそれらを本質的な流れと考えれば、システムとして実現すべきでしょう。ただ、承認者によってやり方が微妙に異なり、必ずしも業務の本質的な部分でなく、システムに取り込む方が業務の処理時間を増大させると考えれば、承認者にはいままでどおり電話ベースで関連する人に相談してもらうということにできます。

　元来、紙という自由度のある便利な媒体がその業務の道具であることにより、情報の伝達に物理的な制約があったとしても、そのものを見せる、場合によっては一部コピーして見せることで、ほかの人に容易に内容を伝えられました。フローの順番も、人間の判断で自由に変えることができます。しかしシステム化することによって、他人には容易に見せることができなくなり、フローの順番も極めて固定的にならざるを得なくなったのです。このように考えれば、ほかの人に意見を求めるために、汎用的で補助的な仕組みとして、その文書をメールで転送する機能だけでも付け加えるというのが、1つの選択肢になるかもしれません。こうしておけば、将来いろいろな人に意見をもらうときに、たとえ関連会社の人にでも送付して意見をもらうことができます。また基本のフローに変更がない限り、アプリケーションはそのまま変更なしでいくことができます。

■本質的なシステム化

　また、ある業務では、文書の回覧ルールで「次に回す人をその直前の人が決める」というようなものがあります。しかし、よく観察すると、ほとんどの場合、あるグループには全員にその文書が回っているというようなことがあります。こうなると、紙でコピーがなかった時代の名残としかいいようがないかもしれません。そこで、文書を単に蓄積するアプリケーションの形にして、新しい文書の追加時にはメールなりの方法でグループ全員にそれを伝える、というような根本的なプロセスの変更も考えられます。この例などは、大げさには大胆な業務改革といえるかもしれません。

　システム化というと、「すべての現行の業務手順をコンピュータ上に実現するのがベスト」だと思い込むことが、システム屋の陥りやすい考え方かもしれません。どこを本質的にシステム化しておいて、どこをしないで開発コストを下げるか、またどこをしないことで将来の変更に堪え得るようにするか、さらには業務自体を本質的に見て大胆に変え、より業務のスピードや価値を高めるか……こういった視点が、あいまいさの中でグループウェア的アプリケーションに期待されることではないでしょうか。

■プロトタイピングの功罪

　さて、システム化する範囲とやり方が決まりました。こうなると、具体的にプログラミングなどの開発作業に入るわけです。昨今はどのグループウェア・プロダクトでも、大抵スクリプト言語などの簡易開発環境を持ち、さらに業務画面を早いうちからGUIでグラフィカルに見せながら開発を進める「プロトタイピング」ができます。

　これ自体は開発生産性の劇的向上を期待でき、何ら悪いことではないですが、どうもこうなったことによって、副作用的な側面もいろいろ出てきたのが現実ではないでしょうか。例えば、すぐに目に見えるものになっていくことから、たとえ後ろのロジックがなくとも、強引なユーザーにどんどん開発期限を短くされたり、あるいはユーザーからのフィードバックが「画面の色」「ボタンの形」「画面の遷移」といった見た目ばかりになりがちです。

　人間の視覚は、言語より何倍も情報量が多いといいます。GUIをユーザーに頻繁に見せるといった行為は、特に見えるもののみに自然と注意を引かせてしまい、本質的な業務の中身に関する議論が相対的に減ってしまうということが起こりがちです。本来、業務の流れ、処理の内容などもグラフィカルに表現し、レビューする仕組みがあるといいのですが、この分野に関してはやはりドキュメントに頼りがちになります。

　また開発者の心理においても、一度組み上げた画面やその仕掛けはなかなか一から作り直すというのもおっくうになります。ユーザーへのGUIの影響と同時に、開発者にとっても、見たものが自分の頭の中で支配的になる傾向があるのではないでしょうか。そして、簡単にロジックが組めるために、先ほど指摘した、「そのプロセスをシステム化すべきか、どう変えるべきか」という課題に対して、耳をふさぎがちになるのではないでしょうか。

　こういった副作用を避けて新しい道具をうまく利用するために、ユーザーのGUIのレビューをかなり後半に回すとか、わざと張り子のとらで中身ができていないことをアピールするとか、開発プロジェクトを進めるうえでいろいろと工夫をすることも必要でしょう。

■グループウェア的なものへの理解

　業務の不定形さ、あいまいさ、変化への許容、業務改革、簡易開発言語、プロトタイピング……これらは昨今のビジネス・スピードの高速化に伴い、あらゆるシステム化に付きまとう問題かもしれません。しかし、これらがより顕著な特徴として出ているのが、いままで手付かずで十分でなかった、ホワイト・カラーの生産性向上に大いにかかわる、不定形な部分のある社内業務、つまりグループウェア的アプリケーションではないでしょうか。

　一方、特に簡易開発言語やグループウェアの基盤により、その上でのアプリケーションのシステム化は、全体のシステム化の作業の中で、相対的に技術的な作業の量を減らしているように思えます。例えば、1人当たりのプログラミングのコード量は基幹のシステムに比べ、やはり少なくなっていることでしょう。このことは、グループウェアにかかわるシステム・エンジニアと呼ばれる人の守備範囲が、上流工程はもちろんのこと、より業務の中身にもかかわるチャンスが増していると思えます。システム・エンジニアにとって、グループウェア的なものの理解とビジネスのエンジニアとしての意識は、今後も強く求められていくのではないでしょうか。

筆者プロフィール

関 孝則（せき たかのり） 新潟県出身。国産コンピュータメーカーでの経験を経て、1985年IBM藤沢研究所へ入社。大型計算機のオペレーティングシステムなどの開発、IBMの著作権訴訟、特許権訴訟の技術調査スタッフなどを担当。1994年から日本IBMシステムズ・エンジニアリングでロータスノーツの技術コンサルティングを統括。代表的な著書に、リックテレコム社『ロータスドミノR5構築ガイド』（共著）、ソフトバンク ノーツ／ドミノマガジンの連載『ノーツ/ドミノ・アーキテクチャー入門』、日本IBMホームページ上のWeb連載『SE関のノーツ/ドミノ徒然草』など。 メールアドレスはts@jp.ibm.com

「Master of IP Network総合インデックス」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）