メイン

企業情報システムのかたち アーカイブ

2007年4月28日

企業情報システムのかたち(1)

はじめに

企業情報システムに関して、これまで「ユーザ目線のBPM」と「ビジネスコンポーネント指向開発」というテーマで書いてきたが、これらはどちらかというとHow Toに近いもので、その前にそこに至った背景というか、全体感があってこそ意味があることになる。すなわち、その会社の情報システムをどんな「かたち」のものにしたいのかを明確にしておく必要がある。
それってEA(Enterprise Architecture)でしょという声が聞こえてきますが、確かにそうなのですが、何かEAと言ったとたん、すごく難しいような気がしてしまいます。もちろんEAの思想や体系は参考にしますが、もう少し気楽に考えようというのがここでの趣旨です。

簡単に言えば、会社のなかの業務にはどんなものがあるのか、その業務遂行にはどんなシステムが必要で、そのシステムの構造をどうするのかがあり、それをどのように開発して、保守・運用していくのかを明らかにすることである。まあ、全体を構造化すると言ったらいいとも思う。

EAに比べるとはるかに泥臭いし、もう少し「ヒト」の問題にも焦点をあてるアプローチである。結局、すばらしい体系や基準を作ってもそれを実現するのは人間である。しかもすべてが優秀な人間ばかりではないので、いかにその会社のリソースに見合った構造にするかが大事なことである。

なぜ、いま構造化が必要なのだろうか。それを解くキーワードは「SpeedとReach」と考えています。ご承知のようにビジネス環境の変化はものすごい早さですし、ITもどんどん新しい物が出現しています。また、インターネットの普及により販売先や取引先は場所を選ばなくなり、コミュニケーションの相手はすごい拡がりを見せています。こうした、環境変化に迅速に対応しないと企業としての存続が危ぶまれることになります。

そのためにも変化対応力に富んだ柔軟なシステム構造にしておかないと、ITが経営の足かせになるなんてことも起こりえるわけで、早い段階に構造改革に着手しないと大変なことになるのである。というわけでこれから「企業情報システムのかたち」というタイトルで“美しいかたち”について一緒に考えて生きましょう。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%894.JPG

2007年4月29日

企業情報システムのかたち(2)

構造的な問題

まず、現状の企業情報システムの構造的な問題を考えてみよう。

大きく3つの問題があるように思える。ひとつは、システムそのものの構造の問題である。従来のメインフレームで作られたシステムをいまだに引きずっているものがけっこうあると思う。密結合でかっちり作りこまれたもので、ホスト集中からオープン分散へ変わっていっても概念的にはホスト集中の思想から抜け出ていないような気がしている。そこが、SOAやBPM、SaaSなどのコンセプトが登場した理由なのだ。すなわち、疎結合で柔軟でアダプティブなつくりにし、前回指摘した変化対応力を備えた戦えるシステムにしたいというのがこれからの方向性になる。

2番目の問題は、情報システム部門あるいは情報子会社とメーカーあるいはベンダーとの関係です。この問題は、「ユーザ目線」で論じているのでこれ以上言わないが、所詮“同床異夢”の世界であるという構造的な問題を抱えているということに立脚して、どうやったらWin-Winの関係ができるかという議論になる。

さて最後の問題は、情報システム部門のヒトの役割あるいは組織のありかたの問題である。企業におけるIS部門の位置づけはどうなっているのだろう。もちろん、一概にどこの会社も同じであるとは言えないが、ITが会社の中枢を担っているようなところを除くと、悲しいかなIS部門の地位はそんなに高くないのではないでしょうか。このあたりの議論は人材活用や分社化の問題などとあわせてあとで行ないます。

ところで、この構造化するということはどういうことなのかもう一度おさらいすると
(1) 全体を俯瞰したうえで、構成要素に分解し
(2) それらの構成要素間の関係をわかりやすく整理し
(3) 統合化されたモデルを作ること
と定義したい。

ということで、まずは企業経営・業務モデル化を行い、その経営・業務モデルに対応した企業情報システムモデルができるということになる。

そして、そのモデルを実現できる実際のアプリケーションやサービスのラインアップを行い、次いでシステムの構造化、そして運用や体制も含めたシステム基盤構築へとつなげていくことが本当の意味の構造化ということになる。

さて次回は企業経営モデルをどう考えるかという議論に入っていきましょう。

2007年4月30日

企業情報システムのかたち(3)

業務機能の分類

企業の業務プロセスは大きく2つに分かれる。コアプロセスとサポートプロセスである。コアプロセスというのは、文字通り会社の根幹をなす業務プロセスで、その会社の商品・サービスを企画・開発して、生産あるいは仕入れて販売するプロセスをいう。会社のメインのPDCAサイクルをまわす業務である。

それに対してサポートシステムはこのコアプロセスが円滑に機能するようにサポートするプロセスである。そのなかでも性格上いくつかに分類できる。まずは意思決定支援のためのプロフェッショナルサービス、例えば、法務や税務などの業務である。そして、サプライチェーンをサポートする環境管理、物流管理、設備管理、品質管理などの業務がある。それと、定型業務である給与計算や福利厚生サービスあるいは汎用購買などの業務がある。情報システムの運用サービスもこの定型業務に含まれる。

