若者のPM離れ

ＰＭになりたくない症候群 ＠ ベテランIT営業が教える「正しいITの使い方、営業の使い方」

プロジェクトマネージャになりたくない若者というのが、入社2年か3年目ぐらいの人たちのことを言っているのか、プロジェクトマネージャとしての仕事を任せられるようになる30中ごろの中堅エンジニアのことを指しているのか分かりませんが、前者であれば実際にPMをやっている中堅エンジニアの苦労話を飲み屋ででも聞いて自分はそうなりたくないな、と思ってるかもしれませんし、中堅エンジニアが言ってるのであれば実際に経験した結果、もうあんなに見合わない仕事はしたくないと思ってるのかもしれません。

何れにせよPMと言う仕事が見合わないと感じることはあったりします。

PMの仕事が見合わない理由

まず、PMというのが何をするかと調べてみると、IPAのプロジェクトマネージャ試験の概要ページ にこんな風に書かれていたりします。

1. 対象者像 
高度IT人材として確立した専門分野をもち、システム開発プロジェクトの責任者として、プロジェクト計画を立案し、必要となる要員や資源を確保し、計画した予算、納期、品質の達成について責任をもってプロジェクトを管理・運営する者
   
2. 役割と業務 
情報システム又は組込みシステムのシステム開発プロジェクトの責任者として、当該プロジェクトを計画、実行、管理する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。 
 
(1) 必要に応じて個別システム化構想・計画の策定を支援し、策定された個別システム化構想・計画に基づいて、当該プロジェクトの実行計画をプロジェクト計画として立案する。
 
(2) 必要となる要員や資源を確保し、プロジェクト体制を確立する。
 
(3) 予算、工程、品質などを管理し、プロジェクトを円滑に運営する。進捗状況を把握し、問題や将来見込まれる課題を早期に把握・認識し、適切な対策・対応を実施することによって、プロジェクトの目標を達成する。
 
(4) プロジェクトの上位者及び関係者に、適宜、プロジェクトの実行計画、進捗状況、課題と対応策などを報告し、支援・協力を得て、プロジェクトを円滑に運営する。
 
(5) プロジェクトの工程の区切り及び全体の終了時、又は必要に応じて適宜、プロジェクトの計画と実績を分析・評価し、プロジェクトのその後の運営に反映するとともに、ほかのプロジェクトの参考に資する。

責任と言う言葉が重く響いたりもしますが、これだけのことを自分が全てコントロール可能だとしたらやりがいがあり、楽しい仕事のはずです。

もちろん、何でもかんでもやっていいというわけでもなく、上位決定者とネゴを取ったり実行方針に関する合意を取るなど面倒な仕事もあったりもします。

しかし、それでも基本方針の合意が取れれば後は自分のプロジェクトとして実行管理ができるはず・・・。

が、実際のプロジェクトとプロジェクトマネージャの仕事はそうでもなかったりする部分もあります。

このプロジェクトマネージャやってて楽しくないと思うのは、下記のようなプロジェクト。

・ 決定権がまるで無いプロジェクト

・ 責任だけを取る役割

・ 適材適所に要員を配置できない

・ お客さんとの窓口だけを押し付けられる

・ ワーカー兼務

結局、そんなプロジェクトばっかりやってたらプロマネの仕事を嫌うのもさもありなん、って思ったりします。

それをうまくやるのもプロジェクトマネージャの仕事と言う人もいるかもしれませんが、理想と現実のギャップが激しすぎて毛嫌いする人も多いのではないかと思ったり。

これはそのプロジェクトの規模によったりもしますが、「君、プロジェクトマネージャね」と言われても実質やることはプロジェクトの管理だけでなく、設計や構築の実業務までをこなすようなことになり、プロジェクトマネージャと言う言葉と役割だけが一人歩きするケースもあったりしています。

あいつプロマネにしようぜ計画

（個人的にどうでもよいことと思ってますが）35歳プログラマー定年説みたいなのがあって、じゃあ君もプロマネの仕事ぐらい出来るようにならなければならないよ、ってな具合に役割を振られだしたりもします。

