「自分でやった方が早い病」は、多くの技術者が陥りやすい病である。
特に技術者がPMに転向する際に発症しやすく、初めてPMを担当する技術者のほとんどが経験すると言っても過言ではない。
私も初めてPMを担当した際、この状態に陥った。そして克服するまでに2年もの時間を要した。
今回は、私が「自分でやった方が早い病」に陥り、トラブルを経験し、克服するに至った経緯をさえずっていきたいと思う。
私が技術者からPMに転向した経緯
私は新卒から5年以上、データ活用系の技術者として経験を積んできた。その後、技術営業（プリセールス）への転向を打診され、20代後半はプリセーラーとして活動していた期間があった。
プリセールス時代は、自身の得意な技術領域を中心に、案件の掘り起こしから提案、受注までを一貫して担当していた。
ある時、私が提案していた大型プロジェクトが受注間近となった。しかし、開発部門で別のプロジェクトにおける大規模なトラブルが発生し、私のプロジェクトに必要な開発体制を確保できなくなってしまったのだ。
通常、開発体制が組めない状況では、提案を断念せざるを得ない。しかし、私にとってその提案は、お客様との信頼関係を築き上げ、ようやく受注間近までこぎつけた重要な案件であり、どうしても諦められなかった。
そこで私は奥の手を使うことにした。当時の上司と社長に直談判し、「この提案が受注できた暁には、私がPMを担当します。どうか最後まで提案を続けさせてください」と申し出たのだ。
プリセーラーは提案活動を専門とするため、受注後のプロジェクトに参画することは原則として認められていない。社長もそのことを知っていたため、当初は難色を示した。
しかし、同席した上司の説得もあり、「受注を条件に、君がPMを担当することを前提として提案を進めても良い」という許可を得ることができたのだ。
結果として、その提案は受注に至り、私は初めてPMに挑戦することになった。
PMは楽だという勘違い
私が初めてPMを任された時、正直なところPMの業務を楽観視していた。
プロジェクトは当初、私を含めて7名程度の体制でスタートした。
その中には、経験豊富なベテランPMや優秀な技術者が含まれており、「彼らに任せておけば大丈夫だろう」と安易に考えていたのだ。
もちろん、PMの業務は決して簡単なものではない。しかし、PM経験のない私は、そのことに気付くことができなかった。
プロジェクトが始まって早々に、私はその甘さを痛感することになった。
開始当初、私は提案時の計画に沿って、チームのベテランPMや優秀な技術者が自発的にプロジェクトを推進してくれるだろうと期待していた。そして、私は彼らの進捗を取りまとめ、顧客に報告する程度の仕事で十分だと考えていた。
当然ながら、現実はそうではなかった。まず、チームのメンバーから最初に言われたのは「決めてください」という言葉だった。
「決める」という重要タスク
結論から言うと、PMのタスクのほぼ全ては「決める」という判断に集約される。
計画フェーズにおいても、実行フェーズにおいても、プロジェクトには「決める」という判断ポイントが数えきれないほど存在する。
- スケジュールを決める。
- ゴールを決める。
- メンバーの役割を決める。
- 人員やコストの増減を決める。
- コミュニケーションの方法を決める。
このように、PMは常に何かを決定し、プロジェクトを成功へと導く。
課題やトラブルが発生した際の対処方針を決めるのもPMであり、二者択一のメリット・デメリットが存在する重要な開発方式の選択もPMの役割だ。
WBSによる進捗管理や、課題管理表による課題管理など、PMは様々な管理ツールを用いてプロジェクトの状況を把握する。
しかし、これら全ては無数に存在する「決める（判断）」の材料とするためのものだ。
初めてPMを担当した私は、チームのメンバーからも、顧客からも、あらゆる方面から「決める」ことを求められた。チームのベテランPM経験者からも例外ではなかった。
ベテランPM経験者からは、「私がPMなら私が決めるが、今回のPMは君だ。私に決定権はない。君の判断に従うから、君の計画と判断で指示してくれ」と言われた。
私は「決める」しかなかった。それまでPMの経験など一度もなかった私がだ。
そこからは猛勉強の日々だった。
技術者時代にPLの経験はあったため、プロジェクト管理における管理手法や必要な管理についてはある程度把握していた。
全くの未経験ではなかったのだ。
しかし、それでも覚えるべきことは山ほどあり、初めて経験する顧客とのコミュニケーションや、留意すべき様々な観点など、初めての体験が次々と押し寄せてきた。
当然、私はすぐに余裕を失い、目の前のことで手一杯になっていった。
自分がやった方が早い病の発病
プロジェクトが一定の段階に進むと、チーム体制やメンバーの役割分担が明確になり、各メンバーの担当領域も定まってきた。
プロジェクトメンバーも当初の7名から10数名に増え、各メンバーの特性や得意・不得意も把握できるようになり、判断を下すことにも慣れてきた頃だった。
私は、「自分がやった方が早い」という病に罹っていた。
もちろん、当時は自覚していなかった。しかし、今振り返ると、間違いなく私はこの時、「自分がやった方が早い病」を患っていた。
理由は、私に余裕がなかったからだと思う。目の前のことで手一杯だった私は、自分が立てた計画を遂行することだけに必死だった。
いつしか私は、自分の計画を遂行するため、私はPMであるにも関わらず、メンバーの一部の作業を巻き取っていたのだ。
自分で言うのもなんだが、私は技術者時代、それなりに優秀だと評価されてきた。新卒から短期間でPLを任されるほど評価を受け、実際に複数の成功体験も積んでいた。
当然、今回も「自分ならできる」という判断基準でプロジェクトを進めており、私のチームが担当するタスクは全て自分自身で対応できるつもりでメンバーに依頼していた。
だからこそ、進捗の遅いメンバーや経験の浅いメンバーの作業の遅れは私が巻き取り、自分の期待する進捗でプロジェクトを進めることに重点を置いていた。
「自分でやった方が早い病」は、時間に追われるほど症状が加速するものだ。時間に追われれば追われるほど、進捗が遅れれば遅れるほど、私はメンバーの作業を奪っていった。
自分がやってしまったことで起きた問題
「自分でやった方が早い病」を患った結果、ついにプロジェクトに問題が発生した。
初期メンバーであるPL（プロジェクトリーダー）の生産性が大幅に低下したのだ。生産性が低下したというよりも、ほとんど仕事をしなくなったと言っても過言ではなかった。
原因は明白だった。私が巻き取ったメンバーの作業には、本来PLが担うべき役割である、部下への指示や作業依頼、相談に乗るなどのコミュニケーションが含まれていたからだ。
正直なところ、そのPLにも至らない点はあった。だからこそ、私がカバーするために作業を巻き取ったのだが、そのPLは技術者としては非常に優秀な人物であり、私はPLの技術を信頼していた。
私はPLの苦手な部分を補完しているつもりだったのだ。
しかし、その結果、PLは仕事をしなくなった。私が優秀だと評価していた技術領域のタスクも、進捗がほぼ停止してしまった。
私はすぐにPLと話し合いの場を持った。PLの生産性が低下したままでは、私の手に負えなくなることを危惧したのだ。もはや、「自分でやった方が早い」という状況ではなくなってしまうと考えた。
PLから最初に言われた言葉は、「あなたがやりたいように、やればいいじゃないですか」だった。
PLは非常に合理的な考え方をしていた。
PMである私が進めたい方向があり、PMである私がそれを自ら実行している状況は、PLにとって非常に合理的に見えたのだ。なぜなら、自分（PM）の計画を自分（PM）で実行するのが、最も期待通りにプロジェクトが進む方法だからである。
もちろん、これは皮肉を込めた言い回しだ。PLが機能しないプロジェクトは、絶対に成功しない。
しかしPLは、自分が介在するとPMの思い通りに進まないと判断した。その結果、進捗の遅延や品質の低下を招くため、PMが自ら作業した方が良い結果になると考えたのだ。
そして、そこには当然、モチベーションの低下も存在した。本来自分が期待されていた仕事、自分が担うべき領域に、上の立場の人間が介入し、その仕事を奪っていくことは、PLにとって戦力外通告されたようなものだった。
PLがやる気を失い、仕事をしなくなるのも当然だった。
私はPLに謝罪し、何度も話し合いを重ねた。
本来PLに期待していたタスクがなぜうまくいかなかったのか、（私が奪い取る以外に）どうすればよかったのか、またPLが私（PM）に求めることは何かなど、互いの反省点を洗い出し、互いにとってより良い状態を模索した。
結果として、PLの生産性は元の状態に戻った。というよりも、以前よりも高い生産性となり、PLはこれまで以上の活躍を見せてくれるようになった。
そして同時に、私の「自分でやった方が早い病」が回復に向かうきっかけにもなった。
自分でやらないように克服したこと
「自分でやった方が早い病」は治せる病気。そして治った後に自分がやらない方が総合的な生産性が高いということに気づく。
優秀な技術者ほどこの病に罹りやすく、克服した後の成長が大きい。
PLとのトラブルをきっかけに、私は自分の本来の役割を改めて考え直すことにした。
PMは本来何をすべきなのか。なぜPMが部下の作業を奪ってはいけないのか。PMに関する書籍を読み漁り、経験豊富な先輩社員に相談し、私は本来PMが取るべき立場や実施すべき業務内容を再認識していった。
そして、それをプロジェクト内で実践することに注力した。
私がこの時に学んだテクニックで、特に効果があった対策は以下の3つである。
体制図上、直属の部下にのみ作業指示を出すようにした。
私はPLとのトラブルをきっかけに、体制図上、直属の部下にのみ指示を出すように心がけた。
これは、メンバーとのコミュニケーションを避けるという意味ではない。（メンバーとのコミュニケーションもPMの重要な業務である）
作業指示や業務上の相談を、意識して直属のリーダーとのみ行うようにしたのだ。
これにより、PMはPLに対して、部下を含めたチーム全体の作業を依頼しているという構図を作ることができ、PLの責任感も高まり、PL自身が自分の責任範囲を誤解することがなくなった。
開発品質の目標を、自分の100点満点ではなくチームの100点満点を基準に考えるようにした。
プロジェクトやタスクの目標を設定する際、自分が達成できる100点ではなく、チームが達成できる100点の目標を意識して設定するようにした。
チームが達成できる100点は、時に自分にとっては80点になることもある。しかし、チーム全員が自分ではない以上、チームで達成できる点数は自分にとっての100点にはなり得ない。
チーム全体の能力を把握し、自分のチームが達成できる100点は、たとえそれが自分にとっての80点であろうとも、そこがこのチームの100点だと考えるようになった。
これは、自分にとっての100点を目指さなくなったという意味ではない。PMとして与えられた期限、人員、予算を考慮した結果、80点しか達成できないと判断した場合、100点を達成するためにどうすればよいか、顧客に対する期待値の調整に重点を置くようにしたということだ。
PMに与えられるリソース（人員、予算）は有限である。しかし、リソースを増やすことなく、期待値の調整をうまく行うことで、自分にとっての80点でも顧客に満足してもらえる状況を作り出すことは可能である。
※期待値コントロールや落とし所の考え方については以下でさえずっているので参考にしてほしい
技術調査や開発に使うアプリケーションやツールをPCからアンインストールした。
私が「自分でやった方が早い病」を克服した後も、しばらくの間、メンバーから私に作業を期待されることが続いた。
「バードブレインさんが自分でやった方が早いですよ」
「バードブレインさんなら自分で調査した方が理解できますよ」
などと言われた。
これは確かに事実ではあるが、「自分でやらないこと」を徹底していた私は、この作業に手を出すわけにはいかなかった。
しかし、以前は自分で作業していた私に対して、メンバーは「なぜ急にやらなくなったのか。自分たちが作業して報告する方が手間がかかるのではないか」と考えていた。
私はこの状況を打開するため、自分のPCにインストールされている開発用アプリケーションや技術調査用ツールをすべてアンインストールすることにした。
そして、私はメンバーに対して「私のPCには調査や開発のための機能がインストールされていない。だから、あなたたちにお願いした方が効率が良いのだ」と説明するようにした。
これは非常に効果的だった。私自身の「自分でやった方が早い病」を抑制しながら、メンバーに対して私が作業しないことへの納得材料を提供することができたのだ。
手段があるからこそ自分で作業してしまうものである。
自分で作業しないようにするためには、作業環境ごと排除することが非常に効果的な手段となり得る。
まとめ
以上が、私が「自分がやった方が早い病」を患い、克服してきた経験である。
「自分でやった方が早い病」は、技術者として成功体験が多い人ほど罹患しやすい病だ。技術者がPMに転向する際、ほぼ例外なく経験すると言っても過言ではない。
しかし、「自分でやった方が早い病」は必ず克服できる。そして、この病を克服した時こそ、あなたは真に優秀なPMになっているだろう。
私はそうだった。
私が「自分でやった方が早い病」を克服した時、本当の意味でのPMキャリアが始まったことを実感したものである。
