データベース管理システム（DBMS）の移行を成功に導く質問：Gartner Insights Pickup（192）

データベース管理システム（DBMS）の移行プロジェクトは、不十分な調査や計画が元で予定以上に時間やコストがかかってしまい、失敗に終わるケースもある。本稿では、移行を成功させるコツを紹介しよう。

[Henry Cook, Gartner]

ガートナーの米国本社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、＠IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。

　私は最近、調査レポート「How to Succeed at Database and DBMS Migration」（データベースとDBMSの移行を成功させる方法）をまとめた。データベースの移行について、相談を受けることも多い。移行は頻繁に行われるようになっている。その背景の一つが、クラウドへの移行という潮流だ。

　DBMSの移行プロジェクトは、時間やコストが計画を超過する場合が多く、完全な失敗に終わるケースもある。プロジェクトの初期段階で行われる調査や計画が不十分なことが、移行が失敗する最も一般的な原因の一つとなっている。「無計画とは、失敗を計画すること」というプロジェクト管理の古い格言そのままだ。以下では、私が相談を受けた時によく話す、移行を成功させるコツを紹介する。

「このシステムは移行できるか」は間違った問い

　直感に反するかもしれないが、「このデータベース／DBMSは移行できるか」という問いは間違っている。この問いは、チームが「どれだけ自信を持って進めているか」を集団で共有することになり、主観的な評価を促してしまう。

　この問いは、幅広い認知バイアスや人間の弱さを招くことになる。これらについては、さまざまな記事や書籍（『Thinking, Fast and Slow（邦題：ファスト＆スロー　あなたの意思はどのように決まるか？）』など）でよく解説されている。人々は得てして、過度に楽観的な見通しを立ててしまう。どんな状況でそうなるのか、例を幾つか挙げてみよう。

• 忙しいチームメンバーが時間に追われ、綿密な調査をしない
• チームメンバーが目先の短期的な問題しか眼中になく、DBMSの移行はまだ先のことと考えている
• プロジェクトリーダー候補者が同僚の前で、頼りなさそうに見られまいとする
• チームメンバーが、経営上層部に良いニュースを伝えようとする強引な上司の圧力に抵抗できない

　誰かに移行の実現性について主観的な判断を求められたら、よく注意しなければならない。全てが悪い方向に進んでしまった場合、最初に評価したあなたのせいにされかねないからだ。

正しい問いは「移行にどれだけのコストがかかるか」

　データベースシステムを移行することは常に可能だ。同じDBMSを使いながらデータベースをあるプラットフォームから別のプラットフォームに移行するのは、比較的簡単だ。だが、チームが古いシステムを廃棄し新しいシステムをゼロから構築しなければならない場合、多大な労力がかかるだろう。また、既存システムを完全に構築し直す場合は、ドラスチックな移行であり、さらに多くの労力がかかるかもしれない。

　通常、チームは元のシステムに関する情報やドキュメントを参考にしてシステムを変換したり、システムの一部を構築し直したりできる。チームにとって、システムに関する知識は失われない。

　このため、「移行できるか」という問いに対する答えは、常に「イエス」となる。実は組織に必要なのは、「どれだけのコストがかかるか」を知ることだ。コストには、かかる時間や労力、コスト、リソースが含まれる。コストが見積もられれば、経営幹部は利用可能なリソースと比較し、プロジェクトの実現性を確認できる。

何を把握すべきか

　コストを問うことは、正しくフォーカスしてプロジェクトを進めることにつながる。この問いに答えるには、チームは次のことを全て把握する必要があるからだ。

• システムのデータ項目：アーカイブ、バックアップ、ディザスタリカバリーサイトを含むあらゆるデータ。見落としがあると、後で予想外のコストが発生する可能性がある
• 各種のデータと、開発者がそれらを新しい環境に変換、転送する方法
• コード：システムとアプリケーションのコード。あらゆるコードについて、その種類と新しいシステムに変換する方法を理解する必要がある。DBMSの移行においては、チームは異なるDBMS間でのコマンドの変換も理解しなければならない。さらに、使われている全ての言語、制御ステートメント、構成ファイルなども考慮する必要がある。そのため、システムに含まれるプログラムよりも多くの種類のコードを把握しなければならない
• テスト：設計者は、上記の全てがテストを経た上で、安全に本番環境に移行されるようにする必要がある。通常、個々のコードとデータについて、一連のステップを踏んでシステム、パフォーマンス、ユーザー受け入れのテストをする
• チームがセットアップ、移行、またはテストをする必要がある他の要素：例えば、ドキュメンテーション、バックアップ／リカバリーやHA／DR（高可用性／ディザスタリカバリー）といった運用手順、トレーニングコースなど

　変換作業が自動化されているか半自動化されているか、あるいは手動かは重要な問題ではない。必要なリソースとそのコストを正確に見積もる上では、チームが上記の全てを十二分に把握することが肝心だ。データとコードを全て考慮に入れなければ、確実な見積もりをすることはできない。技術スタッフがさまざまなタイプのデータとコードをチェックしておらず、各タイプの変換方法も把握していなければ総コストは分からない。同様に、技術スタッフがテストプロセスやテストに必要な特別なツールやコードを把握していなければ、実現性の保証は当てにならない。

主観を排する

　コストを見積もることで、チームは不確かな分野に目を向けられる。それは感情や主観に基づく判断を減らすのにつながる。これは、見積もりを左右するコストの洗い出しのポイントを押さえるのに役立つ。こうしたポイントには次のようなものがある。

• チームは移行の範囲を把握しているか
• 技術スタッフは、全てのタイプのコードを変換するための方法を全て特定しているか
• テスト担当者はテストハーネス（ソフトウェアのテストに使われるソフトウェア）を設計し、その開発の労力を見積もっているか

　チームは、メンバー間でお互いにこれらのポイントについて説明を求めることで、これらのポイントを簡単にチェックできる。確かに、見積もりミスが発生する可能性は残っているが、その可能性は軽減されている。洗い出しが完了すれば、議論の焦点は特定のデータおよびコードオブジェクトのセットや、そのそれぞれについてチームがすべき作業に移る。

　チームはこの一連のプロセスを苦にしてはならない。コストの見積もりにおいて、理解のギャップを埋めていくことは、精度の向上に役立つばかりだ。そしてそれは、1回のサイクルで完了させる必要はない。チームは複数回のサイクルでプロセスを進め、サイクルごとに“サニティチェック”をしなければならない。チームは、数回のサイクルを経れば見積もりが堅実なものになり、その説明可能性や妥当性も向上することに気付くだろう。

　以上のように、DBMSの移行は複雑でリスキーなプロジェクトだが、成功させ、建設的な効果を生むこともできる。全ては、上記のコスト見積もりを含む計画立案にかかっている。

　この記事が皆さんのプロジェクトのお役に立てれば幸いだ。

出典：DBMS Migration − the Vital Question（Gartner Blog Network）

筆者　Henry Cook

Sr Director Analyst