|
||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||
| 技術選択のリスク | ||||||||||||||||
|
最近の技術革新により、オープンシステムの開発に際しては、幅広い選択肢から技術を選択しなければならない現実がある。それぞれの技術を単独で使うことはごくまれであり、いくつかの技術を組み合わせて最適な性能、可用性、信頼性といったシステム要件を実現していかなければならない。 個々の製品について良し悪しを検討することはできても、様々なベンダーの多様な製品を組み合わせて顧客要件に対応していくことは決して容易ではない。その結果、技術選択を誤って問題に至ってしまうプロジェクトも多い。 今回はシステム開発における技術選定のリスクおよびそのリスクを取り除くためのキーファクターについて述べていく。 |
||||||||||||||||
| オープンシステムにおける製品選定の難しさ | ||||||||||||||||
|
新技術を適用するプロジェクトにおいては、その技術の特性、ライフサイクルを含めた見極めが重要になる。
表1:技術の成熟度区分 また製品単独の成熟度だけではなく、プロダクトの組み合わせも重要なポイントとなる。例えばAというOSで稼動しているプロダクトがBに移植されたときに、BでもAと同様の安定性が確保できるという保証はない。 一般に、プラットフォームフリーといわれているJavaにおいても、VM(Virtual Machine)の環境はOSやアプリケーションサーバなどによって異なるため、それぞれの環境で動作検証を行わなければならない。実際にJavaのVMにおいては、ダンプログのフォーマットや起動時オプションなども各ベンダーによって異なっており、運用設計の面からも、どれでも同じというわけにはいかないのが現状である。 さらに選定したプロダクトのベンダーが突然買収されたりサポートが受けられなくなるというリスクもある。例えばベンダーの買収が行われたことで製品のオリジナル開発者がいなくなり、製品のサポートが打ち切られてしまう(代替製品への移行を余儀なくされる)といった点である。 そのため、利用するプロダクトが標準仕様に準拠しているか否か、標準自体のライフサイクルや業界動向に沿っているか、という点にまで目を配ることが求められる。仮にも標準に沿っていれば、利用製品がサポート打ち切りとなった場合でもある程度のマイグレーションでシステムを稼動し続けることが可能となるからだ。 |
||||||||||||||||
| 取り返しのつかないハードウェアの選定ミス | ||||||||||||||||
|
システム開発の過程では、様々な問題がでてくるが、システムを動かす基盤に対する選定ミスは有形の「モノ」が絡むこともあり、後になればなるほど修正が効きにくくなる。例えばデータベースサーバを構築する際、コストを抑えるためにIA-32サーバでLinuxを稼動させて、さらに可用性向上のためクラスを組むという例が実際に見受けられる。 このようなシステムの場合、オンライン処理が主体であれば特に問題はなさそうである。ところがここにバッチ処理が加わると、CPU処理が占有されてしまい、オンラインレスポンスでの十分な要件を満たせなくなるという経験を筆者は味わったことがある。この問題はカットオーバー前に判明したため、改めて高性能のサーバを使って再検証を行い、問題なく稼動させることができた。 こうした経験から、ハードウェアの選定において筆者が考える注意すべきポイントは2つある。 1つはプロジェクトが長期に渡り、かつ早期に機器類を購入しなければならない場合、選定するものをできるだけ最新のモデルにしておくということである。 選定時に安定モデルとみなされていたものでも、カットオーバーが近づくにつれて陳腐化し、当初の要件を満たさなくなっていく可能性は否定できない。したがって長期のプロジェクトであればあるほど、多少なりとも先端の製品を選定し、充分な検証期間を設けて初期導入時のリスクを低減させるといった戦術が必要となる。 もう1つは、製品選定において問題が発生した際に、代替パスとなるものを用意することである。これに加えて製品のロードマップやベンダーとの関係、プロジェクトの予算など、幅広い観点から常に可能性を考慮しておくことが重要である。 |
||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||

