ソフトウェア開発の仕事について8年目です。
今年の4月からリーダーという肩書きを会社から任命されて、プロジェクトリーダーとしてがんばっています。

現在のプロジェクトはWeb系のシステムなのですが、自分自信のプログラミングスキルとしては、あまり高いとは言えません。
自分が新入社員の頃はVisualBasicが流行りで、長年その分野での設計やプログラミングをやってきたからです。

プロジェクトのメンバーがプログラミング的な問題を抱えているとして、なかなか回答を返すことができずに、つらい思いをしています。
メンバーの中には「リーダーは何でもわからないとだめ」という考えの者もいるのですが、この業界ではなかなか難しいと思います。

プロジェクト自体も、同言語、同形態のシステムが続くとも限らないので、プロジェクトリーダーが毎回その言語、形態を熟知するのは無理ですよね。

やはりリーダーとは、メンバーでの問題をどう解決するかの手段を提示する必要はありますが、自分で何でも解決する必要はなく「誰々に聞けばわかるよ」というのが仕事だと思います。

何年もやっていれば気づいてくるとは思うのですが「リーダーは何でもわからないとだめ」と思っているメンバーを説得することは無理でしょうか。

なんか取りとめもない質問になってしまってすみません。

このQ&Aに関連する最新のQ&A

A 回答 (8件)

 頑張れ リーダー!!



リーダーは、何でもわかっている必要があります。(逆説の提言として)

 切に、メンバーがリーダーに求めているのは、「一緒」になって目前の問題を解決してくれる事です。口頭で、解決手段を提示するだけでなく、その解決手段を実施して、ともに行動をしてくれる事です。
 「誰々に聞いて、、」では、メンバーからは逃げにしか映りません。提起された問題の解決手段を、リーダー自ら「誰々」に聞いて、解決手段を自ら模索したあと、そのメンバーと解決策を「とも」に実演してみて下さい。
 リーダーのポリシィとして、何事にも逃げない、ともに行動する、これがプロジェクト全体に行動で示していけば、理解されていくのでは。

全天候性の戦闘機(リーダーの理想)
 言語やシステム形態などは、あくまでも問題解決のまめの道具です。問題解決の基本は、問題解決にいたる計画とたて、現状分析による回避策と予防策を実施することです。リーダーは、道具の使い方ではなく、製品完成のための実現方法で勝負してほしい。迷ったときは、顧客からの視点、営業的立場での考え方をとって見ては、いかがでしょう。顕著化した技術的問題が、実は別な発想で手を打つべき問題であった場合も多いですよ。

リーダーシップの取り方は、人それぞれです。ご自分の得意な指向性(考え方、技術分野)を伸ばせば、自分を活かした、プロジェクト運営ができます。




 
    • good
    • 0
この回答へのお礼

リーダーは、何でもわかるために余裕がないとだめですね。
それだけメンバーよりも経験があり、上司に認められてリーダーになったはずなので「自分にはできるんだ!」と信じてやっていこと思います。

今回のプロジェクトで反省すべきことがありました。

メンバーが設計書に記述してあることをプログラミング的に実現する方法がわからず、技術的にスキルのあるメンバーに実装方法を質問したそうです。
そのときに、大まかな方法は聞いたけど1から10まで完全に聞くことはできないので、自力で調査をしてたようです。

その調査等でスケジュールに遅れが出てきて、3日くらい遅れが出てきたときに俺の方から現状を聞いてみました。
設計書の記述通りに実装すると難しい方法だけど、設計書がやりたいことを実現するためには簡単に実装する方法が見えたため、設計者に相談して確認を取ると、簡単な方法でもOKになりました。

最初の時点で、リーダーに信頼があれば3日の遅れもなかったと思います。
上記の設計変更でまたさらに2日くらいの遅れになってしまいました。

ただ、この方法は他のプログラムでも同様だったため、簡単な方法を取る事にしました。

いろいろな経験を次に活かしてがんばっていきます。

お礼日時:2001/06/17 22:51

システム開発プロジェクトでプロジェクト管理の仕事を3年ほどしていました。



プロジェクトと言ってもどんなプロジェクトなのかでリーダーは全く違った
素質と経験が必要になってくると思います。ただ rally さんのおっしゃっている
リーダーはプログラム開発プロジェクトであろうと思いますので、僕の経験を
1つ。

1.開発プロジェクトであってもリーダーがプログラムSkillの全てを掌握している
のは理想であって、必須では無いと思います。

2.その上でリーダーは何をする人と事前定義をメンバーの前で明確にしなければ、
全部わかるスーパーマンと思われてもしょうがないでしょう。

3.前述の定義無くしてプロジェクトのボトルネックになっている部分を特定
メンバーが全部引き取って処理していたら、誰でもその人がリーダーにふさわしい
と思うでしょう。

