 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||
|
||||||||||||
| 誤ったデータベース選定 | ||||||||||||
|
昨今の情報システムを構築するにあたり、その情報を蓄積し、活用するソースとしてのデータベースが最重要のプロダクトとなる。近頃では戦略的IT活用の高まりもあり、その重要性はさらに増しており、要件としても厳しくなってきている。それだけに、そのプロダクト選定や利用方法において問題が発生するケースも多い。 筆者が経験した、データベースに関連する問題事例としては、以下のようなものがある。
表2：データベースに関連する問題事例 これらのうち、1〜3で上げたものは基盤要素にかかわる問題であり、一方、4〜5はプロジェクトを進めていく際の問題と分類ができる。 いずれの問題についてもきちんと対応していかなければ安定した情報基盤としての活用は困難となり、プロジェクト完了後も潜在リスクを残す（むしろ、カットオーバー後のほうが影響が大きくなる）ものである。 |
||||||||||||
| プロダクト評価に欠かせぬ視点 | ||||||||||||
|
ここまで述べてきたことを踏まえ、ITプロジェクトの円滑な遂行のもとに最適なシステム基盤を構築するためには「技術要素からの視点ではなく、あくまでも主はシステム化の要件の明確化である」ことを、改めて肝に銘ずべきことである。 もしこれが疎かにされると「技術を入れんがためのプロジェクト」になり、その結果、誰も保守できずサポートしてくれないといった、「ゾンビ的なシステム」が生みだされてしまう。 この原則に立ち返って、ポイントとなる3ヶ条を整理し記載する。 |
||||||||||||
| 第1条：運用まで考慮された寿命の長い構成かどうかを評価する | ||||||||||||
|
これは適用するプロダクトや技術がプロジェクト期間内だけではなく、その後のシステム維持にも耐え得るかどうかという視点である。開発プロジェクト中であれば、開発者の確保やベンダーサポートの供給も得やすく、関係者を動員してリリースまで漕ぎ着けることができる。その後の保守フェーズでは、システムが支える事業の展開を睨んだ上での要員確保には困難を伴うのが現状である。 構築されたシステムは、その構築プロジェクトが終わった後も（プロジェクトの期間よりずっと長く）動き続けるものである。そのような中で安定的に動作するということは、メンテナンスを行う立場からするとかなり信頼感が高い。その結果としてTCOなどのトータルなメリットを享受しているシステムになっている。 余談であるが、筆者が駆け出しのころ開発に携わりリリースされたシステムが、リプレースのため昨年サービスを停止した。その停止フェーズにおいても縁あって従事したのだが、きちんとシステムの役割を終えさせたということで、感慨深いものがあった。 |
||||||||||||
| 第2条：実環境で評価を実施する | ||||||||||||
|
個々のプロダクトごとで評価を実施するのではなく、本番さながらの統合環境を揃えて評価することが重要である。たとえそれがA社というベンダーですべて揃えられていても、ベンダーの推奨構成と要件が合致しないことも十分に存在し得るので、実環境での実施が肝要である。 しかしながら、諸事情でどうしても本番環境が構築できない場合やすべてのプロダクトにまで目が行き届かない場合「目利き」の熟練開発者に問いかけてみることが1つの助けとなる。 |
||||||||||||
| 第3条：自分でよいと思える理論を組み立てておく | ||||||||||||
|
「（場当たり的に、）とりあえず揃えました、検証してきちんと動きます」という結果がでても、そこに設計した人間の意志がないと後々「何でこうなっているのか」という疑問に答えきれない。 「なぜこの構成にしたのか」「他との違いは何であるか」といった理論を持っていることが、問題解決の糸口となることもある。設計者としての誇りを持つ意味でも重要である。 |
||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
