ＩＢＭ　ＡＳ４００とパソコンを愛するＳＥのブログ

M.SHIBATA 様

いえいえ、私の方も大概な返信タイミングです。　お気になさらずに😉

前任者の力量が分らず、『ただのバグ』か『何らかの意図』か分かりかねる・・・もう、それ私の会社でもありありです。
ＩＢＭマシンの良い所でもある資産の継承が出来るのは素晴らしいことですね。５０年前のコードが動いていたりします。　でも・・・SHIBATAさんの仰るように、当初は素人が素人並みのコーデイングルール（名前付け規約などを含む）で作っちゃってるんで、あとからソースを見てもさっぱり・・・
コメントが有っても、
C* Ｆ１が押された場合
C* *IN01 IFEQ '1'
とか書かれていて、コメントの意味をなしていないのが殆どだったり・・・

この状態で２ケ月間は暗中模索・・・そして挫折（笑）
経営者は、一から作り直した方が早いと言われています。

確かに、その判断は正しいと思っちゃいました。
変なルーチン、謎のルーチン、少しいじると別の場所に影響の出そうな
スパゲッティーシステム
そして、何故かデータベースの特定の値がおかしくなり、現場から連絡を受け、ＤＦＵで修正して対応完了とするしかない現在のシステム部門
これまで、１からの開発をしたことが無い人たちだから、基幹システム再構築をしようと考えている経営者の方針を具現化出来ない人たち

来年は、エライ年になりそうです。
でも、私は１から作るのが楽しくて仕方がないので
人生２度目の基幹システム構築を楽しみながらやらせてもらいます

それには覚えなければならないことが沢山あります😉
楽しくて仕方がありません。

入力しているうちに論点がかなりずれてしまいました。申し訳ありません（笑）

それでは、大みそかまでのわずかな時間、ゆったりとお寛ぎ下さい。
そして、良いお年をお迎えくださいませ。

来年もまたよろしくお願いいたします。

Y.Taki@AS400　様　

返信、ありがとうございます。返信していただいたのに気づきませんでした（汗）
長くても「どこで」「何をしている」のかがわかれば大丈夫だと思いますね。

ただ、作成年が古くて（昭和とか）長いものは、つぎはぎで。。。内容を理解せず、
別の箇所でパッチ的に突っ込んでるケースも多々あって(笑)・・な場合は困りもの

本体の　プログラムを実行する前に　こまこまの小さなRPGが10本くらい実行されていて
しかもテキスト無しなので・・「何してるねん」ってことになってます。

苦労してるのは　内部記述とか　古い手法で書かれているものとか
システム38のQUERY変更するとか・・・知らねぇって感じです。

前任者の力量がわからないので　「ただのバグ」なのか「何らかの意図がある」のかがわからないのが困りものです。・・・最近、ただのバグが多いような気がしてきました。

そんなこんなの毎日ですが、「あるある」とか思いながらブログ拝見してます。
こちらも　本日仕事納めですが　来年も楽しみにしております。
よいお年を。



　

M.SHIBATA様
いつも読んでくださっているとのこと、しかも興味深く😊　大変ありがたいお言葉です。
感謝いたします。

このブログを始めたのがいつだったか忘れるぐらいで、確認してみると２０２０年６月３日でした。
もう、３年半ほども書き続けていたのかと改めて感慨深い思いに駆られました。

私も前職では、M.SHIBATA様のあるあるがそのままピッタリの環境でした。仕様書は簡単なものがあるばかりで、それを見ても業務や運用を熟知していないと分からないようなものばかり。　そして、ソースにはコメントが書かれてはいるものの、独りよがりで他人が読んでも分からないような内容でした。
まぁ、前職では、System/38導入時から在籍していたので、そのような環境でも負けず嫌いが功を奏して、必死で勉強（ＩＴではなくて会社の業務の方です）して、専門の部隊と互角に話し合えるようになっていました。
また、責任者の立場なのでやりたい放題でした（笑）
ただ、2018年のグループ経営者の交代で、冷や飯を頂くようになり、今年８月末をもって袂を分かつ決心をしました。
自分で育ててきたシステムは我が子のようなものです。別れが大変つらく感じました。

頂いたコメントで、『保守する立場として・・・』に対する私の考えですが、簡単がいいか複雑が良いかは一長一短があので、時と場合によって選択は変わって来ると思います。
私の場合は、複雑とは言われましたが、前職で扱っていたブログラムソースは１万行近く。
それに比べて、複雑と言われたプログラムは６千行弱です。しかも、やたら変数が多いので、同じようなコードがずらーっと並んでいますし、コメントは１画面２５行のＳＥＵで、嫌と言うほどコメントが目につく感じに入れてあります。
これは、教育という点を考えての事です。
また、機能拡張のために、ここに追加すればいいよと言うコメントも点けています。

保守と言うと堅苦しく感じますが、大きく分類すると
・機能拡張
・不具合改善
に分けられると思います。
今回、大幅な機能拡張はもちろんソースコードから改修する必要があるでしょうが、ささいな変更要請はマスタ設定で完了してしまうように開発しました。

例えて言えば、施主から一戸建てを建築してほしいと頼まれたのに、何階建てか？木造か鉄筋か？玄関はどこに？トイレはどこに？とか一切示されず、期日のみ迫ってきている・・・みたいな感じでしたので、どんな仕様になっても短期間で対応できるようにプレハブ部品を必要なぶんだけ作っておき、必要に応じて部品を選択して作り上げる方法を取りました。
なので、作業データ入力画面を１０個つくれと言われましたが、１個４日ペースの見積もりで４０日・・・しかし、年末までにテスト運用開始しておかねばならず、仕様が確定したのが・・・と過去形で言いたいのですが、まだ一部未確定の部分があるような状況です。
なので、仕様が確定したら、１画面１５分以内で作成できるように仕組んでしまいました。

ただ、これを作り上げたおかげで、グループの多数の工場がそれぞれの要望で画面を要望してくるので、１５分で作り上げて、４日分の費用を頂くと、ボーナスが増えます（笑）

結局今回は、必要に迫られて、困った挙句、いろいろな技術を応用して作り上げました。
これは、大変困って、嬉しくてたまりませんでした（笑）

結局、保守する立場では、機能拡張をするのならばその程度によって、簡単パターンの方が良い場合もあるし、今回の複雑パターンの方が良い場合もあります。

なんだか、答えになっていないような気もしますが、私としてはそのように臨機応変に対応して行き、最小の努力で最大の効果をあげる方策を採用することが最善だと思っています。

ながながとすみませんでしたm(__)m

いつも　興味深く読ませていただいてます。

当方、３０年ほど　ＲＰＧでの社内ＳＥをしておりまして、
この８月に３度目の転職をしました（社内ＳＥとしては３社目）
当初は前任者から引継ぎがある予定でしたが・・・
入社以降、ずっとお休みで。。そのまま退職されました。
自社開発あるあるで　仕様書なし、業務フローなし、に加えて「テキストやコメント一切無し」なので　いろいろ「手探り状況」です。

ですので

複雑なプログラム　VS　簡単なプログラム　の下りは　特に興味深く拝見しました。

保守する立場として。。。１本で様々か、簡単複数本か　　うーんどうだろう？