mark-wada blog

これから、企業における業務システムについて年を追うことで書いていこうと思う。これはぼくのITとの関わりという偏見の入ったものであるので、一般的な変遷史とかけ離れているかもしれないが、それはご容赦いただく。ただし、その時点で業務システムはどうあるべきかを真剣に考えていたし、フロントランナーにも意見を求めたし、そう的はずれにはなっていないと思う。

ぼくが、情報システム部門に配属されたのは、1994年の6月末であった。いきなり、余談で恐縮ですが、配属前は、東京の社長室というところで技術企画の仕事をしていたのだが、突然工場のシステム部門に転勤になったのだ。しかも、その年の3月末に家を新築したばかりであった。格言どおり、家を新築すると転勤になった。

この格言はあながちいい加減なものではなく、ある程度論理的であると思っている。要するに、この部署に落ち着いたのでそろそろ家を建てようかなと思うのと、この部署にも長いこと経ったのでそろそろ転勤させようかなという思惑がだいたい同じタイミングになるからである。

それはさておき、ITのことである。1994年に情報システム部門に来たが、業務システムという面では、5年くらい経った汎用機のシステムがやっと軌道に乗って動いているというところで、何しろ基幹系のほぼ全体をカバーしている大がかりの仕組みなので、末端のひとたちまで浸透するのは大変であった。しかも、企業合併もあり、そしてグループ会社への展開もあって、かなりきついことのなっていた。

ただし、事業所では、ホストは本社が管理しているので、むしろ工場のシステムや部門システムをどうするのかが課題であった。すなわち、生産管理、設備保全、物流管理、環境管理といったサプライチェーンをサポートするようなシステムを整備することが求められていた。

一方、この年ぐらいからインターネットが登場してくる。赴任してすぐに人事から海外駐在員あるいは出張者のための安全情報をインターネットから取りたいのだがどうしたらよいのかという相談を受けたのを今でもよく覚えている。この年ネットスケープが会社設立した。直感的にこれはいつかきっと企業の中にも入ってくるなと思った。もちろん、これほどまでになるとはその当時は考えられなかった。

そのころは、徐々にではあるが大型汎用機で何でもやってしまうことに疑問が出始めたときでもあった。ひとつにはパソコンというものが出てきていたからである。爆発的に売れたWindows95は次の年にでるが、Windows3.1もけっこう浸透してきていた。

そして、ローカルなシステムは、オフコンと呼ばれるコンパクトなシステムでソフト込みのようなかたちで普及していた。当時は、IBMがSystem38とSystem36を統合したAS400をだしてきたときでそれを使った。このAS400という機種は今でもPower Systemsのいう名に変わっていますが健在です。これは名機ですね、何しろ運用がメチャ楽ですから。

というわけで、この年は初めての情シス体験で勉強することが主になっていました。しかし、勉強すればするほど面白くなり、もはや自分はこの道でメシを食っていこうかと思い出したのもこの年である。

ここにぼくが当時あるレポートに書いたキーワードがある。

・オ－プン化／マルチベンダー
・クライアントサ－バ－
・マルチメディア
・インターネット／イントラネット

上の二つと下の二つを括ってもいいと思う。

オープン系／マルチベンダー化の先にクアランﾄサーバーがあった。オープン系／マルチベンダーの反対語は、クローズド化／シングルベンダーということになるわけで、これまでは、IBMと大手国産メーカーが自社のマシンに何もかも詰め込んでそれを一社だけでユーザに提供していたのであるSystem/370 、ACOS、FACOM、HITAC、TOSBACといった汎用機がよく知られている。

ぼくは、汎用機のことはよく分からないので詳しいことは書かないが、囲い込みという状況は感じられて、メインフレーマーの手厚いサポートを受けることが当然のようにやられていた。これが悪いと言っているわけではなく、両者にとって都合のよい関係だったのだ。すなわち、ベンダーは定期的に保守料をもらうことで安定した売上を得られること、ユーザは少々高くても専門家に任せれば安心できるということが暗黙の了解事項であった。

しかも、それを覆す選択肢もなかったし、まだまだ技術的にも未完成な部分ものこっていたためそうせざるを得なかったのである。

そこに、登場したのがWndowsPCであり、UNIX系ミッドレンジサーバーであった。1993年にスピルバーグにより映画化された「ジェラシックパーク」でUNIXのコマンドを打つシーンが出てきた記憶がある。

いわゆるダウンサイジングの波である。そして、単なるダウンサイジングではなく、形態そのものを変えてしまおうというクライアントサーバーの流れもやってきた。

実は最初この二つを混同する人がけっこういた。すなわちダウンサイジングでUNIXにマイグレーションして、端末にPCを使って、はいこれがクライアントサーバーですと言っていたひともいた。

ホストー端末とCSSの違いを理解していない結果である。要するにPCが高機能化してクライアント側で処理がある程度できるようになった結果として、こうした形態をとるようになった。サーバーとクライアントは違ったベンダーでもいいということでもあった。

