先日、以下のサイトを紹介されました。
世間からマネジメントスキルは求められる
私が就職活動していると、職務経歴書の中の記載をみて、Project Management業務の紹介を提案をしてくる方が良くいらっしゃいます。私はR＆Dだし、システムアーキテクトが専門でやってきたつもりなのですが、経歴ではそう見えないらしい。
昨今の世間では、マネジメントスキルのあるエンジニアさんが不足しているとのことです。
前職では、Project Managementという職種は、私とは別のPM部門に専門の方が居ましたので、私自信は正式なProject Managementは行っていませんでした。
しかし、ソフトウェア開発の現場においては、ソフトウェア知識の無いPMさんは役に立ちません。予算も日程も、進捗の管理も立てることはできないのです。担当者が作成した予算や日程や計画内容の妥当性も判断できません。
PM部門の新人さんが役に立たなかったので、問い詰めてみた
以前、プロジェクトに新しく入ったPMの方に、日程が遅延した場合にどのようにアクションをするつもりですか？と尋ねたことがあります。
PMの方は自信をもった声で「担当者を呼び出して、対策を立てるように伝えます。」と答えていらっしゃいました。×
私たちの進めようとしているプロジェクトは、そんな悠長なことはしている暇がありません。
彼女はソフトウェアの開発現場経験が多いと言っていたのですが、本当なのでしょうか？
もちろん、状況に応じて「テーラリング」をする必要があることも把握していませんでしたから、「私のやりかたは間違っていない」の一点張りでした。困ったものです。
プロジェクトを円滑に進めるとは？
日程が遅延しそうな問題が発生していることを事前にピックアップして、問題が発生しないように事前に対策を立てる必要があります。
対策を立てるように伝えるだけじゃだめなのです。
計画の段階で、計画が妥当であるのか、進め方にリスクが無いのかを事前に確認する必要があります。
リスクが担当ではどうにもならない場合には、事前に社内や顧客やプロジェクト全体への根回しが必要です。
そもそも担当の知識や経験の不足だったりが要因となる可能性もあります。
そして、遅延の可能性が高くなってくれば、予算の追加、メンバーの追加、業務タスクの見直し等行う必要があります。
そういうのがプロジェクトマネジメントなのでは無いでしょうか？
結果、そのプロジェクトでは、新しく入ったPMの方は、ソフトウェア開発領域には一切関わらないようにしていただきました。炎上確実なので、顧客との対話も避けてもらうようにしました。すみません。
PMの新人さんがやろうとしていた「まねじめんと」は一体何だったのでしょう？
「まねじめんと」できる
結局、「まねじめんと」って何なんでしょう。
Project Managerという肩書で、プロジェクトに参入したことがあればPMやったことになりますか？
課長という肩書があれば「まねじめんと」したことになりますか？
肩書なんて、どうでも良いです。別に課長という役職でなくても、課長以上に課長の仕事しても良いのです。グループのメンバーに業務を適切に配分し、問題があれば相談に乗り、問題点を解決する助言をしてあげたり、メンバー間の業務調整をしたり、タスクの配分を調整したり、メンバーがスキルアップするための手助けをしてあげたりという業務をしっかりして、外部のグループや部門との調整等を行っていれば、もう十分マネジメント業務です。あとの勤怠管理とかは課長に押し付けておいてください、特にスキル不要なんで。ついでに課長の空いた工数は、業務押し付けておいてください、もったいないので。
もし、皆さんが、今後に転職活動をする機会があるのであれば、肩書なんで気にせずに、今までやってきたマネジメント業務の経験を語りましょう。
複数のメンバーでソフトウェア開発をする現場では、マネジメント業務は絶対に必要なはずなのです。
マネジメントができるメンバーが揃っている大規模プロジェクトは成功する
私は、運よくプロジェクト全体のソフトウェアをマネジメントする仕事をかなりさせてもらいましたが、大規模なソフトウェア開発においてマネジメントというのは単独では不可能です。
私のプロジェクトの中には、機能ソフトウェアをマネジメントしてくれた多くの優秀なメンバーが居ました。大規模なソフトウェア開発においては、マネジメント業務を一人でできるはずがありません。
プロジェクトのメンバーである彼らがしっかりと自分が担当するソフトウェアのマネジメントを行ってくれたので、プロジェクト全体が成立してきたのです。一つの製品の中の機能数が数十と存在し、それぞれの機能要件が数十ページにも及ぶ製品を開発してきました。全体のコード数が100万行を超えるプロジェクトを一年間で成立させようとするならば、各機能、各ソフトウェアをしっかりマネジメントできるメンバーが揃っていることが、とても重要です。
私のプロジェクトでは、組込みソフトウェアというハードウェア制約の厳しいプロジェクトであったため「ウォーターフォールプロセス」を基本として、「スパイラル」「テスト駆動型」「イテレーション」「FDD」「リーン」という適応型プロジェクト手法の考え方をたくさん取り込んだ開発の進め方をしてきました。
2021年に発行されたPMBOKガイド第7版に記載されている内容は、我々かなり前から、取り組めていたのです。私のプロジェクトメンバー達は、もっと自信をもって良いと思う。
プロジェクトを進める上で、確実に成功に近づけるための工夫の仕方を共有できたメンバーが揃っていたのです。直近のプロジェクトでは、各ソフトウェアをしっかりマネジメントできる優秀なメンバーがプロジェクトに揃っていたので、超楽できましたｗ本当にありがたいことです。
もし、そういうメンバーが居ないのであれば、育ってもらえば良いのです。それもプロジェクトマネジメントですね。
マネジメントできるメンバーを育てよう
マネジメント業務というのは、仕事を円滑になんとか達成することができる業務です。その手段を日頃からたくさん考えると、エンジニアだってマネジメントしている状況になるのです。
- 他部門や外部のエンジニアと関わる経験を増やす。
- メンバーの下に多くのエンジニアを配属する。
- 自分だけで問題解決しようとせずに、他社と相談しながら業務すすめるようにフォローする。
- 正しい「なぜなぜ」分析等をすることで、どのようにマネジメントしていれば問題が発生しなくて済んだのかを考える機会を増やす。
マネジメントの基礎知識
一応、使えないPMさんを論破するためには、PMBOKの内容は理解しておいた方が良いですよ。
AutomotiveSPICEは理解しておきましょう。他の業界のエンジニアとの差別化できるので、これも強味になります。特定の業界では、通常のPMさんよりも、間違いなく需要があります。
頑張ってください。
