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

グループウェア展開は会社文化との遭遇

関 孝則
2001/11/20

　グループウェアの展開は、すでに多くの企業で一段落した観があります。展開に携わった人は、当初考えていたより多くの課題があって、それらを乗り越えてきた過程を思い起こすことができるでしょう。今回はそれらの展開から見えたものを振り返り、新しい展開への助言や、すでに展開した場合の見直しへのヒントなどを考えてみましょう。

■会社の文化との遭遇

　グループウェアに限らずコンピュータのアプリケーションを展開するときは、「ユーザーが過去にその業務をどのように実施していたか」という現実に直面します。「いまはこうしている」という知られざる事実に始まり、「こんなことはできない」というシステムへの拒否反応まで、さまざまなユーザーの声に新たな発見をするとともに、ある面でのせめぎ合いはつきものです。グループウェアではその対象が社員のほとんどを相手にするため、特定のアプリケーション展開とは比べものにならない、多くのさまざまな現実に直面することは容易に想像できます。

　グループウェアが扱うデータは、会社で流通する文書そのものですから、そういった社内文書のいままでの形式や手続きをそのまま電子化することがアプリケーション要件としてあがってきます。また対象となる社員もほぼ全員というケースがほとんどですから、ユーザーの声を聞けば聞くほど、それぞれの組織のやり方の違いなどが課題となって浮かび上がってきます。それらは歴史のある企業であればあるほど、大きな企業であればあるほどさまざまな蓄積があり、グループウェアの展開はまさに会社の文化との遭遇といってもいいでしょう。

■誰が働いているのか

　もう少し具体的な例を見ていきましょう。まずグループウェアのディレクトリを設計するために、システムを使用するユーザーのことを考えなければなりません。「全社のコミュニケーション基盤としてのグループウェア」といった位置付けをすると、その対象は当然ながら社員全員となりますから、人事データベースからグループウェアのディレクトリにデータを読み込めばよいだろうとすぐ思い付きます。ただ、実はこの社員という概念が、最近では極めてあいまいなものとなっています。もちろん人事データベースに入っている人が社員ですが、「会社の中で働いている」という広い意味では、正社員以外のさまざまな人が働いている現実が浮かび上がってきます。

Illustration by Sue Sakamoto

　補助的な事務や秘書業務をするための派遣社員、システム設計など委託したプロジェクトのために働いている協力会社の社員、設計など高度な専門家を一時的に会社の中枢業務に入れるような契約社員、店舗展開でアルバイトでも店長を任せるようなアルバイト社員……一昔前では考えられなかったいろいろな形態の社員が会社の業務に携わっています。このような傾向はいろいろな業務のアウトソース化に伴い、今後も強まっていくことは確実でしょう。

　「全社のコミュニケーション基盤」といった理念を挙げれば、当然これらの人々もグループウェアのユーザーとする必要性があるでしょうが、どうやって全員を把握するかという課題が浮かび上がってきます。人事データベースにこういった広い意味での社員を登録できるようにしようという動きも見られますが、こと厳格さを求められるデータベースだけに、現場で働いている人の実態が先行するのが常です。グループウェアのディレクトリの設計と運用には、人事データベースのデータ利用と逐次登録といった、いろいろな仕掛けが必要となってきます。

■情報ってどう流れているの？

　文書の流れという側面ではどうでしょうか。一番シンプルな文書としては、掲示板のようなものが考えられます。いままでどこかに掲示または回覧していた文書、これらにはその書式、また公開するための手順や承認など、さまざまなしきたりが存在するものです。いろいろな文書をすぐに掲示する文化を持つ部署、一方でほとんどの文書を管理職を起点に回覧という形で流す部署と、大きな会社であればいろいろな流儀が存在したりするものです。

　また文書のセキュリティという観点でも、ちょっとしたお知らせでもやたら部外秘という“はんこ”を押したがる部署、また関連していそうな部署にもともかく積極的に文書を回すセキュリティをかけない部署などさまざまです。このようなセキュリティに対する考え方は、そのまま情報がどのように流通するかを決める大きな要素となります。

　掲示板や文書ファイルなどのような単純なアプリケーション1つであっても、部署により考え方や使い方が異なり、セキュリティ機能をかなり細かいレベルで実現できるようなものを要求されたり、それまで掲示板だと思っていたアプリケーションが、回覧のためワークフロー・アプリケーションに化けてしまったりもします。「可能な限りオープンなコミュニケーション基盤」といった目標を掲げオープンな掲示板などを考えてみても、その中身を充実させるには、すべての社内文書の原則オープン化や、部外秘文書の届け出制など、何か大原則のようなものが必要と感じられます。

■組織ってなんだろう

　またセキュリティの話でよく出てくるのが、「この掲示板は業務の重要な情報なのでこの組織だけにオープンにしてほしい」といった組織ごとのセキュリティです。昔からの考え方では、業務は組織ごとにまとまって行い、当然その業務に必要な情報は組織ごとに開示されてきました。

　ところが、そんな組織ごとのグループのセキュリティの仕組みを作っても、すぐに「別の組織の何々担当の人もこの業務に深くかかわっているのでそのグループに入れてほしい」とか、プロジェクトと称して「複数の組織の担当の人をこの期間だけ入れてほしい」とか、さらには「契約社員のこの人を入れてほしい」など、さまざまなダイナミックな要求が出てきます。システム的に人事データベースの組織の情報を基にセキュリティのグループを実現しても、すぐにそれ以外のさまざまな要求が表れ、実は正式な組織だけのグループはほとんど使われなくなる、というような事態にもなりかねません。

　いままで当たり前だと思った組織というグループの意味。どうやら、会社で働いている人の変化や働き方の変化で、随分意味が変わってきているような気がします。セキュリティにおけるグループの在り方は、かなり柔軟に考えておく必要がありそうです。

■権限があるのは誰か

　グループウェアの展開でつきものなのが、ワークフロー・アプリケーションです。そして、そのワークフローにつきものなのが“承認者”という考え方です。普通は組織の管理職がその権限を持つわけですが、その人が不在のときにだれが代行するかというのは、決まっているようで実はあいまいだったりもします。その管理職のさらに上の管理職というのが普通のようですが、逆に不在の管理職の組織の中で一番職位の高い人が権限を代行する場合もあります。

　一見明確なルールのようにも見えますが、兼務を持つ管理職だと、2つの組織のどちら側の上の管理職にその権限があるかや、また組織内に一番職位の高い人が2人いたらどうするかなど、かなりあいまいさが残ります。実際は、それらのあいまいさをうまく業務で生かして、だれがいなかったらだれと、承認をもらう側が業務のスピードアップのためにうまく範囲を広げたりするものです。

　ワークフローのシステム化を行う際に、承認の権限者を現実より狭く設定してしまうのはよくあることです。実際、組織によって微妙に違ったりもしますから、やむを得ないこともしばしばです。ただ、「承認プロセスの迅速化」などという目標があるとすれば、システム化のために「承認権限者がすべて出張中や休暇中で承認が取れない」という事態はやはり避けなければならないでしょう。昨今いわれているような「ビジネスプロセスの簡素化」などに沿って、思い切って承認が不要と思われるところはなくすとか、ある職位以上の人は全員承認できるなどして、後はだれが承認したかの記録で妥当性を確認するとか、大胆な設計にする勇気も必要かもしれません。

■こうありたい会社のデザイン

　上で挙げたような例は、まさに会社がこんなふうに動いているという事実です。そしてそれらは会社の文化というような、いままでの暗黙のやり方と密接に結び付いているものです。それらはまた組織ごとに微妙に違うという性質、さらにいまも変化し続けているという性質など、難しい側面を持ちます。

　グループウェアの展開は、全社の情報の流れを扱うという性格上、まさにこれらを嫌というほど思い知らされる大変な仕事です。いままでの情報システムはどちらかといえば、「既存の業務をより効率的に」というように、現在の業務のやり方がすべての基準だったように思えます。しかし、全社展開のグループウェアでそれだけのアプローチを取ると、過去のやり方を固定化するような、会社の中で起きている変化を止めてしまう方に働くかもしれません。

　どんな人が、どんな働き方をして、どのように情報をやりとりしていくべきなのか、こういった会社の将来の姿を見据えた視点が、グループウェアの展開には必要となるでしょう。グループウェアをこれから展開する会社、すでに展開した会社、いずれにしても会社のこうあるだろう、そしてこうありたいという将来の姿を議論したうえで、それらを基点にして、グループウェアシステムの構築や修正を考えてみてはいかがでしょうか。

筆者プロフィール

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

「連載　グループウェア徒然草」

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