そして、このサポートプロセスは、機能分社されたり、シェアードサービス化あるいはアウトソーシングしたりできるので、その会社の実態にあった形で外部化した構造にすることになる。

また、コアプロセスでは、複数の事業の集合である場合が多いし、グループ企業と一体となった経営が行なわれているが、その場合は事業執行部分を縦糸にサプライチェーンサポートを横糸にして、上下を戦略的かつ統制管理的な機能と定型業務機能がサンドイッチする構造になっていく。

そうした構造を図示するが、この図は主として大きな製造業をモデルにしている。しかしながら、非製造業や中堅企業にあっても基本的にはこのような構造になるのではないかと思う。少なくとも骨格は同じようになり、肉の付き方が様々ということではないでしょうか。

次回は、この経営モデルに従って企業情報システムがどのようにかぶさっていくのかを見ていく。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%892.JPG
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%893.JPG

2007年5月 1日

企業情報システムのかたち(4)

企業情報システムモデル

さて、会社の業務の構造ができるとそれにかぶさるように必要な情報システムの姿が見えてくる。

グループ会社全体の管理統制の部分では、経営に必要な情報が集められ、ガバナンスを効かすための意思決定支援の仕組みが重要となる。細かい情報より正確なマクロ情報が経営者にと届けられることが望まれる。

従って、データウエアハウスのような情報活用のシステム化が必要となる。なお、法務や税務のようなプロフェッショナルサービスはシステム化しにくい領域であるが、プロの判断を助けるような情報提供の仕掛けあたりが可能性がある。

事業執行の部分では、SCM(Supply Chain Management)が主体となり、ここはERPがカバーする領域でもある。このなかには、製造業ではプラント制御や生産管理システム、金融業ではATM、流通業だとPOSなどが含まれるが、これらについてはそれぞれ個別の要件なのでここでは議論しない。

サプライチェーンサポートでは、コアプロセスのシステム化が先行しているが、それでもパッケージを適用した管理システムの導入が行なわれている。ただし、今後は各社特有のものがあるため柔軟なつくりが求められているように思える。ですから、このような領域は、いまはパッケージベースですが、「CMS+BPM」による開発が適用できる可能性が大きい。

あと最近重要なのは、顧客接点と従業員サービスです。まさにここはWebアプリケーションによる情報共有の仕組みが大事になります。最新のインターネット技術やサービスを大いに活用する領域でもあります。
こんな感じで大づかみの企業情報システムの構造が浮かんできます。

次回から、こうした仕組みを実現していくためのソリューションやサービスといった話へと進んでいきます。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89A.JPG

2007年5月 5日

企業情報システムのかたち(6)

業務アプリケーションの構造化

業務別あるいは業種別ソリューションのための業務アプリケーションをどのような構成でどうラインアップしていくかということになる。これまで述べたように業務プロセスもミッションクリティカルなものから、しょっちゅう変更を余儀なくされるものなど様々であり、こうした業務プロセスの性格に応じた作りにすることが重要となってくる。

大きく固定的業務プロセスと変動的業務プロセスに分けられる。固定的業務プロセスというのは、例えば、決算システムのように会社を運営していくための根幹の業務プロセスはビジネス環境が変わってもそう大きく変化するわけではないものをいう。一方、変動的業務プロセスというのは、顧客接点の業務など変化が激しいものや、競争優位を保つためにあえて変えていく業務プロセスなどである。

固定的な業務プロセスに対するアプリケーションを開発する場合は、自社のもつデータの解析、特にリソースデータは自分たちがビジネスで戦っていくための原動力なのできちんと整理し、データベース化することが大事だ。そこから堅牢なシステムができてくる。変動的な業務については、変更が容易な、要するに簡単に安く早く作れる構造にしておくことが望まれる。

「ビジネスコンポーネント指向開発」という提案で、コンポーネントを「書類のライフ」とみたてて、それらをBPMで組み合わせて開発するとしているのは、特に変動的な業務プロセスに対する簡単に安く早く作れることをめざしたものである。

ここでビジネスコンポーネントであるが、狭義の意味では「書類のライフ」としてみたが、広義の意味では、固定的業務プロセスに対するアプリケーションそのものもコンポーネントと呼べないこともない。例えば、会計パッケージなどはそのものをコンポーネントとして隠蔽してしまってもかまわない。

“変わるもの(業務プロセス)は変わらないもの(コンポーネント)の組み合わせ”といえるので、コンポーネントには大きなものから小さなものまで様々な粒度がある。その粒度を決めるのは、いかに固定・変動の区分けができ構造化できるかになってくる。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%897.JPG

2007年5月 6日

企業情報システムのかたち(7)

業務アプリケーション調達方針

さて、業務アプリケーションをどうそろえていくかを検討しなくてはいけない。今は、全部自前で作りこむ会社はないでしょうから、自作しないで買ってくるだとか、借りてくるだとかの選択も行なっていくことになる。

買うというのは、出来合いのパッケージを買ってくることで、借りるというのは、最近登場してきたASPやSaaSのように使用量・頻度に応じた従量料金を払うことでサービスを利用することをいう。そういう意味では以前から比べると選択の幅がかなり広くなったといえる。

