
連載:グループウェア徒然草(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総合インデックス」 |
- 完全HTTPS化のメリットと極意を大規模Webサービス――ピクシブ、クックパッド、ヤフーの事例から探る (2017/7/13)
2017年6月21日、ピクシブのオフィスで、同社主催の「大規模HTTPS導入Night」が開催された。大規模Webサービスで完全HTTPS化を行うに当たっての技術的、および非技術的な悩みや成果をテーマに、ヤフー、クックパッド、ピクシブの3社が、それぞれの事例について語り合った - ソラコムは、あなたの気が付かないうちに、少しずつ「次」へ進んでいる (2017/7/6)
ソラコムは、「トランスポート技術への非依存」度を高めている。当初はIoT用格安SIMというイメージもあったが、徐々に脱皮しようとしている。パブリッククラウドと同様、付加サービスでユーザーをつかんでいるからだ - Cisco SystemsのIntent-based Networkingは、どうネットワークエンジニアの仕事を変えるか (2017/7/4)
Cisco Systemsは2017年6月、同社イベントCisco Live 2017で、「THE NETWORK. INTUITIVE.」あるいは「Intent-based Networking」といった言葉を使い、ネットワークの構築・運用、そしてネットワークエンジニアの仕事を変えていくと説明した。これはどういうことなのだろうか - ifconfig ~(IP)ネットワーク環境の確認/設定を行う (2017/7/3)
ifconfigは、LinuxやmacOSなど、主にUNIX系OSで用いるネットワーク環境の状態確認、設定のためのコマンドだ。IPアドレスやサブネットマスク、ブロードキャストアドレスなどの基本的な設定ができる他、イーサネットフレームの最大転送サイズ(MTU)の変更や、VLAN疑似デバイスの作成も可能だ。
![]() |
||
|
||
![]() |
Master of IP Network 記事ランキング
- SIM内蔵PCを3100台 静岡銀行がSASEで統合した新OA基盤、最大の特徴とは
- 貴社のメール送信用IPアドレスが汚れる理由――レピュテーションを高めるウォームアップの5ステップ
- 「Skype」2025年5月にサービス終了 Skypeユーザー向けFAQを公開 Microsoft
- 「AI」でベンダー依存脱却へ、セブン&アイに学ぶ企業ネットワークでのAI活用
- NTT Comが新たなローカル5Gを投入 クラウド型により低コストで導入しやすく
- 新衛星通信サービス「Eutelsat OneWeb」は「Starlink」と何が違うのか?
- 貴社で「メールが届かない」問題が起こる理由――メール送信/受信の基礎知識
- 高速性や低遅延ではない、九州電力がローカル5G「実用化」で最重視した着眼点とは?
- 「メールが届かない」事態を避けるための送信要件の確認と送信用インフラ選定の注意点
- 実は「メールが届かない」問題にはドメイン名も影響する――ドメインレピュテーションの基本とGmail送信者ガイドラインの要件