社内SEの徒然なる日記

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

■ 理解不能の記号

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

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

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

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

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

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

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

■ 帳票の作成

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

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

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

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

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

何だかね。

■ 後書き

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

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

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

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

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

PageTop

今度の開発案件は在庫の発注サポートシステム No1 構想

■ 状況

勤め先では、在庫品の管理は各部署単位で行っています。管理系の部門としては在庫の集中管理をしたいのですが、同じ商品でも部署が違うと原価が異なるため、現場が在庫統合を嫌がるのです。

それに、在庫の発注担当からすると、自分が管理する在庫を使うのは自分の所属部署(つまり、立ち上がって見渡せる範囲にいる人達)だけなので、管理が楽というのもあります。

なのですが、時代が徐々に変わって行って、部署管理から集中管理に方式が変わりつつあります。

■ 在庫管理

さて、そうなると在庫品の荷動きの予想が難しくなるという問題が発生します。受注時に出荷する日付が決まっているのなら話は早いのですが、在庫を使うのは決まっているが出荷日は未定ということが良くあります。

現状の在庫システムでは、現在の在庫数、引当済み数、未引当数は把握できます。出荷日が未定の場合、未引当数にカウントされるのですが、これがいつ頃に出荷されるのか見当がつかないので、在庫品を発注するタイミングが分かりにくくなったそうです。

ってことで、この問題をなんとかする在庫品の発注サポート機能を作ることになりました。

■ 後書き

単純に考えれば、在庫に下限数を設定しておいて、それを下回ったらアラートを上げるという仕組みで良いのでしょうが、これだと問題が解決しない気がします。

色々と知恵を絞っているのですが、過去の入出荷の実績、在庫回転率、出荷数量の標準偏差、発注から入荷までの平均日数、伝票起票から出荷日が決定するまでの平均日数あたりから、適正在庫数を算出できないかと考えています。

理想としては、在庫管理の経験が少ない人でも困らないようなものにしたいところです。さて、上手く作れるかな?

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

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

PageTop

基幹システムの移行!(2017)移行と後始末

■ 基幹システム移行

去年(2016年)からずっと取り組んでいた基幹システムの移行(基幹システムの移行!(2017)基幹システムの移行!(2017)の徹夜でダウン(風邪)DBサーバのディスクをSSDにしたら高速移行が出来た)ですが、ようやく完了しました。

しかし、本稼働後に少し問題は出ました。

Oracleのバージョンが11から12に変わったのですが、その影響か一部の処理(というか、SQL)が異様に遅くなりました。DBサーバの膨大なメモリとSSDの力で何とか業務が止まらない程度の速度は出ているのですが、ちと問題です。

統計情報に問題があるのかとも思ったのですが、取得し直しても結果は変わらず。色々と対応方法は思いつくのですが、素直にヒント句を追加して性能の安定を図りました。

他にもパラパラと出てしまいましたが、大きな目線で問題になることはなかったので一安心です。

■ ラックの移設

本稼動から数週間。今度はラックの移設を行いました。

新しいサーバー(などの機器)は、一時的に借りたラックに置いていたのですが、月を跨ぐと費用が発生してしまいます。今更切り戻しってこともあり得ないので、古い機器を撤去して、その場所に移設することにしました。

言葉にすると簡単ですが、IDCの機器って普段は電源入れっぱなしってのが多いので、移設に合わせて電源の入れ直しをするのは実は結構なリスクがあったりします。

電源の入れる順番を間違えると起動しないとか普通にあるし、電源を入れた後でさらに別のサービスを起動しないと行けなかったりと、きちんとシステム構成を把握していないと大問題に発展します。

ってことで、電源の停止&起動の順番を考えて、稼動後の確認手順を作成して、私がいなくても問題なく作業できるように関係者に周知して、そうそう、移設作業中はシステムが使用できないので現場に連絡して、うん、意外とやることありますね。

・・・・・・・・・・・・いや、基幹システム自体の持分は私ですが、ラックの移設って別の人の担当だったような気が。まぁ、別に良いんですけどね。

■ 後書き

遅くなったSQLを見ると、片方はWITHで作った内部テーブルを抽出条件として使用するSELECT文を UNION ALL でくっ付けています。実行計画を見ると、何故かWITHの結果を見ないで妙な条件で再抽出するような奇妙な動作をしています。もう片方はSQLを引っこ抜いて実行計画を見ると特に変な感じはしません。

前者は結構知恵を絞りました。使用するインデックスの指定だけではダメで、テーブルの結合順番まで細かく指定して、ようやく望みの実行計画になってくれました。Oracleのオプティマイザって徐々に良い感じに動くようになっているとは思いますが、逆に言うと妙な動作をするようになったのなら、チューニングも手間が掛かるようになったとも言えるかも知れません。

