優秀なＳＥが突然プロマネに任命されて潰される原因と対策。

優秀なＳＥの方が突然プロジェクトマネジャーに任命されて、知識も経験もないまま進めていく内に、大炎上を起こして失敗する光景は何度も見てきました。

ＳＥとしては素晴らしいスキルを持っていたのに、プロジェクトマネジャーとはそんなに異質でＳＥの経験は通用しない仕事なのか？

プロマネ未経験の方、正に今このような渦中にいて苦しんでいる方、これからプロマネを目指そうと考えている方向けに、このようなケースの失敗の原因は何処にあるのか、どうすれば解消出来るのかついて解説していきます。

はじめに

グインこと私の略歴を紹介させてもらいます。官庁、銀行協会、都銀などで基幹システムのアプリケーション開発でプロマネを１５年、現在はＷＥＢ・オープン系のプロマネを５年経験しています。

この経験の中で、上述のような状態に陥って、優秀なＳＥだった人が自信喪失してしまい、已む無く会社を去っていった例を何人も見てきました。

このような最悪のケースの場合、会社側の無責任なアサインと丸投げ状態のサポート不足などによる外的原因、またその人の適性や過信、未経験による施策不足などの内的原因があり、殆どの場合その両方によって起こっています。

そして不幸なのが、社内的弱者のプロマネを任された人に責任の殆どが押し付けられ、釈明も出来ず、何が悪かったのかも解らぬままに、会社に居辛くなることが、特に中小企業のSIer会社でよく起こることです。

「プロジェクトマネージャーとは」については別記事で改めて書くとして、今回はこのようなケースの問題点と回避策について噛み砕いていきます。

ＳＥとＰＭの根本的な違い

プログラマーやＳＥの仕事は、アプリケーションコーディングやハードウェア・ミドルウェア、システム設定などの技術的側面の作業で、解らないことにぶつかっても、ネットや本で調べればいつか答えに辿り付く、０か１かの答えが明瞭の世界です。

良くも悪くも自分が作った通りにコンピューターは動作し、奥の深さに底がないため、それを追究することに喜びや楽しさを感じる人、職人気質の人に向いている仕事です。

傾向として、人とコミュニケーションを取ることは苦手でも、黙々と仕事を熟していく人に好まれる職業です。

一方、プロジェクトマネージャーの仕事は、顧客と自社の上層部と開発チームの橋渡し役が主な作業です。

技術的知見・開発プロセスの知識・経験がある事は前提で、コミュニケーション能力と調整力などの対人スキルが最も要求される仕事です。

そのためプログラマーやＳＥの時のように、０か１かの答えの明瞭さとは真逆の世界で、不確定要素を一つづつ潰していく仕事をしなければなりません。

日々直面する問題はネットにも本にも答えは載っておらず、自らの頭で最良の解決方法、打開策を考え、積極的に関係各位に了承を取り付ける作業の繰り返しです。

安さ早さ品質を求める顧客、収益を求める上司、ストレスがなく楽に仕事をしたい開発メンバーと、全て相反する要求を取り纏めなければならないため、顧客からのクレーム、上司からの叱責、メンバーの反発などのプレッシャーは避けて通れません。

これらのプレッシャーはプロマネの経験量と反比例して減らしていくことが出来ますが、経験の少ない最初の頃は精神的にキツイ仕事です。

このように書くと、プロマネなんてなるもんじゃないと感じる方もいるかと思いますが、自身の采配でプロジェクトを成し遂げた達成感、充実感は他の役割では味わえないのも事実です。

優秀なＳＥだったことが仇になる原因と改善策

優秀なＳＥがプロジェクトマネジャーに向いていないという話ではありませんので誤解しないようにお願いします。

優秀なＳＥであるが故に、陥り易いプロジェクトマネージメントでやってはいけないミスを説明します。

① 要件調整などで顧客目線で会話が出来ない

プログラマー、ＳＥ時代に常識として話していた業界用語や会話内容が、殆ど通じない顧客と会話することに慣れておらず、相手が理解出来ない技術的に偏った話をしてしまうことがよくあります。

顧客側が理解しようと前向きな姿勢で、納得するまで質問してくれる方ならラッキーですが、残念ながらそういう奇特な方はまずいません。

業務要件を詰めている時に顧客目線で会話が出来ない人は、相手が理解出来ているかどうかを察すること自体が不得意なため、開発者目線で説明している自分の話が理解されていなくても、気付かずに話を続けてしまう傾向があります。

顧客はその説明に付いて行けず、何が解らないのかも質問できない状態に陥ります。

質問がなくなったことで分かってもらえたと都合の良い解釈をしてしまい、相互に誤った認識のまま要件定義を終えてしまうケースが良くあります。

これは最も危険な状態で、受け入れテストまで進んだ段階で初めて、顧客からこんな認識では無かったと、仕様認識齟齬による無償改修が発生します。

しかも仕様から間違っている場合は、改修範囲が大きく、期限・予算超過は免れず、最悪の場合は契約破棄に発展する可能性もあります。

顧客と業務要件の詰めを行う際は、コンピュータ知識が全く無い人に説明するぐらいの意識で、一般の人が分かる言葉で説明し、クド過ぎるかな？と心配になるくらい理解できたか確認を惜しまない努力が必要です。

② 見積りを開発者観点だけで立ててしまう

見積りはそのプロジェクトの成否を分ける最も重要な作業なのですが、慣れていないがために、この工程を軽い気持ちで作成してしまうことが経験の浅いプロマネによく見られます。

原因の一つに、ＳＥ時代にＰＭから「この機能は大体どの位の工数がかかる？」と質問を受けた際に、「自分だったらこの位」と気軽に答えていることに慣れてしまっていて、その感覚のままに全ての機能を積算して見積もりとして出してしまうことが考えられます。

その感覚で工数を見積ってしまい、プロマネとして顧客に提示してしまうと、全く予算が足りない事態に陥ります。

見積り段階で確定している要件はまだまだ荒く、実際の設計に落とし込む段になって細かい仕様を詰めなければならないことが通常です。

また、開発メンバーの調達は通常、見積りが確定することによって、どの位の期間どの位のスキルの人が何人必要かが判明します。そしてその必要条件を全てクリア出来る人材を確保できる事はまず難しいのが常です。

要員調達の後も、開発環境構築、仕様の啓蒙と浸透にかかるオーバーヘッド、各種管理に必要な作業などを見積りに積んでおく必要があります。

開発に着手した段階で”マージリクエストにかかるレビューや手戻り作業を見積りに加えていなかった！”と後で気付いても残業でカバーせざるを得なくなっては目も当てられません。

見積り内容は例え上司があなたを買い被って「全権、君に任せる」と言ったとしても真に受けず、必ずベテランや上司にレビュー承認をしてもらうようにして下さい。

詳しい説明記事は後日作成します。

③ スケジュールを自分基準で計画してしまう

スケジュールを立てる際、本番サービスインの日付けを起点として、受け入れ検収期間、システムテスト、結合テスト、開発・単体テスト工程、設計工程へと逆引きしていき、各工程のマイルストーンを設定していきます。

これで大日程スケジュールが決まるのですが、この限られた設計・開発期間に②で見積もった工数を当てはめることで、開発要員が最大何人必要かが判明します。

その要員のＷＢＳを引いていく際に、自分自身の生産性を基準に計画を立ててしまいがちです。

要員調達まで自分で采配で思うように出来れば、リスクを減らすことは多少可能ですが、社内で空いている要員をアサインされるか、外注でスキルの不透明な人材が宛がわれるのが通常です。

自分では１人日で出来る作業ボリュームに、新人プログラマーを当てざるを得ない事態になり、２日引かなければならないと分かった時点で、見積もりにリスクを積んでいなかったことに気付きます。

「未知の人材を想定して、見積り・計画など立てれないじゃないか！」と当然感じるでしょうが、そんな時に利用出来る指標として、PMBOKにはPERT法という計算・計画方法があります。

詳しい説明記事は後日作成します。

また、このような想定外の事態に対して、残業・休出でマイルストーンを守ろうと計画を立ててしまうとデスマーチが始まります。

１人日は８時間でＷＢＳを作成する事が絶対条件です。残業ありきで計画を立てることは絶対に避けて下さい。

担当機能を見直す、ベテランに新人のフォローをお願いし、計画を担保してもらうなどの工夫をして、全ての開発要員を無理なく無駄なく配置する努力を惜しまないで下さい。

また進捗会は毎日３０分などと時間を決めて行うこととして、随時前倒しと遅れを調整して計画を見直し、開発要員たちの協力を仰ぐことを疎かにしないようにして下さい。

④ 不確定要素に対し、待ちの姿勢になりがち

要件定義工程で課題管理表を作成し、詰めきれていない課題が後続工程まで残り続けることは頻繁に起こります。

