Tech総研
2006/5/25
| プロジェクトをマネジメントするどころか、メンバーを地獄に陥れるようなプロマネの正体を暴く。現場の悲痛な叫びはプロマネに届いているだろうか。（Tech総研／リクルートの記事を再編集して掲載） |
Part1 |
複雑化・高度化した現代の技術。1人のエンジニアが、1つの案件を仕上げることができるケースなどほとんどない。そこで重要になってくるのが、メンバーを率い、プロジェクトをまとめ上げるプロジェクトマネージャ（プロマネ）の力量だ。しかし……。
Tech総研が、主にIT分野のエンジニア100人に行ったアンケート調査によれば、これまでにプロマネの下でスムーズに進めることができたプロジェクトは5割に満たないと答えたエンジニアが、何と88％にも上っている（図1）。しかも、そのうち79％が、別のプロマネであればうまくいったはずと答えているのである（図2）。
 |
 |
| 図1 これまでにプロマネとスムーズに仕事が進められたプロジェクトは何割？ | 図2 もし別のプロマネだったら、そのプロジェクトはうまくいったと思う？ |
回答の中には、プロジェクトの規模が担当プロマネの手に余り、その結果メンバーの担当する仕事が堤防決壊状態。あまりの激務に変調を来し、うつ病と診断されたという悲惨なケースも。
とはいえ、ある程度の経験を積めば、いずれは自分自身もプロマネとしての仕事を任される可能性は十分ある。そんな将来を視野に入れながら、メンバーの立場からプロマネの力不足が原因と思われる「失敗の事例」を考えてみたい。
Part2 |
赤字計上や大幅な納期遅れ、果てはプロジェクト自体が消滅……。一方ではメンバーへのしわ寄せ・退社など、悲惨な結果に終わったプロジェクトは数多い。そんな失敗を招き寄せたプロマネの行動とは？ 傾向別に4タイプに分類し、失敗事例を追ってみた。
| TYPE1 | コミュニケーション不足でモチベーション急降下！…… “だんまり”プロマネで迷走 |
| CASE1 「情報せき止め型」 |
| スケジュールが全然分からない！ 無線通信の基地局内、無線部を終端とするファームウェア開発プロジェクト。プロマネがメンバーとコミュニケーションをうまく取れず、半数以上のメンバーがスケジュールを理解していない状態に。スケジュール上、試験工程になってもほとんどの設計が完了していないというありさま……。 プロジェクト遂行上、重要と思われるメールさえ、メンバーに転送してくれなかった。 （制御系SE／28歳） |
| その後のプロジェクトは |
| 最終的には上司の判断で、同じプロジェクト内にもう1人プロマネを立てることに。またメンバーは自己防衛のため、プロマネが何もいってくれないなら、できるだけこちらからプロマネにアクセスするように心掛けた。それでもすべてを聞き出すことはできなかったが……。 |
| CASE2 「意思疎通困難型」 |
| お互いに言葉が通じない！ 新しい受発注システムを構築するプロジェクト。プロマネは自社内の人間ではなく、コンサルティング会社から来た人が務めたが、社内の事情もあまり分からず、IT主導のシステムとなってしまった。顧客不在の状態で迷走した揚げ句、最終リリースが半年も先延ばしになってしまった。 コンサルタントだけあって、難しいIT用語を用いることが多く、メンバーもきちんと理解できていないことが多かった。顧客にとってもIT専門用語は難しかったようだ。 （社内SE／30歳） |
| CASE3 「無責任！ プロマネ逃亡型」 |
| 頭数をそろえりゃいいってもんじゃないでしょ！ むちゃなスケジュールと予算で仕事を受けてしまったうえに、スキル無視で人を入れたがために手戻りが多数発生！ さらに作業量が増えるという悪循環に。残業休出は当たり前の、まさに「24時間365日営業状態」となり、他チームの応援を仰ぐやら、顧客とのスケジュール調整に奔走するやら……。 メンバーはただ頭数をそろえただけなので、モチベーションも低くなり、それに対するフォローもなし。そのため次々と人が去っていっただけでなく、しまいにはプロマネ自身もほとんど会社に来ない状態に。 （Webシステム開発／32歳） |
| 影のマネージャ的存在になるのもアリ！ |
| 単に人数分の力ではなく、互いの協力で人数分以上の力が発揮できてこそ「チーム」といえる。しかし、それをまとめるリーダーが機能しなくては、メンバー個々がバラバラに仕事に追われ、逆に人数以下の力になってしまうことも。「失敗に一目散」なプロジェクトならあきらめるしかないが、メンバー相互の関係が密なら、自分が「影のマネージャ的存在」に徹して、メンバーにある程度任せながら、プロジェクトをまとめるのも1つの手かも？ |
| TYPE2 | 「独断専行」に「仕事抱え込み」…… “ブッちぎり独走”プロマネで、周囲はヘロヘロ |
| CASE1 「独り決め型」 |
| ひと言の相談もなく仕様やスケジュールを決めないで！ Web開発のプロジェクト。プロマネがメンバーである開発者に相談もなく、次々に客の仕様変更をOKしたり、対応期間を独り決めしたり。それが適切であれば文句はないが、明らかにチームの処理能力を無視。結局、全体の工数が大きく膨らんで手に負えなくなり、約1億円の大赤字を出してプロジェクトは失敗に終わった。 （Web開発／26歳） |
| その後のプロジェクトは |
| プロマネがメンバーに相談なくすべて決めてしまうため、メンバーの意識が統一できないまま、作業だけが増えていった。プロマネをもっと経験のある人に変えられないのなら、内部調整会議を増やして意識統一を図ればよかったと、いまにして思う……。 |
| CASE2 「くちばし突っ込みまくり型」 |
| 細かいところは任せてよ！ お客さまの要望は十分に考慮された内容。にもかかわらず、かなり細かい部分までプロマネが口を出し、自分が納得いくまで作業を進めさせなかった。おかげでプロジェクトの進ちょくは大幅に遅れるありさま。任せてもらえない担当者はモチベーションを失ってげんなり。結局、上司の判断でプロマネが替わるまでその調子だった。 気負っていたのかもしれないが、とにかく自分で判断しないと気が済まないプロマネだった。本来、担当者同士でやるような細かい作業にまでプロマネが口を出しすぎ。 （汎用系開発／36歳） |
| CASE3 「ため込み巣ごもり型」 |
| もっと早くいってくれれば！ 新開発機種用の試験装置に搭載するソフトウェアの開発プロジェクトだったが、外注に対して仕様変更などを周知徹底できなかったため、手戻りが多くなってしまった。メンバーの作業時間が割かれたため、品質も低下した。結局、コストの大幅超過、延納という悲惨な結果になり、手遅れながらも他部署の支援を要請した。 また、プロマネが1人で仕事を抱え込みエスカレーションを上げるのが遅かったため、ほかの部署からの支援も役に立たない状態になった。 （汎用系開発／26歳） |
| CASE4 「テキトーお任せ型」 |
| メンバーの力量も考えてよ！ 通信事業系の料金徴収システムを手掛けたが、チーム編成時に個人の能力が把握できておらず、偏った仕事の割り振りになってしまった。何とかサービス開始までに間に合わせることはできたのだが、そのために仕事ができる一部のメンバーに作業が集中してしまった。 体制づくりの時点で想定される必要なスキルを持ったメンバーを集めるべきだったのにそれを怠ったうえ、仕事の割り振りも適当。個人のスキル任せだった。 （Web系開発／29歳） |
| 1人で仕事を抱え込んでしまうプロマネにならない！ |
| メンバーのことを考えずに、1人で突っ走ってしまうプロマネ。理由として「自信過剰で他人は信用できない」か、逆に「自信がなくて他人に指示できない」の両極端が考えられる。後者なら、メンバーにうまくサポートしてもらえば状況好転もあるが、前者の場合、自信過剰が強ければ強いほど、プロジェクトが泥沼化する。最初は頼りなくても、メンバーを信用して任せる癖をつけよう。 |
| TYPE3 | 作業指示が明確にできない “あっちこっちフラフラ”プロマネのせいで作業効率は最悪！ |
| CASE1 「詰めが甘い指示ベタ型」 |
| 先にやることやってくれ！ ある工作機械メーカー向けの制御機器の開発プロジェクト。メンバーも割り当てないまま顧客のいうとおりの納期をマネージャが約束。当然ほかの仕事が忙しく、手も付けられないまま納期遅延の連続。半年遅れで試作品を納品したが客先の品質評価で問題が出て現在対応中というオマケ付き。 プロジェクトの体制も整えず、開発の細部も煮詰めないうちに納期だけ決めてしまったプロマネのいいかげんさが諸悪の根元。 （制御系SE／33歳） |
| その後のプロジェクトは |
| 連日の残業と休日出勤でなんとか乗り切った。少なくともメンバーとの見積もり相談、顧客とのスケジュール調整はやってほしかった……。 |
| CASE2 「指示放棄型」 |
| マジメな人間が損をするのか！？ 環境分析用データベース作製プロジェクトに携わっているが、プロマネからメンバーへのはっきりした指示は一切なし。おかげで私以外のメンバーのほとんどが作業をやらなくなり、それが原因で発生した遅れを取り戻すため、いまだに1人奮闘中……。 指示の徹底や連絡など、本来プロマネが行うべき仕事はほったらかしたまま！ 結局、私がプロジェクトメンバーに参加を促すために個別に折衝して回るなど、一部の仕事を肩代わりするはめに。 （研究／28歳） |
| CASE3 「技術知識欠乏型」 |
| もうちょっと仕事の中身を分かってくれ！ メンバーへの指示があいまいだったり、丸投げだったり、とことんいいかげんなプロマネ。おかげでメンバーは急速にやる気が減退、プロマネは人望を失うというありさまで、プロジェクトは停滞。結局その後、残業に次ぐ残業、また残業という地獄になったうえ、当然ながら納期遅延。 プロマネの技術的知識が乏しかったことがそもそもの原因。そのために、メンバーへの指示もあいまいなうえ、結局「一任する」などという丸投げ状態にならざるを得なかった。 （Web系開発／29歳） |
| 的確な指示ができないプロマネは混乱を起こすだけ |
| 本来、リーダーシップをもってメンバーを引っ張るべきプロマネが、的確な指示ができないのでは悲劇の原因になりかねない。これはTYPE1のコミュニケーション不足にもかかわるかもしれないし、TYPE2の「自信なし」タイプとも重なるかもしれない。いずれにせよ、混乱に拍車をかける前に、上司に相談しながら助けてもらうことも考えるべきだ。 |
| TYPE4 | お客さまは神様ですか？ 顧客の要望そのままの“伝言マシン”プロマネで作業量爆発！ |
| CASE1 「被・拉致監禁型」 |
| 顧客の変更要求をリレーするだけなんて！ 度重なるお客さまからの要件変更。現場サイドではその日のうちに実施すべき作業があるにもかかわらず、プロマネからは急かつあいまいな作業指示が頻発。しかも、それもまた“本日中”などの期限付き。キャッチアップするために、メンバーは毎日明け方まで作業。最終的に期日には間に合ったが、実はシステムとして完成されていないところが残ったまま……。 期間は変更できないのに、プロマネは客先でつかまったきりで、ひっきりなしに変更のメールをよこすだけ。 （ネットワーク設計／33歳） |
| その後のプロジェクトは |
| 現場にいないので、その指示もあいまいなまま。会社に現状を訴え、赤字覚悟で人手を大量に出してもらうことに。契約前の提案段階で、システムの詳細な仕様までお客さまと合意をすべきだったと思う。 |
| CASE2 「ユーザーニーズ過敏症型」 |
| 全部受ければいいってもんじゃないでしょ！ 某メーカーの社内在庫管理システム開発。顧客の要望を全部受けてくるので、仕様がとんでもなく複雑化し現場が混乱。結局テスト工程でのバグ発生率が異常に多くなり、工期が大幅に遅れた割には使い勝手が悪く、顧客の評判も良くなかった。 顧客の業務自体が複雑化しており、取引相手ごとに異なるデータ形式にすべて対応していたらきりがなくなる。それをプロマネが顧客にもきちんと説明すべきだった。 （Web系開発／30歳） |
| 顧客のメッセンジャーだけやっていても信頼されない |
| 単なるメッセンジャーと化しているプロマネ。本来は顧客の要望を基に、プロジェクトで追い求める「答え」を絞り込んでいく役を担わなくてはいけないが、まったくその部分を放棄しているわけである。とはいえ、顧客側から見れば「ハイハイ」と聞いてくれる人であるだけに、（最終的にプロジェクトが失敗に終わるまで）信頼を得続けていたりするのがますます怖い。「この場合はこうした方がいい」というオルタナティブ（代案）を出せる技術力、企画力を磨こう。 |
Part3 |
プロマネの能力不足に起因するプロジェクト難航や頓挫も多発するいま。エンジニアたちは何を心掛ければよいのか。自らもプロジェクトマネジメント、プロジェクトアーキテクトを務めた豊富な経験を持ち、現在はIT戦略とプロジェクトマネジメントを中核としたITビジネスのコンサルティングを行う、アイ・ティ・イノベーション 代表取締役 林衛氏にお話を伺った。
プロマネとして「生まれ変わる」ことができるかが鍵
アンケートの中では、プロマネのコミュニケーション能力の不足や判断のミスに起因するとされる、さまざまな「プロジェクト失敗の事例」が挙げられています。しかし実は、これらは単に「コミュニケーション能力」や「判断力」、「指導力」の欠如が原因ではないのです。 特にITの分野は、ますます複雑化・多様化が進んでいます。そこでは、いままでのように「すでに解法があるものを着実にこなす」のではなく、自ら解決策を見つけることが求められています。プロジェクトを推進するとは、まず、「問題がどこにあるのか」を見抜くことから始めなければいけません。しかし、そこが欠けているために、ユーザーの定まらない注文に振り回されたり、一方であいまいな指示しか出せなかったりするのです。 日本の場合、普通にSEがある程度の経験を積んだらプロマネを任されることが多いのですが、メンバーとプロマネでは、要求されている能力はまったく違うのです。プロジェクトとは、「実現されていないものを約束する」行為。当然、その実現にはリスクが伴います。プロマネもまた、そのリスクテイクをする覚悟、あえてそれに向かう自信を持っていなければいけません。そこに気付けるかどうかが、プロマネとして「生まれ変わる」ことができるかどうかの分かれ道になります。しかしまた、優れたプロマネが著しく貴重ないまだからこそ、そこに気付ける人は、大きなチャンスを持っているのだともいえるのです。 |
| コラム：プロマネに一番必要なスキルとは？ | ||
| 現場のエンジニアの中で、「プロマネに必要な資質」として、何が最も求められているのだろうか。メンバーとプロマネ自身に尋ねた質問の答えを、以下に挙げた。高く買われている能力は両者とも共通しているが、“指示を与える方”＝プロマネは「コミュニケーション能力」を、“指示を受ける方”＝メンバーは「指示判断能力」を重視する率が若干高いという特徴が見て取れる。これはむしろ、プロマネ自身は「自分の判断だけでは心もとない」、メンバー側は「やることをプロマネに決めてもらった方が楽」という弱気の表れかもしれない。
|
| ☆“あの”プロマネを超えよう | |
現場がプロマネの言動や能力で惨状に陥れられてしまう様子はまるで阿鼻（あび）叫喚の地獄絵のようだ。ただでさえIT系プロジェクトは困難が多いのに、管理役であるはずのプロマネが部下を苦境に立たせていいものだろうか。 だがアンケートによると「これまでプロマネとスムーズに仕事が進められたプロジェクトは5割以下」と答えた人は実に88％もいる。エンジニアの誰もがプロマネとの意思疎通に悩まされているようだ。 プロジェクトの惨状というと、いつも取りざたされるものにはプロマネのコミュニケーション能力不足や判断ミスがある。だが記事中のコメントによると「コミュニケーション能力」や「判断力」のほかにもプロマネには「解決能力」が必要だという。プロマネとして十分な資質を備えることは容易ではない。 ただし部下として嘆くだけではなく、何が足りないかに気付ける人はチャンスがあるという。これはひどいプロマネの欠点に気付き、反面教師にできる人物は将来伸びる可能性があるということのようだ。苦難を乗り越え、“あの”ひどいプロマネを超え、いつかプロジェクトを本当の意味で管理できる人物になることを目標にしてみてはどうだろう。 （加山恵美） |
この記事は、Tech総研／リクルートの記事を再編集して掲載しています |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
