レベル: 初級 Lotus テクニカル・セールス&サービス, ソフトウェア事業, 日本アイ・ビー・エム株式会社
2006年 01月 01日 ノーツの本格的なアプリケーション開発が進んでくると、必ずと言っていいほど出てくる要件の1つに、『RDB(関係データベース)で持っている人事データベースとノーツとの連携』というものがあります。確かに人事データベース（人事DB）には個人の名前にはじまり、その人の職位や上司、所属している組織、さらに上位の組織などあらゆる人事的情報が入手できます。これらはノーツのようなアプリケーションではいろいろな場面で利用できそうです。でも果たしてそれほど話は簡単なのでしょうか。今回はこの人事DBとノーツとの一見、便利そうな、でも危うい側面を持った関係について取り上げましょう。
 人事DBとの連携ですぐに思い当たるのがワークフローでの利用でしょう。次に誰にその処理をまわすか、また誰に承認してもらうかなどは人事DBの情報によって自動的に決められるという考え方です。多くの書類は自分の上司に処理がまわり、そしてさらにその上司と、まさに人事DBの組織の情報をたどるように処理が流れるのが大半ですから、その考え方もうなずけます。
また情報共有という観点で、文書データベースや報告書のたぐいのデータベースが、ややセキュリティーレベルの高いものの場合、組織の単位でセキュリティーをかけたいという時にも人事DBの情報が使えそうです。ノーツのグループ文書をあらかじめ、組織の単位ごとで人事DBをもとに自動的に更新していけば、それらのデータベースのセキュリティーは個人単位でACLなどを設定するより、そのグループでACLをかけることで、人事異動があってもまったくの手間いらずです。これも便利そうです。
 このような観点で多くの企業が、ホストなどにあるRDBの人事DBをノーツのデータベースに取り込む仕組みを構築しようとしています。夜間にバッチ的にスクリプトやNotesPumpなどでRDBのデータをノーツに反映させる。それを元にグループ文書を更新する。SEとして技術的にもなかなか面白い対象です。しかし実際に使い始めるといろいろな問題がでてきます。どうしてでしょうか。
まずすぐに気づくのが人事DBが結構、不確かなものであることです。まずはその更新のタイミングです。いくら毎日RDBから人事DBを取り込んでも、人事DB側のデータ更新がなかなか追いついてくれません。実際にはX月1日に異動になった管理職でも、それが人事DBに反映されるのに良くて2日、普通は1週間、3週間などという大企業も珍しくはありません。つまり人事DBはリアルタイムではないのです。人事DBはどちらかというと給与計算などのバッチ処理向きの情報であることが多いようです。
さて人事DBの更新が遅いだけなら、更新を早めるように手続きなどを変えることができるでしょう。しかし実際にはそれだけではなかなか解決しない問題があります。例えば赴任などの問題です。X月1日に異動になった支店の店長が実際にそこに赴任するのは1週間後であることもあります。また最近では、本社の人事部は部までの単位は決定するけれども、それ以下の課などの組織は本部や事業部などが決定して、後に人事部に報告して決まることもあります。いわゆる人事の分権化です。さらに、重要な業務に従事している契約社員の登録や更新の問題、組織であって組織でないようなプロジェクトの存在など、不確定で人事DBには実態が反映せず、重要な役割を担っているものは随分あります。
このように多くの企業の人事DBはバッチ的であり、実際の人の動きとはどうしても時間差や内容の差ができてしまうのです。このような情報をもとにワークフローや情報共有のデータベースを制御するとどうなるか。人事DBが実態を反映するまで最悪の場合、仕事がストップしてしまうでしょう。人事DBとの連携によって危うくされているノーツのアプリケーションの姿がそこにあります。
さて仮に人事DBがかなりよく実態を表している存在だったとしましょう。それと連携してアプリケーションの動き全てはうまく行くでしょうか。グループは組織単位でうまく作られて、自動的に更新されます。データベースをユーザーが作成すると、すぐにセキュリティーに使える組織ごとのグループがあるのです。一見かなりよさそうです。でもそこにはどうももっと危ういものが存在するように思えます。
ある小さな企業でノーツを全展開しました。もちろん人事DBと連携した課などの組織の単位でグループ文書を自動更新しています。課などの単位で業務スキルの情報共有のためにデータベースを推進したところ、あまり目的を明確にしていなかったことも手伝って、ある課ではデータベースを全社に公開しているのに対して、ある課では課のグループ文書で完全にセキュリティーをかけられました。データベースの推進者は、全社の共有化が目的だと言ってそのセキュリティーをはずしてもらおうとしたのですが、『課内の情報で他では必要としないもの』とか『一部はセキュリティーレベルが高い』などと言われていっこうに応じてもらえません。これでは"情報共有”ではなく”情報閉鎖”になってしまいます。
もちろんグループ文書自身の存在が悪いわけではないでしょう。情報共有の意図と目的を明確にせず展開した推進者の落ち度かもしれません。ただどうもその課の人と話すと『外からはなんとなく見られたくないから』、といった漠然とした理由がうかがえます。何かそうした昔ながらの感覚を、人事DBと連携したグループ文書によって助長したような気がしています。言い換えれば組織のセキュリティーをかけるために便利すぎる仕組みを提供したような気がします。
先日雑誌の記事でこんなものがありました。『営業情報も個人データも出張旅費の清算や受注データなども含めて社員2万人に開示することで組織のフラット化を進め、経営効率の向上を目指す』。元々情報共有というのは組織というような固定的な単位でしか共有していなかった情報を、組織の枠を超えて共有し相乗効果を狙おうとするものではなかったでしょうか。日本は大部屋制度、毎日の朝礼、飲みニケーションによって組織内の情報共有はかなりされてきたという指摘もあります。それ以上の情報共有はもはや組織という枠組みをとることしかありえないでしょう。しかしそのような認識、広くは文化のようなものが共有されていない状態では、ノーツという情報共有がしやすいインフラに、人事DB連携などでのセキュリティーのかけやすい仕組みは、まさに諸刃の剣とも言える仕組みでしょう。
いかかでしょうか。リアルタイム性が乏しく、会社内の人や組織の状態を的確に表していない人事DB。それと連携したばかりに正確さやビジネスの連続性を危うくされたノーツ。おそらく一つの流れは、人事DBがノーツのようなホワイトカラー全員向けのシステムへの適用をきっかけに、より的確な人的資源のデータベースとしての中身とリアルタイム性を問われていることです。実際グループウェアでの利用をきっかけにして人事DBの再構築に向かっている企業の噂も耳にします。
もう一つは、ある意味では現実に目指すビジネスの形を実現していない組織を表現している人事DB。それと連携したばかりに古い組織やビジネスのやり方を暗黙のうちに助長して、情報共有という大義名分を危うくされたノーツ。これに対しては、組織自身がフラット化などの新しい流れを早く反映するか、または組織にとらわれず、情報共有の文化を早く浸透させることが問われているように思えます。
人事DBという古い組織や仕組みを代表するものと、新しい仕事の仕方を代表するノーツ。2つの背景が異なる道具だては、それを使って新しいビジネスのやり方をめざすユーザーへの試金石のようなものかもしれません。この両者の危うい関係はまだまだ続くように思える今日このごろです。
参考文献
著者について  | | | Lotusテクニカル・セールス&サービス, ソフトウェア事業, 日本アイ・ビー・エム株式会社 |
記事の評価
| 