問題は後者の方です。Enterprise Managerで実行時のSQLを見るとマスタ系のテーブルをフルテーブルスキャンしたり、明らかに参照していない項目を使ったインデックスを使っていたりと、奇妙な実行計画になっています。

しかし、そのSQLを引っこ抜いてSQL Developerで実行計画を取って見ると、良い感じに実行計画を作っています。こういった特定の条件下で発生する遅延って厄介です。

まぁ、実は原因は想像がついていて、おそらくCOBOLから実行しているのが良くないと思われます。COBOLからOracleを使うには、ソースをPro*COBOLプリコンパイラなるものを通して変換する必要があるのですが、その変換に何やら問題がありそうなのです。

こうなった時の対策は、ヒント句を突っ込むのが手っ取り早いです。

いや、正確には動的SQLにしてやればPro*COBOLによる変換を回避できるようなので、そっちにするって手もあるのですが、埋め込みSQLを動的SQLに書き換えるのは少し手間だし、ヒント句の追加に比べてリスクが高くなるので避けたいところです。

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

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

PageTop

DBサーバのディスクをSSDにしたら高速移行が出来た

■ システム移行

少し前に書いていましたが、ゴールデンウィーク中に基幹システムの移行を行います(基幹システムの移行!(2017))。

作業を要約すると、Oracleのエクスポート&インポートという方式なのですが、やはりデータ量が多いので、それなりに時間が掛かります。

今から6年ほど前にも同じように移行をしたのですが、その時はエクスポートして、インポートして、アナライズを実行して・・・とか夜通し実行を続けて、丸々2日掛かりました。

■ SSDの力

今回も同様の方式で移行したのですが、これが恐ろしく早いです。インポートが3時間、アナライズも1時間程度。Oracle以外にも移行するファイルは存在したのですが、そっちの方が時間がかかったくらいです。

何故こんなに早かったかというと、ぶっちゃけるとDBサーバーのディスクをSSDに変えたから。やはり非接触式のディスクは性能が違います。ちと高くはなりましたが、これだけ早くなるなら投資した価値があるというものです。

■ 後書き

そういう訳でして、日が暮れる前に移行が終了しました。終了といっても、移行計画としては翌日の作業もあるので完全に終わりって訳ではありませんが、主要な作業は終わったので終わったようなものです。

事件が起こるとしたら、ゴールデンウィーク明けにユーザーが使い始めてからですね。

さて、軽く祝杯でもあげようかな?

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

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

PageTop

プロジェクトリーダー(自称)だが、メンバーが・・・

■ プロジェクト計画

少し大きめのプロジェクトが動いてい、私が実質的なプロジェクトリーダーとしてプロジェクト計画を立案して進めていました。

ここで指標とするのが、以前学んだプロジェクトマネジメント。まぁ、資格試験の結果は残念なものでしたが(プロジェクトマネージャ、ダメでした・・・)、学んだ知識は無駄ではありません。

ってことで進めているのですが、計画立案において困ったのが人員の割り振りです。

■ 人が振れない、動かない

勤め先の部署は、いわゆる情シスなのですが、10年近く前の基幹システムを再構築しています。それまでのホスト系から、WEBアプリに乗せ替えたわけです。

その結果、それまでホスト系で育ってきた人員のスキルが途絶え、当時若手だった私だけが技術面の担当となりました。

そう、そうなると今のシステムの技術面に関する事に関して振れる人間がいない。若い人間がいれば、将来の成長を見越して出来なくても担当してもらうのですが、見回すと50を過ぎ、60に迫るオッサンばかりで、流石に振れない。

この時点で、私がプロジェクトリーダーと実務担当を兼任することが確定。それでも、運用面や技術に関係ない件に関しては割り振ったのですが、動かなかったり、進捗管理表に入力しなかったり、エビデンスがいい加減だったり、勝手に作業を追加したり・・・

■ 後書き

まぁ、部署自体が良くある(と思う)属人化が進んだ部署なので、計画に従って仕事を進めるという事に不慣れ&勝手にやりたいって人間ばかりなので、こうなるのは分かってはいました。

なので、プロジェクト計画もそれを前提として緩く作りましたし、公式な進捗管理はかなりザックリしたものにして、私自身がメンバーに口頭で話しかけて実体の把握に務めるようにしていたので、プロジェクト自体としては上手く廻ってはいるのですが、もうちょっと計画的に仕事を進められる組織にしていきたいものです。

しっかし、メンバー全員が私よりも年長なのに、プロジェクトリーダーが私と言うのは、ちょっとやりにくいですね。

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

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

PageTop