-
momongarides
- 3717
- 15
- 1
- 0
-
- いいね！0
米村歩@日本一残業の少ないIT企業社長
@yonemura2006
システムで使わなくなった画面項目が出てきた時に、どのような対応方法を取ってますか？ １．画面上から削除し、DBのカラムも削除する ２．画面上から削除し、DBのカラムは触らない ３．害がなければ放置（画面もDBも修正しない） 受託開発で色々な大人の事情が絡むと２または３になりがちｗ
2018-09-14 10:05:17
睦月
@MuTsuKiS_77
うちの現場は2が圧倒的に多数だわ 結果、死んでいる項目がどんどん増えていくっていうね‥ twitter.com/yonemura2006/s…
2018-09-14 10:10:06
ヒロ@SE兼カイロプラクター
@htjpblog
他の画面での使用まで調査工数を掛けれないので、結局、2の画面上からのみ消す方向になる事が多いですねぇ。 twitter.com/yonemura2006/s…
2018-09-14 10:12:44
ずんだ
@violet_zunda
２が多いかなあ。 あとは、 ４．前から表示したかった別の項目として使うために画面を修正する。なお、カラム名の変更はしない(´・ω・`) とかありがち。。。 twitter.com/yonemura2006/s…
2018-09-14 10:13:12
Hiro.Nakamu
@malicia_nakamu
開発のアウトソーシングは、出す側にも要件定義できるだけの技術力と主体性が求められるので、組織内に優秀なリーディング役が居ないと取れない手段ですね。 あとは、決まりきった定期保守プロセスを全部出すくらいかな。 twitter.com/yonemura2006/s…
2018-09-14 10:15:39
米村歩@日本一残業の少ないIT企業社長
@yonemura2006
従業員を雇わずにアウトソーシングできる部分はアウトソーシングしていくというやり方は、それはそれで一つのやり方として有効なのですが、SESのやってるアウトソーシングとは単なる人材の横流しであってピンハネしてるだけだし、それは「奴隷商売」と何ら変わりないことが問題ですね。 twitter.com/SymboliRudolf1…
2018-09-14 09:59:21
システムエンジニアのごみ溜め
@siernosensi
圧倒的2です。小規模なシステムではない限り、大手企業や政府は安全に安全を重ねてこの選択肢になるような方針になることが多いような気がします。 twitter.com/yonemura2006/s…
2018-09-14 10:18:07
潮見佳助
@Keisuke_Shimi
@yonemura2006 だいたい3ですね。 変更してバグになると困るという謎の理論です。 そして数年おきに「要らないよねこれ？ とりあえず、本当に要らないか調査して」「やっぱり要らないのか。でも修正してクレームきたら責任とれないし」 というお約束の流れで無駄な調査工数の発生原因になる。
2018-09-14 10:19:01
いすか
@ishka_norm
金くれないなら3で マイナーレベルの改修ならまず2で メジャーレベルの改修なら要件定義からやるっしょなので1で 大体メジャーレベルの改修する金くれないので2に収まる(大人の事情≒金のパターン) twitter.com/yonemura2006/s…
2018-09-14 10:22:49
えすびす
@snail_develop
５．使わない画面項目が出てくること自体当初設計の瑕疵であり受注者の責任においてシステム全体の再構築をせよって言われてまるっきり違うシステムになるから無問題 (^q^) 最近 #本当にあったIT怖い話 専門アカウントになりかけてるな・・・ twitter.com/yonemura2006/s…
2018-09-14 10:26:51
kisse
@nyannko_kisse
基本的に2.の解決方法にしちゃいそう DBのカラム変更しちゃうと、取ってたデータが失われる場合があるので、別にそのカラムのデータを写した上でカラム削除とかかなぁ twitter.com/yonemura2006/s…
2018-09-14 10:34:40
井二かける@新作よろしく
@k_ibuta
個人的には、あまり良くないと思いつつ、まずは3を検討しますね。テスト工数、検印スタンプラリー工数が許容されるなら2。 twitter.com/yonemura2006/s…
2018-09-14 10:35:09
ケルビン＠斜壊人
@legendkelbin
画面入力＝取引入力なので、取引履歴残す要件の有無次第で1か2。後はお客様の予算次第かなー。DBも消した方が綺麗ではあるんだけど。 twitter.com/yonemura2006/s…
2018-09-14 10:42:05
元佐藤
@regonex
誤入力避けたいユーザ部門とコスト減らしたい&変更時のリスク減らしたい情シス協議の結果、2になるパターン twitter.com/yonemura2006/s…
2018-09-14 10:44:08
ギンレイ【Tomy】
@TomyGX
前職では1でやってたかな 影響範囲の調査はするし、最悪検証フェーズで判定はできてた(と思う) でも、だいたい2が多いんじゃないかな（と思ったりもする） twitter.com/yonemura2006/s…
2018-09-14 10:45:06
づかさん
@duka3d
こちらの提案は1、向こうからの回答は2、やる時にはいつの間にか3になってることも…。 twitter.com/yonemura2006/s…
2018-09-14 10:48:05
ほ
@harutin_99
後先のこと考えると1なんだけど、この先どうなるか確実なことが言えないとokだしてくれないから、結局2か3 twitter.com/yonemura2006/s…
2018-09-14 10:48:05
きーぼう
@ki_bou4789
1ができるのが理想だが、削除するのはトラブると大惨事になるのでやったことがない。2の方法を取るのが通常だが、決断したがらない上司へこの話を持っていくと3でやってくれということになる。 twitter.com/yonemura2006/s…
2018-09-14 10:55:15
YANCHA!
@yancha
|ω･`) 大人の事情で「4. 害が有るけど画面もDBも放置」という事があった。計算式に反映する項目なので必ず1を入力という運用に。 まあ大昔のオフコン時代の事ですが twitter.com/yonemura2006/s…
2018-09-14 10:55:26
ももやと称するsomething
@_momoya_
「使ってないから削除すんべ」と判断してくれる人がいないため 2. で対応しDBは塩漬け状態のままという王道パターンが多いなぁ。 twitter.com/yonemura2006/s…
2018-09-14 11:03:47
ズーキー
@zu_ki_kun
この場合に限らず「削除」っていう選択ができない人が上司またはお客さんだと、クソシステムが出来上がりますよね。 twitter.com/yonemura2006/s…
2018-09-14 11:29:4718/09/14 15:35 まとめ更新