私がプロジェクト管理をしていた時には、プロジェクト管理リーダーの仕事は
0.プロジェクト計画書の作成とプロジェクトチームの編成
1.同時進行 他プロジェクトチームとの調整
2.想定工数と実績工数把握によったスケジュール調整
3.顧客窓口と仕様決め
4.テストシナリオとテストデータ定義
と事前定義しました。はっきり言ってそれだけやっていれば1人の工数は終わって
しまいます。また、誰も僕には実装面やプログラムの問題を聞いては来ませんで
したが、(まぁ 僕も分からなかったでしょうが)プロジェクト管理はうまく行って
ましたよ。

プロジェクトがうまく行くコツは、編成時に各自の役割と責任を明確にする事で
しょう。何も不明確なままでは各自の想定に基づいた不満を解消する事はできま
せん。責任分担が事前に明確になっていれば、そんな問題も起こらないでしょう。

ずいぶん偉そうに書いてますが、結局 段取りですよね。プロジェクトは。
お仕事がんばってください。
    • good
    • 0
この回答へのお礼

「役割を明確にする」というのは、メンバーが安心して作業できるようにするためには必要ですね。
そういえば、そこらへんは明確になってないかも知れません。

メンバーもやる気がないわけではないので、役割を明確にして責任を持たせれば、それぞれが力を発揮できますね。

今のプロジェクトは来週にはほとんど終ります。
メンバーには最後に意見を聞いてみたいと思います。

お礼日時:2001/06/12 00:38

同業者(の様)です。

私からは、辛口の意見を。

最近は、情報の流れが速くて苦労しますよね。でも、「プロジェクトリーダは
仕事の流れを円滑に進めるのが仕事で知識が無くても…」なんて、ぬるいよなあ。

確かに、コストの算出やら、スケジュールの調整やら『システムの作り方』に
関係の無い仕事がたくさんあるのも事実ですが、プロジェクトをまとめる立場と
して必須なのが「リーダについている人間や、その人たちがすることの *評価* を
する」ということがあります。

なので、私は最低限「自分でもできるが、私の手は二本しかないので、他の
人間を使っている」という立場を取るように、自分を *叱咤して* ます。

一昔前だと、言語の違いこそあれ、SE として仕事をする分には、構造化設計が
できていれば、なんとか仕事になりましたが、今ではちょっときついですね。

仕事の内容にも依りますが、Web系の仕事だと最低限、オブジェクト設計が
できること(javaなんかを使う場合)と、数ある実装方法(Perlだphpだなんて)に
何が得意で何が不得意かを知っていないと、任せっきりになっちゃいますよね。

任せる相手が信用できれば良いのだけれど、信頼するに足るかどうかを評価する
のがリーダですからね。

確かに「リーダは何でも分からないとだめ」に応えるのはきついのですが、
それに(ある程度でも)応えてこそリーダとしてプロジェクトを円滑に進めて
ゆけるのだろうな、と思ってます。

くどいようですが、もう一度書きます。

> 「リーダーは何でもわからないとだめ」という考えの者もいるのですが、この業界ではなかなか難しいと思います。

ということに応えられるリーダが居ればこそ、プロジェクトの進行もうまく
行くのだと思います。


◆以下、余談

とは、書きつつも、半分以上は、自分に向けて書いているような錯覚を
覚えます。

最近は Web系の仕事が増えて来て、自分では、まさかするとは思わなかった、
ばりばり Web系のプロジェクトのリーダになってしまいました。しかも、
経験の無い業務分野で。

