2年目PG・・・今後の方向性についてアドバイスをお願いします

質問

私は現在２年目のPGです。先日、上より今後の方向性(異動、退職)について検討してほしいと打診を受けました。
これまでの自分の実績(生産性がすごく低く、スケジュール遅延が多かったので向いてないのかと考えていました)を考えるとしょうがないかな・・・と思う反面、正直戸惑いもあります。これまでの経緯を簡単に述べると新規で開発した機能は数画面、後は運用(改修)がほとんどです。開発していて自分が感じるのは、アルゴリズムの組み立てが遅い、処理フローがすぐにでてこない為、コーディングするときに手が止まるという事です。業務に対するやる気はありますが、同期と比較すると自分がどれだけ低いレベルなのかと落胆し、向いてないんだと落ち込みます。そんな折、最初に述べた話がきたのでこのまま異動してもどうせ使い物にならないのではと不安に感じてしまいます。
やはり今の自分の現状では、この先この業界で生きていくのは厳しいでしょうか？
アドバイスをお願いいたします。

回答No.4

shimauma_8

私見で回答します。
あくまで想像ですから、参考意見として受け止めて下さい。

そして、上から目線で回答する事をお許し下さい。

失礼いたします。

まず、プログラミングの本質を知りたいのであれば、ＶＢからは離れたほうがよいと思います。

主な理由は以下の通りです。
・ＶＢは言語仕様の定義範囲（変数の型を定義しなくても、コンパイルエラーにならない等）が広すぎて、読みづらいコードが多い。
・プログラミングの基本的な考えである構造化プログラミングの４つの手法（順次処理、分岐処理、前判定繰り返し処理、後判定繰り返し処理）とブロック化のバランスを無視している（入れ子が多いが非常に多い等）実装コードが多い。
・プログラミングは書いてから読む事が主な内容であるのにもかかわらず、ＶＢは書いてからデバックする事が主な内容になっている。
・ＶＢプログラマーは、覚える事に必死になるあまり、綺麗なプログラムを書くというプログラマーにとって１番大切な事を忘れている人間が多い。

ここで個人的な見解ですが、IT業界で少しでも長くプログラマーを続けたいのであれば、構造化プログラミングの基本がしっかり身に付くバッチ系の言語を選択したほうがよいと思います。
そして、基本が身についてから、ＶＢ等の画面系言語を選択したほうがよいと思います。
また、個人的なオススメは、運用でも保守でもメンテナンスでも、古いシステムに長く携わる事であると思います。

最後になりますが、IT業界で一番必要な言語を教えます。

それは、日本語です。

ちなみに、僕の人生ではなく質問者様の人生ですから、今回の問題についても、質問者様が責任を持って対応していただきたいと思います。

失礼いたします。

お礼

shimauma_8様有難うございます。
上から目線で全然結構です(笑)参考にさせて頂きます。

回答No.3

lv4u

プログラミングについて、書籍紹介だけじゃあなく、コツを少し書いてみます。

１）段階的詳細化

一気にロジックの詳細を考えず、大きな枠組み（サブルーチン）に分割して、全体をコード化します。この時点では、サブルーチンの中身のコードは、空っぽです。でも、いちおう全体を打ち込んだ気になってひと安心になります。そのあと、作りやすいところ、結果が目にみえるところのサブルーチンから中身を埋めてゆきます。サブルーチンを記述していて、ロジックが難しいときは、さらにサブルーチン（下請け）に投げます。

２）うそっこコード

難しいロジックの部分は、「いろいろ処理して、結果はこうありたい」と、処理結果がわかっているとき、サブルーチンは結果をセットするだけのコードを書きます。こうすると、あたかもプログラムが完成したようにみえます。うそでも、処理結果が表示されると、ちょっと進んだ気になって、またがんばろうと意欲が沸いています。

ちなみに、顧客のデモが迫ったとき、この手で逃げて、デモが終わったあとに、まともなコードと差し替えていたマネージャさんがいましたね。

３）ＰｅｒｌやＲｕｂｙ等のスクリプト言語でロジック検証

Perl,Ruby等のスクリプト言語は、数行で、ＶＢやＣでは数十行必要となるような処理をこなしてくれます。
作ったロジックが正常に動作するかを確認するために、PerlやRubyでプログラムを作成し、正常に動作するのを確認したら、ＶＢとかＣなど目的の言語に変換すれば、効率的です。
（ただし、PerlやRubyをマスターしないといけませんが・・・）

４）ＰｅｒｌやＲｕｂｙ等でプログラムコードを生成

ちょっと違うコードを大量に記述しないといけないとき、Perl,Ruby等のスクリプト言語で、ＶＢやＣのコード（の一部）を生成させると、楽に正確にコーディングができます。入力は、エクセルの仕様書だったり、ＤＢ定義のＳＱＬファイルなどが考えられます。

５）書籍やネットでアルゴリズムを探す

アルゴリズム集という書籍が書店にあります。記述言語が違うこともありますが、ロジックは参考になりますので、それを利用するとあまり悩まずにロジックができます。ネットでサンプルを探すことも可能ですね。

６）煮詰まったら、残業しないでさっさと帰る

「バグを何度修正しても、まともな結果が出ない」ってことがあります。こういうときは、はまっていて、しかも気力も無くなっているので、ガンばらないでさっさと帰宅します。帰宅途中、あるいは、会社の玄関を一歩出たときに、「あ、あそこが間違っていた！」「いい案が浮かんだ！」ってことも多いものです。
疲れて、集中力のないとき、がんばると、ミスしたり、あらたなバグを追加することになりがちなので、さっさと帰りましょう。なお、途中で良い案が浮かんでも、職場には戻らないこと。

