こんばんは。
都内でSE兼プログラマーをしているものです。
プログラマーとして約1年くらいになるのですが、
それほど新規開発が発生しない部署なので、
(修正作業が殆ど)
あまりプログラマーとしてのスキルが
上がってないように感じています。
このような環境で効率よくスキルを上げる方法
(虫のいい話かもしれませんが)などが
ありましたら、何でもいいので書き込みをお願い致します。

ちなみに環境は以下の通りです。

OS:WINNT
言語:COBOL、POWERBUILDER
DB:ORACLE8

A 回答 (2件)

 効率がよいかどうかはわかりませんが、、、時間に余裕があるようでしたら、自分でゼロベースから作りたいアプリケーションを作り上げるということが、スキルを磨くのにいいと思います。


 私自身、もともと趣味と実益を兼ねてフリーソフト制作などをやって、ずいぶん力がついたと思います。
 必ずわからないことにぶつかると思いますが、インターネット上のメーリングリストの過去ログを検索したり、それで見つからない場合は新たに質問を投稿するといいでしょう。そうして得たTipsは仕事にもフィードバックできると思います。
    • good
    • 0
この回答へのお礼

ありがとうございました。
参考になりました。

お礼日時:2003/11/20 00:21

確かにむしのいい話ですね。


SE兼PGでPGが1年ってのはどういうことなのかよく分かりませんが、SEも1年ってことでしょうかね?
いずれにしても1年じゃ効率なんか考えるの早すぎますよ。

まぁここに質問している時間が有るわけですから、自分で自由になる時間が有るわけですよね?なら自分からいろんな技術を調べるなりすれば良いんじゃないでしょうか?
環境云々じゃなくて、あなた自身の考え方なんじゃないですか?
    • good
    • 0
この回答へのお礼