ああ、いくつになっても勉強からは逃れられないのね、と思いつつ、
ひーひー言いながらやってますよ (^^;

頑張りましょう。
    • good
    • 0
この回答へのお礼

リーダーは大変ですね。
日々の努力はこれまで以上に続けなくては務まらない・・・。
密かに実力をつけて「これぞリーダー」と思わせるようにがんばります。

お礼日時:2001/06/12 00:32

補足から...


>おそらく「俺の方がリーダーにふさわしい」と思っていると思います。
 そう言う人間には、私なら技術的なリーダをやって貰います(要するに、サブリーダね)。

>ただ、リーダー兼実装メンバーになっているため、全体を理解する時間もなかなか取れませんでした。
>最初のメンバー割振り、スケジュール設定が間違っていたのかも知れません。
 これも間違いだとわかった時点で見直しをしましょう。それは、マイナスではないと思います。私も、リーダ兼実装メンバ兼営業ってのをやっているのですが、時間が取れないのを言い訳にすると、メンバがやる気をなくしていきます。リーダは、人の見ていない所の努力が必要になりますね。

>例えば、COBOLを何年もやってても、JAVAなどのオブジェクト指向言語のプログラミング技術はアルゴリズムの知識では難しいと思います。
 それを出来るようになる様にするのです。また、それができれば、どの言語でも実装方法の指示が出せる様になります。リーダの資質とは、自分の知識を他の知識に変換出来る能力だと思います。 理想論だと言うのは解るのですが、それ以上に諦める事を簡単に言い出してしまう人をリーダとして仰ぎたいとは思いませんよね。
    • good
    • 0
この回答へのお礼

スケジュールのミスに気づいたときに調整を行う必要がありました。
自分の中で「まだ何とかなる」という気持ちがあったと思います。
余力を持てなくてギリギリで仕事をしてると、信頼はなくなりますね。

単なる実装メンバーのときは、残業なんてほとんどやらないでもこなしていたのに、リーダーになったとたん回らなくなってます。
やり方を変えるようにしたいと思います。

あと、新しい知識の習得は簡単に諦めてるわけではないです。がんばってます。
それでも努力が足りないと言われれば、しょうがないですが・・・。

お礼日時:2001/06/11 00:31

プロジェクトリーダーの真の役割はグループの総合力を最大限ひきだして、目的を完遂すること、常に全体の状況や進捗を管理し、異常事態に直面したことを素早く検知し、臨機応変に対策の指揮を取れることだと思います。

だから、リーダーはグループメンバーよりかなり軽めの分担とし、突発自体への対応や、遅れているところのリカバリーの余力を確保しておくべきです。

建前論は別にして、私の経験から若干のアドバイスを。

開発中の言語を知り尽くしたグループリーダーは必須ではありません。乱暴なことを言えば、開発方法論だって、アルゴリズムだって・・・。要はそういうことに一番長けた人間をブレーンとして使い(例えば標準化担当者として任命)、その人間の意見をよく聞いてグループリーダが最終決定を下す、メンバーの技術的相談は標準化担当者が一手に引き受けるという方法があります。私は、標準化担当者も、グループリーダーも永年勤めてきましたが、この方法で、グループリーダが軽んじられたのは一度も見たことがありません。

言語や手法よりも、プロジェクト運営の方が遥かに難しいと思います。頑張って下さい。ご成功を祈ります。
    • good
    • 0
この回答へのお礼

> 言語や手法よりも、プロジェクト運営の方が遥かに難しいと思います。頑張って下さい。ご成功を祈ります。

ほんとに難しいです。
メンバーの性格はみんな違うから、やる気にさせる方法はそれぞれ違いますね。

これからは余力を残してできるようなスケジューリングでやっていきたいと思います。
今回は本当に余力が持てなかった・・・。

お礼日時:2001/06/11 00:22

完全な私見ですが…。



プロジェクトは本来プロ集団であるべきです。
プロ集団の中でリーダーがやるべきことは「プロが仕事しやすい環境作り」と「円滑な人間関係の構築」でしょう。

しかし、一般的なプロジェクトは“プロ集団”とは程遠いものであり、その中でリーダーは「何でもできるスーパーマン」であることを求められがちです。

本来のリーダーは“技術のわかる管理職”であるべきなのに“管理もできるスーパー技術者”が求められているのです。

もし、プロジェクト内に高い技術力がある人材がいるなら彼に「技術面をサポートするサブリーダー」を頼んでみてはいかがでしょう。
「雑用部分は俺がやる。技術的な部分はお前が引っ張ってくれ」と頼めば(彼のプライドをくすぐるという意味でも)協力が得られるのではないでしょうか。
リーダーの仕事は雑用部分がほとんどなので、実際に彼に任せられる範囲は小さなものですが。

リーダーはマクロの把握、サブリーダーはミクロ(というかピンポイントで難易度の高い部分)の把握と役割分担すれば多少は仕事のやりやすい環境ができるかもしれません。
    • good
    • 0
この回答へのお礼

今回のプロジェクトは、自分も実装を行っているため、技術面ではその「できるやつ」に聞いたり、サポートを頼む事は多いですね。
それプラス、スケジュールの進捗報告、メンバーの勤怠管理、などなど・・・やってると時間が足りず、スケジュールの遅れを発生させてしまいます。

最初の段階で手を打てれば良かったのですが、自分の力を過信しすぎて「まだ何とかなる」という思いでここまで来ました。
リーダーに任命されてから、上からの期待もあるので、気負いすぎてたのかも知れません。

お礼日時:2001/06/11 00:18

ソフトウエア開発プロジェクトリーダーの力量のことでしょうか、昔はオールマイティで仕事人でバリバリできる者(一人親方)にあこがれ、自分もなろうと努力したものです。

しかし、最近では全体をまとめる仕事がこのリーダーという具合に変わってきました。リーダーは、チームワークと業務遂行責任がのしかかります。
一人一人のスキルを把握することはもちろん、全体のおおまかなプロセスの把握も必要です。
さて、今の質問ではこの一人親方(昔の考え)がメンバーの中にいるのではと思います。さらに、同一メンバーの方からはあなたをリーダーとして認めていなく、単に業務命令で昇格、実力無し(何でもわからいとだめという部分)と判断しているのでしょうから。いづれにしても、このままでの開発プロジェクトでは人間関係でつまずきます。
納得させるか排除するしかありません。責任者はあなたですから。
 納得させる方法は、私の考えで申し訳ありませんが、業務命令でリーダーを拝命されたこと。システム開発は一人一人の協力で成り立っていること。進行状況を報告すること。互いにFAQし、一人はみんなの為に、みんなは一人の為に技術向上すること。プロジェクトの責任は私にあることなどです。
あなたリーダーは、メンバー全体の管理監視とそれぞれのスキルを判断して総合的に業務量を調整してください。そうすれば、自然に一人親方のメンバーさんも納得すると思います。
    • good
    • 0
この回答へのお礼

今回のプロジェクトは、リーダーの自分もメンバーと同じ位の作業量を割振ってしまったことが大きな間違いだったと思います。
リーダーの仕事もやりながら、慣れない言語での実装となりましたので、メンバーとしても「このプロジェクトは大丈夫かな?」と、心配させたかも知れません。

作業工数の見積から始めて行ったプロジェクトのため、その部分でのミスが後々引きずってるのかな~。

今回は良い経験になりました。

お礼日時:2001/06/11 00:11

プロジェクトリーダの素質は、会社毎に違うと思うのですが、私見でよろしければ...



 プロジェクトリーダの役割は、仕事を円滑に進める事ですので、別に言語の知識の有無ではないと思います。
 それよりも、メンバの力量の把握が大事だと思います。問題を抱えている人が居る場合に、その問題を解決する手段をもっているメンバを正確に言えるとか...ね。

 説得の方法は、その言ってるメンバの性格がわからなければ、わからないので簡単にもで結構ですので、補足下さい。

 しかし、リーダはプロジェクトの仕様は必ず把握する必要があり、それに伴いアルゴリズム程度は理解する必要あると思います。リーダは、言語の知識よりもアルゴリズム(プログラム技法)の知識が必要でしょう。また、メンバに質問されても、アルゴリズムで答えるのが良いのではないでしょうか?

この回答への補足

> 説得の方法は、その言ってるメンバの性格がわからなければ、わからないので簡単にもで結構ですので、補足下さい。

そうですね~。
メンバーの中では、割りとできる人ですね。
現在のプロジェクトと同言語、同形態を3年やってきているため、自信を持っています。
また、新人の頃から2年以上親会社へ研修に行っていて、そこの「何でも教えてくれる先輩」と重ねているのかも知れません。

おそらく「俺の方がリーダーにふさわしい」と思っていると思います。

そういうメンバーをうまくやる気にさせるのがリーダーなんでしょうね。

> しかし、リーダはプロジェクトの仕様は必ず把握する必要があり、それに伴い
> アルゴリズム程度は理解する必要あると思います。

そうですね。
ただ、リーダー兼実装メンバーになっているため、全体を理解する時間もなかなか取れませんでした。
最初のメンバー割振り、スケジュール設定が間違っていたのかも知れません。

> リーダは、言語の知識よりもアルゴリズム(プログラム技法)の知識が必要でしょう。

それには自信がありますが、言語の形態が変わると、その言語独特な方法もあるので、その辺は難しいです・・・。
例えば、COBOLを何年もやってても、JAVAなどのオブジェクト指向言語のプログラミング技術はアルゴリズムの知識では難しいと思います。

補足日時:2001/06/10 20:09
    • good
    • 0

このQ&Aに関連する人気のQ&A

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

このQ&Aを見た人が検索しているワード

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

Q目標管理シートの書き方について

現在駆け出しのプログラマですが、このたび会社で半年毎に目標管理シートを記載し、下記についてどういう目標を立て実現をめざすかということを記述する事になりました。

1. 利益率の向上
2. 納期の厳守
3. 不良の再発防止
4. 品質の向上
5. 会社業務の生産性の向上
6. 個人の技術力の向上

そして私が思うに下記のような制約があるのですが、この状況下で適切な目標とはどういうものかというのが分からなかった為、アドバイスいただける方がいらっしゃいましたら、ご教示の程よろしくお願いします。

1. 半年毎に数値で評価する事が可能な目標にする必要があると思います(例え数年かかる目標でも、半年毎にその進捗状況が数値で評価できる目標にする必要があると思います)。
2. 一応業務のメインはプログラミングですが、設計などを行なう可能性もあり、半年の間にどのような業務を行なうかは目標設定時には分かりません
(大まかに絞れば、ソフトウェア開発ということになりますが、例えばプログラミング色の強い目標を設定した所、実は業務でプログラムをやることがほとんどなかったという可能性もあり、あまり狭い範囲に絞った目標の場合、自分でコントロールできない所で目標が達成できなくなる可能性があります)。
3. プログラミング言語はその時々で適切と思われる言語が決定された状態で指示される為、半年の間にどのような言語を使用するかは目標設定時には分かりません。

なお、アドバイスについては、具体的な目標、及びその目標の達成基準をご教示いただいてももちろん大丈夫ですし、こういうサイトがあるですとか、こういう考え方があるですとかというような情報でも大丈夫です。
アドバイス等によっては、特定の会社では使えるものの、特定の会社では使えないことなどもあると思いますが、できるだけ多くの意見をいただけると参考になり助かります。

また、情報不足等があり、補足が必要でしたら、その旨ご指摘いただければと思います。

以上、よろしくお願いします。

現在駆け出しのプログラマですが、このたび会社で半年毎に目標管理シートを記載し、下記についてどういう目標を立て実現をめざすかということを記述する事になりました。

1. 利益率の向上
2. 納期の厳守
3. 不良の再発防止
4. 品質の向上
5. 会社業務の生産性の向上
6. 個人の技術力の向上

そして私が思うに下記のような制約があるのですが、この状況下で適切な目標とはどういうものかというのが分からなかった為、アドバイスいただける方がいらっしゃいましたら、ご教示の程よろしくお願いします。

1. 半年毎...続きを読む

Aベストアンサー

コンピュータシステム開発会社に勤務しております。
うちの会社も、通年の目標管理が設定され、半期ごとに、個人評価、上司との面談を行っています。
質問者様の勤務する会社が自社開発ソフトか、業務委託型なのかにもよりますが、業務委託型として、私なりの
考えです。
1.利益率の向上
   顧客先との契約では、個人の単価が関係してきます。個人の単価を上げるためには、顧客先からの評価を
   高めること。つまり、業務知識に精通することです。
2. 納期の厳守
   当たり前なことですが、時として守れないことがあります。メンバーのスキル不足。納期厳守の意識不足。
   あとは、業務開始時に仕様が明確になっていないため、作業工程に戻りが発生すること。また、追加仕様を
   無計画で受け入れてしまうことです。
   開発当初の仕様を明確にする。レビューを繰り返し実施する。仕様変更・仕様追加が発生する場合は、納期を
   どうするか、あらかじめ決定しておくこと。
3. 不良の再発防止
   不良(不具合)の原因としては、仕様もれ、仕様の理解不足・テストケース不足が考えられます。そこで、各工程で
   レビュー(検討会議)を繰り返すこと。テストについても、テスト仕様書のレビュー、テスト結果報告書のレビューを実施
   します。
   万一、不良があった場合、それを記録として残すこと。
4. 品質の向上
   不良を出さないこともありますが、ユーザー側の立場に立った、仕様の検討・提案ができるか?
5. 会社業務の生産性の向上
   会社で、過去に開発したシステムで、再利用・2次利用できるものを活用し、作業工数を減らすことです。
   無駄な残業をしないことも、当然ですね。
6. 個人の技術力の向上
   コンピュータ関連の資格を取得すること。会社として、共通して使用しているツール・DBなどの知識を深めること。
   新規技術(クラウドなど)の情報収集に努めること

参考になれば幸いです。
もうすぐ50のSEでした。
  

コンピュータシステム開発会社に勤務しております。
うちの会社も、通年の目標管理が設定され、半期ごとに、個人評価、上司との面談を行っています。
質問者様の勤務する会社が自社開発ソフトか、業務委託型なのかにもよりますが、業務委託型として、私なりの
考えです。
1.利益率の向上
   顧客先との契約では、個人の単価が関係してきます。個人の単価を上げるためには、顧客先からの評価を
   高めること。つまり、業務知識に精通することです。
2. 納期の厳守
   当たり前なことですが、時として守...続きを読む

Q30歳SE,技術がありません・・・

30歳になった8年目のSEです。独身女です。
技術がありません。
これからの仕事についてどうしたらいいかわからず、途方に暮れています。

私の会社は二次請けの仕事がほとんどです。
文系大学卒業後入社して以来、長期間のプロジェクトに関わる事が多くずっと客先にいたのですが、最近自社に戻りました。
主に現行仕様調査、詳細設計~結合テストの経験しかなく、ほとんどがバッチでプログラミングスキルは新人に毛がはえたレベルだと思います。(PL/SQL,COBOL,少しJava)
仕様を固める為にユーザ企業のシステム課の方と打ち合わせをしたような経験はありますが、リーダー経験もありません。
マスタ管理のようなチームがほとんどだった為、業界のどの企業でも通用するような業務知識もありません。
資格は情報処理試験(基本情報、ソフトウェア開発技術者)だけです
SEというと激務な方が多いですが、私はぬるい環境で仕事をしてきました(残業は多くても月70hくらい)


自社に戻り、上司は新たな職場に派遣しようとしていますが、
年をとり、おまけに主任になった為単価が高く、技術がない私はなかなか仕事が決まりません。
会社で他部署の手伝いなどをしています。

社外にいる間は一次請けベンダーのリーダーさんを目標としていたのですが、
自分の会社では無理な事をいまさら思い知りました。
昔から自分の技術がしょぼい事を感じつつ、現状に甘えてきた結果です。
努力しなければいけない事がたくさんありすぎて、まず何から始めたらいいかわからなくなってしまっています。
年齢が年齢なので、あせるばかりです。

自分ではこんな事を考えているのですが・・・

(1)プログラミング言語の勉強をし、たくさん資格でもとるか?
 今の会社ではこれを求められている気がしますが、実務経験がなく資格だけとって、役に立つのかは不明です。
 ベンダー系資格は受験料が高いので、それに見合う効果があるのかも・・・

(2)管理するポジションを目指す為、転職するか?
 今の技術力まま転職活動をしても望みが薄い気もしますが、勉強してから・・・というのでは年ばかりとってしまいそうで怖いです。
 反面、リクナビNEXTに登録しており、いくつかプライベートオファーも頂いたのですが、面接でアピールできる事が思いつかず、応募を躊躇してしまいます。

(3)他業界をめざすか?
 絶対SEがいいという希望はありませんが、この年齢で他業種で通用するのか?
 ぬるま湯育ちの私が通用するのか?

一番の目標は、ユーザ企業にしばられない業務知識を持ち、管理できる人間になることなのですが、夢のまた夢のまた夢のような気がして・・・

学生時代は定年まで仕事人間でいたいと思っていたのに、今の自分が情けないです。
これからの人生、食べていけるのかも不安になってきました。


あいまいな質問で申し訳ないのですが、私はまずどんな努力をすべきでしょうか・・・
お恥ずかしながら給料が安く、貯金も少ない為お金がかかる事は不可能です。

30歳になった8年目のSEです。独身女です。
技術がありません。
これからの仕事についてどうしたらいいかわからず、途方に暮れています。

私の会社は二次請けの仕事がほとんどです。
文系大学卒業後入社して以来、長期間のプロジェクトに関わる事が多くずっと客先にいたのですが、最近自社に戻りました。
主に現行仕様調査、詳細設計~結合テストの経験しかなく、ほとんどがバッチでプログラミングスキルは新人に毛がはえたレベルだと思います。(PL/SQL,COBOL,少しJava)
仕様を固める為にユーザ企業のシステ...続きを読む

Aベストアンサー

まあ、人生において正解の行動というのは無いわけですが、私だったら転職を志しますね。実際、携帯電話のSEから別業種に転職したことがあります。その後もう1回転職していますが、少しづつ他業種にチャレンジしていたら、今ではSEとは全く違う職種(アプリケーションエンジニア)で生きるようになってしまいました。

色々言いたい事はありますが、とりあえず3つだけ。

>反面、リクナビNEXTに登録しており、いくつかプライベートオファーも
>頂いたのですが、

できれば転職エージェントが対応してくれるサービスを利用した方が良いと思います。紹介される企業の質がそもそも違いますからね。亜リクルートNEXTだけでなく、ありとあらゆる転職サービスに応募するんです。時には門前払いを食う事も有るでしょうが、そんな事を恐れていたら前には進めません。

>面接でアピールできる事が思いつかず

アピール出来る事が無いなんて甘いですよ。それは死ぬ程考えて捻り出す者です。とりあえず、いままであなたがやってきた仕事/期間/使用ツール/開発人数を細かい所まで全部書き出してみましょう。職務経歴書を書いたかもしれませんが、それをもっと細かく書く様なイメージです。その中で、少しでも他者よりも誇れそうな者を抜き出し、10倍程度膨らましてアピール出来る様に文章を作ってみましょう。まずはそれからです。

>絶対SEがいいという希望はありませんが、この年齢で他業種で通用するのか?

通用するのか? じゃなくて通用する様に死ぬ程努力するんです。転職は、そのくらいの気合いが無いと絶対に成功しませんよ。

情けないと思う暇があったら、まずは出来る限りの行動をするべきです。それでも効果がなかったらそのとき初めて嘆きましょう。やるべきことをやっていたら、嘆く暇なんてないはずですよ。

まあ、人生において正解の行動というのは無いわけですが、私だったら転職を志しますね。実際、携帯電話のSEから別業種に転職したことがあります。その後もう1回転職していますが、少しづつ他業種にチャレンジしていたら、今ではSEとは全く違う職種(アプリケーションエンジニア)で生きるようになってしまいました。

色々言いたい事はありますが、とりあえず3つだけ。

>反面、リクナビNEXTに登録しており、いくつかプライベートオファーも
>頂いたのですが、

できれば転職エージェントが対応してくれるサービ...続きを読む

QSEの人たちって、なんであんなに気持ち悪い人ばかりなんですか?

アニメオタクとか変態とか。
SEの人たちって、なんであんなに気持ち悪い人ばかりなんですか?

Aベストアンサー

SEに比較的接する事が多い職場/部署で仕事をしてます。
あくまで私見ですが回答させて頂きます。

質問者さんが感じていることは、概ね合っていると思います。
つまり、SEには一般的な感覚で言うと変わっている人が多いという傾向があります。(気持ち悪いという感覚で書かれていますのがこのように解釈させて頂きました)

その理由は、主要なところで2つ。
1つ目は、SEという職業には他人から好印象を得る必要性が他の職業と比べて少ないからだと思います。というのは、SEという職業は、販売・窓口・営業(その他諸々)のような職業と比べると人から好印象を得るということを重視されません。むしろ、技術力(専門性)の高さを要求されます。このような仕事の特性上、採用の地点で外見/性格が重視されないためすでに新人の地点で変わった人が多いよううに思われます。さらに、そのような環境では就職してからも人からどのように見られるかというところを意識する機会が少ないため改善されることも少ないです。

2つ目は、「~オタク」と呼ばれる人達の「一つのことに執着する」という特性と専門性を高めるという求められる能力が一致しやすいからです。
つまりは、上記の特性を持っている人がその世界に残ることが多く変わった人が多いという結果に至っているのだと思います。

あくまで割合の話でSEの中でも普通(魅力的)な人も多くいます。
なお、SEの人という限定的な範囲ではなく、上記のような特性を持っている職業では同じような傾向は少なからずあるのだと思います。

SEに比較的接する事が多い職場/部署で仕事をしてます。
あくまで私見ですが回答させて頂きます。

質問者さんが感じていることは、概ね合っていると思います。
つまり、SEには一般的な感覚で言うと変わっている人が多いという傾向があります。(気持ち悪いという感覚で書かれていますのがこのように解釈させて頂きました)

その理由は、主要なところで2つ。
1つ目は、SEという職業には他人から好印象を得る必要性が他の職業と比べて少ないからだと思います。というのは、SEという職業は、販売・窓...続きを読む

QSEの方が頭がよすぎ、ついていける気がしない

SEとして社会人になって3年半が立ちました。

ただただ思うのが、タイトルのようなことです。

C言語とかSQLとか、あのようなものをどうしてすぐに読み書きできるのか・・。
私はSQLは「select * from...where」くらいならわかりますが、innter join、left joinなどが入ると途端にこんがらがります・・。

また、自分のチームに別のチームにいた経験15年程度の方が加わったのですが、一週間のうちには自分のチームの携わるシステムを理解し、仕様について突っ込みを入れたり提案したり、会話を主導しており、レベルの違いを感じました。

私の同期はもう後輩を指導している立場になっているのに、私は未だにその15年目のベテランの方に手取り足取り見てもらっている状態です。

私は元々文系なので、目に見えない論理的な話が得意でありません。

この数年間ずっと思っておりましたが、やはり向いてないのかなあと思っています。

向いていなくても、やはり続けるべきなのでしょうか?

他に当て等全くありません。外食や小売に行くのも、自分にカラーが合っていませんし、他のIT企業に行くのはもっと嫌です。

うまく社内の別の部署、総務や営業、販売、あるいは製品検査の部門などに移してくれればそれが一番なのかなと思っています。

全く能力的にその仕事に向いておらず、後輩にも抜かれ、誰がどう見ても足でまといになっているような状態でも、仕事は続けるべきだと思いますか?

うちの会社は4年目でそれなりの基準を満たしている社員は一個上に昇格することになっているのですが、そこは何とか同期と足並みを揃えて昇格できました。
ただ、他の30代の社員を見ていると、30後半でそこの役職止まりの人もいて、そこから差がついてくるようです。

私もこれ以上、昇格出来る気がしません・・。

なんでSEになってしまったのかという気がしています・・。

何かアドバイスありましたらよろしくお願いします。

SEとして社会人になって3年半が立ちました。

ただただ思うのが、タイトルのようなことです。

C言語とかSQLとか、あのようなものをどうしてすぐに読み書きできるのか・・。
私はSQLは「select * from...where」くらいならわかりますが、innter join、left joinなどが入ると途端にこんがらがります・・。

また、自分のチームに別のチームにいた経験15年程度の方が加わったのですが、一週間のうちには自分のチームの携わるシステムを理解し、仕様について突っ込みを入れたり提案したり、会話を主導しており、レ...続きを読む

Aベストアンサー

そうですね、技術的な事のアドバイスはありませんが、
心構えなら二つ三つありますよ。

まず、システムエンジニアがコンパイルされる前のコードを
一生懸命書いているのは、要は開発するシステムの
要求仕様書を満たす翻訳作業をしている訳です。

昔々、CPUが8bitしかなくて、パソコンというものが未だ
世の中に存在しなかった頃、コボルやパスカルを走らせて
いたのはオフコンが大半だったのです。

小さな能力のハードウェア資産の中で、いかに高速に
動作するかは長ったらしくないシンプルで美しいコードを
書けるかどうかにかかってました。

その前はコンパイラさえ満足になかった時代はアセンブラです。
アルファベット二文字に置き換えたニモニックやデータと格闘していた。
手書きですよ? 今じゃとても信じられない。

昔流行ったギャグで、音声化したデータ通信を聴いて目をキョロキョロ
素早く動かして、・・・私には、判る。 とか、プログラムがインストール
されました、だの言って周囲を笑わせる奴がどこにでも一人はいました。
余談ですね。

今はどうですか?

ハードも機械語に変換するツールも恐ろしく進化して、かつてのように
高度なCPUアーキテクチャ(直接CPUに出すコマンド類)など全く勉強
せずとも、結構多くの人とがコードを書けるようになってしまいました。

ホームページなんか、勿論直接HTMLやJAVAが書けないとプロとしては
通用しないけど、小・中学生が「マイホームデザイナー」でペタペタと
サイトを立ち上げたりするのも普通になっちゃいました。

今通用している技術も、あとわずかでもっと高度な、そして多くの人が
利用できる簡単なものに置き換わっていきます。
SE30歳限界説は今は更に低年齢化しているとも言えます。

が。

この数十年で全然、全っ然変わらないものが二つあります。

一つ目は、専門的な事情などお構いなし、出来て当然要求ばかりのクライアント。

そういう意味では、口数など計算もせずに、なんでも出来る出来ると破格値で
契約を取って来る営業マンもその一味と思ってよさそうです。

二つ目は、クライアントの要求を仕様書に整理して書き直す部分は、昔から
進化などしていない、ということです。

そりゃそうです。要求する人間はたかが数十年で進化などしませんから。

つまり、ソフトウェアを開発・運用する会社の中で今後もずっと必要であり
利益を産み出す核になる部分は、「クライアントの要求」の逆アセンブルです。

専門的な事が何一つ判っていない人間がお金を払って実現したいと望む
彼の頭の中にしか無い物を上手に抽出して、効率的なデザインに置き換えて
いく。

この作業に必要なのは、コード・ブックでもないし、勿論、目にもとまらぬ
ブラインドタッチなどでもありません。

相手の話を完璧に聞き取る能力。

これが実に難しい。

こういうことだな、と一人合点していると、成果物を突っ返されて金が払えんと
言われてしまうのです。

こんなことは開発の世界じゃ日常茶飯事。

納期直前にバグ取りの手も足りずに毎晩毎晩ミクをエンドレスで聴きながら
徹夜徹夜で脳死状態。

どんなに優れたスキルがあっても、これじゃ仕事にならないじゃないですか。

だから。

相手が言うこと、考えていることを、自分達がきちんと把握できる形に
翻訳できる能力・・・つまり、相手が「それで間違いない、完璧だ」と言ってくれるまで
何度でも確認し、整理し、煮詰めて練り上げていく根性作業。

それこそが、誰もやりたがらないことであり、もっとも必要とされるスキルなんです。

周囲に流されて自分がバカに見える時は、彼らがハザードになってしまって
その向こう側が見えなくなっている時です。

会社のデスクばかり見ずに、仕事をくれる相手方に赴いて、現在の仕事の仕方や
ユーザー達のヒアリングなど、詰めようと思えばいくらでも余地はあります。

そしてね。

そのスキルは、SEに限らず、物を造る仕事、運用する仕事、そしてサービスを提供する
仕事のいずれにも使える共通技術なんですよ。

常に、人間を見ることを忘れないように頑張ってね!

社会を動かしているのは、人間なんだから。

そうですね、技術的な事のアドバイスはありませんが、
心構えなら二つ三つありますよ。

まず、システムエンジニアがコンパイルされる前のコードを
一生懸命書いているのは、要は開発するシステムの
要求仕様書を満たす翻訳作業をしている訳です。

昔々、CPUが8bitしかなくて、パソコンというものが未だ
世の中に存在しなかった頃、コボルやパスカルを走らせて
いたのはオフコンが大半だったのです。

小さな能力のハードウェア資産の中で、いかに高速に
動作するかは長ったらしくないシンプルで美しいコードを
...続きを読む


人気Q&Aランキング