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

重要ポイント

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

Q. どのような基準で選定したのですか？

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

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

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

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

A. 想定していたよりもはるかに大がかりな再構築が必要になりました。設計の根本から手を入れることになり、当初の見積もりでは収まらない時間とコストがかかりました。初期に削減したはずのコストの何倍もの費用を、後から負担する結果になったと実感しています。

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

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

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

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

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

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