それぞれの選択の基本的な考え方としてはつぎのようになる。まず、買ってくるのは、たいしたカスタマイズをせずにそのまますぐに使えるもので、作るよりも安価であり、再利用をしないようなものが対象となる。例えば、業種・業態別給与計算パッケージなどである。

借りてくるのは、変化が激しくいつやめるかわからない機能だとか、法制度等の変更が頻繁で個別にメンテナンスがやってられないものなどである。例えば、特許情報などです。

ですから、それ以外、例えば自社固有のこだわり機能が多いものや、1回作ったら再利用先がいっぱいあるものだとかは自社開発となる。

こうした特性を見ながら対象業務アプリケーションを調達あるいは開発をしていくが、忘れてはならないことは、ラインナップされた業務アプリケーションが孤島システムにならないようにうまく繋いでいくことが非常に重要であるということである。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%898.JPG
「作る」「買う」「借りる」のバランス、そしてそれらを「繋ぐ」連携が大事であるといえる。このマクロ的なシステム基本構造がSOAの概念で作られるイメージです。基本構造は下図のようになる。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%899.JPG

2007年5月 7日

企業情報システムのかたち(8)

業務アプリケーションプラットフォーム

各種業務アプリケーションをどのようなプラットフォームに置くかを検討していく。こうしたプラットフォームも構造化しておく必要がある。

大きく、入力・ポータル系、業務処理系、出力・情報活用系に分ける。入力・ポータル系では、実際にデータを入力する仕組みでさまざまな方法がある。単純にEXCELシートから入れる場合や最近ではRFIDの利用などがある。さらに、EDIなどでシステム的に連動させるケースも増えてきている。

業務処理系では、確定した後のデータを処理するプラットフォームとそこへ投入するデータを確定していく処理するプラットフォームに分けて考える。前者は会社の根幹となるシステムでおおざっぱにいうと「有価証券報告書」を作るためのシステムとなる。後者は、再三出てくるように情報共有型の仕事により、データを確定していくためのもので、そこにオープンCMSのようなものを活用することを薦めているわけです。

こうして、蓄積されたデータを見せる仕組みが出力・情報活用系のプラットフォームになる。日本ではまだまだ帳票文化が残っているのでレポーティングのシステムは重要になる。ここでもきちんと構造化し、トータルシステムとして機能させることが大事になってくる。意外とここの仕掛けは難しい。データをダウンロードして、分析して意思決定を支援したり、その後のアクションプランに反映することも重要である。最先端は流通のPOSシステムであろうが、そのほかの業種でもこの仕組みをどれだけ生かせるかは、その企業の競争力に大きく影響する。

このデータのハンドリングはただ生成されデータを持ってくるだけでは不十分で、最初のデータベースの設計が非常に大切であることはいうまでもない。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%8910.JPG

2007年5月 8日

企業情報システムのかたち(9)

各プラットフォームの構造

それでは、各プラットフォームの構造を見ていきます。

まず、エンドユーザが業務処理や情報へのアクセスなどを行なうための入り口であるポータルがあります。また、ポータルは内外の関係者との情報交換や情報共有を行なう連携の場でもあります。

従って、連携の範囲により、Personal、Group、Companyに分かれ、情報の処理形態により、Business、Analysis、Knowledgeに分かれます。従来この領域はグループウエアと呼ばれるものが主流を占めていましたが、これからはCMSを使ったブログやHPのようなWebサイトがその機能を担うことでしょう。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%8911.JPG
次に、出力系であるレポート管理システムがあります。

いまは帳票レスの方向へどんどんシフトしていっていますが、法定帳票や一覧性を要求されるチェックリストの類などはなかなかなくなりません。

また、開発のとき意外と手間がかかるのも帳票ですし、運用における面倒臭さもつきまといます。このレポート管理はどちらかというと業務アプリケーションごとだったり、エリアごとだったりと個別の対応にまかされていて、またデータ形式もばらばらだったりと非効率的であることが多い。

ここでも、フォームのデザインを開発する機能、それを使って実際の帳票を作成する機能、できた帳票を仕分して配信する機能、また電子帳票化する機能などに構造化する必要がある。さらにそれらを統合的に管理する仕組みを持つことが望まれる。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%8912.JPG
最後にデータ活用という意味で全社的なデータウエアハウスの構築が必要になる。

データにもさまざまな性格をもったものがあり、また使われ方もまちまちであるため、それらに適したデータベースが配置され、各データベースが整合性をもって統合化された形を作ることが重要である。

会社のリソースとしてのマスタDB、業務アプリケーションを動かすためのトランザクションDB、そこから、情報活用に必要なデータを集約したセントラルデータウエアハウス、また用途に応じて使いやすいように抽出されたデータマートに整理される。さらに、最近では、ネット上(外部サーバー)にある各種データも使われるようになってきている。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%8913.JPG

2007年5月 9日

企業情報システムのかたち(10)

ハブ&スポーク構造