このマルチベンダー化でコストもどんどん下がっていった。しかしながら、クライアントサーバー型のメリットは何なのかとか、そこでの開発方法は何かといったところがまだ議論があって、上述のように混乱していた。ぼくは、このクライアントサーバー型への変化よりもこのころ実は影響が大きかったのRDBMSではなかったかと思う。

1969年にE．F．コッド博士が提唱した関係モデルをベースにしたデータベースで、90年代初めくらいから従来の階層型のDBに変わって普及していったと思う。当時、RDMSはORACLEよりもIngresの方が有名でこれが後のPostgreSQLになっているんですね。

一方、Windows95はちょうどインターネットの登場と合わさるかたちで出てきて爆発的に売れた。ただ当時は、WindowsPCが企業システムの中のクライアントとしてやっと使われだしていたころだったので、まだすぐに導入とはいかなかった。まだ、Windows3.1の時代である。そこではその安定性や信頼性を問題視され、本当はWindowsNTにした方がいいというような議論もあった。しかし、このWindows95はその後どんどん企業システムのクライアントとして普及していったのである。

マルチメディアやインターネットはまだ研究しているという段階で、まずはイントラネットから入った方がいいという意見であった。要するに、セキュリティということが気持ち悪かったのである。そして、当時はこれほどまでになるとは予想していなかったので隔世の感があるのである。
　
こうして、徐々にメインフレームの閉じた世界から、オープンな仕組みへと変化していく曲がり角を感じていた。パソコンのクライアント化やインターネットがそうした変化を後押しした。

そしてまた、IT産業はハード主体のビジネスからソフトウエア主体へとこれまた変化していくのである。最初、情報システム部門に来たとき、それまでコンピュータシステムの値段が、ハードウエア一式いくらということで、ええーソフトはどこに入っているの、みたいなことでびっくりしたことがある。
　

この年は、工場のある製品の生産管理システムの構築プロジェクトをはじめた。生産管理というと、製造、試験、出荷という３つのジャンルにまたがるシステムである。基幹システムからオーダーをもらって、そのオーダーに従ってユーザ規格にあった製品を出荷していくというごくオーソドックスな生産管理システムである。

世はちょうどメインフレームのホストー端末からクライアントサーバーへ移行しつつあったので、われわれもその方式を採用することにした。しかし、問題があって、そのとき工場システムとしてAS400を使った設備保全などの部門システムが稼動していて、当初UNIXを使おうとしたが、まだ信頼できないと言われて、そのAS400を使えとなったのである。AS400をサーバにしたクライアントサーバーは世界でも珍しかった。CSBuilderというミドルウエアをかましてやったのである。

そして、開発方法をどうするかが非常に頭の痛い話であった。クライアントサーバーという新しい仕組みを使うなら、従来の方法ではなくその新しいプラットフォームに合った形のメソッドが必要だと考えたのだ。

ただ、CASEなるものもあったのだが、どうもしっくりいかない。RDBMSにORACLEを使うにしても肝心のDB設計をどうするのか。言語はCOBOLじゃなく４GL（第４世代言語）なら何を使ったらよいのか、バッチはどうするのかなどである。

まず、DB設計のことである。そのとき出合ったのが「T字計ER手法」である。これはSDIの佐藤正美さんが考案したDOAの手法で、ER図におけるエンティティの表現をT字型に記述することからそう名づけられた。

佐藤さんは元アシストだったので、当時のアシストの営業に教えてもらって、自分で佐藤さんのセミナーに行き、直接話も聞きながらこれでいこうと決めたのである。ぼくは、自分で開発も設計もしたことがなかったが、佐藤さんの話は強烈だった。分からないなりにいいものだと感じたのである。

そこでどういう風にコンサルを受けるかであった。お金もなかったので、「赤ペン先生」方式にすることにした。要するに、こちらでER図を書いてそれを添削してもらうという方式である。もちろんそのための講習を受けてだが、最初にビックリしたのは、こちらのプロジェクトの概要や仕様について説明しようとなって、名古屋で会ったときのことだ。

一生懸命計画書の説明をしていたら、途中でもういいからすぐにER図を書いてもって来いと言う。それを見れば、そんな説明を聞かなくても何を作ろうとしているのかすぐにわかるときた。で書き出したわけであるが、そう簡単な話ではない。かなり苦労したが、なんと設計することができ、その図を壁に張って開発を行なったのである。よくER図を見ながらユーザと会話してというけど無理ですね。やはりむずかしい。

次に苦労したのは、コーディングに入ってからである。結局、業務フロー図作成にXupper、RDBMSにORACLE、データモデラーにERwin、４GLにSQLWindows（のちにCentura）という組合せにした。ですから、SQLWindowsでコーディングするのだが、開発していくうちに、こりゃ期限までに終わらないという声が出てきたのだ。

