 |
Microsoft® SharePoint(TM) Portal Server 2001 の導入によって、グループウェアの課題を克服し、全社規模のポータルを構築
|
 |
キリンビール株式会社 では、2001 年 10 月を皮切りに待望の企業ポータルの利用をスタートさせます。これまではロータス ノーツ/ドミノを活用した情報共有の仕組みを、全社規模で利用してきましたが、さまざまな課題に直面し、パソコン等社内の情報インフラの一斉更新を機に、Microsoft SharePoint Portal Server を利用したポータルソリューションを採用することになりました。
＜導入の背景と狙い＞
情報共有を追求するほど標準的なグループウェアでは満足できなくなる
 |
キリンビール株式会社 情報システム部
部長代理 島健夫氏
|
キリンビール株式会社では、営業現場における意思決定のスピードを高めるため、国内酒類事業部門の営業担当者約 1,000 人にモバイルコンピュータを配布して、営業現場での情報共有を実践してきました。同部門では、1997 年にノーツ/ドミノ Lotus R4.5 のパイロット版導入を皮切りに、98 年秋には営業部門の情報共有のプラットホームとして R4.6 の本格的な導入、運用を開始。現場で得た情報を共有 DB に落とし込む方法で、営業担当者全員で情報共有を推進してきました。その後、さらに情報共有の範囲を拡大し、99 年 3 月からは全社メールシステムの整備と合わせて全社的にノーツ/ドミノ環境を整備しました。
このノーツ/ドミノによる全社メールシステムを実現するにあたっては、ユーザーニーズを最大限に尊重したため、大幅なカスタマイズを施さざるを得ませんでした。このカスタマイズが後々大きな問題を誘発することになるとは、当時の情報システム部では想像もできないことでした。
同社ではノーツ/ドミノを情報共有のベースとして利用しているものの、独自の使用方法であらゆる利用場面に応じた大幅なカスタマイズを行っており、もはや標準仕様とはいえない完全なキリンビール仕様のノーツ/ドミノを運用していました。
「営業部門での情報共有に関しては、対象となるユーザーが営業マンという前提がありましたので、できるかぎりユーザーフレンドリーな画面にして、積極的に利用してもらえるものをつくろうというのが当初の意図でした。しかし、その親切心が災いして、ひとつのフォームに大量のフィールドを作成し、多くの画像を埋め込んでしまったため、結果的にレスポンスを落としてしまったのです。その後は、レスポンスを向上させるために再びカスタマイズをかけたり、システム構成を変更したりと、実にさまざまな対策を講じていったのですが、そのことがさらに問題を複雑にしてしまったという感じです」（情報システム部 部長代理 島健夫氏）
＜ビジネスの課題＞
システムの更新をきっかけに、
ノーツ/ドミノのバージョンアップが不可能であることが判明
キリンビール株式会社 情報システム部
主任 中村浩氏
|
|
全社的なグループウェア導入から 1 年半が経過した 2000 年末ころになると、情報共有環境に関するさまざまな課題が浮上してきました。懸案は２点あり、１点目は添付文書の内容も含めた全文検索で、２点目は異なるデータベース間で横串を通した形での統合検索でした。同社では、情報の集中化、運用の効率化をはかるためノーツサーバーをシステムセンターに集約化し情報共有環境を整備しました。集約化した DB では、添付ファイル全文検索のインデックス作成負荷が大きいため、この機能を使わない形で運用し、 一方部門ごと、業務機能ごとに作られた DB は個別に検索を実施する運用を行っていた事もあり、高速な全文検索と統合検索が強く望まれていました。 また、ロケーション毎に設置されたファイルサーバーについては、Windows® の全文検索機能が時間がかかり過ぎて運用に耐えられないという状況もあり、こちらも同様に高速化が望まれていました。
情報システム部 主任 中村浩氏は当時のシステムについて、こう話しています。
「最大の課題は、全文検索と統合検索を高速に行う事です。これは集約化した ノーツデータベースにも、分散配置したファイルサーバーにも言える事ですが、システムが止まっているのではないかと思わせるほどのレスポンスは利用者には許されません。当時利用していた PC のスペックが低かったこともありますが、ユーザーの間では、添付文書の全文検索は時間がかかって話しにならないと、完全にあきらめている感じがありました。ここの部分が解決された時のメリットは計り知れないと思います」
同社のもうひとつの課題は、本来ノーツ/ドミノのメリットであるはずの開発生産性の高さについてでした。他のアプリケーションに比べて、開発生産性が高いといわれているノーツ/ドミノは比較的短期間で簡単に利用部門でのシステム構築が可能となりました。しかし、ある程度利用環境が整ってくると、文書の共有だけではなく、業務システムと連携させて使いたいという要望が増えてきます。このような要望を満足させるためには、基幹システムのマスター DB を利用するしかないため、次第にユーザー任せでの管理は困難になってきました。当初、同社では、ノーツ/ドミノと基幹システムの連携にはデータ転送用拡張ツール、ノーツポンプを利用していましたが、このアプリケーションの複雑な操作までは、さすがにエンドユーザーには難しすぎました。最終的には、情報システム部で 1 年かけて利用環境の調査を行い、厳格な使用基準を策定することになりました。
一見、仕事の効率アップに有効と思われる開発生産性の高さも、利用方法を明確に規定しないと収拾がつかなくなるという貴重なメッセージを、このケースから読み取ることができます。
色々な課題が次々と浮上してくる中で、さらに、もうひとつの大きな問題に直面しました。
当時、運用していたシステムの更新時期が 1 年後に迫り、これまでの Windows 95 ベースのシステムから、全社のシステム（6,000 台のクライアント）をすべて Windows 2000 ベースに、クライアントアプリケーションを Office 2000 に、移行するプロジェクトが動きはじめたのです。
情報システム部では、これを機に R4.6.6ｂ だったノーツ/ドミノを R5 へアップグレードすることを検討。提携ベンダーに R5 へのバージョンアップを打診しました。ところが、同社で運用されていたノーツ/ドミノのように、大幅にカスタマイズされたシステムをバージョンアップするには、莫大なコストと時間を要するという事実が判明。アプリケーション開発を含めたバージョンアップにかかる移行期間が、最低でも 1 年以上必要であり、2001 年 10 月のシステム更新時期に、ノーツ/ドミノ R5 を稼動することは不可能だとの結論が導き出されました。その回答を受けた情報システム部では、ノーツ/ドミノのバージョンアップを事実上断念し、ベンダーからのサポートを受けられなくても現行の R4.6.6b のまま運用することを決断したのです。
＜導入システムの紹介＞
SharePoint Portal Server の導入で情報共有の課題を解決し EIP 実現へ向けて舵を切った
R5 へのバージョンアップが不可能となった段階で、ノーツ/ドミノの課題とされる検索機能を補完するには、他社のサーチエンジンを導入する以外に選択肢がなくなりました。この時点で SharePoint Portal Server の導入が第一の選択肢として挙げられてはいたものの、ジャストシステム ConceptBase Search や富士通 IntelligentSearch などの製品についても、比較調査検討が行われました。しかし、これらの製品はあくまでもサーチエンジンの機能しか持たないため、複数の機能を持つ SharePoint Portal Server と同列に比較する製品ではないとの結論に達しました。また、同社では将来的に全社的な企業情報ポータルを実現していく、というビジョンも持っていたため、ポータル機能を持つ SharePoint Portal Server の導入は、必然的な流れだったのです。
「SharePoint Portal Server は非常に多機能なツールですが、まずは検索エンジンの部分を使いこなすことが第一目標だと考えています。そして、次のステップとして、全社員が利用するメニューを統合したポータルを実現し、最終的なステップとして、文書管理機能を使いこなせるように、順次ステップアップしていく予定です」（島氏）
＜システム構成＞
8 台の並列サーバー構成によるポータルシステム
全社的なポータルシステムを構築するにあたって、全社員が情報戦略の核として利用する SharePoint Portal Server は、ノンストップでの運用が求められるため、ロードバランスや万一の障害を想定し、トランザクション処理用に 4 台、メイン 1 台、インデックス情報をストアするデータ検索用サーバー 1 台、文書データベースをストアする文書管理サーバー 2 台を配置し、合計 8 台のサーバーで運用します。今後の利用度合いに応じて柔軟にシステム構成を拡張する事ができます。
既存の情報共有の仕組みであるノーツ/ドミノの資産には、特別に手をつけることなくあらかじめインデックスを作成し、データ検索用サーバーに格納することで、高速な検索を実現する方法を採用しました。
さらに SharePoint Portal Server では、バックヤードで基幹システムの業務アプリケーションや Web サーバー、ファイルサーバーとの連携も実現しています。
「全社でポータルを導入すると、毎朝一斉に 6,000 人の社員が SharePoint Portal Server へアクセスすることも考えられるわけです。その場合、ネットワークにはかなりの負荷がかかると思われますが、情報システム部としては、そのトラヒック集中の問題もすでに解決済みです。過去のシステム運用上のデータから、レスポンスやアプリケーションごとのトレンドなどは把握していますし、万一逼迫した場合でも、段階的に柔軟にシステム拡張が可能ですので運用面での心配はしていません」（情報システム部 主任 中村浩氏）
EIPシステム構成の概要
＜SharePoint Portal Server 利用イメージ＞
SharePoint Portal Server とノーツクライアントとのシームレスな連携によって、ユーザーオリエンテッドな操作環境を提供
同社情報システム部では、全社ポータルを構築するにあたって、現在利用しているシステムの使い勝手を損なうことなく、今まで以上に高い操作性を実現することを、ひとつの目標と定めました。企業システムというのは、それがどれほど高度な機能を持っていたとしても、ユーザーが使いこなせなければ、「宝の持ち腐れ」になってしまうものです。まして、全社員が利用するシステムは、インターフェイスにおいてもユーザーの使い勝手を最優先に考えなくてはなりません。このようなスタンスに立ち、同社情報システム部ではあらゆる角度から情報共有の利用実態や動向の調査を行いました。その結果、現時点でユーザーが頻繁に利用しているノーツ/ドミノ資産は、最大限に生かす道がベストだと判断しました。せっかくポータルを構築しても、ユーザー側で使いこなすことができず、今までどおりノーツ/ドミノを利用したほうが作業効率がいいということになっては、意味がありません。また、過去のアプリケーション要件や対応可能な技術を掛け合わせてみると、導入当初はなじみのあるノーツクライアントを利用した方がメリットが大きいだろうという結論が導き出されました。こうした要望は、同社情報システム部から Microsoft Consulting Service を通じて SharePoint Portal Server の導入チームにフィードバックされました。
その要望は『Web パーツ』という形となり答えとして返ってきました。具体的には、SharePoint Portal Server の検索機能を使って、ノーツ/ドミノのコンテンツを検索した場合、検索結果を表示するときに[ノーツで開く]をクリックするだけで、ノーツ/ドミノを起動して該当ファイルを開くことが可能になりました。まさに同社が望んだ通りの、SharePoint Portal Server とノーツ/ドミノのシームレスな連携の実現です。
「『Web パーツ』という柔軟な仕組みで、容易に当初の課題を克服することができました。現時点でノーツ/ドミノとの連携については、大きな期待を寄せています。また、この短期間にポータルを導入することができたのは、ひとえに Microsoft Consulting Service の方のアドバイスやサポートのおかげだと感謝しています」（島氏）
『Web パーツ』とは、それ自体でひとつの小さな Web サイトを構成するコンポーネントです。SharePoint Portal Server では、この『Web パーツ』を複数画面に貼り付けることによって、容易にポータルを構築できる仕組みになっています。なお、一度コンポーネント化された『Web パーツ』は、汎用的に利用することができます。SharePoint Portal Server の公式サイトには、こうした汎用的な『Web パーツ』を無償でダウンロードできる「Web パーツギャラリー」が用意されています。ちなみに前述した、キリンビール株式会社で採用された DBに対する検索結果をノーツクライアントで表示できる[検索結果（ノーツ 対応版）]もすでに汎用パーツ化されて、現在ダウンロードが可能になっています。
「Web パーツギャラリー」では、日本語環境で使用できるサンプルが数多く公開されており、これをフルに活用すれば短期間かつ低コストに、独自のポータルソリューションを実現することができます。
SharePoint Portal Serverの検索画面 [ 拡大図 ] |
|
SharePoint Portal Server からのノーツの起動画面 [ 拡大図 ]
|
＜SharePoint Portal Server 導入に伴うファイル共有システムの構成変更＞
ロケーションも、部門も越えた全社的なファイル共有環境を整備
全社的な情報共有環境の構築を指向している同社では、SharePoint Portal Server 導入以前から部門単位での統一されたファイル共有を実現していました。以前のシステム構成は、4 つの共有フォルダが用意されており、それぞれ[U ドライブ（部門内共有フォルダ）][T ドライブ（公開用フォルダ）][V ドライブ（共通ファイルシステム）][W ドライブ（個人フォルダ）]という名称で利用されてきました。SharePoint Portal Server 導入に伴って、これらの情報共有構成に変更が施され、部門を越えた理想的な全社のファイル共有環境が整備されました。
最大の変更点は、[S ドライブ]が新たに追加されたことです。[S ドライブ]は、ロケーションを跨り、部門を越えてファイルを共有する形態をとり、SharePoint Portal Server の文書管理の仕組みを最大限に活用したものです。[S ドライブ]という全社共通の大きなフォルダの中に、カテゴリ分類が設定されたさまざまなファイルを保存することができ、ニーズに応じて必要なファイルだけを参照することが可能です。また、クライアントアプリケーションである Office 2000 とのシームレスな連携により、ドキュメント上からチェックインアウトを実現することや、保存時に自動的に属性設定ができるので、特別なトレーニングを積まなくても、クライアントレベルで容易に文書管理環境を利用することが可能です。そのうえ高度なバージョニング機能が実装されているためファイルの世代管理も簡単。さらに保管した文書のインデックスが自動生成されるため、[S ドライブ]のみならず、すべての共有フォルダを全文検索しても、非常に高速なレスポンスを得られるようになりました。
なお、[S ドライブ]の追加に伴って、これまでサーバーで管理していた[W ドライブ]を廃止して、個人フォルダは PC に移動する形へと変更されました。SharePoint Portal Server の導入によって、全社的なファイル共有構成がシンプルになり、操作性、管理性ともに大幅に向上させることができました。
＜導入結果と感想＞
高速な全文検索に大きな期待
「ポータル導入以前に抱えていた検索の精度とレスポンスの課題については、ほぼ解決できるのではないかと考えています。プロジェクトで試験した結果、SharePoint Portal Server に実装された強力なインデックスエンジンのおかげで、全文検索をかけても非常に速いスピードで検索結果を表示してくれる事が確認できています。また、検索精度に関しても、結果をランキング表示してくれる機能があり、利便性の向上に大きな期待を寄せています」（中村氏）
現時点で同社システムのポータルからの検索対象は、ファイルサーバー、Web サーバー、ノーツ/ドミノの DB となっています。今後利用を進めていく段階で、検索対象 DB の数を徐々に追加していく予定です。
＜今後の展望と期待＞
全社統一のポータルからパーソナライズされたマイポータルの実現を目指して
2001 年 10 月の運用スタート段階で実現される同社ポータルのトップ画面には、業務アプリケーションのランチャー的な機能が配置されます。
「ポータルという概念が浸透する以前からユーザーレベルでは、アプリケーションのショートカットをデスクトップに並べたり、スタートメニューの使いやすい場所に配置したり、などの工夫が行われていました。しかし、今回のように全社的にシステムが更新されてしまうと、ユーザーはまた最初から操作を覚えなくてはならず、せっかくカスタマイズした環境も無駄になってしまいます。このような状況を回避し、なおかつ業務の効率化を実現するには、ポータルのトップ画面にアプリケーションの起動機能を盛り込むことが不可欠だと考えました」（中村氏）
まずは全社員 6,000 名に統一のポータル画面が提供され、起動アプリケーションも汎用的なものが提供されます。その後は、ユーザーの要望を取り入れながら、職種や役職に応じてパーソナライズしたポータル画面を提供し、最終的にはワークスペースポータルを実現する予定です。既に、その準備に向けて、プロジェクトチームが結成され、検討が進んでいます。
「部内でレビューをした時、もっと利用方法のノウハウを蓄積して、アプリケーションの開発部隊やユーザーを巻き込まないと、十分な活用はできないだろうという意見がでました。そこで、新たにプロジェクトを立ち上げ、インフラ系以外にアプリケーション系のグループも参画させました。現在はわれわれ情報システム部門と情報システム系のグループ会社（株式会社キリンビジネスシステム）でプロジェクトのメンバーを構成していますが、実際の運用がはじまった段階から、ユーザーにもプロジェクトに参加してもらい、より使いやすいポータルをつくりあげていきたいと考えています」（中村氏）
さらに、現在はノーツ/ドミノによるメールベースとアプリケーションベース（Oracle、DB2 等）の 2 系統に分かれている承認システムをポータルに載せて、一元化する計画も進められています。
「全社ポータルの運用が一段落したら、部門ごとにパーソナライズされたマイポータルの実現を目標にして次期バージョンを開発する予定です。そのときには、インターフェイスの部分もより直感的で操作性の高いデザインを目指したいと考えています」（中村氏）
|
|
| |
本ケーススタディに記載された情報は初掲載時のものであり、閲覧される時点では変更されている可能性があることをご了承ください。
本ケーススタディは情報提供のみを目的としています。Microsoftは、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。
|
|
 |
|
|
|
