Loading
|
|
|
Loading
|
| ＠IT > 報われない情報システムへの処方箋 連携と可視化でビジネス貢献度UP！ |
 |
情報システムは1日で成るものではない。構築のための戦略があり、それに基づいた設計、開発を経て、ようやく運用開始に至る。それぞれのフェイズで練りに練られたものが後工程に渡され、導入されたあかつきには極めて順調に安定的に稼働するはず、である。しかし、現実には各フェイズや担当部署間には深い溝が横たわる。それぞれが分断され、孤立していることが多い。そのためこれらの間で十分な連携がとれておらず、構築した情報システムの品質低下や不良資産化につながっている。このような問題を根本的に解決するために、企業の情報システム部門は何をすべきなのか。
――いつどこでこのような悪循環に陥ったのか分からない。しかし、今では容易に抜け出せないほどに深みにはまってしまっていた―― 情報システム部長は、運用担当部署からの直訴に言葉を詰まらせていた。難産の末にようやく本稼動したばかりの電子商取引サイトのことだった。彼らによると、“システム自体に問題が多すぎて、このままでは面倒見きれない”というのだ。まず、サーバの性能が不十分で、アクセス数増加に耐えられない。対策として、事前にベンダから説明されていた通り本番機にCPUをフルに増設しても、処理能力が伸びなくなるポイントがあり、焼け石に水。どうやら開発したソフトウェア内にボトルネックがあるようだ。さらに、これまで触ったことのない技術が採用されているため、専門的なトレーニングも一部のスタッフが受講したばかりで障害発生時の作業がそのスタッフに集中する。 運用部署の責任者は、“問題が起これば、すべて現場が全部尻ぬぐいをしている。携帯電話で24時間、深夜であろうが、休日であろうが関係なく呼び出される私たちの身になってください”と、机を叩かんばかりに憤（いきどお）っていた。このサービスの運用については開発開始直前になって初めて経営会議で聞かされた。その後、スタッフ不足の中、受け入れ体制をなんとか作り、ぎりぎりの状況で運用を行っていたのである。 一方、情報システム部長は、仕様に開発部門の状況が勘案されていないことや先行しているプロジェクトの開発計画に支障が出ることを理由に抵抗を試みたが、結局はビジネス優先ということで、積極策を推進する常務および経営陣の意向に押し切られた。 現場のリソースやスキルセットを考慮せずに作られた夢のような新技術盛りだくさんの仕様書。渋るプロジェクトマネージャ。ハードウェアベンダに発注されたシステムのサイジングは、これらの新技術による実績がほとんどないため、厳密な性能評価を行わず、一般的な例を参考に行われた。仕様確認やリソース手配にも予想外に時間がかかり、開発プロジェクトは常に遅れ気味だった。 経営トップが期限を切ったシステムである。なんとしても間に合わせなければならない。計画遅れのしわ寄せは最終工程であるテスト期間にきた。テストプランを作成する工数に余裕がなかったことから、通り一遍のテストは行ったものの、業務面での仕様の詰めが十分でなく、実運用での業務を想定したテストが行えず、実際のところ品質保証には程遠い内容だった。 このような経緯でシステムは予定どおりに船出した。そして、迎えた現実が運用部の憤りだったというわけだ。情報システム部長は、言葉もなくただただ虚空をにらんでいた。
情報システム部門において、戦略、開発、運用を担当する部署はそれぞれ独立しており、分断されていることが多い。戦略的な発想で予算、物、人、リスクのバランスを考慮しながら将来のシステム像を描くべき企画部門は経営陣のわがままに振り回され、往々にして、肝心な部分をベンダに丸投げして受け売りする。開発部門はその企画を理解し、納品することに手一杯で運用時の性能や品質等を想定した設計ができない。
結局、運用部門はすべての波をかぶって、問題をせき止めることに追われ続ける。誰もが無責任な気持ちでそうしているのではない。それぞれ会社のためを思って必死に働いているのだ。なのに、できあがったものは、当初の目的とは違って、ビジネスの役に立たない。立派なIT不良資産になってしまう。この悪循環は、その時期があまりに長く続いたために、部門間のコミュニケーションが希薄なだけでなく、深い溝、対立といったレベルにまで至ってしまっている企業もある。 今日、情報システムなくしてビジネスの発展は考えられない時代になったために、企業の情報システム部門、特にその企画部門には運用現場のほか事業部門、一般ユーザーなど、社内のあらゆるところからさまざまな要求が寄せられる。新システムを開発してほしい、既存のシステムに機能を追加してほしい、パフォーマンスを上げてほしい、使いやすくしてほしい、などといった事業部門からの現実的なリクエストに加えて、経営層からは中長期ビジョンを達成するための次世代情報システム構想を求められることもあるだろう。前述のように、競合会社としのぎを削る中での「ビジネスニーズ」も発生する。情報システム部門をとりまく変化の激しさは日に日に高まるばかりである。 情報システム部門も万能ではなく、ましてやマジシャンでもないから、そうした殺到する要求のすべてに応えることはできない。予算や人員などのリソース、時間は有限である。それらの要求のうち、何を優先し、何を先に延ばすのか、何を選択し、何を却下するのか。残念ながら、先の例にあるように現状は判断のための明確な基準もなく、声の大きな者が勝つような事態になっているのではないだろうか。それでは有限である資源の最適な配分は難しい。そこにはよりどころとなる大きなIT戦略がなければならない。また、常に最大の投資対効果をはかろうとする思想がなければならない。情報システムが主役の今日だからこそ、これがあるとないとでは、その後の企業の発展に大きな差がついてしまうのだ。 「失われた10年」と呼ばれる経済不況の1990年代、多くの日本企業はそれまで聖域としていた情報システム投資予算を根本的に見直した。しかしその見直しの大半は、個々のプロジェクトの特性や中身をあまり吟味することなく、新規プロジェクトの全面的な凍結や、一律何パーセントカットといったものだったため、多くの企業は成長の活力を減退させることになってしまった。逆に、そのような時期にも投資すべきシステムを見極め、取捨選択をしつつ計画を進めた企業は、厳しい状況を生き延びてきたのだ。
情報システムに対する、あふれんばかりの要求を優先順位付けして、正確かつ迅速に処理していくためには、これらの要求に対してビジネスの視点で正しい判断をする必要がある。それを行うために不可欠なのが、既存システムや新規プロジェクトの「見える化」、つまり可視化だ。
Aプロジェクトは、いくらの予算で、業務の効率化を享受できるユーザー規模はどのくらいで、それによって得られる効果および発生するリスクはどういうものがあるのか。投資対効果はどのくらい期待できるのか。そういった客観的な資料がプロジェクトごとに整備され、関係部署で共有できていれば、より正しい判断が可能になり、経営層の納得も得やすい。ほかのプロジェクトやシステムとの優先順位付けも容易になる。情報システム部門が孤立しないためにも、企業全体でこのような情報を共有することは非常に重要だ。 稼動している情報システムが不幸にもうまく利用されていないといった場合も、状況の可視化を行うことによって、対策を講じることができる。これまでは軌道にのらなかった情報システムに触れることはタブー視されることが多かったのではないだろうか。しかし、見て見ぬふりするだけでは不良資産化したシステムはなくならず、膨大な予算が浪費され続けるだけである。システムの有効性を常にチェックし、ある基準を下回ったらシステムを更新、場合によっては破棄するといった判断もするべきである。プロジェクトの予算を適切に判断し、投資の最適化を実現するために、戦略、開発、運用を通した情報システム全体の「見える化」は必須である。
情報システムを不良資産化させないために重要なことは、「戦略」「開発」「運用」の各段階を一連のライフサイクルとしてとらえ、全体を見通すことだ。これは、ビジネスの視点で情報システムのあり方を考えるということである。分断を解決するために戦略と開発は、「ビジネスへの貢献」という目的のもとで一枚岩であるべきで、設計や開発担当者は運用の体制を理解して行わなければいけない。 運用担当者もまた運用だけが分かっていればいいというのではなく、どのような開発が行われたかを理解する努力が必要だ。担当部門が「作ったら次の工程に渡して終わり」という時代は終わった。たとえそれが1つの企業内ではなく、アウトソースやオフショアなど、外部の組織であったとしても、これらは緻密に連携され、ドキュメント化されていなくてはならない。これは製造業の現場などでは、昔から当たり前に行われていることだ。情報システムでも、ライフサイクルを通した連携性が実現されて初めて、その品質も、その稼働安定性もゆるぎないものになるのである。 では、具体的にどうすれば、情報システムを不良資産化させない「見える化」や「ライフサイクル連携」が可能になるのだろうか。次回からその詳細を見ていく。
提供：日本ヒューレット・パッカード株式会社 企画：アイティメディア 営業局 制作：＠IT編集部 掲載内容有効期限：2007年5月1日 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