ＳＥ時代はＰＭが課題管理をしてくれるため、待っていればデッドラインまでに回答を貰えるでしょうが、これに慣れてしまっていることが原因で残課題を見落としたまま開発を進めていくことが経験の浅いプロマネにはよくあります。

プロマネとなった限りは、顧客が玉を持っている課題に対してでも、積極的に解消していかなければなりません。

顧客が仕様を固められない場合、デッドラインを守るためにこちらから対応可能な案を２つ３つ提示して決めてもらったり、期限を設けてその日までに回答をもらえない場合は、次回案件として今回の対応から外すなどの調整をしなければなりません。

「顧客に催促ばかりして煙たがれるのもどうか」と遠慮したり、「解消しようとしない先方に責任がある」などドライな発想でこちらから何らアクションを起こさず、ただ待ち続けた状態で顧客に対し「お応えがなかったのでスケジュールが遅れました」や「その機能は対応出来ていません」と経緯を説明しても大抵の場合は通用しません。上司に掛け合われてねじ込まれるのが関の山です。

理不尽に感じるかも知れませんが、日本の商習慣ではまだまだ受注側の立場は顧客と対等とは言えないのが現実です。

裁判を起こして顧客を失うリスクを会社が負うのと、残業・休出でリカバリするのとどちらを採るかは言わずもがなです。

プロマネは課題に対して常に目を光らせて、プロジェクト完遂させるために常に先手を打つ事を意識するようにして下さい。

⑤ 進捗遅れの原因は開発者の力量不足だと不満を持つ

 例え開発要員の勤怠が著しく悪かったり、技術不足で大幅な遅延が発生したとしても、顧客には何の言い訳にもなりません。

プロマネは品質と期限を担保することが絶対条件です。

実際に要員に問題があったとしても、それを早期に除去してリカバリーを図らなければなりません。

その改善策として、進捗会の時に全員の前でその要員を怒鳴ったり、叱責する事は絶対に避けなければなりません。

その行為はチームの指揮を著しく低下させるだけで、その要員がその日から突然やる気を出したり、生産性が上がるようになることはありません。

別の場所でその要員と二人で冷静に相談し、改善の目途が立たないと判断した時は、交代させることも視野に入れて正直に話して納得してもらう必要があります。

そしてその交代は決して懲罰であってはいけません。あくまでも適材適所の采配の問題であることをお互いに理解することが重要です。

よくあるケースでは、新人プログラマーが周りに遠慮をして一人で抱え込んでしまうことが良くあります。新人を育成することもプロマネのタスクの一つです。

私は新人が参加している時には「３０分悩んでも自分で解決出来ない時は必ずベテランに聞いて解消すること」と必ず全員に言うことにしています。そしてその人のメンターを任命して、質問し易い状況を作るようにしています。

また、経験の浅いプロマネの場合、自身の立てた計画に問題がある可能性も高く、一概に開発者の力量の問題ではないこともあります。

大人しい人や、委縮しがちな人も往々にしているのがプロジェクトです。遅延している理由を話し易い雰囲気作りを心掛けるのもプロマネの適性に必要な要素です。

理由を聞いてみると、未知の機能追加が合ったり、既存不具合が有って対応をしていた、設計では見抜けなかった複雑な機能でその担当者には荷が重過ぎるものだったということが良くあります。

そういう遅延理由を聞き出すことも出来ず、この人は生産性が悪いと単純にレッテルを張ることがないように注意をしましょう。

常に計画よりも前倒しで終わらせ生産性が高いと思っていたら、後続試験で障害が続出させる要員が居たり、生産性はバッファを持った計画通りにしか進められないが、障害を殆ど出さない要員が居たりと、長い目で見ないと要員の良し悪しは判断できないことはよくあることを心掛けましょう。

⑥ 遅延解消に自らが開発を手伝ってしまう

これが有能なＳＥがプロジェクトで炎上を起こす際たる原因です。

遅延の解消のために自らが開発に携わり、リカバリーをしたくなる気持ちは良く解るのですが、プロマネである以上は、自身の仕事を疎かにして開発に参加する事は避けるべきです。

理由として全体に眼が行き届かなくなることです。本来プロマネは全体管理と品質の確保を最優先にするべきで、開発を手伝うことで、レビューを後回しにしたり、顧客との調整事を疎かにするすることで、遅延を解消しているつもりで、全体の進捗を遅らせていることに気付かないことが良くあります。

プロマネは開発期間はレビュー位しかやることがないと考えていないでしょうか？

