
連載:グループウェア徒然草(7)
システム環境の変化に堪える
ディレクトリ
関 孝則
2002/1/10
前回(第6回「グループウェア展開は会社文化との遭遇」)、グループウェアのディレクトリを設計するうえで、意外にも、人事データベースがうまく利用できない側面があることを紹介しました。今回はそれをもう一度掘り下げて考え、グループウェアのディレクトリを取り巻く、今日の在り方と明日の姿を描いてみましょう。
■グループウェアのユーザーは誰か
「グループウェアのユーザーは誰か」という問いに対して、全社のコミュニケーション基盤という位置付けを考えれば、「全社員がユーザー」というのが自然な考え方です。ただ「全社員とは誰か」という問いを発すると、昨今の企業では実にさまざまな解釈が存在します。これは、前回指摘したとおりです。
長期の雇用関係を結んでいる正社員。短期の契約で、ある決まった仕事をこなすアルバイト的社員。同じように短期であっても、専門的な能力を買われて、デザインや設計など会社の中心的業務をこなす契約社員。さらに社員ではないものの、会社の業務を一部またはかなりの部分にわたって委託して、まさに正社員と同じように働く関連会社の社員。最近では、必ずしも資本関係がなくとも、かなりの業務を任せてしまうアウトソーシング化の流れも顕著です。
このような会社で働く人の多様化の傾向は、見ている限り、強まることはあっても弱まることはないといえるでしょう。このことが、グループウェアのような全社員のためのシステムのディレクトリを考えるうえで、実に悩ましい問題となってきます。
■ディレクトリは人事データベースから?
![]() Illustration by Sue Sakamoto |
このように複雑化、多様化した会社で働く人の実態は、グループウェアのディレクトリのメンテナンスという課題をより複雑にし、当然のことのように自動化や半自動化によるメンテナンスコストの削減にシステム設計者を駆り立てます。そこで出てくるのが、社員が登録されているデータベース、人事データベースとディレクトリを連携させるという仕組みの構築です。
しかし、この人事データベースはルーツをたどれば、もともとは給与を算定したり配布するための元帳であり、正社員のリストでしかありませんでした。そのため、その更新は月次がベースで、リアルタイム性に関しては最近改善の兆しがあるものの、しょせん数日という単位でしかありません。
一方では、人事の分権化として人事権自体が本社の人事部ではなく各部単位までに落とされて、部内の組織変更などは、実施後に数日たってからでないと人事部に集まらないという事態も生じています。このことは、契約社員の新規雇用などには顕著に表れ、契約してからかなりたたないと、契約社員向けの人事データベースには登録されないこともあり得ます。
さらに、関連会社の社員についてはどうでしょう。それら広い意味での社員は、所属する会社が当然別ですから、いくら深い業務関係を持っているとしても、人事データーベースに登録するという考えには至らないことは明白でしょう。しかしながら、会社の業務をこなすうえでコミュニケーションの必要性から、それらの人もユーザーとして扱うべき側面は否定できません。
■自動化とビジネス環境の変化
このような人事データベースの限界を知ってか知らずか、ともかくできる範囲でディレクトリを自動メンテナンスしようという取り組みが常に行われています。ディレクトリのメンテナンスコスト削減のため、人事データベースとの連携というアイデアは、システム設計者の効率化への追求という点では大変評価されるべきものです。しかし、ふと現実を見ると、ビジネス環境はどんどん変化し、会社で働く人という社員の概念はあいまいになり、さらに会社という概念もアウトソーシングなどの新しい考え方の前では、その定義を考え直さなければならない事態となっています。
コンピュータ導入効果の代名詞でもあった観のある「自動化」という言葉は、「数カ月後にアウトソース化される」といったような急激に表れる変化に対しては、「固定化」という言葉にも聞こえてきます。なぜなら、「自動化する」とは、ある作業を効率化のためにコンピュータ的にプログラミングするということで、そこにはソフトウェアがいつも抱えている課題である、変更の困難さが付きまとうからです。
一方、急激なビジネス環境の変化は常に予想困難であり、それらにシステムを適応させていくには、むしろきっちりと作り込んで自動化したシステムというのは、足かせのようにも思えてきます。かといって、すべてを手動で行うようなアプローチも、そのコストを考えると疑問に思えます。
■自動化と手動の間にあるもの
![]() |
そこで、われわれが現実に取り得るアプローチは「完全自動化」「完全手動」のその間にあるように思えます。手動ほど非効率でなく、完全自動ほど変化に対してガチガチでないような仕組み、そんな仕組みに答えがあるのではないでしょうか。適度な自動化、適度な手動運用といったところでしょうか。
そんなシステムは、人事データベースとグループウェアのディレクトリをゆるく結合し、場合によっては手動でも更新でき、場合によっては大量変更を自動的に行えるような、そんな柔軟性を持ったものでしょう。具体的には、手動操作を簡単にするツール群、自動化の部分もスクリプトか、あるいは簡単なプログラミングで実現したものになるでしょう。
これらの度合は、各企業の人事データベースの状況、会社環境の変化の状況によって変わってくることでしょう。最終的には、自動連携のための作り込みのコスト、手動として残る部分の運用コスト、そして環境の変化により予想される作り込み部分の変更コストと、これらのトータルコストを最小化するように考えていくことが望まれます。この程度を見誤り、多くの自動化を行ったために、これらの仕組みをビジネス環境の変化に合わせて、年中その連携システムと格闘し続けなければならない、ということにはしたくないものです。
いずれにしても、人にかかわる環境は常に変化するという前提に立ったシステム作りが望まれます。そして、それらの変更が、人事データベースの仕組みに反映される前に、仕事そのものであるコミュニケーションをつかさどるグループウェアが、その変化の影響を受けるということを忘れてはいけないでしょう。「適応できるものが生き残る」という生物の原理は、システム作りにもいえるのではないでしょうか。
■広がるグループウェアの範囲
さて、今後のディレクトリをめぐる動向を展望してみましょう。企業がより多くの企業と密接に絡み合ってネットワーク的に業務をこなすようになってくる近い将来においては、企業間でのコミュニケーションのニーズがより高まるのは必然でしょう。当然、メールでのやりとりだけでなく、グループウェア的な機能の利用が必要になり、そのユーザーの範囲を広げることでしょう。そこには、関連する企業に共通のグループウェアのインフラストラクチャというニーズを呼び起こします。
実際には、その中でも中心となる企業のグループウェアをより広い範囲で適用するようにするか、あるいは各企業のグループウェアをインターネット化したアプリケーションとして企業間で提供していく形になるでしょう。そのためか、昨今のグループウェアはインターネット・プロトコル化が当然のように実現されています。
■“第2”のディレクトリ
そこには特定の企業だけでなく、複数の企業が相互にそれぞれのディレクトリを参照するというニーズが膨らみます。それは単にユーザーの一覧としてのディレクトリだけでなく、メールのあて先として、電話帳として、さらには組織図としてのディレクトリを意味します。ディレクトリの役割は、その業務の密接度、連携度から企業をまたがって、重要性を増していくわけです。
恐らくこれらのニーズを満たすには、ビジネス環境の変化の激しさを考慮すると、すべての企業のディレクトリを統一するというような壮大なものより、各企業のディレクトリを緩く結合した第2の統合ディレクトリが現実解となるでしょう。それはLDAPのようなインターネット・プロトコルでアクセスするといったものになるかもしれません。
そういった流れからは、さらに各企業のディレクトリと第2の統合ディレクトリ間で、できるだけ自動化するような連携がやはり必要となってくるでしょう。このように考えると、ディレクトリをめぐる環境はますます複雑化しそうです。その中で、ビジネス環境の変化が起こっても、それらの仕組みをできるだけコストを抑えて連携し運用していくという挑戦が、システム部隊に付きまとってくることを認識しなければならないでしょう。
ネットワーク化した企業、そして激しいビジネス環境の変化という新しい時代の流れは、システム開発者にいままでの「自動化がすべて」といったシステム作りの考え方の修正を迫っているように思えます。それが、ディレクトリという象徴的なシステムアプリケーションの仕組み作りに、顕著に表れていると考えられるのではないでしょうか。
| 筆者プロフィール |
関
孝則(せき たかのり)新潟県出身。国産コンピュータメーカーでの経験を経て、1985年IBM藤沢研究所へ入社。大型計算機のオペレーティングシステムなどの開発、IBMの著作権訴訟、特許権訴訟の技術調査スタッフなどを担当。1994年から日本IBMシステムズ・エンジニアリングでロータスノーツの技術コンサルティングを統括。代表的な著書に、リックテレコム社『ロータスドミノR5構築ガイド』(共著)、ソフトバンク ノーツ/ドミノマガジンの連載『ノーツ/ドミノ・アーキテクチャー入門』、日本IBMホームページ上のWeb連載『SE関のノーツ/ドミノ徒然草』など。 メールアドレスはts@jp.ibm.com |
| 「Master of IP Network総合インデックス」 |
ホワイトペーパー(TechTargetジャパン)
- どこまで出る? LTEの通信速度 (2010/3/17)
光ファイバに匹敵する通信速度を実現すると期待されているLTE。ホントにそんなに出るの? という疑問に答えます - インターネット世界の地図 (2010/2/23)
荷物の届け先まではどの道を通っていけばいいのでしょう? それを決める「経路選択」の仕組みを説明します - Androidアプリはビジネスになるのか (2010/2/12)
「iPhoneアプリの次はAndroid?!」NECビッグローブのAndroidアプリ販売サイト「andronavi」を通して、その可能性に迫る - 知られざるLTEのネットワーク構成 (2010/1/13)
LTEのネットワーク構成やプロトコルスタックを詳解。それぞれどんな役割を果たしているかを解説します
|
|
スキルアップ/キャリアアップ(JOB@IT)
スポンサーからのお知らせ
- - PR -
| 「いつかは壊れるサーバ」そんな故障に 迅速で安価に手軽に対応する方法とは? New! |
| 「特権ユーザー」の事件を防げ! 万能権限を持つユーザーの管理方法とは? New! |
| 仮想環境の構築とデータ保護の特効薬?! 実績と信頼性の高いパッケージで安心運用 |
| 仮想環境のバックアップもこれまでどおり 「まるごと取ってまるごと戻す」簡単運用 |
| おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
| その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |
| 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |
| 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |
- - PR -
お勧め求人情報

