アカウント名:
パスワード:
私もSIerの一員でした。そして誰もが知っている超大手メーカの出入り業者として様々なシステム開発を受託してきました。(開発当時としては)新しい技術を使えたこともありましたが、保守案件は総じてひどいものでした。Struts1、Tomcat4、素のJSP(w/ ものすごい量のスクリプトレット)、VB6等々なんでもござれでした。
要するに一度作ったら基盤のバージョンアップはしないわけです。だからそれを保守する係もポンコツ基盤と付き合っていかなくてはいけません。そうしているうちに世の中に置いていかれてしまうわけです。しかしこの手の保守案件は定期的に(たい
システム新規開発の企画時に「システムの寿命」というものを考慮していないことがあげられます。
システムのライフサイクルの定義をすること自体は可能でも、これを顧客に納得してもらうのは難しくありませんか?
年単位の歳月をかけて作ったシステムが数年でリプレースが必要ですよなんてお話は顧客に到底納得いただけないです。 結果、追加投資を最小限にしていかに使い続けるかを模索するわけなんですが、 コストが限られているから人の流れもとまって属人化してしまっている様に思えます。
こうしたシステムのライフサイクル全体を踏まえてこそ「システムエンジニアリング」だと思うのですが…
まっとうなシステムエンジニアリングにはコストが掛かりますしユーザーにとっては耳の痛い(面倒な)話も多いです。 それでも顧客をうまく説得するのもエンジニアリングの手腕でもあると思うのですが本当に難しいですね。 ボク自身連戦連敗です...
WEBシステム屋だけど客は〇年で減価償却する開発予算を立てるだけだから、要件定義の段階で寿命の設定をしないなんてことも納得しないなんてこともありえなんだけどどんな分野なの。別に設定した寿命を超えてユーザが使い続けることを止めはしないけどそれによって引き起こされる問題を保証する義理も面倒見る義理もないよね。
結局保守による人貸し業で安定収入を確保したがるシステム屋の経営方針が客のシステム投資に対する意欲を鈍らせる要因になってるだけだと思う。
基幹系では塩漬けのシステムって良くある話ですね。 継続したビジネス(人貸し業での安定収入やリプレイスタイミングでの開発案件)を期待しているからこそベンダーは面倒をみるのです。運用保守の現場がヒドいといっても長期的には数十億~数百億のビジネスですからベンダーは撤退しないでしょう。
一方でそんな現場に嫌気がさすならエンジニア個人として転職するっていうのはアリだとは思います。
それって減価償却後も使い続けてるだけでしょ、最初から考慮しないのとは全く別の話じゃん。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
その決断ができるならSIerなどとっくになくなっている (スコア:2)
私もSIerの一員でした。そして誰もが知っている超大手メーカの出入り業者として様々なシステム開発を受託してきました。(開発当時としては)新しい技術を使えたこともありましたが、保守案件は総じてひどいものでした。Struts1、Tomcat4、素のJSP(w/ ものすごい量のスクリプトレット)、VB6等々なんでもござれでした。
要するに一度作ったら基盤のバージョンアップはしないわけです。だからそれを保守する係もポンコツ基盤と付き合っていかなくてはいけません。そうしているうちに世の中に置いていかれてしまうわけです。しかしこの手の保守案件は定期的に(たい
Re: (スコア:2)
システム新規開発の企画時に「システムの寿命」というものを考慮していないことがあげられます。
システムのライフサイクルの定義をすること自体は可能でも、これを顧客に納得してもらうのは難しくありませんか?
年単位の歳月をかけて作ったシステムが数年でリプレースが必要ですよなんてお話は顧客に到底納得いただけないです。
結果、追加投資を最小限にしていかに使い続けるかを模索するわけなんですが、
コストが限られているから人の流れもとまって属人化してしまっている様に思えます。
こうしたシステムのライフサイクル全体を踏まえてこそ「システムエンジニアリング」だと思うのですが…
まっとうなシステムエンジニアリングにはコストが掛かりますしユーザーにとっては耳の痛い(面倒な)話も多いです。
それでも顧客をうまく説得するのもエンジニアリングの手腕でもあると思うのですが本当に難しいですね。
ボク自身連戦連敗です...
Sin
Re: (スコア:0)
WEBシステム屋だけど客は〇年で減価償却する開発予算を立てるだけだから、
要件定義の段階で寿命の設定をしないなんてことも納得しないなんてこともありえなんだけどどんな分野なの。
別に設定した寿命を超えてユーザが使い続けることを止めはしないけど
それによって引き起こされる問題を保証する義理も面倒見る義理もないよね。
結局保守による人貸し業で安定収入を確保したがるシステム屋の経営方針が
客のシステム投資に対する意欲を鈍らせる要因になってるだけだと思う。
Re: (スコア:2)
基幹系では塩漬けのシステムって良くある話ですね。
継続したビジネス(人貸し業での安定収入やリプレイスタイミングでの開発案件)を期待しているからこそベンダーは面倒をみるのです。
運用保守の現場がヒドいといっても長期的には数十億~数百億のビジネスですからベンダーは撤退しないでしょう。
一方でそんな現場に嫌気がさすならエンジニア個人として転職するっていうのはアリだとは思います。
Sin
Re:その決断ができるならSIerなどとっくになくなっている (スコア:0)
それって減価償却後も使い続けてるだけでしょ、最初から考慮しないのとは全く別の話じゃん。