そこで、急遽専門家を呼んでレビューしてもらったら、こんなふうにゼロから作りこんでいたのでは時間がかかってしまってしょうがないという指摘である。そして、クラスの利用を薦められて、それを購入してしのいだ。それでもかなり工期が後ろに倒れていった。そのクラスで助けてもらったのが、クラステクノロジーの四倉社長で、今もECObjectでがんばっているので陰ながら応援している。

さて、そんなわけで、新しいプラットフォーム、開発方法論で始まったプロジェクトはかなりの苦戦を強いられながら、進んでいったのである。
　

この年は、生産システムの開発に全力を注いでいたが、他にもいろいろな変化が押し寄せてきた。ダウンサイジングという波はすでに言ったが、EUC（End User Computing）という流れもあった。これはPCの性能向上と普及が背景にあるが、IS部門に頼んでもなかなかやってくれないというバッグログ問題も横たわっていた。

ちょっとしたシステムをホストでやるわけにはいかない、さりとてユーザはＰＣでまともなシステムの組みかたをしらない、といったせめぎあいの兆候がでてきた。そして、どんどんＰＣが入り込んできて、ＩＳ部門がその応対に苦労しだしたのである。何しろ数が多く、様々なユーザがいるわけだから、日々問い合わせやら苦情やらが対応できないくらいになる。

そこで組織したのが、「システム化推進員」である。課とかグループごとにパソコンに詳しい人間を1名それに任命するのだ。その人のところで、まずは一次切り分けをしてもらうことにした。まあ、「パソコンお世話係」といったところである。でもそれでずいぶんと助かった。

このPCの管理コストはばかにならなくて、当時TCO（Total Cost of Ownership）という言葉で語られたように、PCの保有コストという議論がおこり、ガートナーがPC一台あたりのTCOはPC価格の5倍であるというようなことをまことしやかに唱えていた。

一方でこのPC普及とともに、EUC（End User Computing）という流れも起こってきた。その象徴的なものが、Lotus Notesを使った開発である。これは割りと簡単にアプリケーションがつくれるので、エンドユーザ自らが開発できてしまう。

そこで議論が巻き起こったのである。どこまでやらせていいものかである。当時のIS部門は、そんなものはシステムではない、おもちゃみたいなもので企業のシステムはできない、セキュリティはどうなるのだ、運用はどうするのだ、といった消極論で、それに対してPCのスキルをつけたエンドユーザや工場のIS部門は、これまでのバッグログの問題もあったため、積極論であった。

結局、限定的な使い方にし、できるだけIS部門がAccseeやCSシステムを使って開発してあげることにした。それがよかったか悪かったかよくわからないが、いまNotesが普及した会社はその保守とマイグレーションで困っていると聞く。

EUCの問題は、作るのは手軽にできるが、作った人が転勤になったらどうするのかという保守にある。手に負えなくなった資産があふれてくるのである。

ただし、この問題は、いままた出てくるように思う。例えばSaaS型で簡単に業務アプリを取得できるようになってくるとエンドユーザが直に使い出すからである。こういった、これまでと違ったタイプのEUCはどうなるのかという議論があるように思う。

さて、工場の生産管理システムは何とか動いたのだが、どうしてもできなかったものがあった。それは、生産計画システムであった。正確に言うと生産計画というより、製造スケジューリングといったほうがいいかもしれない。

販売計画に基づき、最適化された稼動スケジュールを描くというものである。反応釜がいくつかあって、キャンペーンごとにそれらを切り替えながら製造する。さらにそれを入れるサイロ繰りもスケジューリングする。

これが難しいのだ。まあ、スケジュール問題はとくに最適化の要素が絡むとかなり難しくなる。当初は、AsprovaだとかArtemisだとかいったソフトを買ってきてやろうとしたが予算の関係上買えないことがわかり、それじゃあ最適化を諦めて単なるスケジュール作成システムにするかと考えた。

最適化を入れるか入れないかでぜんぜん違ってくる。後年、この難しさから、私はケーススタディができベターケースを人間が選択すれば十分じゃないかという考えになった。

ところが、そのとき名古屋のあるベンチャーがやりましょうと言ってきた。それもイスラエルのソフトを使ってやりますという話である。研究的要素があるので安くやるということに目がくらみ開発を始めた。しかし、2年経ってもできなかった。これはにがい思い出のひとつである。

さて、この年の半ばに工場のシステム部門から東京本社の情報システム部長に転進した。この組織は協力会社のひとを含めて120人くらいの所帯である。東京は主にメインフレームを使った基幹業務システムの運用管理である。

まだ、赤坂の一等地の地下にコンピュータ室があって、何人かのオペレータがいた。いやー、メインフレームの経験がないのでこんなものかと思ったが、なにか重厚な感じがしたものである。

そのころの開発にSFAがあった。確か人事が主宰して事務部門の効率化プロジェクトみたいなものを立ち上げた。そのなかで営業部門のシステム化がテーマになった。営業情報が属人的になったり、上司に報告がいかなかったり、そんな問題を解決しようとなったわけである。

