◆技術的リスク
近年は、ＩＴの高度化・複雑化によりシステム構築における技術的リスクが高くなっている。かつての汎用機だけの世界に比べると、パソコンやＵＮＩＸが混在し、それらがネットワークでつながれている。また、搭載されるソフトウェアも、さまざまなベンダのものが混在している。さらに、これらを接続するためのミドルウェアと呼ばれるソフトウェアが複雑さに拍車をかけ、ブラックＢＯＸ化を増長している。
いきおい、新しい技術や製品を採用した場合、マニュアルでは可能なはずが、実際は繋がらない、動かないという事態が発生する。複数ベンダの製品を組合わせて採用した場合は、解決が困難になる傾向にもある。こういったリスクを避けて、実績のある枯れた技術だけを採用してシステムを構築できれば、信頼性、安定性などの技術面だけでなく、コスト・期間でも有利であることは間違いない。しかし、それだけでは満足できないほどビジネス側からの要求も高度化している。
例えば、既存の汎用機上のシステムを、インターネット経由で社外から利用したいなど、既存の技術だけでは実現できない要求に対して、新しい技術を採用しなければならないこともある。また、新ビジネスを短期間で立ち上げ同業他社より競争優位に立ちたいと思えば、技術的なリスクを覚悟で、新技術を採用し短期構築に挑まなければならない。システム構築コストを削減するためには、オープンソースソフトウェアの採用も必要だ。
このような場合には、できるだけ早めに技術的な検証を目的とした実験を行うことだ。例え、開発初期に追加の費用を払ってでも技術検証を依頼したほうが、システム構築が本格化してから「できない」という事態になるよりはましだ。最悪「できない」という事態になってしまったら、その理由が費用的なものなのか、時間的なものなのか、それとも純粋に技術的に不可能なのかを良く見極める必要がある。
費用的・時間的にできないという場合は、その影響を分析し、投資対効果を見極めた上で実施の可否を判断する。また、技術的に不可能な場合は、より高い技術者を採用すれば可能なのか、一般的に不可能な要求なのかを見極め、あきらめるか否かを決断する。時間と費用をかければ大抵の技術的課題は解決すると思われるが、ビジネス上の目的や目標に照らして、その技術を採用することの有用性を経営的観点から判断しなければ、単に技術的興味でコスト・納期に影響を与える事となる。技術自体に価値を見出すのは研究者やシステム業者に任せておけばよい。
この他にも、ＩＴ業界は浮き沈みが激しく欧米では企業再編なども盛んだ。こういったことに対して、採用した製品が巻き込まれると、突然のサポート停止や質低下となることもある。できるだけ、将来性のある製品を採用することと、もう一つは、その製品に依存しないようにシステムを構築しておく。ポイントは、実行時には業務プログラムだけで動 き、製品の存在を必要としないこと。一部の開発ツールには、実行時にも製品が無いと業務プログラムが動かないものがある。もし、その製品がサポート停止になれば、業務プログラムも塩付けになる。
そして、保守可能な形でソースコードを確保すること。これも一部のソースコードを生成する類の開発ツールは、製品が無いとプログラムを全く変更することができない。製品が無くても、ソースコードさえ完全な形で存在すれば、なんとかなるものだ。さらには、特定の基盤ソフトやデータベースソフトに依存しない言語や環境を採用しておくこと。近年、Ｊａｖａを採用する企業が増えてきたのも、技術動向の流れが速いＩＴ製品に対し依存度が低く、一度作成した業務プログラムは、どの製品の上でも動かすことが出来る「Write once, run anywhere]という利点が評価されているからだ。
自社でゼロからシステム構築する力の乏しい企業が、業務パッケージを採用して手っ取り早く、業務改革とシステム構築を済ませるというケースも増えてくると思うが、ソースコードも無く、中身もブラックＢＯＸでは、業者に首根っこを押さえられたも同然。せめて、自社の業務が、パッケージソフトに塩付けにされないように、業者の経営状況や製品のサポート状況をこまめにウォッチしてほしい。そして危ないと感じたら、早めに他の製品に乗り換えることを考えたほうが良い。その為にも、追加開発は必要最低限に抑えておくべきである。大型の業務パッケージでは、技術的リスクが経営的なリスクに直結しやすいので、その製品の１０年、１５年先を見極める力量が必要になる。
コメント