サマータイムの議論をいろいろ見ていて
自分でいうのもなんですが、私は大手SIerで業務SEをやっていましたが、その中ではレアなオール工程経験型です。(もちろん程度はありますよ)
事業計画(社内のお金回り)をはじめ、営業*1やコンサルから、保守運用、撤収現場まで経験していて、最後の部署に異動になった時は、なんじゃこの経歴?って言われた記憶があります。*2
現場でラッキングしたり、床に潜って配線調査とかも普通にしてます。
人事や総務、会計とかはしてないので経験しておきたかったです。資材調達とかも面白そうだとおもいますがその辺は分業で経験することはできませんでした。*3
いきなり脱線しました
で、サマータイムのような事案をシステムに組み込むなんてことは、少なからず自分が担当していた(かかわっていた)システムに適応するなら、これぐらいってのは分かっています。
が、大体自社管理の大規模システムだったり、自己完結するシステムだったり*4するんですよね。。。
前記事にも書いていますがスタンドアローンでエンドユーザにわたるシステムってあまりかかわっていなんですよ。大体ネットにつながっていたり、データセンタがあったりするものばかりでした。
ってことで、世間からずれてる気がします。
なので一番最初の記事にも書いたようにCE(カスタマーエンジニア)とかエンドユーザに近い人達の混乱は多大なものだと思います。
小さいシステムは
おんぶにだっこじゃないですが、ある程度他社製ミドルなどに依存し、影響が免れない可能性が高いでしょう。
なのでPCに入っててアップグレードも手動、設定も手動的なアプリ開発をしている場合は、変更がクソめんどくさい気がします。
とはいえ、保守対応ができているのであればUpgradeパッチを提供するだけでしょうが、日本の悪しき文化として保守に入らない人がいっぱいいます。はてさてそういう人にはスポット対応ですかね、、高いっすよー。
国内全体で整合性が取れなくなったらどうすんの?ってことですねハイ。
そういう小さいシステムほど
顧客が個別対応で五月蠅い気がします。
対価を払わないのに対応しろと、、、人を確保するだけでもどれだけのコストがかかると思ってるんだこの野郎、って思ったことは大規模システム開発でも同じでしたのでそれがいたるところでおきるわけですよね。はてさて、契約しなかったあんたが悪いとか、これが今回の見積もりですどうぞみたいな感じで言い切れるだろうと思うのは私が大企業病にかかっているからだと思います。
仕様変更を仕様変更と思ってくれない人達の比率はシステム規模(額)に反比例している気がします( ´艸`)
何が言いたいか分からない記事ですが
混乱はある、そしてどこでどの程度の規模で起きるかもある程度想像できる、がその問題をどう表現するかが難しいきがします。
なのでシステムエンジニアにフタンガー、フタンガーってッて言ってごまかしている気がします。
導入にあたり検討する方々は幅広い知識をお持ちの方でしょうから私なんかよりも精度の高い予測ができると思います。それを偉い(と思っている)、システムのことなんてちんぷんかんぷんな人達にどう説明するかを見守っていきたいと思っています。
まとめ
一般人にまずサマータイムってなんなのよをちゃんと説明する期間と起きた時の対処方法を周知しないとね。
思いついたからやってみよう!的なのならマジやめちまえ。なんでもそうですが準備が99%なんですよ。
ということで、利用者(エンドユーザ)の意識欠落割合が一定数を超えてる時点で破綻するでしょう。
多分、業界(やエリア)で10%もいたらどうしようもなくなると思います。(しらんけど)