アカウント名:
パスワード:
他の大手と違って、これまで企業合併・統合しつつも、システム面やサービス、業務を全然整理できていない状態なんだから、来いって言われても困るだろうな
そもそも自分とこの子会社が上手く立ちまわったり仕切れないのに、いらん事ばっか主張してくるもんだから、ベンダーも自分の責任にされたくないって方向に向いちゃうと思うし一過性の増員要請に対して、ベンダーがその後に何を期待できんの?って事もあるし
既に何年も経ってるのに、未だに合併前の基幹システムは温存させちゃうってたりとか、設計書の無いサブシステムだらけとか、イレギュラーな処理を無理やりカスタマイズで延命させてたりとか、どこを見ても不幸なレールしか見えないってのは、なかなかないと思うんだよね更に付け加えると、ベンダーやソフトハウスをどれだけ大事にしているかという所も大きいと思うし
問題はどこにあるのかってのを経営陣もわからんといかんと思うんだよなあ
ゼロベースで新しく作って,古いほうと並行して動かす.どちらへも同じ入力が行くが,新しいほうからの出力は古いほうからの出力と比較するのみ.違いがあったら新しいほうを修正する.実際に使うのは古いほうからの出力だけ,というのを1年間続けてから移行,とかできないかな.川人先生の本にあった,小脳のモデルのように.
君、DB使うプログラム書いたことないだろ?
いや、スクラッチからの開発じゃないけど、それやっているところありますよ(大手金融機関)入力をスプリットして、新しく開発したシステムにも流し、結果をチェックするというプロセスを1年続けてました。
はい。やりますよね金融系とか信販系。
おまけに本番データを扱うことになるので開発会社は「スプリットする仕掛け」までしか扱えず、実際のオペレーションは現場の人に「同じように」やっていただく必要があるため、現場への負担がものすごい。
個人情報バリバリのデータなので、結果比較も我々が手を出せなかったりするため、比較ツールや手順をきっちり組んで相手側システム会社にやってもらうとか。ネットワーク的にも本番系と開発系を入り混ぜるわけにいかないため、並行稼働用の環境を別途用意とか……
さらにこの辺どこまで現場の人と実際の業務時間を捻出してもらえるかの交渉とか、日程調整、全データが無理だとしたら「火曜日の午前、1時間だけ」とか時間やデータを区切るとか、そういうことの調整作業がものすごく大変。
そこまでしないと信頼できるシステム作れないのか?という意見もあるかとおもいますが、システム入れ替えで結果が変わらないことをどう保障するんだ?という問いに対する答えとして実際に並行稼働をやっているシステム、開発プロジェクトはあると思いますよ。
「同値検証」って言い方も。金融でなくてもやるでしょ、大きくてしっかりしたところなら。自分が先日までいたのは電話系。
どっちかというと、受け入れ側でシステム入れ替えで問題が出ないことを納得するための意味合いが強いような気がする。ユーザに納得してもらうという事自体はすごく重要なので、馬鹿にしているわけではありません。#というか仕事の半分以上はそれを目的としているとも言える
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
同じ金融系でも (スコア:0)
他の大手と違って、これまで企業合併・統合しつつも、システム面やサービス、業務を全然整理できていない状態なんだから、来いって言われても困るだろうな
そもそも自分とこの子会社が上手く立ちまわったり仕切れないのに、いらん事ばっか主張してくるもんだから、ベンダーも自分の責任にされたくないって方向に向いちゃうと思うし
一過性の増員要請に対して、ベンダーがその後に何を期待できんの?って事もあるし
既に何年も経ってるのに、未だに合併前の基幹システムは温存させちゃうってたりとか、設計書の無いサブシステムだらけとか、イレギュラーな処理を無理やりカスタマイズで延命させてたりとか、どこを見ても不幸なレールしか見えないってのは、なかなかないと思うんだよね
更に付け加えると、ベンダーやソフトハウスをどれだけ大事にしているかという所も大きいと思うし
問題はどこにあるのかってのを経営陣もわからんといかんと思うんだよなあ
Re: (スコア:0)
ゼロベースで新しく作って,古いほうと並行して動かす.どちらへも同じ入力が行くが,新しいほうからの出力は古いほうからの出力と比較するのみ.
違いがあったら新しいほうを修正する.実際に使うのは古いほうからの出力だけ,というのを1年間続けてから移行,とかできないかな.
川人先生の本にあった,小脳のモデルのように.
Re: (スコア:0)
君、DB使うプログラム書いたことないだろ?
Re:同じ金融系でも (スコア:1)
いや、スクラッチからの開発じゃないけど、それやっているところありますよ(大手金融機関)
入力をスプリットして、新しく開発したシステムにも流し、結果をチェックするというプロセスを1年続けてました。
Re:同じ金融系でも (スコア:1)
はい。やりますよね金融系とか信販系。
おまけに本番データを扱うことになるので開発会社は「スプリットする仕掛け」までしか扱えず、
実際のオペレーションは現場の人に「同じように」やっていただく必要があるため、現場への
負担がものすごい。
個人情報バリバリのデータなので、結果比較も我々が手を出せなかったりするため、比較ツール
や手順をきっちり組んで相手側システム会社にやってもらうとか。ネットワーク的にも本番系と
開発系を入り混ぜるわけにいかないため、並行稼働用の環境を別途用意とか……
さらにこの辺どこまで現場の人と実際の業務時間を捻出してもらえるかの交渉とか、日程調整、
全データが無理だとしたら「火曜日の午前、1時間だけ」とか時間やデータを区切るとか、
そういうことの調整作業がものすごく大変。
そこまでしないと信頼できるシステム作れないのか?という意見もあるかとおもいますが、
システム入れ替えで結果が変わらないことをどう保障するんだ?という問いに対する答えとして
実際に並行稼働をやっているシステム、開発プロジェクトはあると思いますよ。
Re: (スコア:0)
「同値検証」って言い方も。
金融でなくてもやるでしょ、大きくてしっかりしたところなら。
自分が先日までいたのは電話系。
Re: (スコア:0)
どっちかというと、受け入れ側でシステム入れ替えで問題が出ないことを納得するための意味合いが強いような気がする。
ユーザに納得してもらうという事自体はすごく重要なので、馬鹿にしているわけではありません。
#というか仕事の半分以上はそれを目的としているとも言える