なんにしても、天才級の人々がプログラミングについて、いろいろと研究した成果を書籍等で発表してくれています。凡人の私たちが、少々がんばっても追いつけるものではありません。ＩＰＡの情報処理試験には、プログラム手法についての問題が出たりしますが、それらの技法の名前を知るだけでなく、その技法が解説された専門書を実際に読んでみると、ロジックを組み立てる能力がアップすると思います。

以前、霊感ある友人が、悩んでいるときに霊界からのアドバイスとして言ってくれたのが「ドラム缶に水を入れて、あふれ出たときが、いちおうそれをマスターした時だとする。でも、人によってドラム缶の直径も、高さも違う。中は見えない。いつあふれるかは分からない。それでも水を入れ続けていれば、いつかあふれる時がくる。」

苦しんだものほど、身につくのも確かですし、がんばっていれば、それを誰かが見ているものですよ。もうちょっとがんばってもいいでしょうね。それでダメなら、方向転換もアリでしょう。

お礼

lv4u様
>いろいろとアドバイス有難うございます。
調べる努力を怠っていた自分を恥ずかしく思います。是非参考にさせて頂き、もう少し頑張りたいと思います。

回答No.2

Joemary

>やはり今の自分の現状では、この先この業界で生きていくのは厳しいでしょうか？
ＰＧはプログラマの略ですよね？

ＰＧが好きならＰＧとして努力していってもいいし、既に努力しきった結果
適性がないと思うなら、転職も可能ならありだと思います。

ただ根本的な話として、プログラミングが好きでＰＧになったのでしょうか？
それともなんとなく？その会社であるいはＰＧとして技術者として、あるいは
ＩＴ業界で何をしたいかという目標は持ってますか？目標がなければ方向性も
考えられないのではないでしょうか？

まずは自分は何がしたいのかを考えてみてはいかがでしょうか？
質問からはそれが見えてこないように感じたので。

お礼

Joemary様回答有難うございます。
＞ただ根本的な話として、プログラミングが好きでＰＧになったのでしょうか？
それともなんとなく？その会社であるいはＰＧとして技術者として、あるいは
ＩＴ業界で何をしたいかという目標は持ってますか？目標がなければ方向性も
考えられないのではないでしょうか？
→全く仰るとおりです。正直目標が定まっていないのが現状です。だからこそ、この現状に至ったのだと痛感しております。今一度、自分の気持ちを整理したいと思います。

回答No.1

lv4u

>>アルゴリズムの組み立てが遅い、処理フローがすぐにでてこない為、コーディングするときに手が止まるという事です。

それは、プログラマを目指して、仕事を始めたころの私と同じですね。私のときは、言語がＣＯＢＯＬで、ロジックを修正を加えるごとに、パンチカートの束がぶ厚くなって、「いつまでそれをやっているんだ！」と怒られたものです。

その当時、私は、「プログラムロジックは、自分の頭で考えるもの」と思っていたのですが、構造化プログラミングの書籍を読むことで、「ロジックパターンを組み合わせてゆくもの」に変わりました。

そうすると、処理フローは、多くの場合、ほとんど考えることなく組み立てられるようになりましたよ。

「全て自分の頭で考える」とやっていると時間もかかりますし、考えて出てきたロジックが正しいかどうかも疑わしいものですからね。

その当時、読んだそれ以外の書籍は、以下のものです。

・プログラム書法／共立出版
・プログラム作法／共立出版
・ソフトウエアの信頼性／近代科学社
・高信頼性ソフトウエア／近代科学社

いずれにしても、手持ちの武器（知識）が多いほど、処理フローを組みたてる速度が早くなります。そしてＰＧなら経験５年くらいで一人前って気がします。２年目なら、まだまだ見習い期間ともいえると思います。学生時代の受験勉強のような感じで、もっと専門書を読んで、ネット上にあるソースコードを読んで、自分で作ってみるのがいいと思いますよ。

ちなみに、ＶＢなど、イベントドブリンな言語から入った方は、処理パターンを考えるのが苦手っていう傾向があるみたいです。ある処理フローを、私なら一瞬で思い浮かべるのですが、５年以上もＶＢのＰＧやっている方が、ウンウンと手書きのフローチャートを前に唸っているのを見て、不思議な感じがしたことがあります。

お礼

ご丁寧な回答有難うございます。大変参考になります。
＞その当時、私は、「プログラムロジックは、自分の頭で考えるもの」と思っていたのですが、構造化プログラミングの書籍を読むことで、「ロジックパターンを組み合わせてゆくもの」に変わりました。
→私もlv4u様の考えを知るまで、ロジックは自分の頭で考えるもの=個人の才能が問われると感じていました。従って「とにかく他者のサンプルソースを自力で内部構造に落とし込む」事が一番の近道だと思いこんでいました。

＞いずれにしても、手持ちの武器（知識）が多いほど、処理フローを組みたてる速度が早くなります
→仰るとおりですね。。。ロジックの組み立てにつまずいてるようでは
その後の開発工程にどれだけ時間がかかるんだ！って話ですよね。
ちなみに余談ですが今現在、私が使っている言語はVBです。

＞２年目なら、まだまだ見習い期間ともいえると思います
→そうですか。。そう言われて少しほっとしている自分がいます。
しかし残念ながら上長には完全に適正がないと判断されているみたいです。