そのとき営業支援ソフトを導入して、営業日報の記入と共有化を行なうのがいいとなった。ところが、最初のころはよかったのだが、だんだん使われなくなってしまった。

そこでなぜ使われなくなったのかをいろいろ考えてみた。実際の現場の営業マンや営業部長などにも聞いてみたのだが、どうも現場の営業マンが営業日報を書かなくなったのがそもそもの発端で、なぜ書かないかというと書いてもそれが上司のためだけであって、自分の役に立たないということが理由のようだった。

要するに、日報を書くインセンティブが書く本人にないことに起因しているのだ。せっせと上司に報告するだけで、しかもそこから的確な指示が出るわけでもないとなるとモチベーションが下がりますよね。そんなわけでほとんど使われないというまたまた苦い思い出になった。

ところで、いまSalesForce.comが注目されていますが、うまく使えているのだろうか。
　

この年はなんと言っても「Y2K」であろう。いわゆる2000年問題である。これはずいぶんと脅された。ニュージーランドではもはやこの問題で工場で事故があったとか、いろいろと煽り立てられた。

社内に対策委員会をつくり、事務用コンピュータから制御用コンピュータ、あるいは組み込み型システムまで網羅的にやった。

結局、ホストはプログラムをなめて直していった。困ったのは、工場のプラント管理のコンピュータでまともな対策をすると大金がかかる。そこでどうしたかというとコンピュータ内の時計を戻したというようなトリッキーなこともやった。非生産的ところに大きなお金をかける気がなかった。

会社によっては、2000年問題のためにERPにリプレースしたとかいう話もあったが、大きな投資をせずに乗り切った。もちろん、1999年の大晦日から2000年正月までは泊り込みで徹夜で監視した。

社長も陣中見舞いに来てくれた。ほとんど何もなく年を越したのである。全国的にも大過なかったのである。あの騒ぎはなんだったのだろうか。

そして、この年から分社化の検討に入った。機能分社という言い方で、間接部門を本体から切り出して子会社化することである。対象となったのは、物流、設備管理、試験分析、人事総務サービス、そして情報システムである。

こうした場合、最初の方針や理念が大事である。すなわち、なぜ分社化するのか、その目的は、どういう事業ドメインにするのか、プロフィットセンターなのかコストセンターなのかといったことである。

ここの軸がぶれないように気をつかった。何より問題は人の問題で子会社に出向していく人たちの処遇の問題やモチベーションの維持，評価基準などをどうするのかである。

もうそのころのIS部門はかなり専門化しており、また本体との人材の交流も少なくなってきて、その道で生きていこうというひとも少なくなかった。そうした人にとっては分社化は覚悟を決めるきっかけになるが、そうでない人にとっては悩ましいことになる。そこは、本体との行き来は残すことで分社化に踏み切ったのである。

もうひとつ悩ましかったのは、プロフィットセンターかコストセンターかである。親におんぶしてもらわないようにできるかということである。これは簡単なことではない。

しかし、プロフィットセンターを目指さない分社はありえないと考えた。何よりも、従業員のモチベーションがあがらないという問題が残る。利益を出さなくてもいいという会社はあるのかという思いで、プロフィットセンターとして出発することにした。

しかしながら、すぐに外に行って利益をだすことなんてできないから、当面は親からのミルク補給で力をつけ、何年後に自立するという絵をかいたのである。それは、親会社依存率を下げていくことを意味している。

あまたの情報子会社はこの親会社依存率を下げる過程でかならず大きな谷にぶちあたる。簡単にいえば、自立するための教育投資やインフラ整備といったリソース確保のコストが高くなり急激に収益性が悪化するのである。その谷を乗り越えられるかが勝負である。

でもだからといって親会社の仕事だけをやっていても面白くない。そのときのロジックは、外で儲けられないような技術・サービスを親会社に提供したら、結局コスト高ということだから、そんなことは親は望まないはずだ、というものであった。

まあ、そんな議論を繰り返しながら船出した。この分社化はただ分社したわけではなく、その会社が強くなるためのいくつかの施策を考えていたのである。この話は、2000年のところでする。
　

さて、この年の初頭に分社化をする。全員出向というかたちで新会社に移籍した。

企業理念や経営方針といったものは重要ではあるが、情報子会社だから自ずからだいたい決まってくるので、むしろどういう形態の会社にしていくかが難しい。提供サービスを何にするのか、誰を顧客とするのか、人材育成をどうやるのかといったことをきちんと決めなくてはいけない。そして、前回にも言ったが“自立するとは、あるいは自立できるのか”を追求していく必要がある。

当たり前ですが、まずは親会社にとってメリットがある子会社になるのが最優先である。それはコスト削減に他ならないのである。

実は、1980年代に分社化ブームみたいなことがあって、その時はどちらかというと多角化という考え方だったように思う。ですから、コスト削減というより、新規事業創出といった文脈で語られていたと思う。しかしながら、そうした情報子会社で企図したように育った会社は少なかった。従って、2000年における分社化の目的はコストダウンにならざるを得ない。