それまでプロマネをやって人は、一つ上の立場から指示を出すようにもなるんですが、それによって指示系統が著しく冗長で複雑になっている気もします。

プロジェクトの体制図を見ると、プロジェクトマネージャの上にはプロジェクトオーナーがいて、プロジェクトマネージャが出す方針について最終合意を得て支援や協力を得られるはずですが、そういう一つ上の立場の人が間に入ってあれこれ指示を出したりもして、プロジェクトマネージャの決定権や裁量権を奪っていったりもします。

結局プロジェクトマネージャに与えられる仕事は、その責任を取ることで上と下の板ばさみにあったりし、とても見合わない仕事と認識されたりするのではないかなと。

「プロマネとして一人前ではないから」という気持ちはわからなくも無いですが、十分な教育を受けることも無く役割だけが与えられて、何も出来ない状態でプロマネの役割だけをこなしていく羽目になれば、何も楽しいと思わないのではないでしょうか。

これは、体育会系の「先輩からやられたから後輩にもそうする」みたいなことを歴史的に繰り返していってるだけのような気もするわけです。
なので、プロジェクトマネージャには責任だけが残り、やりがいや楽しさを見つけられる要因が無いのではとも思ったり。

本当にプロジェクトが自分でコントロールできれば否応なしにやりがいや楽しさって見つかる気はするんですがね・・・。

関連記事

エンジニアを育てるということへのジレンマ

5年目のエンジニアと話してアドバイスしたこと

規模の大きなプロジェクト運営で気をつけたいこと

プログラマがプログラミング以外にしていること

何でも屋であることの強みと危うさ

システム屋が非システム屋と話すときに留意すること

社内エンジニアのプログラマー定年説

非効率な3年間だからこそ学べたこと

社内とネット上とで随分と変わってくる「優秀なエンジニア」の定義

管理職エンジニアが伸び悩む理由

システム保守・運用エンジニアの迷走

業務をアウトソーシングした後の社員は何をするの ＠ ナレッジ！？情報共有・・・永遠の課題への挑戦

こういう話はどこの会社にでもあるもんなんだな。

システム保守・運用を行う現場の人間は、ITコストの増大によってお荷物のような目で見られたりします。

そして、アウトソーシングやオフショアを活用してそのコストを低減させようと目論むわけですが、何でもかんでもそう簡単に成功するわけでも当然ありませんよね。

人的コストが安かったり、自社に人員がいなかったり、いたとしても自社でやるメリットが無かったりで外注すると言う結果になり、その外注をうまくコントロールできるだけでよいのであれば事足りでしょうけど、実際のそのシステムの保守や運用の要員を自社にとってどれほど重要な存在なのかを見極めないと、そのすっぽり抜けた穴を埋めることが出来ずにトラブルが起き、返ってコストが増大するだけでなく自社のサービスにも大きな影響が出ることにもなりかねないのではと思ったりします。

武器の使い方を知らずして武器を持つ矛盾

こういうことが進むと、一つは技術を知らずして技術をコントロールする矛盾を強いられることになるのかなと感じたりします。

ITは企業にとって不可欠になっていますから、それを排除することはできません。

その運用や保守をアウトソーシングしたとしても、誰がやるにせよコントロールしていく必要があり、それは自社としてしなくてはならないことになります。

その時に、例え元システム部門の人だったとしても遠く現場から離れたような状況になれば、それを上手くコントロールすることは出来るのかが疑問だったりします。

武器（技術）の存在は知っていてもそれの使い方がよくわからないわけです。

その武器をまともに扱えるとも思えませんし、その持ち味を十分に発揮できるとも考えられません。

「もう少しコスト抑えてできないの？」「それをやるメリットは？」「それをやっても他には影響ないんだよね？」ぐらいの言葉を使いこなして上手くコントロールが出来れば誰も苦労はしません。

外注業者をコントロールすることが高度な仕事のように思われている節もあったりしますが、実際は主導権を相手に握られているだけで、「はい。じゃあそれで」と相手の言いなりになっていたりするケースもあります。

