アカウント名:
パスワード:
「さすが」って、それ毒されすぎ。
改元なんて絶対に起きることのひとつであり、むしろ運用計画に入っていて当たり前。洗い出しに工数がかかるなんて、閏年の対応を洗い出しますと言っているようなレベルの話であり、改元の影響がわからないから洗い出すなんて、そんなことを平然と主張できる神経を疑う。
それな。。。
ほんとなんなのこのマッチポンプって思う。自分たちが中身作ったんじゃないんで知りません、って言ってるだけじゃん。
私もそう思っていた。
だが,平成生まれのコーダたちは「改元ってなんですか?」のレベルだ。 平成1x年入社の連中も大差はない。
改元ってなんですか?
風邪薬。
10年、20年に一度のイベントが運用計画に入っていて当たり前というのはさすがに要求が高すぎではないでしょうか。もちろん、最初の要求仕様として入っていれば話は別ですが。
日本人なら当然考慮すべき仕様なのに何言ってんの?馬鹿なの?いつ事故やテロにあわれて崩御するかもわかんないんだよ?
言いたいことはわかるけども、元のコメントにもあるように「要求仕様にあるならば」ですね。起きるか起きないか定かじゃない機能にお金と時間を割くということを良しとしない組織は多々あるので、「わかっちゃいるけど組み込むことを禁じられた」ってケースも多いと思う。
実際、設計したり作ったりしてるのは外部の人間だから、そこを強く押して突き通すほどの義理もなく……って。
で、10年20年たって「まったく別の組織やチーム」が和暦利用箇所洗い出しをやらされる。そんなところかと。
>起きるか起きないか定かじゃない自体が考え間違ってるでしょ。
「改元は必ず起きるもの」だろうに。天皇陛下が機械の体貰って不老不死にでもならない限り。
「”このシステムの運用期間中に”起きるか起きないか定かではない」が正しいシステムの稼動期間を限定してコストを下げるという事は普通に行われます
でも真面目な話、「組み込むかどうか」は議論になれど、「想定するかどうか」で言ったら想定はすべき仕様ですよね。「改元?うん、分かってるけど期間短縮のため省略」はまあアリとしても「改元?なんですかそれ?」はバカじゃね?と言われても仕方ない的な意味で。だから「洗い出しに工数がかかる」はまあ非難するこっちゃないけど「さすが」もちょっと言い過ぎ、くらいが落としどころなのでは(適当)
間違いなく工数削減のために削られてますよね。客は予算を削りたがり、納期は固定したがるのだから。
客「元号変更に対応し、運用手順書とテストもしてください」開発「テストの工数はXX、運用手順書の作成にYYかかります。その分を見積もりに上乗せしますね。」客「それは無理。テストや手順書は不要だから改元を考慮したシステムにしたら工数の上積みは不要?」開発「設計では当然改元を考慮するので不要です。」客「じゃあそれでいいです。」
だいたいこんな感じで、改元に関しては何のテストもされないまま納品されるのが普通でしょう。
同意。富士通は、消費税が変わる時も調査やテストが大変とか言うのだろうか?(だとしたら、相当にタコ)
消費税の変更があったら改元以上に「難しくはないが大きな工数が予想される」のは当然だけど。# 消費税対応で設定用パラメータ変えるだけおっけーなので、ほぼ工数0です!なんてエンジニアが居たら、基本地雷だと思うよ。# 極小システムで予算が無ければ仕方ないとして諦めるだろうけど、基本は全通テストして重要システムなら稼動日は担当者をそれなりの人数待機させるでしょ。
和暦使用箇所を中央集権的に管理して全て把握してるならいいが、そうでないなら何らかの洗い出しは必要だし、何かを変えたら必ずテストが必要になるのが普通だと思うけどなあ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
改元の影響を「洗い出す」とは・・・ (スコア:1)
「さすが」って、それ毒されすぎ。
改元なんて絶対に起きることのひとつであり、むしろ運用計画に入っていて当たり前。洗い出しに工数がかかるなんて、閏年の対応を洗い出しますと言っているようなレベルの話であり、改元の影響がわからないから洗い出すなんて、そんなことを平然と主張できる神経を疑う。
Re: (スコア:0)
それな。。。
ほんとなんなのこのマッチポンプって思う。
自分たちが中身作ったんじゃないんで知りません、って言ってるだけじゃん。
Re: (スコア:0)
私もそう思っていた。
だが,平成生まれのコーダたちは「改元ってなんですか?」のレベルだ。 平成1x年入社の連中も大差はない。
Re:改元の影響を「洗い出す」とは・・・ (スコア:2)
風邪薬。
Re: (スコア:0)
10年、20年に一度のイベントが運用計画に入っていて当たり前というのは
さすがに要求が高すぎではないでしょうか。
もちろん、最初の要求仕様として入っていれば話は別ですが。
Re: (スコア:0)
日本人なら当然考慮すべき仕様なのに何言ってんの?馬鹿なの?
いつ事故やテロにあわれて崩御するかもわかんないんだよ?
Re:改元の影響を「洗い出す」とは・・・ (スコア:1)
言いたいことはわかるけども、元のコメントにもあるように「要求仕様にあるならば」ですね。
起きるか起きないか定かじゃない機能にお金と時間を割くということを良しとしない組織は
多々あるので、「わかっちゃいるけど組み込むことを禁じられた」ってケースも多いと思う。
実際、設計したり作ったりしてるのは外部の人間だから、そこを強く押して突き通すほどの
義理もなく……って。
で、10年20年たって「まったく別の組織やチーム」が和暦利用箇所洗い出しをやらされる。
そんなところかと。
Re: (スコア:0)
>起きるか起きないか定かじゃない
自体が考え間違ってるでしょ。
「改元は必ず起きるもの」だろうに。天皇陛下が機械の体貰って不老不死にでもならない限り。
Re: (スコア:0)
「”このシステムの運用期間中に”起きるか起きないか定かではない」が正しい
システムの稼動期間を限定してコストを下げるという事は普通に行われます
Re: (スコア:0)
でも真面目な話、「組み込むかどうか」は議論になれど、「想定するかどうか」で言ったら想定はすべき仕様ですよね。
「改元?うん、分かってるけど期間短縮のため省略」はまあアリとしても
「改元?なんですかそれ?」はバカじゃね?と言われても仕方ない的な意味で。
だから「洗い出しに工数がかかる」はまあ非難するこっちゃないけど「さすが」もちょっと言い過ぎ、くらいが落としどころなのでは(適当)
Re: (スコア:0)
間違いなく工数削減のために削られてますよね。
客は予算を削りたがり、納期は固定したがるのだから。
客「元号変更に対応し、運用手順書とテストもしてください」
開発「テストの工数はXX、運用手順書の作成にYYかかります。その分を見積もりに上乗せしますね。」
客「それは無理。テストや手順書は不要だから改元を考慮したシステムにしたら工数の上積みは不要?」
開発「設計では当然改元を考慮するので不要です。」
客「じゃあそれでいいです。」
だいたいこんな感じで、改元に関しては何のテストもされないまま納品されるのが普通でしょう。
Re: (スコア:0)
同意。
富士通は、消費税が変わる時も調査やテストが大変とか言うのだろうか?
(だとしたら、相当にタコ)
Re:改元の影響を「洗い出す」とは・・・ (スコア:3)
消費税の変更があったら改元以上に「難しくはないが大きな工数が予想される」のは当然だけど。
# 消費税対応で設定用パラメータ変えるだけおっけーなので、ほぼ工数0です!なんてエンジニアが居たら、基本地雷だと思うよ。
# 極小システムで予算が無ければ仕方ないとして諦めるだろうけど、基本は全通テストして重要システムなら稼動日は担当者をそれなりの人数待機させるでしょ。
Re: (スコア:0)
和暦使用箇所を中央集権的に管理して全て把握してるならいいが、そうでないなら何らかの洗い出しは必要だし、何かを変えたら必ずテストが必要になるのが普通だと思うけどなあ。