社内SEの徒然なる日記

私が管理しているシステムがあるのですが、色々と社内政治的な事情で別のシステムに置き換えることになりました。

業界特性的にパッケージソフトの適合性が低くいため、フルスクラッチで開発しています。また、運用保守もしっかりできているので、それっぽいパッケージソフト持って来ても色々と難しいのですが、どうしても新システムにしたいのだとか・・・

その辺りは別に良い（良くはないけど、どうせ失敗するし）と思っているのですが、その新システムとやらを担いできたベンダーが恐ろしくレベルが低くて驚愕しました。

何と言うか、今まで２０年ほど勤めて業界（といっても社内SEですが）の常識みたいなものも体に染み付いていると思っていたのですが、どうやら勘違いだったようです。

そのベンダーは、そこそこ歴史はあるのですが、規模としては小さなベンダーなので、大きな期待はしていなかったのですが、こちらが当然と思って話す言葉が通じない。うん、ビックリです。

例えば、ER図と言う言葉はお互いに通じるので、それで意思疎通できるのかと思ったのですが、相手が認識しているER図は何と言うか、CRUDを業務フローに合わせて配置したようなものだったりと、うん、訳がわからん。

専門用語を出しても一見通じてるように見えるのが質が悪いです。何と言うか、よくこれで今までやってこれたと驚いてしまいました。


ちなみに、ベンダー選定に私は関与していません。と言うか、会社の規模が小さすぎてリスクが高すぎるので、私であれば、そもそも候補にもしないようなベンダーだったりします。

最初に社内政治と書いたことから察するかもしれませんが、最近のDXとやらの影響で集められた自称システムに詳しい人たちが好き勝手にやっていると言う、ここ数年んで良く聞くようになった一コマだったりします。

会社の上の人たちって、システムをコストセンターくらいにしか捉えていないので、口の上手い人が適当に話していること（もっと安くなります！）を信じちゃうんですよね。そして、プロジェクトが進むにつれて過酷な現実に晒されて、ただただ無駄にお金が消えていくと言う・・・

さて、本当はもうちょっと具体的にダメダメだった話を書こうと思ったのですが、あんまり具体的に書くのも良くないかと思ってやめることにしました。結果的に、ただ愚痴っぽい記事になっちゃいましたね。

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

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

月に１度、決まったタイミングでデータベースの状態をチェックしています。

具体的には、ストレージの容量、Oracleが使用してている容量をストレージのスライス毎に算出。テーブルスペース、データファイルの容量を取得。これを毎月保存しておいて、一ヶ月間のデータ増加量（の平均値）、ストレージの空き容量などを確認しています。

さて、私が管理しているシステムでは月のデータ増加量は２〜３GBって所だったのですが、いきなり増加量が１０GBまで膨らんでしまいました。

・・・何かあったかな？


詳細は省きますが、色々と調べて行くと、旧システムから現在のシステムにデータ移行するために作ったインデックスに根本的な原因があるようです。

そのインデックス自体は使っていないのは知っていたのですが、私がシステム管理を引き継いだ時には既にあったものなので、消してしまう勇気が出なくて残していたのです。

でも、こうなると消さないとダメですね。

って事で、とある日曜日にシステムを停止してメンテナンスを行いました。インデックスを削除して、念のために統計情報を取り直して・・・

うん、何だか久しぶりにエンジニアらしい仕事をした気がします。


この類の仕事って、相応に知識と技術が必要な上に手間暇かかるし、上手くいっても目に見える変化がないので誰も褒めてくれないし、逆に失敗すると責められるので、やりたがる人は少ないと思います。

ただ、それでも私は結構好きだったりします。何というか、ゴミ掃除を終えてスッキリ！みたいな。

ここ数年は、自らプログラムを書くことも少なくなり、管理的な仕事が増えてきました。そういう仕事も嫌いじゃないし、むしろ得意ではあるのですが、やっぱり私はエンジニアっぽい仕事の方が好きなようです。

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

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

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

・・・遅い！

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

・・・何だかね。


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

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

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

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

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

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