回答ありがとうございます。
ご指摘の通り、もちろん自分でも
調べたりはしてはいるんですが
(こういう事は本人が言うと言い訳に
取られてしまうのですが(^_^;)、
ただ効率よくやれるやり方があるかなと
思って、お尋ねした訳であります。

>いずれにしても1年じゃ効率なんか考えるの早すぎますよ。

やはりそうなのですか?
この業界で年齢的にキャリア薄(もうすぐ29)と
いうのは、ヤバイなという危機感もあるもので。

さらなるアドバイス、叱咤その他お待ちしております。

お礼日時:2001/12/16 09:47

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aと関連する良く見られている質問

Q会社のコンピューターはCOBOLで動いているのですが、COBOLの将来

会社のコンピューターはCOBOLで動いているのですが、COBOLの将来性はどうなんでしょうか?

Aベストアンサー

COBOLってのは確かに旧式言語ですが、今日明日で無くなるような物ではないです。
ある企業では、COBOLからJAVAへのリプレースを行っている所もあるようですが、今からCOBOLの開発環境を構築するって話は聞いた事が無いです。今後COBOLと言う言語を使って動くシステムが減って行く事は否め無いでしょうね。
かと言って自社のシステムがCOBOLだからと言って悲観する必要も無いと思いますけどね。

Qプログラマー歴4ヶ月はどれくらいのスキルですか?

タイトルの通りですが、
また2年経ったらどれくらいのレベルか、
あとはロジックなどを考えて構築するのがスムーズにできる様になるには
何年目くらいになるのでしょうか?

現在私は4ヶ月でまだ設計書を見てもロジックがどうすればいいか思い浮かびません

Aベストアンサー

会社の規模や扱っている業務にもよりますが、新卒で4ヶ月目だと
社会人及びシステム開発の基礎の研修が終わるかどうかの時期だと
思います。
後は、各人の資質や能力等を考慮しつつ、開発グループに配置して
グループリーダーがOJTによる教育を行う事になるでしょう。
人によって、千尋の谷に落として自力で這い上がってくる部下のみ
を育てようとしたり、能力が未熟なのはしょうがないと割り切って
簡単だが時間がかかる単純作業を割り振って、徐々に難しい作業に
していこうとする人がいたり様々です。
そんなこんなで1~2年経ったら、ベテラン社員に時間的な余裕が
無かったり、教える事で本人が学んできた事の再確認をする効果も
有るため、新人の基礎教育を担当させる所も有ります。
毎年、数人以上の新卒者の採用をしている会社だと、2年経っても
新人の基礎教育はできません、上から細かい指示が無いから仕事が
できませんといったレベルに止まっていたら切り捨てられても文句
が言えません。
難度が低めのプログラムを、簡単な指示だけで作れる様になれれば
とりあえず合格(?)。
#判断基準は会社の環境や人によって様々
より短い期間でできる様になればもっと良い。

>勉強しながら気長にやっていきます
仕事は人の成長を待ってはくれない物です。
上司もずっと新人気分のまま、のんびり仕事を続ける足手まといを
どこまで待てれるか判りませんので気を付けて...
#焦らず急いで

会社の規模や扱っている業務にもよりますが、新卒で4ヶ月目だと
社会人及びシステム開発の基礎の研修が終わるかどうかの時期だと
思います。
後は、各人の資質や能力等を考慮しつつ、開発グループに配置して
グループリーダーがOJTによる教育を行う事になるでしょう。
人によって、千尋の谷に落として自力で這い上がってくる部下のみ
を育てようとしたり、能力が未熟なのはしょうがないと割り切って
簡単だが時間がかかる単純作業を割り振って、徐々に難しい作業に
していこうとする人がいたり様々です。
そんな...続きを読む

Q 日本ではプログラマーは使い捨て、米国ではプログラマーは設計および作成

 日本ではプログラマーは使い捨て、米国ではプログラマーは設計および作成者

 日本では、ほとんどの会社はプログラマーは使い捨て(派遣多様)のようです。
米国は、プログラマーは設計および作成者となっています。

 
 日本ではプログラマー=単純労働者、SE=設計者(パワハラ設計者)となっているにもかかわらず
日本のソフトウェア品質は世界最低水準となっています。

 これって、日本のソフトウェア業界が技能と組織階層の考察が世界最悪(ようするにバカ)だからなのでしょうか?

 いまでも、とある業種の下請け情報サービス産業がほとんどですよね?(業種コンサルができない=的確な設計ができない)

 要するに、収益源があいまいでへんな業種という事になります。
下手をしたら若いおねーちゃんのテレホンオペレーターの方がまし?

Aベストアンサー

日本は昭和時代の年功序列の考えで、プログラマが何年かしたらSEになる(する)と言う最低の考えが今でも尾を引いています。つまり単純事務職と同じ発想で技術職を考えているのです。
昔は机に座った技術職がなかったので机に座った単純事務職と同じなのです。
ところが、プログラムをまともにできない、ゴマすりの世渡り上手が年功序列でSEになります。
当然のことながらこんな輩は仕様書や設計書が書けません。だから、まともなシステムができないのです。さらに、そんな輩がSEだと威張り腐るから、プログラマもたいした経験や技術無しでSEになれるとほとんどが勘違いしての連鎖で今に至ってます。
また、昔の大企業はちゃんとしたSEがいましたが、今は単なる商社と化して客の要求を右から左に下請けに流すだけです。そうなると、ますますSEの力は低下して、そのSEなるもの作成した仕様書もどきからは、プログラマみたいな輩でも作ることが可能です(客の要求物とは似て非なるものですが)
ようはSEやプログラマは専門技術職で対等なことが必要なのですが、今の経営トップはまだ、年功序列の制度の中で生きていて、次世代の幹部(患部)もそれに倣えになっています。

収益源は明らかです。下請けに丸投げでピンハネですからね。

テレホンオペレータよりは専門性があると思うけど。

日本は昭和時代の年功序列の考えで、プログラマが何年かしたらSEになる(する)と言う最低の考えが今でも尾を引いています。つまり単純事務職と同じ発想で技術職を考えているのです。
昔は机に座った技術職がなかったので机に座った単純事務職と同じなのです。
ところが、プログラムをまともにできない、ゴマすりの世渡り上手が年功序列でSEになります。
当然のことながらこんな輩は仕様書や設計書が書けません。だから、まともなシステムができないのです。さらに、そんな輩がSEだと威張り腐るから、プログラマ...続きを読む

Q2:4:2:3の法則

「2:4:2:3の法則」とはどのような法則なのでしょうか?
よろしくお願いします。

Aベストアンサー

システム開発工程の比率ですかね?
2:4:3:2
がそれぞれ
要件定義:設計:開発:テスト
にあたります。
見積の時等、この比率を元に人月を積算したりします。

QCOBOLのプログラミング力を上げるには?

私は25歳女性、現在COBOLのプログラマーです。
去年の夏2か月ほどCOBOLのプログラミングをした経験がありますが
初めてで全然できず、いろんな上司に手伝ってもらいながらやっとできました
(ほぼ他力)。

今月からまたプログラムを作ることになり、ソースは勉強して読めるようになりましたが、「この処理の詳細設計書いて!」と言われても。全く書けません。
どういう処理なのか教えてもらっても、理解するのに他人の10倍は時間が
かかります。

あまりにできなくて自信がなくなり、質問しにいくのも恥ずかしく、落ちこんでばかりです。ネットで調べても、本を読んでも、あまり実務につながりません。
上司もなんだか呆れています。
派遣で今の会社にきて1年半、この間ほぼ事務職だった私には、はっきり言ってプログラミングは厳しいです。
新卒の子は一人一人に教育係がいるのですが、私はすべて自分で動かないと何も進みません。
なのに周りは男性ばかりで質問するのが恥ずかしく、一人で考えて煮詰まっちゃいます。

今のプロジェクトでがんばって、評価してもらおうと気合十分だったのですが、
早くも挫折してしまいました。
このままではタイトなスケジュールの中、私が足を引っ張り他のメンバーに
迷惑がかかってしまいます。

勇気を出して質問にいくようがんばりますが、それ以外に
どう努力したらいいのでしょうか><。

どうようもないことで質問をしてすみません。

ちなみに今担当している処理は
(1)ファイルを読み込む→データを抽出→抽出したデータをファイルに出力
(2)出力ファイルのデータをDBに取り込む

簡単そうでなかなかできません。

私は25歳女性、現在COBOLのプログラマーです。
去年の夏2か月ほどCOBOLのプログラミングをした経験がありますが
初めてで全然できず、いろんな上司に手伝ってもらいながらやっとできました
(ほぼ他力)。

今月からまたプログラムを作ることになり、ソースは勉強して読めるようになりましたが、「この処理の詳細設計書いて!」と言われても。全く書けません。
どういう処理なのか教えてもらっても、理解するのに他人の10倍は時間が
かかります。

あまりにできなくて自信がなくなり、質問しにいくのも恥...続きを読む

Aベストアンサー

プログラミング力という言葉が使われていますが、この「力」の中には、

1.言語仕様を理解し、コーディングができる能力
2.仕様を理解し、アルゴリズムを作成する能力

のふたつがあると思います。

前者は、他の方が言われているような、MOVE や PEFORM とか IF や EVALUATE だったり、最後にピリオドがなければならない、ということです。
これは言語によって、異なるので、新しい言語を習得するたびに必要なことです。

後者は、
・詳細設計書を読み解き、実現したい「現象」を(データベースやファイルのフィールドがどうならなければならないかまで)具体的に理解すること

と、そのうえで、

・その「現象」を実現するためのアルゴリズムを組み立てる能力

と言えると思います。

フローチャートの読み方のときに教えてもらったと思いますが、手続き型プログラミング言語の基本構造は、
・順次
・判断
・繰り返し
この3つしかありません。すべてのアルゴリズムはこの組み合わせです。

これがわかっていて、フローチャートが書けているならば、詳細設計に書かれている、実現したい「現象」を具体的に理解していますか?
「理解する」ということの、一番簡単な説明は「他人に説明できる」ということです。他人に説明できますか?

他人に説明できるのであれば、COBOLの言語仕様は理解していますか?
アルゴリズムがわかり、現象が他人に説明でき、COBOLの書き方を理解していて、はじめて、コーディングができるのだと思います。


フローチャートは書けるとのことですが、おそらくは、「現象」を他人に説明できるほど、詳細設計書を理解していないんだと思います。
さらに、「現象」が理解できないことを、処理をCOBOL言語で書けないことにすりかえてしまっており、(もしくは混同してしまっており)前に進めていないのだと思います。

いくつかのヒントを出しましたが、自分がなにがわからないのかを明らかにし、ひとつひとつ前に進んでいってください。

さしあたり、春の基本情報処理技術者試験の受験をおすすめします。:-)


最後に、えらそうなこと書いてすいませんでした。m(_ _)m

プログラミング力という言葉が使われていますが、この「力」の中には、

1.言語仕様を理解し、コーディングができる能力
2.仕様を理解し、アルゴリズムを作成する能力

のふたつがあると思います。

前者は、他の方が言われているような、MOVE や PEFORM とか IF や EVALUATE だったり、最後にピリオドがなければならない、ということです。
これは言語によって、異なるので、新しい言語を習得するたびに必要なことです。

後者は、
・詳細設計書を読み解き、実現したい「現象」を(データベースやファ...続きを読む


人気Q&Aランキング

おすすめ情報