武器を持ってない相手に武器の説明をされてもよく理解できないのは当たり前で、鈍らの剣を高額で売りつけられることにもなりかねません。

また、例えそのコントロール上手くいったとしても保守・運用するシステムがレガシー化していき、ゆくゆくは大きなコストを犠牲にしなければならなくなってもくるでしょう。

作れるエンジニアだけでは重宝されない時代

レガシーなシステムでも何でも作れればエンジニアは重宝されると言うのは一昔前までのことだったりもします。

アウトソーシングをする企業や人件費で優位に立つオフショア開発などと比べても自分たちがやることの優位性をアピールできなくてはならなくなっています。

武器の使い方を知っていたとしてもその武器が弱ければ武器にもなりません。

システム部門であっても、今のシステムを保守・運用すれば良いやという考えでは他の代替案によって淘汰されることもあるでしょう。

単に要求したものをシステム実装すると言うだけでなく、自ら企画したり提案したりその要求の理解力が求められたりします。

単にその企画力や理解力があったとしても、自分自身あまり武器にはならない気もします。

餅は餅屋と言うことわざがあるように、システム開発や運用も専門家に任せた方がよいでしょう。

ただ、自らを餅屋と言い切れるだけの専門性を持ってないといけないのは自明です。

話が少しそれますが、最近のクラウドなどの流行を見ていると、プラットフォームを作るエンジニアとそのプラットフォーム上でアプリを作るエンジニアと言うものに二極化されている気がします。

Googleなんかを始め、プラットフォームを提供する企業やサービスと言うものは乱立してきていますから、自社に中途半端なプラットフォームを築くことはコスト面であまりメリットが持てません。

それが、自社のサービス基盤の根本となるプラットフォームであれば別でしょうけど、そうでない場合はそのプラットフォームとそれを支えるエンジニアを自社においておくメリットがあまり見つからないでしょう。

そんなプラットフォームを作る技術や要員は他を当てにして、その上で動くアプリを構築するエンジニアに特化させていくと言うのであれば、アウトソーシングやオフショアに関しても意味あるものになるのではないかと思ったりします。

必要な技術を持つエンジニアだけに特化させ、自社で抱え込む必要の無いエンジニアについては外注をうまく使ってそのプラットフォームを上手く自社に構築する。

この問題は保守・運用の体制でも言えることですが、数年おきに歴史を繰り返すことになるんではないかな、と思ったりします。

アウトソーシングして、トラブルが起きるとやっぱり自社に優秀なエンジニアを抱え込んでないとダメだという流れになり、また数年後にコストがかかりすぎるからアウトソーシングしろみたいな。

時代の変化に応じてエンジニアのあるべき姿も大きく変わっていってるんだなということを痛感します。

関連記事

エンジニアを育てるということへのジレンマ

5年目のエンジニアと話してアドバイスしたこと

プログラミングが出来る人になるための熱意

運用の中で崩壊していくシステム

若者のPM離れ

社内の情報共有スタイルが変わらない理由

不安定な環境だからこそ身に付けられる技術ってあると思うよ

自分の単価を知らないことで生まれる弊害

社内とネット上とで随分と変わってくる「優秀なエンジニア」の定義

管理職エンジニアが伸び悩む理由

教育のレール

誰かに何かを教えるにあたっては、ゴールに向けたシナリオを作っていた方がやりやすいことが多々あります。

教科書なんて典型的な例で、1年で覚えるべき知識を詰め込んだカリキュラムを作って教えていくわけですよね。

ビジネスの現場においてはそんなマニュアルなんて存在しないので、特定の仕事をするために覚える知識を一つずつ先輩などから教わっていくわけです。

でも、そのシナリオってかなり教わる側の自己都合的なものになっていないかなって思ったりします。

教育のレールを引く人

教える側から見れば一刻も早く現場で一人前に仕事して欲しいとか思うので、とりあえず必要な知識を詰め込んでいったりします。

素直な新人であれば、はいはいとそれをこなしていくわけですけど、それってその仕事をこなすための知識でしかなかったりします。

なので、教育が終ってみると教えた幾つかのシナリオどおりしか対応できなかったり。

