FC2ブログ

社内SEの徒然なる日記

改元対応の再調査完了!

■ 新元号の発表

新元号の発表日が正式に開示されました。事前の予想通り2019年4月1日だそうです。

・・・遅い!

確かに、大抵のシステムはパラメータを直すだけですが、一ヶ月前じゃ手間が増えるのです。

例えば、事前に2019年5月1日以降だった場合も「平成」と表示するようにプログラムを直し、新元号が発表されたら「平成」とした箇所を新元号に置き換えるとか。

言葉にすると簡単ですが、最近のシステム改修って色々と手続きとかあるし、他の案件との調整とかもあるので面倒なんですがね。

■ 再調査

それはそうと、改元に対する影響の調査自体は前年の内に終わらせていました(改元の対応が思ったよりも辛い(ListCreator))。

なのですが、そこで横から「全部、西暦にしよう」とかいう衝撃の発言が・・・

いや、パラメータを変えるだけで終わる機能(画面、帳票)については放置の予定だったんですが。そこを含めると影響範囲が増えるんですが。根回しもなく、いきなり宣言するのやめて!

ってことで、再調査ですよ。やれやれです。

■ 後書き

実のところ、もう手を付けないと間に合いそうに無いのですが、他に大きな案件があって調整が大変です。改元対応と、別の案件で機能が被っていたりするので、それをどうするのかって話もありまして。この様子だと、6月くらいまで引きずりそうです。

そうそう、基本的には和暦は廃止する予定なのですが、一部は和暦のままにします。例えば、手形とか。

もう西暦で良い気がするのですが、そもそも手形にプレ印刷されているし、勝手に西暦にしても受け付けてくれないだろうし、そうなると和暦で出力せざる得ません。

これ、手形の印刷もそうですが、合わせて手形に関係する画面や帳票も和暦で表示した方が一貫性があって使う方としては便利なんですよね。

あと、官公庁に関係するシステムも同じことが言えます。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

改元の対応が思ったよりも辛い(ListCreator)

■ 改元の対応試算

2019年5月1日に改元が行われるようです。システム屋としては、これに対応しなければなりません。そろそろ年も変わりそうなので、影響範囲を調べて見ました。

今のシステムは10年くらい前に作ったものなので、元号の変更対応は出来ているはず。手形の関係とか、一部の機能で和暦を使っていますが、データ自体は西暦だし、西暦と和暦の変換は共通処理になっているので、そこを修正するだけで対応完了・・・の筈だったのですが、実際に調べて見ると誤算がありました。

■ ListCreator(帳票)

まず、帳票に直接「平成」と書かれているものがありました。何かの冗談かと思ったのですが、本当に元号を直打ちしています。

・・・誰だ、こんな帳票作ったのは!

さらなる誤算がListCreatorの和暦表示。ListCreatorというソフトで帳票を作っているのですが、かなりの本数で和暦表示をしていました。

まともに対応すると、1ヶ月以上かかりそうだったのですが、ソフトウェアの変換であれば、何かの設定ファイルの変更とかパッチとかで対応できる気がします。

そう思って調べたのですが、ListCreatorには「和暦のカスタマイズ指定」が可能らしいという情報を見つけました。これで行けるかと思って、自分が使っているパソコン上で設定を弄って見たのですが、ListCreatorデザイナのプレビュー機能では確かに新元号への対応が出来ました。

これで行けるかと思ったのですが、ここに罠が・・・

実際にAPサーバの設定を修正して試して見たのですが、「和暦のカスタマイズ指定」が機能しません。どうしてだろうと思ったのですが、マニュアルを読むとCOBOLからの出力には対応していないとか。

だったら、Javaからだったらどうかと思ったのですが、こちらもダメです。

んで、こちらの理由はListCreatorのバージョン。「和暦のカスタマイズ指定」ってV10.4からの対応だったらしく、APサーバのバージョンはV10.0。

・・・結局、地道に対応するしかなさそうです。

■ 後書き

しかしこれ、富士通(ListCreatorの製造元)はどう考えてるんですかね。せめて修正パッチを提供するのが当然の対応だと思うのですが。対応しているバージョンにアップデートしろと言われても、Solaris(APサーバのOSはSolaris)に対応したバージョンってV10.0までだった気がします。

うーん、プログラムで和暦変換するって手もありますが、それよりも和暦表示を止める方が良い気がします。とりあえず、その前提で見積もりますかね?

ちなみに、Oracleの機能を使用した和暦変換も1機能だけ使っていたのですが、それはプログラムを書き換えることにしました(Javaで作った共通処理で和暦変換する)。Oracleの設定で対応することも可能みたいですが、たった1機能しか使っていないのであれば、プログラムを直した方が早いです。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

年度変わりの組織変更と業務組織の機能集約の影響

■ 問い合わせ

私は社内SEなので、現場の人間から色々と相談を受けて、基幹システムを修正したり、業務の自動化を行ってきました。もう20年近く会社にいるので、私が作ったツールが多数社内に存在しています。

普段は意識していないのですが、この時期(4月、5月)になると、それに対する問い合わせが頻繁に発生するようになります。

何でかというと、年度変わりで組織変更したり、人事異動をしたりするので、担当者が変わるのです。その時に前任者から引き継ぎは行われるのですが、伝言ゲームのごとく情報に漏れが発生して、結局はこちらに問い合わせがくることになります。