さて、アプリケーションプラットオームの構造を見ていくと、骨格がハブ&スポーク型に描かれているのがわかると思います。データにしてもアプリケーションにしてもいったんハブに集められ、そこを経由して配信されるイメージである。

今まで提示してきた構造は、まだSOAとかESB(Enterprise Service Bus)という言葉がない時代に筆者が考えたものであるが、そのSOAやESBとどう違うのかという議論がある。ここで厳密に違いを明らかにする意味はあまりないと考えるが、ざっと整理してみる。

システム間連携の歴史を追うと、最初は2つのシステム間の直接のデータのやり取りでした。しかし、これだと同期をとらなくてはならないのでかなり難しい。そこで登場したのがMQ(MessageQueuing)で間接的、非同期のやりとりにより統合がスムーズになったが、1対1ならまだしも1対NとかN対Nのような統合となると複雑になりすぎて現実的ではなくなった。

そこで、考えられたのがハブ&スポーク型の構造でこれにより複雑さが解消された。EAIである。従って、いままではEAIのアーキテクチャーであるハブ&スポークは、主としてMQなどのメッセージ伝送用APIによる独自の仮想化のことでした。ところが、いまや多くの異種システムを抱えてきてそれらの連携にはどうしても標準化と分散化というのが避けて通れなくなった。そこにオープン技術で標準化されたSOAやESBという概念が登場したわけです。

ですから、おわかりのようにSOAはハブ&スポークと同列の話ではないし、ESBもあくまで仮想化の話だから、基本的な構造概念はハブ&スポーク型でそれがバス的な接続になっているだけと筆者は考える。

それで重要なのは、どういうハブを用意するのかである。SOAだからサービスをつなぐんでしょと言われそうだが、そりゃちょっと粗っぽいわけで、もう少し分類しておく必要がある。

まず、データの連携のためのハブ機能は従来型のEAIであり、またデータウエアハウスもデータハブといえる。「ユーザ目線のBPM」でさんざん議論したように機能のハブはBPMである。前回紹介した「統合レポート管理システム」は言ってみれば帳票のハブでもある。そして忘れてはいけないのは、データ総研の椿さんが言っている、業務アプリケーション(プログラム)のハブ/通信場としてのデータベースの役割です。

ですから、システムの構造を規定しているハブ&スポークという考え方は幅広い概念といえるのです。
統合化されたプラットフォームイメージを下図に示す。次回から開発技術について論を進めていく。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%8914.JPG

2007年5月10日

企業情報システムのかたち(11)

開発技術

業務アプリケーションの調達には、作る・買う・借りるという選択肢があると言ったが、そのうちの作るという場合はその形態にバリエーションがある。すなわち、純粋に自社要員(情報子会社も含めて)と自社技術で開発する場合とSIerに作らせる場合がある。またその中間のような常駐外注に委託するようなものもある。

やはり、情報システムの重要性を感じているのなら、自社で開発できる技術とリソースを確保すべきであろう。なかには、持たざる経営とか言ってアウトソーシングに走る会社もあるが、経営とITの狭間がますます拡がるように思える。

しかしながら、IS部門や外販を志向しない情報子会社(こうした子会社の問題はあとで議論する)が、IT専門会社のように開発技術を深く突っ込む必要はない。基本的には、プログラムレスで開発する技術を追求すべきであるから、設計寄りのスキルを保有し、プログラミングは外部へというのがめざす方向性となる。ここは多少気になるところで、プログラミングができないで設計ができるのかという声が聞こえてくる。理想的には、ほんの少数の優秀なプログラマーを抱えておければいいのだが。

プログラムレスの開発ということになると、フレームワーク、コンポーネント、テンプレートを使った開発ということになる。すなわち、これらフレームワークなどはスーパークリエーターにプログラミングしてもらい、それを道具としてプログラムをあまり書かないで済む開発方法である。

「ビジネスコンポーネント指向開発」とはまさにこの開発方法論である。詳しくは、既に書いてあるが、簡単に言うと、ビジネスコンポーネントを書類のライフと見立て、その機能をオープンCMSで実現し、そのコンポーネントをBPMで組み合わせて業務プロセスを作り上げることにある。

従来の開発方法と違ういくつかのポイントがあるが、それも「ビジネスコンポーネント指向開発」に詳述しているが、書き忘れたことがあるので補足的に述べる。CMSを使ってあるタスク(書類の作成-承認)を遂行するというのが大きな特徴なのだが、それは昔のある経験から思いついた。

もうかれこれ10年くらい前になるが、工場の生産管理システムを開発したときのことである。当時筆者は情報システム部門に来たばかりであったが、立場上プロジェクトマネジャのような役割であった。システムは、営業・製造・品質保証・物流が関係するけっこう大きなものであったが、初めてということもあって、この開発プロジェクトではさまざまな貴重な経験をした。

開発対象となったなかである重要な業務プロセスに、製造部門がバッチで生産された製品を入庫し、品質保証部門が引き当てて、物流部門がローリーで出荷するというのがあった。これをシステム化するのだが、多くの例外処理や戻り処理が発生し大変なことになる。

