時間だけはあった・・・
新しいプロジェクトであてがわれたプログラム作成のお仕事。
仕様はちょっと複雑で、マッチングなんだけど、
一筋縄ではいかないタイプでした。
仕様はちょっと複雑で、マッチングなんだけど、
一筋縄ではいかないタイプでした。
マッチングっていうのは、突合処理と言ったりもしますが、
主に２つ以上のファイルを入力にして、それぞれを読み込みながら、
キー（顧客番号とか）が一致するデータに対して処理をしていく、
というものです。
キーのタイプによって、１対１とか１対Ｎとか、
Ｎ対Ｍとかいう破滅的なものもあります。
もちろん、入力ファイルは、キーで昇順なり降順なりで
ソートしておかなければいけません。
が、JCL（Job Control Language）っていう便利なものがあって、
ソート処理は、JCL上で簡単なパラメタを記述すれば、
前提条件として行えるんです。
なので、プログラムを作る際は、
「第１キーの昇順、第２キーの降順でファイルがソートされている」
という前提で作ればよいわけです。
（そういえば、RDB＆.NETでプログラムを組んでいる同期に、
「RDBはマッチングしなくていいんだよー！便利！」
と言われて、当時は何のことか分からなかったんですが。
今となっては・・・SQLサイコー！です。）
初めてまともな業務プログラムを作成するにあたり、
気合の入りまくったわたくしは。
お試し入力データを、Excel上で何パターンも作成し、
フローチャートに沿って、机上（頭の中・笑）で処理を実行する、
という作業を、時間が許す限り繰り返してました。
というのも、新人さんは、フローチャートで上司のOKをもらえるまで、
プログラム組めなかったんですよ。
なんとしても、フローチャートで一発OKもらいたかったので、
考え付くすべてのイレギュラーパターンも考慮して、
フローチャートにこれでもか、と書き連ねました。
もう、そのままプログラムロジックになるくらい（笑）
結果、フローチャートは一発OKをもらいまして♪
『ダメな子、拾っちゃった（汗）』という素振りを見せていた上司も、
ちょっと驚いてました。本当に。
最初のフローチャートは相当ダメダメだろう、と思っていたようで、
思いっきり手を抜いてレビューを始めようとしてましたから。
さて、晴れてフローチャートを元にCOBOLプログラムを作成しよう、
というところで、ある事実を知らされたのでした・・・。
主に２つ以上のファイルを入力にして、それぞれを読み込みながら、
キー（顧客番号とか）が一致するデータに対して処理をしていく、
というものです。
キーのタイプによって、１対１とか１対Ｎとか、
Ｎ対Ｍとかいう破滅的なものもあります。
もちろん、入力ファイルは、キーで昇順なり降順なりで
ソートしておかなければいけません。
が、JCL（Job Control Language）っていう便利なものがあって、
ソート処理は、JCL上で簡単なパラメタを記述すれば、
前提条件として行えるんです。
なので、プログラムを作る際は、
「第１キーの昇順、第２キーの降順でファイルがソートされている」
という前提で作ればよいわけです。
（そういえば、RDB＆.NETでプログラムを組んでいる同期に、
「RDBはマッチングしなくていいんだよー！便利！」
と言われて、当時は何のことか分からなかったんですが。
今となっては・・・SQLサイコー！です。）
初めてまともな業務プログラムを作成するにあたり、
気合の入りまくったわたくしは。
お試し入力データを、Excel上で何パターンも作成し、
フローチャートに沿って、机上（頭の中・笑）で処理を実行する、
という作業を、時間が許す限り繰り返してました。
というのも、新人さんは、フローチャートで上司のOKをもらえるまで、
プログラム組めなかったんですよ。
なんとしても、フローチャートで一発OKもらいたかったので、
考え付くすべてのイレギュラーパターンも考慮して、
フローチャートにこれでもか、と書き連ねました。
もう、そのままプログラムロジックになるくらい（笑）
結果、フローチャートは一発OKをもらいまして♪
『ダメな子、拾っちゃった（汗）』という素振りを見せていた上司も、
ちょっと驚いてました。本当に。
最初のフローチャートは相当ダメダメだろう、と思っていたようで、
思いっきり手を抜いてレビューを始めようとしてましたから。
さて、晴れてフローチャートを元にCOBOLプログラムを作成しよう、
というところで、ある事実を知らされたのでした・・・。
トラックバックURL
コメントいただきました☆
1. Posted by やま
July 09, 2008 06:13
『ダメな子、拾っちゃった（汗）』って表現がおもしろかったです。オチが楽しみです！
うちの職場は本社のサーバーからＯＤＢＣでつないでaccessで入力やら印刷やらしているんですが、そのシステムを作ったのは本社の方なんです。「こういうふうにして欲しいな」ってことがいろいろあっても、うちの上司は「これで動いているから変える必要はない」という考えで本社の方に取り継いでくれません（泣） で、勝手にいろいろいじくっています。そこで質問なんですが、自分が作ったものをいろいろいじくられるのは嫌ですか？ ＤＢ自体はいじくれないし、そもそも作った人はもういないんですけどね（担当はいます）。
うちの職場は本社のサーバーからＯＤＢＣでつないでaccessで入力やら印刷やらしているんですが、そのシステムを作ったのは本社の方なんです。「こういうふうにして欲しいな」ってことがいろいろあっても、うちの上司は「これで動いているから変える必要はない」という考えで本社の方に取り継いでくれません（泣） で、勝手にいろいろいじくっています。そこで質問なんですが、自分が作ったものをいろいろいじくられるのは嫌ですか？ ＤＢ自体はいじくれないし、そもそも作った人はもういないんですけどね（担当はいます）。
2. Posted by
ハル
July 09, 2008 21:18
やまさん、いらっしゃいませ♪
オチ、期待してますか！？昔のこと（汗）思い出しながら書いているだけなので･･･。過剰な期待は禁物です。
＞自分が作ったものをいろいろいじくられるのは嫌ですか？
これ、微妙ですね〜。
手を入れられるのが嫌かどうかの観点なら「良くなるのであれば、お好きにどうぞ！」です。ただし、手を入れた場合は、こちらでは責任を負いません。バグ修正やバージョンアップをする際も、対象外です。
システムを作る側として考えると、システムを使う側の観点がおろそかになりがちなので、今後のためにも、ユーザの意見は欲しいです。
「ココがこうだったら、もっと使い勝手がいいと思います」って、本社側に意見をあげられるのが一番いいんですけどね･･･。
オチ、期待してますか！？昔のこと（汗）思い出しながら書いているだけなので･･･。過剰な期待は禁物です。
＞自分が作ったものをいろいろいじくられるのは嫌ですか？
これ、微妙ですね〜。
手を入れられるのが嫌かどうかの観点なら「良くなるのであれば、お好きにどうぞ！」です。ただし、手を入れた場合は、こちらでは責任を負いません。バグ修正やバージョンアップをする際も、対象外です。
システムを作る側として考えると、システムを使う側の観点がおろそかになりがちなので、今後のためにも、ユーザの意見は欲しいです。
「ココがこうだったら、もっと使い勝手がいいと思います」って、本社側に意見をあげられるのが一番いいんですけどね･･･。
3. Posted by やま
July 10, 2008 07:04
返信ありがとうございます！
＞ただし、手を入れた場合は、こちらでは責任を負いません。
それがあるので慎重にいじくってます。大丈夫なはず。。
＞本社側に意見をあげられるのが一番いいんですけどね･･･。
ヒラだから仕方ないっす。せつないなあ。
＞ただし、手を入れた場合は、こちらでは責任を負いません。
それがあるので慎重にいじくってます。大丈夫なはず。。
＞本社側に意見をあげられるのが一番いいんですけどね･･･。
ヒラだから仕方ないっす。せつないなあ。
是非！コメントをどうぞ♪
