こんにちは。今日は久しぶりに新聞記事を採り上げます。日経新聞の企業面（10面）に今日から「消費増税の焦点」という連載が始まりました。
「消費増税」という表現には違和感を覚えますが、これは2014年4月と2015年10月に予定されている消費税率の引き上げの事を指しているようです。（といっても巷ではほとんどこの言い回ししかされていないようですが）
コンピュータシステムの中でも勘定系や決済系のシステムでは諸税法の改正などにより日々のメンテナンスを余儀なくされます。基準日や割合（率）、基準値の境界などの定数を書き換えなければなりません。ただ変えれば良いのではなく、新しい率がいつから適用されるのか、またどの範囲に適用されるのかといったことを緻密に管理していかなければなりません。
今日の新聞記事で採り上げられていたのは東日本旅客鉄道のIC乗車券といえばお馴染みの Suica です。記事によると Suica のシステムは、サービスインの期日を優先するため消費税率の変更機能の作り込みを見送ったそうです。おそらく見送った機能はそれだけではないと思いますが、それでも、今度の税率引き上げ期日までに消費税率変更機能を実装するには1年以上の期間と数十億円の費用を見積もっているとのこと。
記事はここまでの状況を淡々と伝えるにとどまり、このことについてどう評価すべきかについては何も書かれていません。これは非常にげんなりする状況です。だからといって設計者や当システムのオーナーを簡単に責めるべきではないと思います。サービスインの期日を優先するということはビジネス戦略上の判断だったと思います。2000年問題の時もそうでした。多くのシステムでは将来の改修費用よりも現在のストレージ費用の節約を選びました。しかしその一方で、必ずやって来る2000年を想定して最初から年を4桁で格納するように設計されたシステムも存在していたのです。
最初からあらゆる変更に対応できるように、あるいはあらゆる業務に対応できるように汎用的なシステムを望むユーザーは多いです。しかしそのためにはシステムの設計からテストまで費用も時間もかかってしまうし、汎用的であるということは裏を返すと「どの局面においても使い勝手がイマイチ」となるリスクもあるのです。重要なことはあらゆる変更や変化を想定した上で、どこで折り合いをつけるかというトレードオフであるということ。そして判断には少なからず責任が伴うということではないでしょうか。