シナリオ外のことをやらせると途端に何も出来なかったり「そんなの教わっていない」と言われることもあったり。

でも、これってその引いたレールから外れられることを教える側が嫌っていたりもするわけです。

教育っていうのは未来の投資であって、それ自体で何か利益が生まれるわけでもなかったりします。

なので、教える側から見ればそれ自体はなるべく早く済ませてしまって、自分自体が楽になりたいと思ってたりもします。

なのでそのシナリオも自分が思い描く答えの方に導こうとレールを敷設します。

教わる側が迷っていたらヒントの一つも出すもんですが、その答えも結局そのレールから外れないようにするものだったり。

外れられると時間が大きく取られることにもなるので、なるべく最短経路で進むようにシナリオを組み立てようとします。

新人なんかもよくわからない状態ならそのレールを歩いていくことが近道と考えますし、何よりも上からの指示なのでとりあえずそれに従うような形になってしまいます。

これによって教わる側は考えることを止めてそのレールを一歩ずつ歩いていくことに専念しだしますし、自分で冒険したくともそのレールに結局は戻されてしまったりもします。

そして、何時しかそこで生じた疑問も忘れて、シナリオに沿った知識だけが刷り込まれていったりします。

教育のレールの感じ方

教わる側から見ればそんなレール引きやがってって構えたりもするんですが、実際そのレールを歩いていくのは自分だったりもするわけです。

外れることを疎まれるかもしれませんが、そのレールを歩いていこうと決めているのも自分。

なので、結局レール自身を作っているのは教わる側だったりもするのかなと思います。

ただ、このレールと言うのは教育の現場においては当たり前にあったりするので、レールはあるものと割り切ることも大事なのかと思ったりします。

それよりも、今どのあたりを歩いていて、そのレールの先には何があるのか、って考えた方がよいのではと。

その先に得るものがあれば歩いていけばよいですし、得るものがないのであれば、即座に脱線してしまえばよい。

道しるべがないと路頭に迷いますから、実際はレールに沿った方がよっぽど楽なんですがね。

ただ、多くの場合は目の前の仕事とか短い距離でのレールなので、それが自分の思い描く未来につながっていることは少ないでしょう。

レールに沿って歩くことになれてしまうと、それが終わりに達したときにその先どう進めばよいのかがわからなくなったりもします。

何時でもそのシナリオを外れられると言う未来の計算も必要なのではと感じるわけです。

複数のレール、複数のゴール

教育の現場から見ればそういったシナリオを予め決めて、その中を歩かせていくことの方が効率的です。

しかし、それは教える側のエゴであったりもするもので、あれこれやられると面倒だからその中を歩かせているというのもあったりします。

だから、レールから外れようとすると強制的に戻そうとする力を加えたりする。

実際ゴールと言うのはあるにしても、それは教育課程でのゴールであって、そこに達したからその人が一人前に仕事が出来るようになるってわけでもありません。

なので、レールと言うのを無理に引かずに間逆や真横に進まないようにぐらいを監視して、方向性だけ導いていく方がよっぽど有効な教育になるのではないかと思ったりします。

問題は、それを教える側が我慢できるかってただ一点に尽きるような気がします。

そこに多大なコストを払うことになるのは目に見えていますので。

ただ、教育が未来への投資であれば短期的な視点だけでなく、長期的な視点と言うものの方がメリットは大きいでしょう。

実際、即戦力を育て上げようと短期集中で教育し、とりあえず仕事は出来るようになるものの、後々マニュアル人間ばかりで見たいな愚痴もよく聞きます。

でもそれって、そういう人を育て上げるためのレールでしかないのだと感じるわけです。

関連記事

エンジニアを育てるということへのジレンマ

5年目のエンジニアと話してアドバイスしたこと

「考える」ために作る7つの環境

仕事をダラダラしないための考え方

若者のPM離れ

目標至上主義ってどうにかならんもんだろうか

何が無いかを知るという強み

勘違いする社員、その傾向と対策

サボってる人って意外と優秀かもよって話し

残業しなくなってから考えるようになった3つのこと