例えば、出荷規格あるいはユーザ規格から先入れ先出しで自動で引当するなんてロジックを組むのだが、いざ運用すると、規格内に収まっていてもあるユーザにはもっといい品質でないとだめだとか、つぎの出荷に大事なユーザが控えているので引当てたものはとっておくといったふうになり自動で運用できないとか、最低在庫を割ってしまうからそのサイロから出庫できないはずが、いやその程度なら経験的に量は確保できるからだいじょうぶだとかになる。

要するに担当者の頭の中で決められてしまうことがけっこうあり、しかも製造、品質保証、物流の三者が別々の場所にいて、主に電話でやりとりするわけで、このコミュニケーションがうまくいかないと手違いが起きたり、戻って処理するようなことが起きる。

そのとき、プロジェクトのメンバーに言ったことをいまだによく覚えている。「この問題のもっとも効果的な解決策は何かわかるか? それは、3つの部門の担当者を一つの建屋に集め机を並べて仕事をさせることだ」。

で、もちろんそれはできなかったのだが、業務を安定化させるあるいはデータを確定させる作業は非常に不安定なふるまいだから、不定形な会話を繰り返しながら徐々に確かなものにするのがいちばん早いように思えたのだ。ですからここをシステムに乗せるというかプログラムで書くことはしょせん無理なのではないかとずっと思っていた。

しかし、いまや机を並べて会話しながら仕事を進めることと同じように双方向コミュニケーションがシステム的に可能となったのだ。すなわち、CMSを使った情報共有的作業である。ここに「ビジネスコンポーネント指向開発」のヒントがあったのだ。

また、開発技術というと言語レベルのような実装ITを考えがちだが、企業のIS部門にとっては、業務プロセスをデザインするスキルこそ最も重要かつ必須なものである。何回も繰り返すが、事業に役立つ業務プロセスがデザインできてこそ、ITが使えるわけで、先にITありきではないというのが基本です。

ただ、全くそうかというと逆のアプローチも必要なことももちろんある。Web技術のCMSから情報共有プロセスを考えつくなんてはこうしたアプローチに近い。今後は、RESTとかRSS、Wikiとかいった技術から新しい知的生産作業プロセスが生まれてくるだろう。

企業のなかには、業務プロセスのデザインを外部のベンダーやSIerにまかせているところもあるが、それは間違っています。そこのスキルは死守しなければなりません。それがここでいう開発技術ということになります。

2007年5月11日

企業情報システムのかたち(12)

システム運用

さて、いよいよ運用の話になるが、ユーザからみてここの領域は、専門性が高いところでもあり、技術的な突っ込みは限界がある。むしろ、体制だとか管理プロセスといったソフト的な対応が重要となる。

まずは、運用業務はITIL(Information Technology Infrastructure Library)でほぼ網羅的に規定できる。ただしITILはあくまでIT業務プロセスのフレームワークであるので、これに基づいて自分たちの体系・基準・手順に落とし込んでいかなくてはいけない。よくITILに限らずこういったフレームワークやガイドラインをそのまま適用すればOKだと勘違いするひとが多くいるが、そんなものはありません。あくまで指針であり、リファレンスですから、それを参考にして自らの手で自分らの身の丈にあったものを作り上げないと意味がない。

そういった観点からITILをみると、ITILはよく整理されていて、その言わんとしてるところをよく理解すれば、非常に参考となるフレームワークだ。ITILは大きくサービスサポートとサービスデリバリーがあり、そのなかに6つと5つ合計11の管理項目が提示されている。これらを厳密に全部やろうとするとけっこうしんどい話なので、まずは肝のところを確立するのが現実的だ。

サービスサポートでは、IT資産管理台帳の整備とヘルプデスクの充実だ。クライアントPC、サーバー、ストレージ、プリンター、ネットワーク、ソフトウエア、ライセンスなどを一括管理できるデータベース(CMDB(Configuration Management DB)の基本部分)を作り、それと不具合や故障履歴などと連携させ、ユーザからの問合せに迅速に対応できるようにしておくことが大切である。

サービスデリバリーでは、SLA(Service Level Agreement)の作成である。それも、完璧なものはできないので、決められるものから始めるのが大事である。何よりもユーザとの合意が必要なので、できないことを謳ったり、どちらともとれる曖昧な表現は避けたほうがよい。

従って、ITIL準拠の運用管理の基本は、CMDBとSLAということができると思う。このあたりは、普通の業務システムと同じで、データベスと業務機能・プロセスの適正化のことなのです。

セキュリティに関しては、セキュリティポリシーの策定とそれにそれに付随するセキュリティ対策基準、技術基準などが必要となる。これもやみくもに対策を打つのではなく、きちんとしたリスク評価をして実施することが大事である。

その他、最近ではBCP(Business Continuity Plan)やDR(Disaster Recovery)といった地震災害などを想定し、事業の継続性をどう維持していくのかといった対応策を策定しておく重要性も増してきている。

運用体制については次回に議論する。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%8915.JPG

2007年5月15日

企業情報システムのかたち(14)

情報インフラの構造化

さて、情報インフラであるハードウエア設備をどう構成し、配置していくのかになる。実際には運用体制のところで述べたように、かなりの設備はアウトソーサーのセンターに配備されるわけだが、物理的な問題というより、安全性、安定性、可用性、利便性などからみた構成の考え方が重要である。また、コストとの兼ね合いもあるので、コストパフォーマンスのよい構造化が必要となる。

