今日はシェアードサービスについてのお話。ひとくちにシェアードサービスといっても、人事・総務・経理業務なども関係するが、ここでは情報システムの保守・運用についてのシェアードサービスに話を限定する。シェアードサービスというのはご承知のとおり、複数の子会社をもつ大企業が、グループ企業各社の間接部門を１つにまとめ、場合によっては別会社にすることで、グループ全体としての経営効率を高めることをいう。
情報システム部門の場合、グループ各社のそれぞれが各社の情報システムを管理するために個別に人員をかかえていたのを、企業グループ全体で一つの組織に統合し、業務を集中化する。それによってグループ全体としてみたときに、重複していたＩＴ費用を削減することができる。
同時に、情報システムに関する企業グループ内の資源（ハードウェア、ソフトウェア）やノウハウを集約することで、情報システムの標準化を実現でき、情報セキュリティのレベルを同じレベルに高めることも期待できる。
また、情報システム部門を集約することで、これまで社内の管理部門だった人員が、グループ各社にサービスを提供する立場に変わる。それによって、より良いサービスを提供しようという「サービス・マインド」（何だかこういう話について書くとヘンな英語ばかりになってしまう）が産まれることが期待される。
以上が、情報システムのシェアードサービスに関する理想論だが、実際のシェアードサービスはこんなに美しいものではない。
僕はふつうの会社員より転職回数が多い分、某大手コンピュータメーカに情報システム部門のシェアードサービス化を委託している企業を、２社も経験することができた。１社は大手自動車メーカ、もう１社は大手不動産デベロッパーだ。
自動車メーカではグループ会社をとりまとめる親会社の情報システム部門の社内ＳＥとして、そして、不動産デベロッパーではとりまとめられる側の100%子会社の情報システム部門の責任者として働いていた。シェアードサービスを提供する側と受ける側の両方を経験させてもらっているというわけだ。
企業規模を社員数でいうと、自動車メーカはグループ全体で3万人以上、不動産デベロッパーはシェアードサービスの範囲内のグループ各社合計で2000人前後と思われる。これだけ企業規模が違うと、当然のことながら某大手コンピュータメーカが構築しているシェアードサービスの仕組み（かっこよく言うと「スキーム」となる）も異なっていた。
そもそも自動車メーカの方は、シェアードサービス化する以前に、情報システムの保守・運用を担当する100%ＩＴ子会社が存在した。そのＩＴ子会社にネットワークから業務システムまで、保守・運用のノウハウが蓄積されていたので、某大手コンピュータメーカはこの子会社に出資することで、シェアードサービス提供会社として生まれ変わらせるという方法をとっていた。最終的にこの会社は自動車メーカは完全に某コンピュータメーカの100%子会社になった。
一方、大手不動産デベロッパーの方は親会社の情報システム部門のうち数人が某大手コンピュータメーカからの出向者といっしょになって、シェアードサービスを提供するための別会社を立ち上げていた。別会社の主要メンバーは某大手コンピュータメーカからの出向者で、親会社からの出向者はどちらかといえば脇役だ。
不動産デベロッパーのシェアードサービス提供会社には、自動車メーカの元100%ＩＴ子会社と違って、そもそもグループ各社の情報システムに関する知識がまったくないので、分社化された後もネットワークと情報共有基盤の運用にサービスを特化していた。対して自動車メーカのシェアードサービス提供会社はネットワークなどの情報基盤だけでなく、業務アプリケーションの保守運用も継続してサービスメニューとして提供していた。
グループとして社員数が２～３千人以下の場合、シェアードサービス提供会社の人員がグループ各社の業務システムの内容まで把握するというのは、超人的に有能な業務ＳＥでもいない限り不可能である。したがって情報基盤に関するサービスに特化するというのは、一定のサービス水準を維持するには妥当な方針だ。その意味でこの大手不動産デベロッパーのシェアードサービスの仕組みは合理的だと言える。
他方の自動車メーカのシェアードサービス提供会社についても、もともと各社の業務システムの保守・運用ノウハウを有していた100%ＩＴ子会社が母体になっているので、このＩＴ子会社そのものが数百名規模をほこっていたことからして、グループ各社の業務システムの保守・運用までをサービス内容に含めるというのは妥当である。
しかし、グループとして社員数が２～３千人以下であり、もともとグループ各社の業務システムノウハウが集約されているようなＩＴ子会社もなく、シェアードサービス提供会社の人員数も数十人という規模といった状態なのに、各社の業務システムの保守・運用までサービスに含めるというシェアードサービスのスキームには無理がある。現実的なマネジメント感覚をもっている管理職なら、このようなスキームに明らかに無理があることは容易に判断できる。
しかし、そういった明らかに非合理的なことがたびたび起こってしまうのが、現実のサラリーマン社会というものなのである。現実のサラリーマン社会で人の合理的な判断を歪める要素になるのは、過剰な期待、過剰な自信、過剰な自尊心などだろうか。
完璧な人間は一人もいない、それが単なる一介のサラリーマンならなおさらである、と言ってしまえばそれまでなのだが、そのような誤りに対するチェック機構が働くかどうかが、失敗を避けられるかどうかの分かれ目であるような気がする。
月別アーカイブ: 2006年7月
やはりIBM Lotus製品群は限界か
情報共有基盤の製品選定というのは、いつも堂々巡りになっているような気がしてイヤになってくる。もっともそれは僕の情報共有ソリューションの中核となるスキルがIBM Lotus Notes/Dominoだからかもしれない。
単にWebメール、スケジュール管理、会議室予約、掲示板、電子会議室（スレッド形式の掲示板のようなもの）がとりあえずできればいいというのであれば、サイボウズ、デスクネッツなどお手ごろなパッケージ製品の選択肢は無数にある。
しかし、少しでも自社向けにカスタマイズしたいとなると、情報共有基盤の製品選定は様相がガラリと変わる。たとえば、電子会議室に発言するときに、自分が発言したという通知メールを指定した関係者に送信したい。そんなつまらない機能を追加したいというだけで、製品選択の幅はいきなり狭くなってしまう。
サイボウズ・ガルーンがどの程度までカスタマイズを許しているのか詳しくないが、おそらくメール送信機能が関係するカスタマイズは無理だろう。RSSフィード機能を利用すればいいという反論があるかもしれないが、RSSリーダを社内の標準クライアント・ソフトウェアを位置づけている企業がどれほどあるというのだろうか。デスクネッツはまったくカスタマイズの余地がない。
新規に情報を登録したときにメールを一発送信するカスタマイズくらい対応してくれよ、というのは、ずっとNotes/Dominoにかかわってきたシステムエンジニアならではの発想で、そもそもNotes/Dominoが簡易開発基盤としてよくできすぎているのだ。（もちろんその弊害として現場の利用者が勝手に開発したノーツデータベースが乱立するということもあるのだが）
それ以外となると、もうマイクロソフトのExchangeとSharePoint Portalの組合せをASP.NETででもカスタマイズするぐらいしか選択肢がない。
ワークフローの構築となるとさらに話が面倒になってくる。人事異動があったら組織階層と所属の情報は、人事データベースからデータを取ってきて自動更新させたい。組織変更があるたびに手作業で修正するような鈍なことはしたくない。
また、承認経路についても、ある程度までは社内の特殊事情に合った定義ができるようになっていてほしいし、承認が完了した文書については承認済みの正式文書として後々検索できるように文書の種類ごとに保管したい。
こうなってくるともうマイクロソフトか、IBMかの選択になる。
さらに、Notes/Dominoユーザならお分かりいただけるだろうが、Notes/Dominoというのは個々のデータベースファイル内の文書数（関係データベースにおけるレコード数に当たるデータ件数）が万単位になると、文書一覧を表示させる性能が急に悪化し、ほとんど使い物にならなくなる。
したがって、件数の多いデータを共有したいとなると、やはり関係データベースを直接検索しにいくようなしくみを開発する必要がある。ここまでくるとNotes/Domino単体では対応が難しくなる。Notes/DominoのWebアプリケーションで無理やりCGIアプリケーションのようなものを開発することもできるが、邪道もいいところだ。
そうするとIBMでそろえるにはWebSphere上にJavaで関係データベースのシステムを開発するかとなるが、ここまでくるとかなり本格的になり、Notes/Dominoデータベースのようにそうそう手軽に社内開発するわけにもいかなくなる。Visual Web Developer ExpressでASP.NET利用のWebアプリケーションを開発する方が、まだ開発生産性は高いだろう。
ここまでくると一つ大きな問題が出てくる。シングル・サインオンである。DominoのWebアプリケーションへのログインは、Notes/Dominoのユーザ名とWebアプリケーション専用のパスワードで行う。DominoのWebアプリケーション専用パスワードは、Notes/Dominoをクライアント・サーバ型で利用するときのIDファイルによる認証の仕組みとは連動しない。したがってNotes/Dominoの認証のしくみとマイクロソフトのActiveDirectoryの間で同期をとる運用をしていたとしても、DominoのWebアプリケーションはその枠から外れてしまう。
最近IBM Lotus製品群からIBM Workplace Designerという開発環境が発売されている。Notes/Dominoと非常によく似た感覚でJavaScriptを開発言語としてWebアプリケーションを構築できる製品だが、データはXML形式で関係データベースに保管されるため、飽くまで「文書」が単位になり、それを「一覧」（ビュー）形式で見せるというNotes/Dominoの思想まで受け継いでしまっている。そのために万件単位のデータをあつかう検索システムには不向きのようだ。
しかもIBM Workplace製品群は、Notes/DominoのWebアプリケーションとのシングル・サインオンは、僕の理解している限りでは、別の製品を持ってこない限りは不可能である。
そもそも企業内のWindowsパソコンは、マイクロソフトのActiveDirectory配下で管理されていることが多いのだから、ユーザ名とパスワードを管理するユーザ認証の仕組みはActiveDirectoryで統一したい。しかしIBM系のツールで開発したWebアプリケーションはその枠から外れる。ここでマイクロソフト製品が俄然、有利になってくる。
IIS 6.0上でASP.NETを使って関係データベースのシステムを構築すれば、IIS 6.0側の設定でActiveDirectoryを基本認証として利用することができる。そうすれば少なくともパソコンを起動して最初にログインするときのユーザ名とパスワードで、Exchangeにも、SharePoint Portalにも、お手製のASP.NETによるWebアプリケーションにもログインできるようになる。
いや、IBM製品でもTivoliのディレクトリシステムを使えばシングル・サインオンは実現できると言われるかもしれないが、中堅・中小企業にとってTivoliという製品群は明らかに技術的に敷居が高いし、運用が重荷である。
中堅・中小企業が、自社特有の組織的な事情や業務フローに合わせて、ある程度のカスタマイズができる情報共有基盤を構築し、数万件単位のデータ検索も同じ仕組みの中で実現したい。そんなささやかな情報共有の要件を実現しようとしているだけなのに、製品の選択肢は以上に見てきたように恐ろしく限定されてしまうのだ。
以上の要件全てを満たそうとすると、現時点ではマイクロソフト製品群の方に分があると言える。IBM Lotus製品群はIBM Workplace製品群を投入して奮闘中だが、Managed Clientというリッチクライアント製品を使っても、ominoのWebアプリケーションへのログインと、IBM Workplace製品群へのログインは別になっているようだ。
そういうわけで、そろそろDominoのWebアプリケーションの限界を追求するという不毛な作業を放棄して、ASP.NETの高機能なサーバコントロール群を使いこなせるような勉強をすべきなのだろうかと考え始めている。かつては「Notes/Domino命！」だった僕でさえこのように判断が傾きつつあるのだから、IBM Lotus製品群の未来は危うい。
ベイズ理論の直感的な説明
スパムメールをフィルタリングするプログラムに「ベイズ理論」が使われているというＩＴ系の記事からリンクが張られていたので、いまこちらのページ「An Intuitive Explanation of Bayesian Reasoning」を読み進めているところだ。
ベイズ理論の直感的な説明ということで、かなり分かりやすい解説であることには違いないのだが、最近、英語をほとんど読んでいなかったせいで意外に苦心している。しかし面白いことは確かに面白い。たしか『行動経済学入門』の中にも、古典主義経済学が前提とするほど人間の判断は完全に合理的ではないという論証の部分で、このベイズ理論が登場したと記憶している。
この長い英文の入門記事で、最初の例としてあげられているのは、乳がんとマンモグラフィ検査の例だ。
「マンモグラフィ定期健診に参加する女性の1％が乳がんである。乳がんの女性のうち80％がマンモグラフィで『がんがある』と診断される。しかし乳がんではない女性の9.6％もマンモグラフィで『がんがある』と誤診される。ここにマンモグラフィで『がんがある』と診断された一人の女性がいる。この女性が本当に乳がんである確率はどれくらいか」
この問題に正しく答えられない方は（僕もそうなのだが）、ぜひ上述の「An Intuitive Explanation of Bayesian Reasoning」を読み始めて頂きたい。このベイズ理論とスパムメールのフィルタリングがどう関係するのかは、４分の３くらいを読み進めたところで分かってくる。
僕もまだ最後まで読んだわけではないので、偉そうなことは書けないのだが、ベイズ理論は、ある事象が起こる確率を正しく特定することに対して、何が影響を及ぼし、何が影響を及ぼさないか、そして、影響を及ぼすとすれば、どれくらいの影響を及ぼすかを知るための手がかりになる、らしいのだ。
おそらくは、スパムメールの場合、メールの中にＡという単語が含まれる確率が、そのメールがスパムメールであるかどうかの判断にどの程度影響するかを、ベイズ理論を使えば定量的に計算できるのだろう。そして、判断材料となる単語の数を増やしていけば、スパムメールをより正しく特定できるようになる、ということなのだろう。
ともかく最後まで読んでみないことには。以上、「山手線でココだけ」ではないが、ココだけの話、というわけでもないココだけではない話であった。（←『ワールドビジネスサテライト』に取り上げられたら、すぐキーワードを挿入しておく。これも一種の検索エンジン最適化）
宮崎アニメと『ザンボット３』の接点
そういえば動画配信サイトShowtimeで『ザンボット３』を観ていたころに、この「愛と苦悩の日記」の読者の方からメールで「金田パース」というものについて教えて頂いた。日本語版のWikipediaの金田 伊功（かなだ よしのり）氏の項をあたって頂ければわかるが、金田氏は宮崎駿監督作品の原画としても有名な人物らしい。
金田パースというのは、遠近法（パースペクティブ）という言葉が入っていることから分かるように、極端に強調された遠近法のことで、ロボットものなどで架空のカメラの手前にあるものをより大きく、奥にあるものをより小さく描くことで、ロボットや戦闘機の動きのダイナミズムをより強調する手法のことを言うようだ。
金田氏は別に「金田ビーム」という戦闘ロボットものに欠かせない表現技法も編み出しているらしく、セルの透過光を利用した、ビーム光線の独特な表現も氏オリジナルのものらしい。こういうところから出発して、金田氏は『天空の城ラピュタ』や『となりのトトロ』、『魔女の宅急便』、『紅の豚』、『もののけ姫』などで原画を担当する、今や日本アニメ界の重鎮になっているとのことだ。
『ザンボット３』のような、見方によっては「下らないお子様向け合体ロボットアニメ」が、実は今の日本のアニメーションの品質や芸術性を支える確かな職人たちのインキュベーターになっていたということなのだから、「ジャパニメーション」が世界で評価されているからといって、お金をかけて創造性や芸術性ばかりを追求した作品ばかりを製作していたのでは、将来の日本アニメを担うクリエーターが育たなくなってしまう、ということなのかもしれない。
『ガンダムSEED』富野氏は単なる原作者
『ターンＡガンダム』と『ガンダムSEED』シリーズの落差について読者の方からメールを頂いた。『ガンダムSEED』については富野氏は単なる原作者としての位置づけでクレジットされているだけで、内容について決定権はまったくないとのことだ。確かに『ガンダムSEED』のクレジットをよく読むと、『ターンＡガンダム』などと違って、富野氏は総監督となっておらず、単に原作者でしかない。
また、ガンダムの商品化権はサンライズにたった３０万円で買い取られてしまっており、富野氏自身にはガンダムのプラモデルがいくら売れてもお金は入ってこないらしく、『ターンＡの癒し』にあった富野氏自身の非常に自虐的なコメント、つまり自分はアニメ製作現場にあっては最底辺の存在だという言葉もうなずける。たしか松本零士氏も同じようなことを言っていた記憶があるが、日本のアニメ業界は創作者が儲からず、サンライズやバンダイ、東映のような企業が潤う仕組みになっているようだ。