Contents
プロジェクトリーダー乗っ取り作戦
PL(上司)抜きでもプロジェクトをまわせるのでは？
そう気づいたやまさんはプロジェクトリーダーを出し抜く作戦を実行する前に実験してみることにしました。
乗っ取るのはシステムAのPLという立場ですね。
プロジェクトの体制を図解すると、こんな感じ。
乗っ取り作戦の実験ということで、システムBのPLとの定例会議の共有をやめてみます。
システムAのPLは存在しないように扱う感じですね。
前回は忘れただけでした。
ですが、今回からは意図的に報告しないようにします。
ぶっちゃけ、怒られそうな気がしてました。
「定例会議の内容を報告しないってどういうつもりなの？」ってつめられる気がしてたんですよね。
普通のPLは怒ると思います。
プロジェクトで発生してる問題とか今後の方針とかの情報が分からないわけですからね。
まあ怒るなら、定例報告会議、出席してよって話ですが…^^;
結果、どうなったかというと…。
何もおこりませんでした…
内容の共有をやめても、音沙汰なし。
定時にPLは帰っていきました。
本当にあの人、興味ないんだな。
プロジェクトの成功とかどうでもよくって、
ラクに仕事できて、
えらい人から評価されて
給料たくさんもらう
それであったら後はどうでもいいと思ってるだろうな。
そういう一面が見え隠れしてたんですよね。
上から評価されて給料たくさんもらうのも、しっかり仕事してる人だったらいいと思うんですよ。
しっかり仕事で結果を残してプロジェクトの成功に貢献しているなら何も言いません。
ですが、てきとーに仕事してるだけなのに評価と給料を持っていかれるのは納得いかなくないですか？
少なくとも、ボクはモヤモヤします。
モヤモヤしまくります。
ぶっちゃけモチベーションが下がりまくります。
なので、しっかりだしぬくことにしました(笑)
乗っ取り作戦の実験も成功しましたしね。
ここから当時のボクは本格的に乗っ取り作戦を実行にうつすことにします。
乗っ取り成功！ PLの立場としてプロジェクトを進める
乗っ取り作戦の実験も成功ということで本格的に作戦を実行していくことしたやまさん。
システムBのPLとの定例報告の共有をやめても、ウチのPLは何も言いませんでしたからね^^
定例報告以外のプロジェクトリーダーとしての作業はこんな感じです。
- システムAの中で解決すべき問題の分析、関連チームへの指示
- プロジェクトの全体の進捗状況の把握
- 品質状況と要員（コスト）の管理
- PMへの報告資料作成、報告内容（カンペ）の作成
- お客さんとの調整作業
- etc…
これらの作業をすべて自分でやることにしました。
というか、もともと自分でやってたのでたいして作業量は変わりません^^;
むしろ、PLの報告とかPM報告用のカンペ作りの作業とかをしなくていいので全体として軽くなりました。
ただ、さすがに乗っ取り作戦を本格的に実行してからはPLからの抵抗はありました。
PMへの報告のときですね。
早く報告資料みせてとか、報告内容(カンペ)はどうなってるんだ、とか。
えらい人からの評価をとても気にする人なので、正直、プレッシャーが半端なかったです(苦笑)
で、抵抗されてどうしたかと言うと…
全部ムシしました←
というのも、ボクは乗っ取り作戦の前からチームリーダーと実質的なPLの作業を兼任していました。
なので、とても忙しかったんですよ。
ほとんど自分のデスクにいません。
さらにいうと、今回の出来事はコロナのかなり前でしたが、ボクの職場は当時からフリーアドレスっぽい感じの働き方を採用していました。
いちお自分の席はあるんですけどね。
在宅ワークでも仕事ができるように仮想PCのような環境がすでにあったんですよ。
なので、システムBのPLの近く席から仮想PCへ接続して仕事していました。
実際、PLとしての仕事をするにはそちらの方がはかどるというメリットがありましたしね。
正直なところ、乗っ取り作戦前からPLからのプレッシャーがかかることは想定済。
結果、PLはメールやチャットでプレッシャーをかけてくるだけなので全部ムシできたわけです。
で、PMへの報告会議当日を迎えます。
では次に例のプロジェクトの報告頼む。まずはシステムAの進捗はどうだ？
えらい人から催促されます。
ここでどうなるかなーって思ってたんですが、PLはボクに話を振ってきます。
「最近まで、私(PL)は有給をいただいていたので本日はやまさんから報告させていただきます」
たしかこんな感じで話を振られたと思います。
いや、普通に出社して定時に帰宅してたやんけ！(何してたか知らんけど)って思った覚えがあるのでたぶんあってます(笑)
で、普通にボクはPMに作業状況を報告します。
まあもともと報告内容はボクが考えていたので、報告できるのは当たり前なんですけどね。
ただ、当時、PMへの報告を直接やるのは初めてでした。
なので、めちゃくちゃ緊張したんですよ^^;
すごい噛みまくりでしたし、たどたどしかったと思います。
プレゼン形式で話をするのは内容も大切ですが、場数のような慣れも必要ですからね。
当時のボクには圧倒的に経験が足りなかったわけですよ。
でもまあ、聞いてる側も分からないことはなかったようです。
プレゼンというか、話し方はちょっと慣れてない雰囲気が出てるけど内容としては問題ないみたいな感じですね。
PMから質問も飛んできますが、回答できます。
本当のPLよりプロジェクトの実態を知ってますからこれも答えられるのは当たり前^^;
最終的にPMへの報告も無事終わり、会議自体も終了します。
そこでボクは確信します。
これいけるわ。
PL無しでもうまくいける。
むしろ、作業がスムーズに進むからプロジェクト全体としてもいい方法に向かっている。
PMとか、えらい人からも何も言われなかったし乗っ取り作戦は結果は成功って言っていいよね。
こんな確信がありました。
正直、PMからいろいろ言われて問題になるかなって思ってたんですよ。
やっぱり、上の人とは見えてる範囲も経験も違うので。
ですが、蓋を開けてみれば心配していたのがウソのようにうまくいったんですよね。
ちなみにPM報告会議の後、PLに呼び出されました。
この後、ちょっと来なさい、みたいな感じですね。
ここでPLはお叱りというか、いろいろボクをつめたかったんでしょう。
ですが、別の打合せがあるので後日お願いしますとか言って、ボクは逃亡しました(笑)
だって、PLと話をしても何も進みませんからね。
無駄な作業はカットです。
プロジェクトリーダーとメンバー作業の兼任で忙殺される
乗っ取り作戦は成功。
本格的にシステムAのPLという立場をやまさんが乗っ取りプロジェクトを進めます。
その後もPM報告会議はありましたが、しばらくしてもともとPLをやっていた人は出席しなくなりました。
毎回、ボクにしゃべらせて自分は何もしてない状態をえらい人に見せるのはマズいと思ったんでしょうね。
正直、ボクとしてはPLからの抵抗はもっと大きくなると思ってました。
それでいいのか？とも感じましたが、ボクとしてはラクになったのでほっておきました。
プロジェクトに集中ですね^^
ちなみに、メンバーとして仕事してくれているエンジニアさんたちも横やりを入れられることがなくなったので余計な作業は増えなくてうれしい、と言ってくれました。
実は乗っ取りが成功しても、メンバーとして参加してくれているエンジニアさんから反発があるんじゃないかって心配だったんですよ。
当時ボクは入社4年目ぐらいの若造です。
一方、メンバーのエンジニアさんは全員先輩。
10年選手のエンジニアさんもいました。
なので、当時若造だったやまさんがPLとしていろんな人に指示を出すことに反発する人もいるんじゃないかって思ってたんですよね。
ですが、いらない心配でした。
というか、PLだった人がアレすぎたのもあって、まとまることができた感じありましたね。
共通の敵がいることによってチームワークが生まれるとかそんな感じの空気に近かったと思います。
ということで、乗っ取り作戦が成功しボトルネックになっていたPL抜きでプロジェクトを進行できるようになりました。
で、すべてがうまくいきましたーってなればいいんですけどね…
そう簡単にはいきませんでした。
何が問題だったのか…
単純にボクの仕事量がやばくなりました。
たしかにPL向けの無駄な作業はなくなりましたよ。
ですが、ボクがPLとしての作業とチームリーダーとしての作業、両方やらないといけない状態に変わりはなかったんですよね。
まあ、当たり前なんですが…
実質的にPLが完全にいなくなってボクがチームリーダーとプロジェクトリーダーの仕事を兼任してるだけですからね。
ただ、乗っ取り作戦が成功しても、成功しなくてもこの兼任の状況に変化はなかったはずなので乗っ取り作戦はやって正解というは間違いなかったでしょう。
ということで、かなり仕事をしました。
当時のやまさんの仕事の仕方は次のような感じです。
- 日中帯はPLとしての仕事をしてプロジェクトを全体をまわすような作業
- 定時後からチームリーダーとしての作業
2人分の仕事を1人でやってるのと変わりません。
なので、少しずつ限界が近づいてきます。
作業効率化施策！！ 最強の効率化は「作業をやらない」だった
乗っ取り作戦は成功しPL向けの無駄な作業はなくなったものの、結局2人分働かないといけない状況は変わりません。
無駄な作業量が減ったとは言いつつも、ボクは次のような毎日を送っていました。
- 平日は終電帰りがデフォルト
- 金曜日など次の日が休みの日は徹夜で作業
- 土日はかろうじて休めていたけど疲れ切って寝るだけ
身体的にも、精神的にも限界がきます。
特にプロジェクト後半、試験工程に入ると忙しさが増していきました。
発生するバグ対応などの問題解決で時間を取られていたんですよね。
このままではマズい…
どうにかしないと自分がつぶれる…
なんとかして効率的に作業を進めないと…
そうしてボクは効率的に作業を進めるための対策を考えます。
考え抜いた結果、ボクが出した結論は…
うん、全部の作業をこなすのはムリだな！
考えてみてください。
エンジニア歴4年目の若手と中堅の間みたいなエンジニアが1人で2人分の作業をできると思います？
できて1.5人分ぐらいではないでしょうか。
さらにいうと、2人分の仕事の内、片方は初めて担当するプロジェクトリーダーとしての仕事。
正直、ムリゲーでした。
ジリ貧でした。
どうしようもありませんでした。
ということで、PLとチームリーダーとしての全ての作業を自分でやることはやめました。
そもそもにムリがあったんですよね。
これに気付いたボクは重要な作業に集中することにしました。
自分しかできない作業に集中することにしたってことですね。
例えば、これまでシステムAの中で発生したすべてのバグについて原因分析から対処まで考えていたんですが、これをやめました。
分析と対処方法をチームメンバーに考えてもらって、それを報告してもらい判断だけやることにしたんですよね。
分析と対処方法を考えるのはPLの立場として働いているボクじゃなくてもできます。
ただ、実際、どういう対処方法をとるのか判断する部分はPLとして仕事をしている自分しかできない(PLがやるべき)ので、そこに集中しました。
他にもPM報告向けに資料を作ったりしてましたが、これもやめました。
といっても、何かしら報告はしないといけません^^;
考えた結果、システムBとの定例会議で使っていた資料をそのまま流用することにしました。
こんな感じで自分じゃなくてもできる作業は人に任せる、簡略化できる作業は簡略化するといった感じで作業そのものを減らすようにしたんですよね。
このような考え方をエッセンシャル思考と呼びます。
重要なことに集中してそれ以外に力を入れることをやめる考え方ですね。
もちろん最初は不安もありましたよ。
ですが、ふたを開けてみれば意外とうまくいったんですよね。
むしろ、ボク自身が注力すべき作業の精度やスピードが上がったことで全体としての品質が上がったんですよ。
今思えばなんですが、実はこれってよくあることなんですよね。
重要なことを見極めてそこに集中することができれば、全体としてはむしろ良くなることって結構あります。
特に忙しいと、猛烈に作業をこなすことに目が行きがち。
ですが、ポイントはそこではありません。
全体をうまくまわすために大切な部分に集中する。
これがポイントなんですよね。
忙しくはありましたが、エッセンシャル思考を活用してなんとかボクの仕事はまわるようになりました。
さらにいろんな問題も発生しましたが、チームメンバーであるベテランエンジニアさんの力も借りつつ、プロジェクトも無事終わりをむかえます。
無事にリリース！！ それと後日談
「PLからの仕事の丸投げ」からの「PL乗っ取り作戦」、そして「やまさん自身のパンク」などいろいろありましたが、なんとかしてプロジェクトは完遂することができたんですよね。
で、ここからはえらい人(PM)から、後日、聞いた話です。
実はPMもPLが報告会議に出てこなくなったころから「何かおかしいな」と感じていたようです。
で、いろいろ探ってみた結果、ボクがPLを乗っ取っていることに気づいていたみたいなんですよね。
普通、乗っ取り作戦はえらい人にバレた時点で怒られます。
客観的に見ると、メンバーの暴走ですからね^^;
ですが、今回のPM、少し様子を見ることにしてくれたそうです。
プロジェクト自体はうまくいっていたということもありますが、やまさん個人の成長も考えてくれたようでした。
さらに、プロジェクトに参加するメンバーが「やまさん頑張ってるよ」みたいな話をしているのをPMが耳にしたことも大きいかったようですね。
めちゃいいPMです！
ただ、最後までうまくいくのは予想外だったみたい…^^;
特にPLとチームリーダーとしての仕事の両方をこなすのはムリだと思っていたようですね。
どこかでギブアップが出るのを予想していたけど、なかなかギブアップ来ないなーって思っていたそうな。
それでいいのか？って思ったりもしましたが、広い心で任せてくれた当時のPMには今でもとても感謝しています。
そして、うれしいことにこのプロジェクトをきっかけに「やまさんという若手がなかなかスジがいいらしい」という話が広まったみたいなんですよ^^
元々、注目されていたプロジェクトでもありましたしね。
そしてこれ以降、ボクはプロジェクトリーダーとして仕事をさせてもらえるようになりました。
まとめ：ここぞというときに頼りになるのは技術力だけじゃない
いかがでしたでしょうか。
2つの記事にわたってボクが最短最速でプロジェクトリーダーになれたきっかけの話をしてみました^^
一般的にエンジニアという業界で注目されるのは最新のIT技術やプログラミングなどのITスキルがほとんどです。
ですが、実際の現場ではIT以外の知識が役に立つことも多いんですよね。
むしろ、プロジェクトの危機的状況を回避したり発生した問題を解決するのはIT以外のスキルであることが多いんですよ。
さらに言うと、こういった”IT以外のスキル”を身に着けて現場で使えば会社(えらい人)から評価を得やすいです。
今回の話で言うと、やまさんもエッセンシャル思考という”IT以外のスキル”を使っていろんな人から評価を得ることができました。
評価を得ると、どうなるかと言うと…昇格して給料があがったりするんですよね(笑)
お金のために仕事をするなんて…といった話もありますが、せっかく働くならたくさんもらえた方がうれしいのではないでしょうか。
ただ、一方でエンジニア業界では「ITの勉強しないエンジニアは失格」という空気感を感じるのも事実…
そのことについて、こちらの記事でまとめてみたので、気になる方はぜひ一度読んでみてくださいね。
それでは！
最後に（おまけ）
ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;
プログラミングなど、ITに関するスキルが壊滅的だったのです。
ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。
こう言うと、なかなかの怪しさですよね（苦笑）
ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。
ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^
プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。
めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。
そのためか、昔は
- エンジニアになったはいいものの、IT技術に関して興味を持てない…
- 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
- IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
- 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…
このような悩みを抱えていました。
おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。
ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…
というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。
このブログの中でも人気の記事なので、気になった方は一度見てみてください^^
最後まで読んでいただきありがとうございました！！
会社の偉い人から社内でも注目プロジェクトへチームリーダーとして参加をお願いされた若手時代のやまさん。
「やったー！」と思い参加してみたものの、プロジェクトのプロジェクトリーダー(PL)は仕事を丸投げ、放置するタイプの人でした…
チームリーダーとしての仕事と、丸投げされたPLとしての仕事でやまさんは疲弊する毎日を送ります。
とうとうプロジェクトも炎上しかけますが、あるとき「PL抜きで仕事してもまわるのでは？」
そう、当時のやまさんは勘づきました。
そして、小心者のやまさんはPL抜きでも本当にプロジェクトをまわせるのか実験を開始します。
前回までの詳しいお話が気になる方はこちらからどうぞ！