ネットワークでは、ミッションクリティカルな業務が乗るものと多少の停止は我慢できるものとは別系統にしてコストダウンを図るだとか、情報量による区分け、バックアップ回線の持ち方など最近のネットワークサービスの多様化を利用して工夫するところでもある。今後は、テレビ会議システムなど音声やさらに動画が乗ってくると思われる。

サーバー/ストレージでは、集約と分散のバランスということになるが、集約には器の集約と場所の集約があり、その会社の環境条件やリソースで構成を決めていくことになる。ちょっと話はそれるが、ブレードサーバーが出現したとき、あれこれはプラント制御に使うコントロールステーションと同じではないのかと思ってしまった。分散計装の世界と事務処理システムとがだんだん近づいているように思える。

情報端末は、今後携帯電話がどのような形で企業情報システムに入ってきるのか、仕事する場所の概念が変わるかということも含めて興味があるところである。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%8917.JPG

2007年5月16日

企業情報システムのかたち(15)

人材育成・活用

いくらいいシステムを作っても、あるいはいくら素晴らしい体系を作っても、最後はヒトだといういうことを筆者の経験から言わざるをえない。従って、あえて人材育成・活用というタイトルで書かせてもらう。

会社で働く人には4つのタイプがあるように思う。能力が高くよく働くAタイプ、能力はそんなないが、言われたことは確実にこなすBタイプ、能力はあるのだけれど自分の気に入ったことしかやらないCタイプ、能力もやる気もないDタイプである。これは、よく言われる2:6:2の法則に近いのだけれど、その6の中に2つのタイプがあるのではないのかというのがここのポイントです。人材育成は、B、C、Dタイプの人間をどうやってAタイプにもっていくかになる。

まず、Dの人間をCかBにするわけだが、Cにするのはなかなか難しい。たまに、ユーザ部門でふてくされていてIS部門に来たがITを勉強し出したらすごい早さで習熟してしまったなんて人がいないことはないが、やはりITスキルは専門性が高いのでハードルが高い。現実的には、何とかうまく指導してBタイプにもって行くことになる。

CタイプをAに持っていくには、いろんなインセンティブでやる気を起させることだ。報酬もそうだが、いわゆるギークに近いので名誉だとか、外部で発表させるだとかそういったインセンティブも有効かもしれない。

結局、創造的な仕事はAタイプにやらせ、そこでできた成果物を使って多少のカスタマイズや運用・保守をBタイプにやらせるという棲み分けが必要ではないでしょうか。そして、いかにDタイプの人間を減らせるのか、Cタイプの人間を早く戦力化できるのかで総合力を上げていくのが望ましい姿となる。

こうした人材育成・活用には、ベースとなるのがスキル・キャリアマップである。ITSS(ITスキルスタンダード)があるのでそれを参考に自社独自のキャリアパスとそれに必要なスキルをマッピングする。そのまえに、意外とやられていないのが現状の保有技術の棚卸ではないでしょうか。やはり、現有リソースとレベルが把握できてこそ、これからどういう人材を育成するのかが決まってくるので重要な作業である。

いずれにしろ、ヒトが能力を高め、稼働率をあげるには、それ相応のモチベーションを与えることに尽きる。そのためには、組織として、個人として、それぞれの達成目標と役割を明確に示し、気持ちよく働ける環境をみんなで作り出し、結果を正当に評価するというシステムを機能させることが大切である。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%8918.JPG

2007年5月17日

企業情報システムのかたち(16)

情報子会社のありかた

企業はIS部門を社内に抱え込むのか分社化するのかという選択がある。情報システム部門を分社化するのは、少し波があって最初の波は多角化の一貫として情報会社を作るというのがあった。ですから、このときは外販主体で外で稼いでこいよという形態だった。

そのあとの波は、選択と集中の動きの中でコアコンピタンスではない事業や機能は売却したり、分社化したりした結果、情報子会社ができたケースである。前者の場合は、まだ本体のなかにIS部門を残し、本体業務はそこでやっているという形態も多く、中途半端になっていてそこを整理する動きもある。

情報子会社がめざすところはおおかたは外販比率を高くし、収益性のある、親会社から自立した会社になることだが、これが難しい。外販比率を上げるすなわち親会社依存率を下げていくと必ず収益性悪化の谷に落ち込む。そうですよね、外販するためには売上が上がらない中、教育投資やリソースの確保などコストがアップするわけだから、当然収益があがらないことになる。この谷を越えられるかどうかが大きな試練になる。

そこが難しいとなると親会社べったりの経営になるが、そこはコスト優先だから人件費を下げなくてはならない。ところが、それじゃ人員を親会社に帰すかとなると、分社化の意図と矛盾するというジレンマを抱えている。従って、分社化したのならやはり外販をしていくことをめざさない限り存在価値はないように思える。

ところが、外販に向かうにしても、親と子のめざすところや思いが微妙にずれていることが多い。親の第一の望みはコストダウンだ。子としてはコストの多くが人件費だから人員を減らしたいが、さっき言ったように親会社が引き取ってくれるわけではないから、余った人員を外販にまわそうとする、しかし外販するには優秀な人材を投入せざるを得なくなる。

