何もできない私がSEになるまで ~事務職からSEになるまでの奮闘記~ その2
一言報恩
冬の時期になり、また現場を抜けた私に武井社長からの現場のお誘いがきました。
なななんと!!
PGのお仕事でした!!
業務内容は某金融系システムのOPEN化です。
社長の下でPG見習いとして同じ現場で仕事をさせて頂ける機会を頂いたのです!!(=゚ω゚)ノヤッタネ!
しかし、初めて触れる言語…COBOL(プログラム言語)
当時、COBOLの有識者は武井社長だけでした(社員のM.Kさんは除外)
そもそも、初めて聞く言語だし、いきなりプログラミングなんて出来るのだろうか…
…いや、できるかどうかではない。やるんだ。
何事もチャレンジ精神が大事。
特に今回は1人ではない、贅沢なことに武井社長が私に付いている。
飛び出たものが何1つなかった私には大チャンスでした。
当時は、特にこの言語でやっていきたい等もなく、SEになりたいという目標のみでした。
これをきっかけに、現在自分がSEになれたと言っても過言ではありません。
現場に入って、客先の新卒社員さんと一緒にまずはCOBOLはどういうプログラムなのかを簡単に学びました。
その後、社長のフォローもあり、複数のプログラムを修正し、そのまま単体テスト
(またの名を「ユニットテスト」 修正したプログラム部分がちゃんと修正した通りに動くか
確認・他のプログラム部分に影響を及ぼしてないか確認すること)を行いました。
当時、武井社長には社員教育もビシバシと受けました。
今となっては当たり前になりましたが、いくつかピックアップしておきます
(慣れると忘れがちなことでもあります)
私は③、④は未だにまだ出来ていない部分があります。
①始業開始時間には席についている(お手洗いは始業前に済ませておく)
②遅刻をする場合は、到着時間より少し遅めの時間帯で連絡しておくこと
(ギリギリの時間ではリスクが高い為)
③人が話しているのに下に俯かないこと
④わからないことは、まずは自分で少し調べてうえで考え、調べてみてそれでもわからなかった場合、どうわからなかったのかを相手に伝えて聞くこと
ほんの一部ではありましたが、上記のことがすべて出来ている方はいらっしゃいましたか?
特に①に関しては、始業ギリギリに出勤している方は難しいのではないでしょうか。
時間に余裕を持った行動は大事ですね(簡単に言いますが、意外と難しい…)
武井社長には本当にお世話になっています。
当時、武井社長が「Kを切るのであるならば、俺も抜けます」と先方に伝えたと聞いた時は、
責任をもって私を受け持っていることが凄く伝わり、胸を打たれました。
もっと全力を出して頑張ろう、結果を出そうと奮闘しました。
武井社長は私にCOBOLを与えてくれた恩師です。そして、チャンスを与えてくれた方です。
★人*´∀`)圧倒感謝(´∀`*人☆
臥薪嘗胆
武井社長との愛しさと切なさと心強さもあった現場を抜け、
再びCOBOLの案件を手に入れました。
…そうです、SEの仕事です!!!
ヤッタネ!!✌(‘ω’✌ )三✌(‘ω’)✌三( ✌’ω’)✌!ヤッタネ‼!
業務内容は証券システム保守です。
憧れのSEの仕事です。設計書作成させてもらえます!!
だけど、読者の皆様は気付いてるかもしれません。
…そうです!早くない!?ビクーン∑(;゚Д゚)(゚Д゚;(゚Д゚;)ナ、ナンダッテー!!
まだCOBOLを初めて4ヶ月です。
正直言うとプログラムを弄ったのは2ヶ月ないくらいです。
そんな状態から急にSEの仕事をするのは不安でした。
しかも、SQLは必須と聞き、少し弄ったことがある程度な私は更に不安になりました。
現場で頂いたテキスト(今だから言いますが、テキスト微妙でした)を抱え、いざ、現場に赴くのでした。
入ってみると皆さん親切丁寧に仕事を教えてくださって、手を取り合ってうふふふ…
\(^o^)/なんて、人生は甘くなかった!!\(^o^)/
まぁ、私が離席している時に現場のチームリーダーが大きな声で
「なんでこんな奴雇ったんだ!」と言っているところに遭遇したこともあります。
それぐらい役立たずです。
でも、半年以上経った時の飲み会で、周りの人たちに「Kさんはよく頑張っているよ」と評価され、今ではたまにチームメンバーと飲みに行ったり、チームリーダーとはLINEでやり取りもしています。
リーダーは辛辣なところはありましたが、とても面倒見がよく、いつも自分のことをフォローしてくださり、とても良い方です。
その時のリーダーやチームの方々のおかげで、私はCOBOLとSQLが出来るようになったと言えるでしょう。
(まだまだ修行の身ですが…)
当時の簡単な仕事内容をいくつかあげます。
・概要設計書(またの名を「外部設計書」とも言う)の作成
→ ユーザ側にどのようなシステムを提供するのか設計しているもの。
・詳細設計書(またの名を「内部設計書」とも言う)の作成
→ 概要設計書から更に製造側よりに設計しているもの。
・プログラム設計書の修正
→ プログラムの内部構造。製造側への製造指示書にもあたる。
・プログラミング
→ プログラムソースの修正・作成
・単体テストケース(テスト指示書)作成
・結合テスト(またの名を「ST」とも言う)の実施
→ 作成したモジュール(作成したプログラムがシステムとして動かせるように部品にしたもの)を別のモジュールに問題なく結合(インターフェイス)出来るか確認する。
・総合テスト(またの名を「PT」とも言う)の実施
→ 対応したシステム部分を最初から動かしてみて問題がないか確認すること。開発側の最終テストでもある。
単体テストは主に海外の方にお願いしていたので、より具体的に書かないといけませんでした。
また、設計書やテスト結果など作成後には対面式の内部レビューがあり、
自分の作成物が本来やりたいこととかけ離れていないか、
また、おかしくないかなどシステム有識者に確認してもらう為に発表しました。
そして、現在は完全に事務的業務からは外れ、PG/SEで仕事をしています。
事務職サヨナラバイバイ!おれはこいつと旅に出る(コボチュー!)
~その3へつづく~