**先週の人気講座ランキング**
〜CCNA編〜
| ◆ | TomcatやJBossなどAPサーバ環境に関する 情報を集約! “業務”用APサーバ大百科 New! |
| ◆ | 一気に解説! 最新のクラスタストレージ 「RAIDを超えたストレージ基準」……など New! |
| ◆ | クラウド的ユーザー体験の変化は脅威か? 仮想化技術を使いこなす運用管理術を紹介 New! |

| ◆ | 上司や部下、部署内メンバーとの情報共有 を“ガラッ”と変えるコラボツールとは? New! |
| ◆ | おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| ◆ | 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |

| ◆ | Twitterのアカウントはなぜ突破された? メールによる新手の攻撃手法とその対策 |
| ◆ | もう仮想化のお試しフェイズは終わりだ! Hyper-V 2.0が基幹システムも仮想化 |
| ◆ | 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |

| ◆ | クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 |
| ◆ | .NET編集長が実践する「技術情報検索術」 サンプル・コードを簡単に探す“技”は? |
| ◆ | 業務効率と情報セキュリティ対策を両立! 手間なく確実に機密情報を守る方法とは? |

| ◆ | 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| ◆ | 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |

| ◆ | 【CTC事例】約30の基幹システムを統合! 膨大なバッジジョブを制御した方法は? |
| ◆ | 仮想化すればコストは削減できるか? 仮想化に必要な「3つの視点」を解説する |
| ◆ | その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |






関
孝則(せき たかのり)