だから、優秀な人材を外販にまわし、そうでない人員を本体向けに残して置くことになる。そうなると親からの声は、内へのサービスを質を落としてまでも外販するなとなる。さあどうしよう。

ここをうまく突き抜けないと自立した情報会社になれないのだ。

おろおろしてもしょうがないので、がんばって戦略をたてなくてはいけないのが、もう少し本質的なところ、もっと会社としての基本的な問題のところを議論する必要があるのではないだろうか。すなわち、外販だろうが内販だろうがまず何を売るのかということがある。サービスなのかソリューションなのか技術なのか単にプロダクトを売るのか、こうした事業ドメインの定義が重要である。

情報子会社の問題は最初から親会社へのサービス提供がありきから始まってしまい、そのモデルをそのまま使をうとするところに無理があるのではないでしょうか。ですから、親会社以外へどういう商品を揃え、どういうビジネスを展開するのかという戦略を描くことがもっとも大事であり、そこが大きな課題となろう。

全く新たに起業することを考えた場合、会社というのは本来売りたいものがあり、それを作れるひとがいて、それを売って儲けたいひとがいて成り立つのですが、情報子会社の場合は、そういう能動的なひとが少なくほとんどが親会社から行けと命令されたからしかたなしに移ったとういうひとたちが多いようです。従って、ひとの意識の問題とともにどうしたら起業プロセスを持ち込めるかが大事な要素ではないでしょうか。挑戦より堅実、変化より安定といった志向のうちは基本構造問題は永遠の課題になってしまうでしょう。

また、ユーザ系会社は業務知識が売りみたいなことですが、それなら業務要件に合ったソフトウエア、プラットフォームなどをなぜ提案できないのか。いまはほとんどソフトベンダーが作ったERPやパッケージに振り回されて、それをどう使いこなすかが問われています。これっておかしいわけで、ひとつには情報子会社がアイデアを出せない、コンセプトを作れないことなのでしょう。本当にその会社の経営に貢献できる情報システムを作れるのは本来その会社にいる(いた)人間ができなければいけないのではないでしょうか。

ですから期待を込めて情報子会社が主導権をとり、既存のSIerの地位を奪い取るくらいの覚悟でやることが、自立した情報会社になる道ではないかと思う。
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%8919.JPG

この連載はこれで最後になるが、今回は比較的図を入れるようにしましたが、わかりやすかったでしょうか。

また、企業情報システムの美しいかたちは見えてきだでしょうか。結局、この美しいかたちを作るのもヒトです。そのヒトが企業の業務機能やプロセスを俯瞰できる目があり、それらの本質を見極めてシステムに落としこめるかが勝負です。

そのとき、ここでもやはり「ユーザ目線」ということが非常に重要なキーワードになるといえます。

2007年10月26日

SaaSあるいはASPそしてSOA - 企業情報システムのかたち(17)

さて、こちらも久しぶりのエントリーになります。テーマは最近の流行であるSaaSあ(Software as a Service)とSOA(Service Oriented Approach)についてです。

このふたつのキーワードに熱いまなざしが向けられている。それは、バズワードという、一見専門用語のように見えるがそうではない、明確な合意や定義のない用語のことではないかという人もいる。筆者はそうではないと考えるが、定義の仕方がひとによってばらばらのような気がする。

それはどうしてかというと、特に3文字略語の場合、その言葉やコンセプトを作ったひとはどういうことかもちろんわかっているが、そうでない人たちは、まずは3文字ありきなのであって、その3文字を自分の知識や理解で勝手に解釈してしまうからだ。だから、そうした言葉を使いながら話をしていて、お互いに全然違う定義でしゃべってしまい、かみ合わないことがある。

結局、言葉から入るのではなく、自分のやりたいこと、考えていることがそのコンセプトやアーキテクチャに合っているかどうかという視点が重要で、それが合っていれば腹に入って来るのだ。

そうした目で見ていくと、まずSOAから言うと、多くの間違いは、SOAを技術やソフトウエアだと思っている人がいることだ。わけが分からないのは、さあ今からSOAを構築しましょうというやつで、それどうやって作るの、何に使うのということになる。これでは、ベンダーがだまそうとするバズワードになってしまう。

SOAはあくまで、思想であり、概念である。システム全体をフレキシブルでアダプティブな構造にして、ビジネス環境の変化にシステムが迅速に対応していこうという考えかたなのである。だから、システム側の要求でもなんでもなくて(まあメンテナンス性の向上はあるがメインではない)、ビジネス側が望んでいることなのである。

ここをしっかりと理解する必要がある。すなわち、ビジネス側の要求として、必然的にSOAが求められたのだ。それが、これまでは技術的に難しいところがあってできなかったのが、ここへきてやっと実現できるようになったから、注目されているわけで、そういう意味でバズワードではないと言っているのです。