それとも関連するが、単体経営から連結重視へと変わるときでもあったことが影響している。グループ経営という考え方が前面にでてきたのである。

当時はまだグループ会社はIT部門があるところはほとんどなく、しかもIT化も遅れていた。連結経営では、こうしたグループ会社の収益が相対的に重要さを増すわけで、それにはITによる経営効率の向上が望まれることになったのである。

そこで出てきた当面の施策はこうしたグループ会社への貢献を目的としたもので、親会社の情報子会社がグループ会社のIT化を促進させることになる。

ですから、ターゲットはグループ会社です。そして、そこに対してどういったサービスをどのように提供したらよいかになるわけです。その時、打ち出したのが、「Total Solution Provider」、「Application Service Provider」、「Outsaucer」という概念です。

要するに、IT部門を持たないところにはなんでもトータルで面倒みてあげることが必要である。

さらに、自分たちのところにシステムを置いて運用管理はできないから、業務アプリケーションをネット経由で利用させることにした。当時は、まだASPという言葉もあまり聞かれないし、実際にやっているところはほとんどなかった。あるベンダーにこの計画を話したときにそこの社長が「ああ、本当にやろうとしている会社があるんだ。まだ言葉だけかと思っていた」といわれたことを覚えている。

今では、SaaSというかたちで定着しているが、当時は手探りで始めたのである。ネットワークの敷設から、PC配布、Web化などなど大変苦労した。

さらに、アウトソーシングという考え方である。これには、二つの方向があって、受けるほうと出すほうである。どういうことかと言うと、グループ会社に対しては、アウトソーサーとして振舞うが、自分たちの業務で外に出せるものはアウトソーシングするという形である。

実際にもグループ会社には、システム運用から業務アプリケーション、OAに至るまでのフルアウトソーシングを指向し、出すほうとしては、メインフレームの運用を大手ベンダーのアウトソーシングサービスに出したのである。

このアウトソーシングは、単なるコストダウン(大幅なコストダウンを達成した)だけではなく、分社化後の重点はメインフレームの運用といったような守りの業務から、グループ会社の開発も含めた業務系へと移す必要があったため、リソースの再配分をおこなったのである。

こうして、コストダウンを図りながら、一方でその原資の一部を使い、グループ会社向けの業務アプリケーションパッケージを導入していったのである。このあたりの話は次回にする。
　

前回書いたようにその頃からこれまでの単体経営重視から連結決算、グループ経営重視に舵が切られていた。会計監査ももちろんそういう見方になった。すなわち、親会社の損失を子会社につけまわすなんてことができなくなったのである。

これは、大きなインパクトで、親がちゃんと子の面倒をみなくてはいけないということなので、それまでは、論功行賞的な人事で子会社の社長を充てていたのを、きちんと経営できる人材を送り込まなくてはいけないというふうに変わっていった。実務的にも親会社のリソースやノウハウを子会社にトランスファーすることが求められるようになった。

情報システムに関しても、前回書いたようにグループのアウトソーサーとして振舞うことが重要になった。アウトソーサーというと、どちらかというとインフラを考えてしまうが、インフラだけではなく、アプリケーションの領域まで拡大する必要があった。そうなると、共同利用になるわけだから、標準のアプリケーションを設定して、それらを各社が使いまわすことが効率的である。

当時は、一部親会社のメインフレームの業務システムを子会社が使うことをやっていたが、それをこれから拡張するわけにはいかないので、新たな共通システムをもってこなくてはいけなくなった。

さて、それをどう調達するのかである。それというのは、基本的には製造業なのでサプライチェーンの仕組みである。選択肢としては、手組みで作るか、パッケージを買うかである。もちろんまだ、SaaSという形態はなかった。その当時の雰囲気はもう手組みの時代ではない、パッケージを使って安く早く作る方が得策であるということであった。

そして、ある中堅ベンダーのパッケージを決めてそれらをカスタマイズして使うことにした。しかも、Javaで走るWeb対応のもので、ASP型のサービス提供である。おそらくこんなことをやっていたところはほとんどなかったのではないだろうか。案の定、大変苦労して何とか動かした。苦労はパフォーマンスの問題が大きかったが、開発で各社の要件をどこまで入れ込むかといったことも難しい問題であった。

連結重視のグループ経営といってもまだまだそれぞれの会社の固有性や“癖”みたいなものを無視するわけにはいかないし、どうしてもカスタマイズが発生してしまう。

このあたりが非常に難しいところで、標準と固有のバランスをどうとるのか、標準に寄せるときのガバナンスをどう効かすのか、ずいぶんと悩んだものだ。

で結局、そのパッケージは数社に入れたあと、もっと自分たちの融通が利くようにするため、自前のパッケージを作ることにした。もともとそうした技術力はあったが、コストとのかねあいでパッケージ導入に踏み切ったのだが、変更が多くなるとそのための期間とコストもばかにならなくなるため、かえって自前のものにしたほうがよいという結論になった。

