西暦が無難ですねって話

スポンサーリンク

1年前に元号改定プロジェクトを経験して、西暦が無難だねーって思った話をします。当時僕が担当していた顧客は全てスクラッチ開発で納品したシステムだったため、すべてのシステムを調査から行いました。ほとんどテストを行うプロジェクトでしたが、まぁ大変なプロジェクトでした。

まずは調査!和暦の持ち方バラバラ問題発生

当時の顧客のほとんどが和暦表示のシステムだったため、調査がすごく大変でした。

同じ会社が納品したシステムなのに和暦の持ち方がバラバラでした。iniファイルを利用したシステム・DBにマスタを持っているシステム・レジストリから読み込むシステムがありました。なかにはマスタとレジストリのハイブリッドも存在していました。

調査を行う側からすると「統一してくれー」って思いましたよwその時にiniファイルやレジストリについて勉強できたので良かったのですが。

顧客への説明資料作成

変更箇所の特定・日付表示箇所の調査が完了すると、資料にまとめ顧客へ新元号対応の提案をしました。

顧客からは「元号対応は保守で行うべきではないのか」という意見もある一方で、「なぜ開発時に西暦にしなかったのか」と言う顧客もいました。どちらも契約書や開発時の議事録を基に説明したため、強引な押しはありませんでしたが、価格の交渉や変更箇所・テスト内容の説明で半年かかりました。

今回の改修を機に和暦から西暦への改修も提案しましたが、すべての顧客は和暦での継続を希望しました。

全画面のテスト開始

当時のリーダーが全画面・全帳票を確認する工数で受注してきたため、和暦表示箇所を全てテストすることになりました。(読み込み関数やクラスは一緒なのですが。。。)

平成最後の日と新元号の初日で出力結果が想定している元号であることのテストを永遠に行いました。テストは嫌いではありませんが、この作業はきつかったですw

西暦が無難ですね

唯一西暦の顧客は元号の改修はありませんでした。話を聞いてみると、昭和から平成に変わったときに西暦にしたそうです。

和暦の顧客にも話を聞きましたが、銀行や市役所などに提出する資料は和暦にする必要があるそうです。残念なことに西暦にしたいけど、取引先や役員が和暦派のためどうしても変更できないということもありました。

西暦だと改修もパッチもいらないので、西暦がいいなーって思った案件でしたw

タイトルとURLをコピーしました