つぎにSaaSだが、これと同じような仕組みにASP(Application Service Provider)というのがある。2000年くらいに若干もてはやされていたが、いまはこの言葉を聞くことは少ない。実は、筆者はその当時、ASPを実際に始めた経験を持っている。この仕組みを適用しようとしたきっかけは、情報システム部門の子会社化である。

情報子会社の使命のひとつにグループ会社の支援がある。グループ会社というのは、だいたいが中小規模でシステム部門をもたないようなところが多い。その当時はどこの会社も子会社の情報システムはあまり面倒をみていなかった。独立心の強い会社が多い(昔は親会社がそう仕向けた面もある)せいでもあったが、自分たちでできないから地元のITベンダーにまかせっきりになっていた。

ところが、2000年3月期から連結決算の開示の義務化により、単体経営から連結経営重視へ舵がきられたため、親会社も子会社のシステムについて知らんぷりもできなくなってきた。典型的な例が、連結決算データの集約が早く正確にやらなくてはいけなくなったことなど、グループ全体のシステム化という視点を持たざるをえなくなった側面がある。

で筆者が掲げたのは、情報子会社はグループ会社のための、Application Service Providerになろうと決めたのである。すなわち、グループ会社はIT資産はPCとLAN以外は持たないということである。親会社のシステム部門に開発から運用まで全部任す形態である。

そのために、一箇所にアプリケーションを置いてそれを各社が共同利用するというシェアリングの考え方を採用したのである。その頃はまだ、Webアプリケーションも少なく、ネットワークパフォーマンスやサーバーのスケイラビリティイの問題があってなかなか難しかった。

いまや、ASPとはあまり言わず、SaaSという言葉が主流となっているが、どこが違うのだろうか。これについて昨年栗原潔さんがブログに書いてあるのを借用してみる。いま言ったようなことを踏まえると筆者の考えを代弁してくれている。

現状のSaaSの定義は、「アプリケーション・ソフトウェアをユーザーが自分のシステムに導入して使うのではなく て、ソフトウェア・ベンダーが所有するインフラで稼働してもらって機能だけをネット経由で使うモデル」という感じでしょう。そうなりますと、SaaSと ASPモデルはどこが違うのという話になります。

ネット上で「SaaSとASPはここが違うんだ」という意見をサーチすればするほど、私的には「やっぱり同じでは」と思えてしまいます。たとえば、

1.ネットコストの違い: 昔のASPは通信費が高かったが、SaaSは高速回線を安価に使用できる
   これは利用環境が変わったというだけで、特に本質的な違いではないのでは?

2.ホスティング方式の違い: ASPではシングルテナント(1サーバ=1ユーザー)が普通だったが、SaaSではマルチテナント(1サーバ=複数ユーザー)が主流
   これまた利用環境の違いであって、モデルの本質的な違いとは思えません。

3.アプリケーション設計の違い: ASPはクライアント・サーバ・アプリケーションを無理にネット対応にしたもの、SaaSは最初からネット向けに設計
   そうなんでしょうか?ASP時代にもネット・ネイティブのアプリケーションはあったと思います。

ということで、今の私の結論は「SaaSとASPに本質的な違いなし、ASPにはあまりビジネス的に成功できなかったという悪いイメージがあるので それを避けるために、ベンダーがマーケティング上SaaSという新しい言葉をプロモートしている」というものです。そもそも、1990年代末のASP時代 から"software as a service"という言い回しはよく聞かれてました(SaaSという短縮形は一般的ではなかったかもしれませんが)。

まさにこの通りで、ASPといわれた時代の技術的な限界がいまはなくなって、その当時思い描いていたことが実現できるようになったということだと思う。

そこで、SaaSの利用の仕方についてである。現時点で有名なのは「SalesForce.com」であるが、これが正しいSaaSの利用の仕方なのだろうか。どうも疑問がある。まず、ユーザサイドでいうと、大企業から見るのと中小企業から見るのとはだいぶ違う。

中小企業は、全社システム丸ごとという利用の方向であるが、大企業は必要なサービスだけをもってくるという方向であると思う。大企業は、基幹業務システムは自社で保有するが非基幹系あるいは情報系については必要に応じて外部サービスを使うというのが多いでしょう。

こうしてみると、「SalesForce.com」はSaaSで提供されるべきものなのだろうかと考えてしまう。しかも、営業の業務というのは様々な形態があるし、またその会社あるいは部署によって特徴のあるプロセスだったりするわけで、それをある決まった型に押しこめるのはいかがなものだろうか。そもそも基幹業務なのではと思う。

SaaSに向いている業務サービスは、差別化しなくてもいい、あるいは自社でメンテしにくいもの、専門的なものが適している。例えば、プロフェッショナルサポートと呼ばれるような税務、法務・特許、労務、与信などのサービスを外部にまかせるというのが取るべき形態であると思う。

いまや多くの業務がSaaSに取って替わられるような勢いで語られることもあるが、そう簡単に移行できるとは思わない。むしろ、以前のASP的なアプローチで最終的にはBPO(Business Process Outsourcing)につながるような形態が多くなるような気がする。

About 企業情報システムのかたち

ブログ「mark-wada blog」のカテゴリ「企業情報システムのかたち」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

前のカテゴリは企業における人とITです。

次のカテゴリは働きたくなるITです。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type