こんにちは。倉内です。
エンジニア(特にSE)は、ある程度経験を積むとプロジェクトリーダー(PL)を任されるようになります。一概には言えませんが、新卒入社から3~5年くらいで経験する方が多いのではないでしょうか。
PLの仕事の多くは正解がなく(PMも含むマネジメントの仕事全般に言えますが)、プロジェクトの規模や難易度によって必要なスキルも異なります。
たとえば、小規模でメンバーが類似プロジェクトの経験者ばかりであれば、PLの負担は比較的軽いでしょう。一方、複数の協力会社が携わり、何百名ものメンバーがアサインされる大プロジェクトのPLはかなり大変です。
そのため実践で経験を積むしかない部分もありますが、「こういう気質や考え方をする人がPLに向いている」「こういうスキルを持っているとよさそう」といえる点もあります。
そこで今回は、若手エンジニアの皆さんと一緒に、PLに向いている人とはどんな人なのかを考えてみたいと思います。
プロジェクトリーダー(PL)について考える
一般的なリーダーの定義
PLの話をする前に、そもそもになりますが、リーダーというのはどんな役割を持つ人なのでしょうか?
「リーダー」とは、指導者や統率者、先導者という意味を持ち、チームの目標達成や課題解決に向けてメンバーを束ねていく人を指す。
(出典)HRpro「「リーダー」の意味や役割とは? 育成に役立つ必要なスキルやタイプと種類などを解説」
「チームの目標達成や課題解決」がいちメンバーとは異なる、大事な役割と言えそうです。
次に、ここではリーダーを大きく「カリスマタイプ」と「サーバントタイプ」の2つに分けて話したいと思います。
カリスマはイメージしやすいと思いますが、行動力や決断力があり、先頭に立ってメンバーをぐいぐい引っ張っていくタイプです。ワンマンすぎると誰も着いていかなくなってしまいますが、難しいプロジェクトや関係者が多い場合は頼もしいタイプでもあります。また、情に流されずフラットな判断ができる人も多い傾向にあるようです。
サーバントは、近年注目を集めている「奉仕型」と言われるタイプで、以下のように定義されています。
自分のリーダーとしての地位に関わらず他人を助け奉仕することから信頼を得ます。
信頼関係が構築しやすく、そこから部下やメンバーとの有益なコミュニケーションが生まれます。部下の話によく耳を傾けることも重視するため、会話は一方通行の説明や命令にはなりません。このことは、チームの一人ひとりがモチベーションを向上させることにもつながり、組織全体の士気も高まります。
(出典)ピポラボ「サーバントリーダーとは?近年注目を集める支援型リーダー」
リーダー像も時代とともに変化すると言われています。以前はリーダーに必須だと思われていた資質や考え方でも、現代には合わなくなり、新たに定義されることもあります。
以下は、少し古いアンケート調査(2019年)ですが、「求められるリーダー像は変化してきている」「これからのリーダーに求められる力」「以前は必要とされたがこれからは求められない力」などが興味深い内容になっているので、よければ参考にしてみてください。
PLの役割
次に、PLの役割についてお伝えします。
- PLはプロジェクトの実行責任を負う立場である
- 多くの場合自身にもタスクが割り振られているため、自分の作業の進捗はもちろん、プロジェクトメンバーの進捗を管理する必要がある
- メンバーとコミュニケーションをとってフォローしながら、計画されたスケジュールを守って納品物を完成させる
ときにメンバーとPMとの板挟みになったり、スケジュールを守らなければいけない VS 大変な思いをしている現場に無理を強いられない…と苦悩したりする場面もあるでしょう。
実行責任というのは、もう少し噛み砕くと「プロジェクトを成功に導く責任」というと分かりやすいかもしれません。
PLはリーダーなので大変な面はもちろんありますが、その分プロジェクトを無事成功させたときの達成感ややり甲斐は大きいと思います。
PLの具体的な仕事
もう少し具体的な仕事内容も挙げておきます。ただし、プロジェクトによって異なりますので一例としてごらんください。
- プロジェクト進行(進捗管理)
- システム要件定義
- 設計(おもに基本設計)
- システムの品質管理
- メンバーの労働環境や健康への配慮
- トラブル発生時の対処(対顧客ではなく現場)
ちなみに、PLとPMの違いが気になる方も多いのではないでしょうか。以下の記事で詳しく説明していますので、よければごらんください。
「PLに向いている人」5つの特徴
PLの役割や仕事内容が分かったところで、本題の「どんな人が向いているのか」について考えていきます。
計画に従って着実に実行していくことが好き
PLのもっとも重要な役割は、スケジュールの遅延なくプロジェクトを進め、成果物を顧客に納める(もしくはリリースする)ことです。
途中仕様検討漏れや仕様変更があり、顧客と仕様を調整したりスケジュール・コスト(費用や人員)の見直しをしたりが必要になった場合は、おもにPMが対応することになりますが、決められた仕様とスケジュールに沿って滞りなく進めるのはPLの仕事です。
そのため行き当たりばったりの人よりは、計画性があって期日を見据えて仕事を進められる人が向いています。
問題発生時に適切にエスカレーションできる
過去に類似のプロジェクトの経験があったとしても、なかなかスムーズにいかないのがITプロジェクトです。新規プロジェクトであればなおさらです。
そのため現場で何か問題が発生し、PLだけで対処するのが難しいと判断した場合は、速やかにPMに報告する必要があります。
判断が遅いと問題が大きくなるケースがほとんどなので、「こういう問題が起こりそうで……」というレベルでも内容によっては伝えておいたほうがいいこともあるでしょう。
イレギュラーが起きるとパニックになってしまったり、隠そうとしてしまったり…そういうタイプの人よりは、報告・連絡・相談をためらわずおこなえる人のほうが向いています。
メンバーとの関係構築がスムーズにできる
「コミュニケーション能力がある」というと少し誤解がありそうなので、こういった表現にしました。
適切なエスカレーションにもつながりますが、進捗が遅れたり仕様検討漏れがあったりといった問題は、実際に手を動かしているメンバーが最初に気づきます。
信頼関係ができていないと、問題発生時にメンバーに報告してもらえず、取り戻せないような状況になってから発覚するなんてこともあり得ます。話しかけやすい、相談しやすい雰囲気づくりをしておけば、火種が小さいうちからキャッチすることができます。
PLにとって、メンバーとの関係構築やコミュニケーションは、プロジェクトを滞りなく進めるために思っている以上に大切なものです。
リーダーというと、いわゆるリーダーシップがあってメンバーを引っ張っていくタイプをイメージする人も多いかも知れませんが、こういったことを踏まえると、むしろITプロジェクトのリーダーには、さきほど説明した「サーバントタイプ」のほうが向いている側面もあります。
共感力が高く、メンバーを思いやれる
さきほどPLの仕事に「メンバーの労働環境や健康への配慮」を挙げました。
世の中には長時間労働や休日出勤などをまったくいとわず、常に元気でバリバリ仕事ができる人もいます。一方、体質や性格、体力などは人ぞれぞれで、休息を取ったりストレスの発散をしたりしないと仕事が難しくなる人もいます。
PLになる人が前者のようなタイプだと、メンバーにも悪気なく無理を強いることがあります。しかし、途中で人員が欠けてしまうとプロジェクトの進捗が遅れ、結果的にPLの役割である「プロジェクトの実行責任」がまっとうできなくなってしまいます。
プロジェクトはひとりだけが頑張っても遂行できません。それぞれの事情にできる限り耳を傾け、メンバーが安定して進捗を出せるような管理ができる人がPLには向いています。
また、若い世代はぐいぐいくる熱血タイプや、「失敗してもいいからとりあえずチャレンジしてみてよ!」といった無茶振りタイプ(責任は取ってくれるとしても)に拒否感があるため、時代に即した対応も必要になってきます。
しかし「思いやる」を通り越して「甘い」になってしまうと、プロジェクトを計画通りに進めるのが難しくなってしまいます。うまくバランスを取れるかもPLの力の見せどころです。
ある程度の技術的スキルがある
SIerのSEの場合、プロジェクトの規模にもよりますが、PLはコードを書かないケースもあります。
そのとき開発は協力会社の方にお願いすることになりますが、「ここは技術的な理由でこうするのが難しいから少し変えたい」といった相談が来た場合に「そう言われてもよく分からない……」と返してしまっては一気に信頼を失ってしまいます。
お恥ずかしながら、わたしは前職のSIerでそういった経験があり、情けない結果を招いてしまったことがあります。
上記の記事にもありますが、コードを書かないと言ってもある程度は技術的な話ができないといけないなと思います。そうしないと見積もりの精度も下がりますし、開発担当からの相談も理解できません。
これからPLを任されそうという方で、ほとんど開発工程に携わっていないのであれば、paizaラーニングのような学習サービスで身につけるというのも手です。ブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。
詳しくはこちら
(補足)PLやPMのキャリアパスが合わない場合
わたしは新卒でSEになったとき、情報系出身だったので新人研修の課題(Java)は問題なくこなせました。ただ、実務に入ってみると、複雑な業務システムで自分がコードを書くのは難しそうで、優秀な協力会社のエンジニアさんに任せたほうがずっと効率がよいと感じました。
こういう場合であれば、(向き不向きはいったん置いておいて)マネジメントのパスに乗ることは特に抵抗もないと思います。
一方、技術を追求していきたい人・プログラミングが好きな人は、エキスパートとしてのキャリアパスがないため、結局転職していく人も多かったように思います。
新卒のときは5年・10年先まで見据えて、自分がどんな会社に入るといいか考えるのは難しいかも知れませんが、情報公開(SNSやブログで)しているエンジニアも多い時代ですので、十分情報収集をしておけばそういったミスマッチはある程度避けられます。
もちろん、SIerでも千差万別ですし、研究開発の部署であれば、エキスパートのキャリアパスもあります。逆に自社開発でも年次を重ねるとプレイングマネジャーになったり、完全にマネジメントに回ることもないとは言えません。
エンジニアは転職が珍しい職業ではありません。現状に違和感があったり、我慢してまで続ける明確な理由がないのであれば、転職で自分のやりたいことを叶えるという選択肢もあります。
paiza転職は、ITエンジニア専門の転職サービスです。プログラミングスキルをはかる「スキルチェック」で取得したランクによって応募できる企業が変わってきます。
詳しくはこちら
また、第二新卒や若手の実務経験年数が少ない方に向けて、EN:TRYというサービスも提供しています。
詳しくはこちら
まとめ
「PLはどんな役割なのか?」を把握し、どんな人が向いているのかを考えてきました。
本文でも述べたとおり、ITプロジェクトにまったく同じものはありません。パッケージ導入でもお客様が違えば、違うことは多々あります。カスタマイズが入るとその違いはもっと大きくなります。
はじめてPLをやるときは戸惑いも多いかと思いますが、スムーズにこなせるようになるためには、実務で経験を積むことがもっともよい方法です。
ここで向いている人の特徴を見て「自分は向いていないな~」と思っても実際やってみると、やり甲斐や楽しさを見いだせることもあります。PLを任される機会があればぜひチャレンジしてみてください!
「paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。詳しくはこちらをごらんください。
そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
詳しくはこちら