TOPプロジェクト管理> 誤ったデータベース選定
プロジェクトの成功要因
プロジェクトを成功に導くキーファクター

第4回:安定したIT基盤を支える技術選択

著者:日本総研ソリューションズ  前田 稔   2007/5/24
前のページ  1  2  3  次のページ
誤ったデータベース選定

   昨今の情報システムを構築するにあたり、その情報を蓄積し、活用するソースとしてのデータベースが最重要のプロダクトとなる。近頃では戦略的IT活用の高まりもあり、その重要性はさらに増しており、要件としても厳しくなってきている。それだけに、そのプロダクト選定や利用方法において問題が発生するケースも多い。

   筆者が経験した、データベースに関連する問題事例としては、以下のようなものがある。
  1. 処理の高速性を追求した結果、CPU性能にばかり目がいき、データを格納する際に最も重要となるDISKの性能を軽視していたため、I/Oでボトルネックとなった

  2. 信頼性、可用性向上のために十分な冗長化構成を採用したが、本来必要とされる以上の構成にしたため、無駄に遊んでいるサーバができてしまった

  3. システムに格納されるデータ量の見積もりが甘く、運用時のデータ再編成の頻度が上がり、それによって計画停止の時間が増えた

  4. ハード構成、データ容量の見積もりはきちんとできていたが、アプリケーション側で最適なロジックやSQLが考慮されていなかったため、レスポンスが返ってこないなど、性能面で深刻な問題が発生した

  5. リレーショナルデータモデルの特性が考慮されておらず、データモデルの正規化がなされていなかったため、メンテナンスが不可能なくらいアプリケーションが複雑になってしまった

表2:データベースに関連する問題事例

   これらのうち、1〜3で上げたものは基盤要素にかかわる問題であり、一方、4〜5はプロジェクトを進めていく際の問題と分類ができる。

   いずれの問題についてもきちんと対応していかなければ安定した情報基盤としての活用は困難となり、プロジェクト完了後も潜在リスクを残す(むしろ、カットオーバー後のほうが影響が大きくなる)ものである。


プロダクト評価に欠かせぬ視点

   ここまで述べてきたことを踏まえ、ITプロジェクトの円滑な遂行のもとに最適なシステム基盤を構築するためには「技術要素からの視点ではなく、あくまでも主はシステム化の要件の明確化である」ことを、改めて肝に銘ずべきことである。

   もしこれが疎かにされると「技術を入れんがためのプロジェクト」になり、その結果、誰も保守できずサポートしてくれないといった、「ゾンビ的なシステム」が生みだされてしまう。

   この原則に立ち返って、ポイントとなる3ヶ条を整理し記載する。


第1条:運用まで考慮された寿命の長い構成かどうかを評価する

   これは適用するプロダクトや技術がプロジェクト期間内だけではなく、その後のシステム維持にも耐え得るかどうかという視点である。開発プロジェクト中であれば、開発者の確保やベンダーサポートの供給も得やすく、関係者を動員してリリースまで漕ぎ着けることができる。その後の保守フェーズでは、システムが支える事業の展開を睨んだ上での要員確保には困難を伴うのが現状である。

   構築されたシステムは、その構築プロジェクトが終わった後も(プロジェクトの期間よりずっと長く)動き続けるものである。そのような中で安定的に動作するということは、メンテナンスを行う立場からするとかなり信頼感が高い。その結果としてTCOなどのトータルなメリットを享受しているシステムになっている。

   余談であるが、筆者が駆け出しのころ開発に携わりリリースされたシステムが、リプレースのため昨年サービスを停止した。その停止フェーズにおいても縁あって従事したのだが、きちんとシステムの役割を終えさせたということで、感慨深いものがあった。


第2条:実環境で評価を実施する

   個々のプロダクトごとで評価を実施するのではなく、本番さながらの統合環境を揃えて評価することが重要である。たとえそれがA社というベンダーですべて揃えられていても、ベンダーの推奨構成と要件が合致しないことも十分に存在し得るので、実環境での実施が肝要である。

   しかしながら、諸事情でどうしても本番環境が構築できない場合やすべてのプロダクトにまで目が行き届かない場合「目利き」の熟練開発者に問いかけてみることが1つの助けとなる。


第3条:自分でよいと思える理論を組み立てておく

   「(場当たり的に、)とりあえず揃えました、検証してきちんと動きます」という結果がでても、そこに設計した人間の意志がないと後々「何でこうなっているのか」という疑問に答えきれない。

   「なぜこの構成にしたのか」「他との違いは何であるか」といった理論を持っていることが、問題解決の糸口となることもある。設計者としての誇りを持つ意味でも重要である。

前のページ  1  2  3  次のページ


株式会社日本総研ソリューションズ 前田 稔
著者プロフィール
株式会社日本総研ソリューションズ  前田 稔
株式会社日本総研ソリューションズ 技術本部
テクノロジーセンター所属
1998年 東京工業大学大学院修了
1998年 日本総合研究所に入社。主にカードシステムに関わる開発に従事
2005年 技術本部に着任。現在はシステム基盤研究、開発支援業務を実施中


INDEX
第4回:安定したIT基盤を支える技術選択
  技術選択のリスク
誤ったデータベース選定
  活用まで見据えた「真のアーキテクト」