・・・そんな、何年も前に作ったものなんて覚えていないよ。

■ 業務組織

さて、勤め先では、今年は管理系の部門で大きめの組織変更が行われました。

その中で、これまでは営業部門の中にいた業務サポートの人員を、一つの業務部を作って集中させることになりました。ですが、まともに機能していないようです。

基本的には営業をサポートする部署ではあるのですが、明確に部署が別れると仕事って頼みにくいんですよね。その結果、誰にも頼めずに自分で抱えることになってしまいます。

前述の問い合わせですが、取引先から送信される納品データを変換して基幹システムに取り込むというツールに対するものだったのですが、私の記憶では業務サポートの人が処理を行っていたはずです。

なのですが、実際の問い合わせは営業の課長クラス。一体どうしたのかと思ったら、これまで頼んでいた人が人事異動で全員いなくなり、部署も分けられてしまって頼めなくなったので、自分でやっているとのこと。

・・・何だかね。

■ 後書き

各部署に散っていた業務サポートの人員を集めて部署を作るって発想そのものは、理論としては間違っていないのでしょうが、現実的にはなかなか機能しないものです。

勤め先でも、管理系の部門の人間の主導で時々行うのですが、数年後には営業から仕事が廻らないとクレームがついて、元どおりに各部署に人を配置するようになるという流れを何度も繰り返しています。

構想としては、各部署から仕事を請け負う組織としたかったのでしょうが、部署が別れた段階で、仕事を頼むのが大変になるので、結局は自分で抱えてしまうんですよね。

さて、今回作った組織は何年持つかな?

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

絵に描いたようなシステム導入失敗の進み方

■ 失敗事例?

ここ数年、会社に銀行出身の人たちがやってきて、新部署を設立して何やらやっています。勝手にやっていれば良いと思うのですが、火の粉が我が身に降りかかってきたので、人ごとではなくなりました。

奴らは、何やらシステムを導入して業務を効率化するとか言っています。

それが悪いとは言いませんが、現状分析も何もせず、ベンダーや商品の選定もせず、これまで付き合いのなかった会社からシステムを購入して話を進めようとします。

口が上手いのか、経営陣にはうけが良いらしく誰も反対せずに導入決定。なのですが、そこからの進め方が・・・

導入するシステムを使うのは営業系の部門なのですが、その打ち合わせには管理部門の人間しか参加していません。

我々システム部門の人間には、一切相談なくベンダーやシステム構成まで決めてしまって決裁まで進めてから、「基幹システムから連携しろ」とかって上から目線言っています。

・・・何か、システム導入が失敗する典型的な進め方だなぁと思う、今日この頃です。

■ 後書き

他所から来た人間は、短期間に何らかの成果を求めるようで、そのために分かりやすいのがシステム導入による業務の効率化です。

だからこそ、システム導入のノウハウを持つシステム部門の承諾もなく話を進めているのでしょうが、さて、どうなるでしょうかね。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

画面や帳票にやたらと*とか#とか付けたがるの止めて!

■ 理解不能の記号

昔々のシステムは、今のように画面を自由に動かすことが出来ませんでした。また、帳票にしても柔軟な出力ができず、多くの制約がありました。

つまり、1画面、1帳票に表示できる内容に限界がありました。

そこで、ある状態を表すために記号を多用していました。例えば、ある状態を表す時に *(アスタリスク)を表示する、とかです。見る方は、記号を読み取って意味を解釈していました。

ただ、この方法には、不慣れな人には記号の意味が分からないという問題があります。

業界特有の表現方法とかなら兎も角、特定の画面、帳票の中での特有の状態を表す区分とかに使うと、もう何が何やら分かりません。

ってことで、私がシステム開発の主担当になってからは、保守が面倒な記号表記は取りやめて、日本語で表現するようにしました。昔のメインフレームと違って、今はかなり柔軟に作れるので、表題とかレイアウトを工夫すれば、案外何とでもなるものです。

これによって、「この * って何?」っていう問い合わせがなくなりました。

■ 帳票の作成

会社の業務処理の変更とやらで新しい帳票が必要になりました。

使用用途を確認して、社内の業務内容を検討した上でソート順だのレイアウトだの作って提示したのですが、かなりダメ出しをくらいました。

その指摘が納得できるものなら良かったのですが、・・・まぁ、この話の流れで分かる通り、条件を満たす明細に *(アスタリスク)を付けろと言うのです。

何でも、帳票の表示項目を増やすためだとか。

いや、今の帳票って指定サイズに収まるように文字フォントを自動縮小したり、段落とかの区切りも柔軟に設計できるので、そんな無理しないでも良い感じに収まるんで、見た人が分かるように日本語で表現しましょうよって言ってるんですが・・・

何だかね。

■ 後書き

もちろん、こんなことを言うのは年配(55〜70)の方々です。どうも、昔からの感覚が捨てきれないようで、何度話しても一歩も引きません。

正直、そう言う見栄えの部分は若手に任せて貰ったほうが良いものが出来るし、本人たちも私が入社した頃には同じようなことを言っていたはずなのですが、何と言うか、年をとるって嫌なものです。

まぁ、正直もうどうでも良くなりました。これ以上言うと私の人事考課に関わりそうなので、もう放っておきましょう。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop