現在PG（プログラマー）やSE（システムエンジニア）として働いていて、今後PM（プロジェクトマネージャー）を目指したいという方は多いかと思います。PGもSEもPMも同じ開発現場にいますが、それぞれ役割が異なります。
PGとSEは割と重複する業務も多いのですが、PMに関しては設計やコーディングよりもむしろマネジメント業務が重要です。そこでこのページでは、PMに必要なスキルについて解説します。また私自身SIerでPG、SE、PMを経験しているため、実際に現場で必要なスキルの違いを体感しました。
プロジェクトマネージャーの役割
スキルの前にPMの役割について説明しておきます。PMはプロジェクトに責任を持つ立場で、管理する役割を持っています。具体的な作業内容としては以下のようになります。
- プロジェクトの進捗管理
- PG、SEのスケジュール管理
- PG、SEとの話し合いなど
- クライアントとの打ち合わせ（要件定義など）
以上がPMの主な役割になります。成果物とメンバーの両方に対して責任があり、管理責任、監督責任があります。ただしこれはあくまでも定義上の役割なので、基本設計を行うケースは割と多く、場合によっては詳細設計、コーディングを担当することもあるでしょう。
プロジェクトマネージャーに求められるスキル
PMの業務は幅広いので、細分化していくと多くのスキルが必要になるかもしれません。たとえばひとことにマネジメントスキルと言っても、コミュニケーションスキル、資料作成スキル、メンバー育成スキル、などいろいろです。またコミュニケーションスキルに関しても、業務伝達とメンバー間の人間関係構築のためのコミュニケーションでは異なります。
細分化しすぎるとかえってわかりにくかと思うので、ある程度まとめて挙げていくことにします。そうすると、PMに必要なスキルは以下に集約されるでしょう。
- コミュニケーションスキル
- 書類作成スキル
- ITスキル
三つ目はプログラミングスキルではなくあえてITスキルと書いていますが、これには理由があります。詳しくは後ほど説明します。
コミュニケーションスキル
コミュニケーションスキルと言ってもいろいろありますが、PMに求められるコミュニケーションスキルは以下です。
- 正確に情報伝達するためのロジカルなコミュニケーションスキル
- メンバーと人間関係を構築するためのコミュニケーションスキル
正確に情報伝達するためのコミュニケーションスキル
まずPMはプロジェクト全体を管理すると同時に、クライアントとプロジェクトメンバーの橋渡し役も担う必要があります。プロジェクト内での一般的な開発フローを簡易化すると以下のようになります。
要件定義 → 基本設計 → 詳細設計 → プログラミング → テスト
PMがどこまでやるかはケースバイケースですが、少なくとも要件定義は中心になって行うことが多いです。要件定義に参加していないプロジェクトメンバーもいるため、仕様や役割を明確に伝えなければなりません。
仮にPMの情報伝達が正確でないと、設計やプログラミングの工程でどんどんクライアントの意向とずれていってしまうことになります。またプロジェクトメンバーも曖昧で不安を抱えたまま作業することになるでしょう。
システムの仕様は基本的に細かいです。またメンバー間でクラスやメソッドを使いまわすような設計にすることも多く、その辺をきちんと伝えておかないと手戻りが多くなります。手戻りが多くなるとみんなが混乱し、結果的にバグにもつながります。
スムーズに開発を進めるためには、PMがクライアント、メンバーに正確かつわかりやすく情報伝達を行うことが必須なのです。またクライアントの意向で仕様や設計が変わることも多々あるので、そのたびにきちんとメンバーに伝える必要があります。
そしてメンバーが解釈を誤って設計やソースコードが予定と違ってしまった場合、それはPMの責任です。
メンバーと人間関係を構築するためのコミュニケーションスキル
次に、PMはプロジェクトの中でもっとも積極的にメンバーとコミュニケーションを取る必要があります。理由としては、PMとメンバーが打ち解けていないと業務に支障が出るからです。たとえばPMに質問したくてもしずらい、なかなか話しかけられない、といったことがあるとプロジェクトにブレーキがかかります。
そのためPMはランチを一緒に取る、普段から雑談するようにする、などしてメンバーとある程度距離を縮めておいた方が良いでしょう。とはいえ特別な会話が必要なわけではなく、普通にコミュニケーションを取って打ち解けておけば問題ありません。
書類作成スキル
PMにとって書類作成は重要かつ割合としても多くの比重を占める業務です。まずプロジェクトの管理やスケジュールは書類（紙に印刷するとは限りませんが）で作成する必要があります。また上で正確な情報伝達が重要と説明しましたが、当然重要な情報は口頭だけで伝えるわけではありません。
メールやその他ツールで書類を作成する必要があり、それをクライアントやメンバーと共有することになります。PMの作った書類ベースにプロジェクトが進むと言っても過言ではなく、PMの作った書類がわかりにくいとクライアントもメンバーも混乱します。
PMはよくエクセルエンジニアと揶揄されますが、そのくらいにエクセルやその他のツールで文章や図を作成していることが多いでしょう。またプロジェクトの進行のためだけでなく、たとえばトラブル発生時などもPMが書類を作って報告する必要があります。
ITスキル
最後にITスキルです。なぜプログラミングではないのかというと、PMが直接プログラミングを行う機会は少ないからです。しかしソースコードを含め、仕様や設計を理解している必要があります。
PMはクライアントと開発メンバーの橋渡しになることも多いため、PMが開発内容を理解していないとよくわからないまま伝達することになります。当然バグや手戻りの原因となるでしょう。またPMはプロジェクト全体に責任を持っているため、設計書やソースコードも当然その対象です。
設計書やプログラムはPGやSEが作ることが多いですが、その責任はPMにあります。品質を担保する必要があるので、きちんと設計書やソースコードのレビューを行い、理解しなければならないでしょう。
プログラミングを突き詰める必要はありませんが、少なくとも設計書やソースコードのレビューをした際に、読んでわかることが最低限の条件です。またPMが開発メンバーのサポートをできた方が良いので、プログラミングスキルを含め、設計やツールの活用などITスキルに長けていた方が良いです。
SEからPMになった際の注意点
PMの多くはSEを経験しているはずです。SEから出世してPMになるイメージです。そのため、ほとんどのPMは現場の開発に必要なプログラミングや設計のスキルは持ち合わせているはずです。
技術力的に、PGやSEより上であるケースも多いでしょう。また本人の意志ではなく会社の意向で急にPMになるケースも多いため、SEの気分のままプロジェクトに参加してしまうのです。そして、マネジメントよりも自分で作ることに専念してしまうようなこともあります。
PMのメイン業務はマネジメントなので、マネジメントを疎かにして自分で開発してはいけません。いくらPMが開発を頑張っても、マネジメント不足でメンバーがうまく機能しないと結果的に開発スピードは落ちてしまうでしょう。
技術力はPGやSEのサポートに活かす方向で、PGやSEの力を最大限引き伸ばすのが得策です。ちょっとしたことなら自分でやった方が早いということで自分で片づけてしまうPMも多いのですが、それを繰り返すと結果的にPGやSEが成長しにくくなってしまいます。
そのため代わりに仕事をやりすぎず、PGやSEが成長できるようサポートしていくと良いです。
