既存のデータアーキテクチャがイノベーションを阻んでいる10の兆候：パート3 #MongoDB #DataArchitecture #DIRT
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは、MongoDB社のブログで2022年1月22日に公開された「10 Signs Your Data Architecture is Limiting Your Innovation: Part 3」の日本語翻訳です。
これまでの記事はこちらでご覧いただけます：Part1、Part2
データベースのアーキテクチャが複雑であると、すぐにさまざまな問題が生じます。生産性が低下し、開発者のストレスが増加するほか、開発チームは既存システムの保守に時間を奪われてイノベーションの取り組みに集中できません。アプリの現状を維持するのに煩雑な作業が必要で、その作業で工数を使い果たしてしまうため、アプリの機能強化に必要以上に時間がかかってしまいます。
この複雑さは、様々なかたちとなって現れ、それらが積み重なると、革新的なアイデアを市場に送り出す際の深刻な妨げとなる可能性があります。MongoDBでは、この影響をデータアーキテクチャの複雑さを直接の根本原因とする一種の税と捉えており、DIRT（Data and Innovation Recurring Tax、データとイノベーションに関する経常税）と呼んでいます。
さらに、弊社は、企業がこのDIRTを支払っている場合に現れる10の徴候を特定しました。詳細については、弊社のホワイトペーパー、『10 Signs Your Data Infrastructure is Holding You Back』（英語）をご覧ください。
徴候その5：新しい機能を数日で展開できず、完了までに数か月を要する
データアーキテクチャが複雑であると、開発者は、複数の言語を絶えず切り替えたり、さまざまなフレームワークで思考をしたりしなければなりません。データベースを直接操作する言語、データベース上に開発されたオブジェクトリレーショナルマッピング（ORM）レイヤーを使用する言語、あるいは検索機能にアクセスする言語など、開発者がそれぞれ違う言語を利用している状況になっている可能性もあります。このような状態は、生産性の低下を招く足かせになります。
これでは、個人のレベルで作業のスピードが落ちるだけでなく、開発チーム全体の仕事の進め方にも影響が生じます。すべてのアプリケーションアーキテクチャが個別開発のアーキテクチャである場合、開発者のスキルを組織全体で共有したり、役立てたりするのはほぼ不可能です。そして開発のスピードは低下します。また、キーパーソンであった従業員が退職してしまうと、ほかの人間ではその代わりを十分に務められず、そのニッチなスキルを持つ人材を新たに確保しなくてはなりません。これだけでも大変困難なことに加えて、そのスキルが1～3年後に必要がなくなるかもしれないという問題もあります。
徴候その6：スキーマ変更の展開が、新しい機能を開発するより時間がかかる
リレーショナルデータベースを使用し、アプリケーション内容の変更を頻繁に行っている場合、スキーマ※の変更はまず避けられないでしょう。ある調査によれば、アプリケーションの内容を変更する場合、60%のケースで既存のスキーマの改修が必要になると言います。おまけに、データベースへの変更は、データベースがサポートするアプリケーションの変更以上に、デプロイに時間がかかるのです。
レガシーのリレーショナルデータベースを使用する場合、開発者はプロジェクトの最初の段階でスキーマを選択しなくてはなりません。必要なデータの全体像やアプリケーションの使われ方を理解するのはその後になります。そして、ユーザーのフィードバックを受けながら、時間の経過とともにアプリケーションの形が整っていきますが、それが当初予想していたものとは異なるケースが少なくありません。この時点ではスキーマがすでに固定されているので、変更はきわめて困難になります。そのため、開発チームは、難しい選択を迫られることになります。すなわち、実際には適しているとは言い難いスキーマ環境のままで新しい目標の達成を試みるか、痛みを伴うプロセスを経てスキーマを変更するかのどちらかを選ばねばならないのです。
※スキーマとは、データベースの構造を定義したもの。各フィールドのデータ型やデータの大きさ、主キーの選択など。
>DIRTやDIRTの軽減方法について詳しく知りたい方は、
ホワイトペーパー『DIRT and the High Cost of Complexity』（英語）をご覧ください。
ブログシリーズの続きはこちらにてご覧いただけます：Part4
