アカウント名:
パスワード:
手間暇掛けてアップグレードしても、自分の得にならない。ただ、面倒なだけ。
開発業務の中で、バージョン管理ソフト等々、古いものを使う習慣には私は馴染めないなぁ。(このトピックの主題は、一般企業の業務システムのようだけど)
定形操作のステップ数が多く、フェイルセーフが不十分なツールで事故に対処してると実は再教育のコストのが小さいんじゃないか?と思う。
フェイルセーフが不十分なツール?
そもそも新しく出てきたものはほぼ例外なくフェイルセーフは不十分だよ。うっかりタッチしただけで即実行される方が危険ともいえる。
開発ツールの変更による操作ミスもしくは、新しいツールのバグ(および仕様)による設計ミスが起こり得るからでしょすでに稼働実績があるものであれば少なくとも既存製品のものでそういった不具合は起きない(起きてないことが確認できてる)訳でたいていが、代々資産を引き継いで次の製品に適用しいて行く方針だとこれは検証行程も減らせるありがたい話回路設計だと一つのミスが尾を引くと試作段階でも数百万円相当のインパクト、量産段階で発覚すると数千万、下手すりゃ億単位になっちゃうからツール一つに関しても切り替えは慎重にならざる得ないしそうなってくると変える人も億劫になってくるソフトウェア設計は今はオンラインバージョンアップの仕組みが整ってるからそんなあほみたいなコストにはならんだろうけどさ
バージョン間でフォーマットが違って、読めたり読めなかったりすると、大抵今使われてる古い方に合わせろっていう話になりますね。あとは、バージョンごとにIT部門に許可取らないといけないような仕組みになってる所だと、社員にそんな仕事をさせるのは失礼に当たるということで古いバージョンのまま運用されてたりします。
IDEを用いずに、エディタで開発している人挙手(^^)ノ
# エディタを使わずに、コマンドライン上から直書きが普通ですか(>_)
問題が起こる前に、その予兆がないか監視し、問題が起こる前に対処する事を、保守というのですよ。
残念な事に、起こってから対処した方が評価は良いわけで。
本当にそうだと思う。火事を予防する行為は評価されない。しかし、火事の中を飛び込んで助ける人は、英雄と評価されるのが現実である。よって賢人は評価される事が少ないという話でした。
経営者、あるいは、上司が理解ある会社は良いですね。
経営者側は、何故問題が起きていないのに対処する必要があるのか考えるはずです。具体的な損害額を算出して、それよりも保守費用が少なく済むことを経営者に示さなければならないんですよ。
今時の製造時には人が要らないほど自動化された工場でも、設備は定期的に保守、点検されていますよ。問題が起こった時に失う信用がデカイので、ソフトウェアなら運用でカバーできるとか夢見てるのかもしれませんけど。
工場なんかだと、操業時間に対する機材の運用時間ってのは普通に評価対象なんで、ストップタイムとメンテ・リプレースの関係は簡単に示せるので寧ろマシ。
問題はオフィスみたいに、問題が頻出しながらも非効率なりに業務が続けられる様な所。
セキュリティに理解が広まるまでの経緯とおなじです
XP?
みんな、3270に戻ろうぜ。端末が何であれエミュレータさえ動けば生きていけるんです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
めんどくさい (スコア:2)
手間暇掛けてアップグレードしても、自分の得にならない。
ただ、面倒なだけ。
Re:めんどくさい (スコア:1)
開発業務の中で、バージョン管理ソフト等々、古いものを使う習慣には私は馴染めないなぁ。
(このトピックの主題は、一般企業の業務システムのようだけど)
定形操作のステップ数が多く、フェイルセーフが不十分なツールで事故に対処してると
実は再教育のコストのが小さいんじゃないか?と思う。
Re: (スコア:0)
フェイルセーフが不十分なツール?
そもそも新しく出てきたものはほぼ例外なくフェイルセーフは不十分だよ。うっかりタッチしただけで即実行される方が危険ともいえる。
Re: (スコア:0)
開発ツールの変更による操作ミス
もしくは、新しいツールのバグ(および仕様)による設計ミスが起こり得るからでしょ
すでに稼働実績があるものであれば少なくとも既存製品のものでそういった不具合は起きない(起きてないことが確認できてる)訳で
たいていが、代々資産を引き継いで次の製品に適用しいて行く方針だとこれは検証行程も減らせるありがたい話
回路設計だと一つのミスが尾を引くと試作段階でも数百万円相当のインパクト、量産段階で発覚すると数千万、下手すりゃ億単位に
なっちゃうからツール一つに関しても切り替えは慎重にならざる得ないしそうなってくると変える人も億劫になってくる
ソフトウェア設計は今はオンラインバージョンアップの仕組みが整ってるからそんなあほみたいなコストにはならんだろうけどさ
Re: (スコア:0)
バージョン間でフォーマットが違って、読めたり読めなかったりすると、大抵今使われてる古い方に合わせろっていう話になりますね。
あとは、バージョンごとにIT部門に許可取らないといけないような仕組みになってる所だと、社員にそんな仕事をさせるのは失礼に当たるということで古いバージョンのまま運用されてたりします。
Re: (スコア:0)
IDEを用いずに、エディタで開発している人挙手(^^)ノ
# エディタを使わずに、コマンドライン上から直書きが普通ですか(>_)
Re: (スコア:0)
問題が起こる前に、その予兆がないか監視し、問題が起こる前に対処する事を、保守というのですよ。
Re:めんどくさい (スコア:5, すばらしい洞察)
残念な事に、起こってから対処した方が評価は良いわけで。
Re:めんどくさい (スコア:1)
本当にそうだと思う。火事を予防する行為は評価されない。しかし、火事の中を飛び込んで助ける人は、英雄と評価されるのが現実である。よって賢人は評価される事が少ないという話でした。
Re: (スコア:0)
経営者、あるいは、上司が理解ある会社は良いですね。
経営者側は、何故問題が起きていないのに対処する必要があるのか考えるはずです。
具体的な損害額を算出して、それよりも保守費用が少なく済むことを経営者に示さなければならないんですよ。
Re: (スコア:0)
今時の製造時には人が要らないほど自動化された工場でも、設備は定期的に保守、点検されていますよ。
問題が起こった時に失う信用がデカイので、ソフトウェアなら運用でカバーできるとか夢見てるのかもしれませんけど。
Re: (スコア:0)
工場なんかだと、操業時間に対する機材の運用時間ってのは普通に評価対象なんで、
ストップタイムとメンテ・リプレースの関係は簡単に示せるので寧ろマシ。
問題はオフィスみたいに、問題が頻出しながらも非効率なりに業務が続けられる様な所。
Re: (スコア:0)
セキュリティに理解が広まるまでの経緯とおなじです
Re: (スコア:0)
XP?
Re: (スコア:0)
みんな、3270に戻ろうぜ。
端末が何であれエミュレータさえ動けば生きていけるんです。
Re:めんどくさい (スコア:2)