データベース管理システム(DBMS)の移行プロジェクトは、不十分な調査や計画が元で予定以上に時間やコストがかかってしまい、失敗に終わるケースもある。本稿では、移行を成功させるコツを紹介しよう。
ガートナーの米国本社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、@IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。
私は最近、調査レポート「How to Succeed at Database and DBMS Migration」(データベースとDBMSの移行を成功させる方法)をまとめた。データベースの移行について、相談を受けることも多い。移行は頻繁に行われるようになっている。その背景の一つが、クラウドへの移行という潮流だ。
DBMSの移行プロジェクトは、時間やコストが計画を超過する場合が多く、完全な失敗に終わるケースもある。プロジェクトの初期段階で行われる調査や計画が不十分なことが、移行が失敗する最も一般的な原因の一つとなっている。「無計画とは、失敗を計画すること」というプロジェクト管理の古い格言そのままだ。以下では、私が相談を受けた時によく話す、移行を成功させるコツを紹介する。
直感に反するかもしれないが、「このデータベース/DBMSは移行できるか」という問いは間違っている。この問いは、チームが「どれだけ自信を持って進めているか」を集団で共有することになり、主観的な評価を促してしまう。
この問いは、幅広い認知バイアスや人間の弱さを招くことになる。これらについては、さまざまな記事や書籍(『Thinking, Fast and Slow(邦題:ファスト&スロー あなたの意思はどのように決まるか?)』など)でよく解説されている。人々は得てして、過度に楽観的な見通しを立ててしまう。どんな状況でそうなるのか、例を幾つか挙げてみよう。
誰かに移行の実現性について主観的な判断を求められたら、よく注意しなければならない。全てが悪い方向に進んでしまった場合、最初に評価したあなたのせいにされかねないからだ。
データベースシステムを移行することは常に可能だ。同じDBMSを使いながらデータベースをあるプラットフォームから別のプラットフォームに移行するのは、比較的簡単だ。だが、チームが古いシステムを廃棄し新しいシステムをゼロから構築しなければならない場合、多大な労力がかかるだろう。また、既存システムを完全に構築し直す場合は、ドラスチックな移行であり、さらに多くの労力がかかるかもしれない。
通常、チームは元のシステムに関する情報やドキュメントを参考にしてシステムを変換したり、システムの一部を構築し直したりできる。チームにとって、システムに関する知識は失われない。
このため、「移行できるか」という問いに対する答えは、常に「イエス」となる。実は組織に必要なのは、「どれだけのコストがかかるか」を知ることだ。コストには、かかる時間や労力、コスト、リソースが含まれる。コストが見積もられれば、経営幹部は利用可能なリソースと比較し、プロジェクトの実現性を確認できる。
コストを問うことは、正しくフォーカスしてプロジェクトを進めることにつながる。この問いに答えるには、チームは次のことを全て把握する必要があるからだ。
変換作業が自動化されているか半自動化されているか、あるいは手動かは重要な問題ではない。必要なリソースとそのコストを正確に見積もる上では、チームが上記の全てを十二分に把握することが肝心だ。データとコードを全て考慮に入れなければ、確実な見積もりをすることはできない。技術スタッフがさまざまなタイプのデータとコードをチェックしておらず、各タイプの変換方法も把握していなければ総コストは分からない。同様に、技術スタッフがテストプロセスやテストに必要な特別なツールやコードを把握していなければ、実現性の保証は当てにならない。
コストを見積もることで、チームは不確かな分野に目を向けられる。それは感情や主観に基づく判断を減らすのにつながる。これは、見積もりを左右するコストの洗い出しのポイントを押さえるのに役立つ。こうしたポイントには次のようなものがある。
チームは、メンバー間でお互いにこれらのポイントについて説明を求めることで、これらのポイントを簡単にチェックできる。確かに、見積もりミスが発生する可能性は残っているが、その可能性は軽減されている。洗い出しが完了すれば、議論の焦点は特定のデータおよびコードオブジェクトのセットや、そのそれぞれについてチームがすべき作業に移る。
チームはこの一連のプロセスを苦にしてはならない。コストの見積もりにおいて、理解のギャップを埋めていくことは、精度の向上に役立つばかりだ。そしてそれは、1回のサイクルで完了させる必要はない。チームは複数回のサイクルでプロセスを進め、サイクルごとに“サニティチェック”をしなければならない。チームは、数回のサイクルを経れば見積もりが堅実なものになり、その説明可能性や妥当性も向上することに気付くだろう。
以上のように、DBMSの移行は複雑でリスキーなプロジェクトだが、成功させ、建設的な効果を生むこともできる。全ては、上記のコスト見積もりを含む計画立案にかかっている。
この記事が皆さんのプロジェクトのお役に立てれば幸いだ。
出典:DBMS Migration − the Vital Question(Gartner Blog Network)
Sr Director Analyst
Copyright © ITmedia, Inc. All Rights Reserved.