これは、モチベーションの問題にも関係していて、お仕着せのものから自分たちで作り上げることで意欲も上がることが大きかった。

そんなわけで、開発フレームワークを作り、それをもってグループ会社へ展開したのである。

前回と同様グループ経営のためのIT化の話になるが、象徴的なシステムであり、標準化、統一化しやすいものに連結決算システムがある。連結重視というなら連結決算の状況がいち早く見える仕組みがいるのは必然でもあった。

従来は、メールでExcel表を添付して送ってきたり、郵送で来たりした。また、決算期も違っていたりして、海外の会社もあり、その集約と整合にものすごく苦労していた。本社経理部の若手は5月の連休中もずっと計算に追われる。新入社員が入ってくると連休は休めないものと思えというのが最初の先輩のアドバイスである。

そして、その連結の計算を早く仕上げることが大きな課題となったのである。そのプロジェクトを1年前に立ち上げていて、そのスローガンが「ゴールデンウイークを休もう」である。

で結局作ったのは、「グループ経営情報システム」というWebサイトを立ち上げ、そこにまず決算の情報を流すようにした。期日だとか前提条件だとかいった情報をその掲示板に載せるのである。そして、そこから、統一されたフォーマットでできた決算データ記入シートをダウンロードさせるようにした。そこには、前年どの実績値などを脇に示して入力の支援をしたりした。このシートはもちろんExcelである。ほんとうにExcelは重宝である。だれでも使えるし、インターナショナルでもある。

このシステムと、ガバナンスにより、決算が連休前にできるようになったのである。だから、ぼくらは決算発表がすぐにできると期待したのだが、意外な障害があって連休後になって残念な思いをした。

さて、この年に基幹システム用のフレームワークはできたが、それ以外の情報系をどうするかがあった。そのための開発基盤や使用ソフトウエア、さらに開発手法などが議論された。この領域は、みな好き嫌いも含めて、一家言あって、やれNotesだColdfusionだ、.netだとかまびすしい限りだ。で結局ここにBPMを導入したのである。

ぼくは、もともとシステム屋ではなかったのでプログラムを書いたことがないので、コードも読めないし中味はよくわからない。それで、プログラマーの人に最初に聞いたことは業務にはワークフローという機能が必ずあるよね、それはどうやって書いてあるのということであった。そうしたら、システムごとにプログラムで流れを書いているような答えだった。そのとき、それを抜き出せないかなあと思ったのがきっかけであった。機能とプロセスの分離である。

データについては、1996年のところで書いたようにDOAを試行したこともあって、その限界みたいなものもわかってきた。すなわち、T字形ERでは、イベントデータを上にリソースデータを下に書いて、イベント系は時系列に並べていくというのが基本で、これにより業務プロセスも表現していると言われたが、それだけではよくわからないと言うのが正直なところだ。少なくともユーザにはなかなか理解してもらえない。

そんなこともあって、プロセス的な指向が必要と考えていたとき、BPMSであるSavvionに出会いそれを使うことにしたのである。そして、そのBPMSのアクティビティをどうするのか、画面をどうするのかが問題になった。

そこをいろいろ考えていたとき、ある外注のプログラマーのひとからデータコンポーネントという考え方が提示されて、思わずひざを打ったのである。データコンポーネントというのは書類のイメージと思えばよくて、その書類上にデータを転記していって書類を完成させ、それらをSavvionでつなげばプロセスになると思えたのである。

じゃあ、そのデータコンポーネントを何で作り、どうやって結ぶかが問題であった。結局、当時Webサービスが出てきていてそれでつなぐことにして、それに対応を表明した.netを使ったのである。この仕組みを使って、PCやプリンターなどのIT調達のプロセスを開発したのである。ただその後ERP導入のプロジェクトがあったりして進展しなかったのが残念であった。

BPMも浸透してきたので、この経験が生かして、多くのBPMアプリケーションが作られることを支援したいと思っている。
　

２００３年は、本社のＩＳ部門に来てから５年経過したことになり、それまでいくつかの施策を実施したが、それをまとめる意味で全体像を作っていった。いわば、自分なりのＥＡ（Enterprise Archtechture）である。

その前に、情報子会社としての体力強化のようなことを実施したことを書いておく。絵を描くだけだと餅になってしまうので、それぞれの分野で競争力のあるものにしていかなくてはいけない。そこで始めたのが「チャレンジ３０」という運動である。

工場も含めてやったが、本社主体のものでは、開発生産性３０％アップ、システム運用コスト３０％ダウン、売り上げ３０％アップといったものである。この数字にこだわることがミソで、単に効率アップ、売り上げ増大といったところで、お題目だけになってしまう。ですから、より具体的にイメージできるようにするには、こうしてがんばれば到達できる目標値を提示することが大事なのである。

目標数字があると、まず現状の数字を見ることになる。それがいことで現状分析をしっかりやって、３０％アップというのがどのくらいのマグニチュードであるかを把握できる。それだけでも効果的だが、さらに実効をあげさせるのである。そこでは、実際にお金に換算することと期限を設定することを忘れてはいけない。

