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