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