そんなことで、いろいろなアイディアを出して、その中から実行案を作ったのである。ただ難しいのは、自分たちだけだと技術的な深堀に限度があったり、そこまで検討している間に新しい技術が登場したりということがあり、かなり限定的なものになってしまったが、みんなで様々な角度から議論したということは大変よかった。

さて、その我流ＥＡであるが、ＥＡを作ろうという意識より、前にも何回かこのブログでも言っている「構造化」を全体に関してやってみようということであった。

まず、大きな括りとして、提供するものとしての「ソリューション」と「サービス」があり、それを支えるシステム基盤として４つのレイヤーを設定した。「業務アプリケーション」、「システム開発」、「システム運用・管理」、「インフラ」の４つである。

それぞれ、もう少し詳しくみていくと、ソリューションもまた二つに分けることができる。業務別ソリューションと業種別ソリューションである。

業務別というのは、基幹業務と非基幹系があって、非基幹というのは業務支援系といってもいい。その他には、現場系のもの、すなわち工場の生産や小売業のPOSとか銀行のATM、運送のトラッキングなどがある。これらは、業種別ソリューションに含めてもいいかもしれない。

次にサービスであるが、業務アプリケーションをサービスするという意味でASPがある。当時はまだSaaSはなかったので、いまではSaaSかもしれない。あとは、システム環境を提供するデータセンターや運用も含めたアウトソーシングサービスもある。

このあとのシステム基盤については次回に書くことにします。
　

さて、ソリューションやサービスを提供するためには、システム基盤が整備されていなくてはいけません。最初の業務アプリケーションレイヤーでは、業務アプリケーションそのものとそれが動くプラットフォームがあります。

業務アプリケーションはその昔は手組みが基本でしたが、その頃にはパッケージも出てきましたし、アプリケーション間の連携もできるようになりました。ですから、そのアプリケーションをどうやって調達するのかどうかの方針を決めておく必要があります。「作る、買う、つなぐ」の考え方で、今ではそこに「借りる」が追加されるようになりました。

プラットフォームに関しては、コンポーネントという考え方とハブという考え方を採用しました。コンポーネントというのは、業務的には伝票一枚から給与計算システムのようなものまで、システム的には、データからプログラムモジュールまでを言います。

実は重要なのは概念的な規定で、そのときは、“変わらないもの”をさして、その単位がコンポーネントであるとしました。ですから“変わるものは、変わらないものの組み合わせ”であると考えたわけです。

また、ハブということで言うと、連携や協調がこれからは必要ということで、そのためには、ハブ＆スポーク型の構造が必須と考えました。

その必要性をもう少し具体的に言うと、バケツリレーの排除、インターフェースプログラムの削減、変換ロジックの一元管理、開発生産性の向上といったところでしょうか。
ハブの種類はいろいろあって、データのハブがEAI、機能のハブがBPMS、帳票のハブもあってという感じです。

さて次に開発技術のレイヤーです。ここでは「作る技術」と「つなぐ技術」があります。つなぐ技術は前述のEAIやBPMSを使いこなす技術となります。作る技術は、どういう言語で、どういうフレームワークを使うのかとなりますが、ただひとつに統一するのではなく、対象アプリケーションの種類によって変えるほうがよいと考えました。

ざっくり言えば、基幹系にはJAVAベースの自社開発フレームワークとして、情報系については.netベースにしました。あと悩ましかったのは、製造会社だったので、工場のシステムどうするかであった。

基本はリアルタイムデータベースを中心にした仕組みにした。基本機能は、DataLinkといって、リアルタイムのデータやヒストリー値や期間計算値などを高速読み出しできることとProcessBookといってビジュアルな作図・表示機能でリアルタイムトレンドがわかることである。

この仕組みは、プラントの監視には強力なツールで役に立った。いま、こうした仕組みをビジネスプロセスにも適用できないかを考えている。

さて、次は運用管理の構造化です。運用管理で構造化というのもおかしいかもしれませんが、体系の整理という意味でも大切なことだと思います。

そうした体系では大きく2つになります。ひとつは、ITIL準拠の統合的な運用管理体系を確立することです。もうひとつはセキュリティ体系です。

統合運用管理は、ITILに従ってやるのがいちばん分かりやすいのですが、なんでも全部適用することは現実的ではないと思います。成熟度の高い企業ならいざしらず、普通の会社では、サービスサポートではCMDB（Configuration Management DB）の構築、サービスデリバリーでは、SLA（Service Level Agreement）の確立をやっておけば最低限それでいいと考えました。

CMDBというのは、システム構成データベースのことで、簡単に言えばIT資産管理台帳である。ハード固有情報や、所有・移動情報、保守記録などの静的情報と、稼動OS、メモリー、HD容量、IPアドレス、使用アプリケーションなどの動的インベントリー情報を収集する。