開発期間は次の結合テストやシステムテストのテスト計画、テスト試験仕様書の作成、開発工程の定量・定性評価、障害・変更管理など、後続工程の事前準備や全体の管理に意識を常に集中しておかなければ、必ず後工程で皺寄せが襲ってきます。

そして開発要員に分散させている作業は最終的に自身にレビューとして集中します。

只でさえボトルネックの役割であるプロマネは固有の作業を抱えてはならず、常に起こる不測の事態に備えて、自身のリソースに余裕を持たせておかなければなりません。

プロマネは植物で例えると幹の部分に当たります。根は顧客やステークホルダー、自社の管理サイドに当たり、枝葉は開発部隊です。

幹が機能不全を起こすと、その先の枝葉は全て壊死してしまう事を忘れないようにしましょう。

⑦ 本人も上司も過信している事に気付かない

成長期の中小企業にありがちな例を挙げます。

順調に売り上げを伸ばしてきたある会社では、受注量に対してプロマネの育成が追いついていませんでした。

中途でプロマネ層を増やそうとしますが、採用も思うように行きません。

せっかくの受注を逃すまいと、急場凌ぎで社内で優秀なＳＥをプロマネに任命しました。

彼は今までプロマネに積極的に貢献してきたし、彼なら実戦でＰＭスキルでも身に付けてくれるだろうと、上司も忙しい事を理由に丸投げの状態になっていました。

彼自身も今迄見てきたプロマネの仕事を参考に、問題なくやって行けると根拠のない自信がありました。

しかし知識も経験もないため自分の管理に穴があることも前述のようなミスを犯していることも全く気付来ません。

初めてのプロマネで気合いが入っていて、優秀なＳＥだった為、自信にも満ちていたため、開発メンバーも彼に意見を言える雰囲気では有りませんでした。

表向きは順調に見えていたプロジェクトも開発工程が大詰めを迎える時に、先送りしていた問題が彼の余裕を奪っていきます。

全体を見渡すことが出来なくなっていき、そのシワ寄せは開発メンバー全員の残業と休出で賄うようになりました。

開発メンバーには不満が蓄積していき、ある日、一人が来なくなりました。

これを皮切りにして、今迄大人しかった開発メンバーが一気に不満を漏らすようになり、収集が付かなくなっていきます。

彼はその打開策が全く浮かびません。既に自分が手伝うことで吸収出来る遅延ではありませんでした。

大炎上が傍目で見ても分かる状態になって初めて上司が気付きます。

しかし既に手遅れの状態で、増員や小手先の対応でリカバリー出来るレベルではありませんでした。

彼と上司は顧客に状況を説明し、期限を２ヶ月延長してもらい、無償で対応することになりました。

上司がプロマネを担い、彼は開発者としてリカバリーに努めますが、周りの目は冷たく、プロジェクト終了を機に退職していきました。

これが炎上するプロジェクトで良くあるパターンです。

たとえ自分に揺るぎない自信があったとしても、経験の浅い間は自ら逐一上司に報連相を行い、巻き込んでいきましょう。

上司に逐一報連相をして、あれこれとダメ出しをされ「そんな事は分かってる」「言われずともやってる」と煩わしく感じると思います。

しかしダメ出しを受けているのは、そこに不安を感じているためです。

自分では分かっているつもりでも本質を理解出来てない事もあるので、へそを曲げずに感謝の気持ちを持って自分の理解が合っているのか確認してみましょう。たまに目から鱗が出る時があるものです。

プロジェクトが無事成功した後になって「あの時のあの一言に実は救われてたんだなぁ」と気付くことがいくつか思い浮かぶこともあるでしょう。

まとめ

会社の成長過程において、こういう事は起こりえます。何度かこういう失敗を繰り返すうちに会社も管理体制を強化して、損失を無くすようになっていきます。

しかし前途ある有望なＳＥが受ける精神的ダメージは尋常ではありません。

そんな不幸な境遇に巻き込まれないためにも、必ず自ら進んで自分やり方に問題がないかチェックしてもらいましょう。

自分で自習したい方にお勧めの本を紹介します。

この記事を読んで、分かり易いと感じた方にお勧めの本です。

画像をクリックすると
ebook japan商品ページにジャンプします。

PMBOK参考書は小難しくて良く解らないという方の場合、この本でしたら具体的なプロジェクトマネジメントで起こる様々なシチュエーションの事例を挙げて、どういう言動がまずいのかを分かり易く解説しているので一つ一つが刺さると思います。

それでは！