コストだけで選んだデータベースが、あとで足かせになった話

重要ポイント

• 時期: 2000年代・日本
• 立場: 動画配信システムの開発責任者
• 判断: 費用の安さだけでデータベースを選定
• 結果: 移行時に大がかりな作り直しが必要に

Q. どんな選び方をしたのですか？

A. 費用の安さだけを見て、特定のデータベースに依存した設計にしてしまいました。当時はその選択が合理的に見えましたし、実際に初期コストは抑えられました。予算が限られている立ち上げ期だったので、安さを優先したくなる気持ち自体は自然なことだったと思います。

Q. どこで問題に気づいたのですか？

A. 事業が育っていく中で、そのデータベースに強く依存した設計になっていることが表面化してきました。機能を拡張しようとしても、そのデータベース特有の仕組みに縛られて自由が利きません。事業が小さいうちは気づかなかった制約が、成長するにつれて足かせとして表れてきました。

Q. 実際に移行しようとしたときは、どうなりましたか？

A. 想定していたよりもはるかに大がかりな作り直しが必要になりました。設計の根本から手を入れることになり、当初の見積もりでは収まらない時間とコストがかかりました。初期に浮かせたはずのコストを、何倍にもして払い戻すような結果になったのが実感です。

Q. 今はどう対策していますか？

A. どんな技術を選ぶときも、あとで他のサービスに乗り換えようとしたらどれくらいの費用と時間がかかるかを、見積もりの段階で必ず試算するようにしています。乗り換えのしやすさそのものを、選定基準の一つとして数値化するイメージです。

Q. これは中小企業のシステム選びにも共通する話ですか？

A. 共通します。特に月額の安さで選びがちなSaaSやクラウドサービスほど、あとで乗り換えにくい設計になっていることが多いです。導入前に「これをやめるときはどうなるか」を確認しておくだけで、多くのトラブルを防げます。

Q. 見積もりの段階で試算するとき、具体的にはどんな数字を出すのですか？

A. 移行にかかる開発工数、データ移行の手間、移行中の停止時間による機会損失などをおおまかにでも数字にします。厳密でなくても、「乗り換えるとこれくらいの負担がある」という桁感を持っておくだけで、選定時の判断がまったく変わってきます。