怒りを通り越してあきれるOracleユーザー
「Oracle Database（DB）は信頼性や可用性が高く、当社のシステムには欠かせない。しかしここ数年、保守料が右肩上がり。IT予算に占めるOracle DBの保守料金の割合が増えて困っている」。 製造業A社のシステム部長は悩んでいた。会計や販売管理、生産管理など社内の主要なシステムは全てOracle DBを利用している。しかし開発時期はバラバラで、システム構築を依頼したITベンダーもシステムごとに異なっていた。Oracle DBのライセンスはシステム構築に合わせて、その都度購入している。システムごとに同じOracle DBとはいえ、バージョンは異なり、システム部門の保守作業も手間になっていた。 「Oracle DBを使っているシステムの維持費用を削減したい」。こう考えたシステム部長は、安定稼働していて、今後も大きな業務機能の変更もないと想定できるシステムのデータベースの保守契約を止
技術的負債を抱えた状態で技術者がすべきこと - sandbox
この Qiita のエントリに触発され、元文章の目的はさておき、技術的負債についての自分の考えを書いてみようと思う。 技術的負債の定義や、問題は下記エントリを参照して頂くとして、なかでも最後の「技術者がすべきこと」について、「自分だったらこの様にアプローチするか」ということを書く。 技術者がすべきこと 大前提 開発前にステークホルダー(ここではプロジェクトの責任者とする)に、プロジェクトの性質として何を重視するかを認識、選択してもらう。 短期的な価値実現を最優先とし、初速を重視、ソフトウェアの健全さ、プロダクトの成長速度を犠牲にする 長期的な価値実現を最優先とし、ソフトウェアの健全さ、プロダクトの成長速度を重視し、初速を犠牲にする 1 を選択するという事について、健全でない状態や、成長速度が犠牲になった状態がどの様なものかを、プロジェクトが走り出す前に十分に認識してもらう必要がある。 …と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
