プロジェクトリーダーのスキル

質問

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

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

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

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

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

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

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

回答No.8

otabe · ベストアンサー

頑張れ　リーダー！！

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

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

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

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

お礼

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

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

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

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

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

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

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

回答No.7

noname#15922

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

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

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

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

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

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

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

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

お礼

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

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

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

回答No.6

a-kuma

同業者（の様）です。私からは、辛口の意見を。

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

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

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

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

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

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

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

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

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

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

◆以下、余談

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

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

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

頑張りましょう。

お礼

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

回答No.5

mnabe

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

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

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

お礼

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

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

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

回答No.4

ymmasayan

プロジェクトリーダーの真の役割はグループの総合力を最大限ひきだして、目的を完遂すること、常に全体の状況や進捗を管理し、異常事態に直面したことを素早く検知し、臨機応変に対策の指揮を取れることだと思います。だから、リーダーはグループメンバーよりかなり軽めの分担とし、突発自体への対応や、遅れているところのリカバリーの余力を確保しておくべきです。

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

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

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

お礼

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

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

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

回答No.3

toysmith

完全な私見ですが…。

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

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

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

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

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

お礼

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

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

回答No.2

tadanokuma

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

お礼

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

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

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

回答No.1

mnabe

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

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

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

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

補足

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

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

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

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

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

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

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

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