エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント1件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
DB構造の悪さが事業の足をひっぱる - 設計者の発言
何度も大規模改修するわりに、いつまでたっても使いにくく保守しにくい。大企業を含めてそのような業務... 何度も大規模改修するわりに、いつまでたっても使いにくく保守しにくい。大企業を含めてそのような業務システムを抱える例がじつは少なくない。基幹システムとして事業の足を引っ張っていることが明らかなので、思い出したように刷新プロジェクトを立ち上げるのだが、使いやすさも保守性も一向に改善されない。 じっさいには「刷新」が求められるケースはそれほど多くない。たとえばCOBOLシステムをRDBベースに置き換える場合ならば、全面刷新は必要だし、意義深い。他にも、それまで手当されていなかった業務領域をシステム化するとか、サイロ化された複数のシステムをひとつに統合するといった場面でも全面刷新やスクラッチ開発が求められる。しかし、頻度が少ないとはいえいったん全面刷新した後に、10年以内のサイクルでおおがかりな改修を繰り返しているとしたら、何らかの根深い原因があると考えていい。 典型的な原因が「DB構造の悪さ」だ
2018/07/20 リンク