これには、市販のIT資産管理ツールを買ってきましたが、固有のAP識別子が取得できないとかいう問題があったりして、かなりカスタマイズして使った。だが、これでやっとITリソース状況がつかめるようになり、不要ライセンスの削減などの効果を上げました。

セキュリティについても、重要なのは小手先の対策ではなく、ちゃんとセキュリティポリシーを作成し、リスクアセスメントをし、それに基づく技術的対策というかたちでまとめる必要があります。

そして、データ・アプリケーション・OS・ネットワークのそれぞれに対して、予防・検知・回復という観点から構造的にアクセス制御、認証や冗長化といったような具体策を講じることが大事です。

さらに運用ということだと、アウトソーシングかインソーシングかという問題があります。どういう運用の機能を外出しなのか自分たちでやるのかです。

結局、ホストコンピュータの運用はベンダーのデータセンターにアウトソーシングした。このとき、機種もアップグレードしたにもかかわらず、相当なコストダウンを図ることができた。従って、情報化戦略立案は親会社にもたせ、それとホスト運用以外の機能を分社した情報子会社がもつようにしたのです。

さて、最後は情報インフラの構造化ということになります。ここでも大きく２つに分けられます。すなわち、ネットワークとサーバー／クライアント／ストレージです。

ネットワークでは、基幹系と情報系という分類があります。ここで採用したのは、基幹系はIP-VPNで情報系はインターネット-VPNです。ミッションクリティカルなものについては安定性のあるネットワークにして、グレードを落としたところを情報系にしています。

次に、幹線と支線という分類もあります。幹線はトラフィック量が多いのでそれなりの容量のものを用意する必要があり、広域LAN、メトロイーサを充てました。支線はIP-VPNかＢフレッツです。その他、常時とバックアップ、データと音声という切り分けも必要になります。

次は、サーバー／クライアント／ストレージということになりますが、ここは当時の考え方のポイントは集約化ということでした。集約も器の集約と設置場所の集約の二つがあります。これは要員の効率化による運用コスト削減が目的です。

これが当時はけっこう悩ましいところであって、徐々に集約化していきましたが、ここの領域はクラウド化や仮想化技術の登場、そして、圧倒的なハードコストの低下があり大きく様相が変わってきているところではないでしょうか。ですので、ここでは多くを語ることはやめにします。

これまでかなりはしょって書いてきたので分かりづらいところがあったかと思いますが、一応２００３年度をもってこの「私家版業務システム変遷史」を終わります。

実はこのあとＳＡＰ導入プロジェクトがスタートすることになったのですが、それについてはまだ生々しいことと途中で会社を辞めたこともあり、書くことができないということです。

いまこうして５年前までを追いかけてみたわけですが、５年前と今とどう変わっているのだろうかと考えている。最後に書いたように情報インフラは劇的に変化しているように感じられます。そのほか、運用やアプリケーションプラットフォーム、開発技術なども新しい技術やサービスがどんどん出てきているように思います。

しかし、業務システムそのものは構造的にもコンセプト的にもほとんど変わっていないとうのが偽らざる思いです。

ところが、最近あるところでオラクルとＳＡＰの今後の戦略のようなことを聞く機会があったのですが、この２社以外にもＩＢＭやマイクロソフトを含めて、彼ら外資系ベンダーの変貌ぶりに驚かされています。おそらく、業務システム構築という領域でのパラダイムシフトが早晩やってくるように思えます。

それに伴うビジネスモデルも違ったものになっていきます。単なるソフトウエアライセンスビジネスは縮小均衡に入っていき、さりとてシステム開発費用もソフト･ハードの低価格化によりどんどん下がっていく中で、どこに収益源を求めるかが最大の課題になってくるのではないでしょうか。

それに比べて国産ベンダーやわが国の対応はどうなっているのでしょうか。少なくともぼく耳には敏感に反応しているという声は入ってきていません。だいじょうぶでしょうか、少なからず心配になってしまいます。（ぼくが心配するようなことではないか）

パラダイムシフトのキーワードは「プロセス指向」「ＳＯＡ指向」です。こうしたことが簡単に実現できるプラットフォームや、そこで使うサービスが提供されてきます。このシリーズでも出てきた、柔軟でアダプティブ構造化が進み、業務アプリケーションやサービスの「作る・買う・つなぐ・借りる」が容易になってきたわけです。

ですから、こうした動きに対してますます重要性を帯びることはいったいなんだと思いますか。確かにサービスやテンプレートはリポジトリー化され、好きなようにひっぱり出せるようにはなるのですが、ではどんなサービスを選択するのかはどうして決めるのでしょうか。

それには、自社の事業を適正にプロセス化することがもっとも重要なことになります。そこではじめて要求されるサービス機能を的確に選択できるわけです。まずは自分たちのプロセスありきです。これはいくらいいプラットフォームがあっても提供してはくれません。

従って、これからの業務システム構築の主戦場は業務プロセス設計と業務ルール管理になってきます。そんな予感がします。