こんにちは、チャイフ(@chaif123)です。
世の中には、プロジェクトマネージャーという職種が存在します。
しかし、従事していない人から見ると、業務内容が抽象的でいまいち大変さが理解されていないような気がしています。
そこで、2年以上プロジェクトマネージャーを続ける僕が、経験から得られた教訓を備忘録としてまとめていきます。これを読んで、プロジェクトマネージャーの大変さを理解してくれる人が1人でも増えることを願っています。会社に身バレする可能性はなくはないけど、まぁ大丈夫やろ()
今回は、「技術なしにPMが務まるか？」についてです。
それでは！
Contents
プロジェクトマネージャーとは？
プロジェクトマネージャーとはどんな仕事でしょうか？
細かい所掌範囲や定義は会社によって異なるとは思いますが、共通する要素としては、「納期までに成果物を完成させられるように、プロジェクトをマネジメント（≒管理）する」仕事ではないでしょうか。
そのために、例えばこんな業務が挙げられるでしょう。
- キックオフ
- クライアントの要望から計画の立案
- 全体スケジュールの作成
- 担当メンバーのアサイン
- プロジェクト推進
- マイルストーン管理
- 担当メンバーの進捗管理
- 担当メンバーのモチベーション管理
- プロジェクトのコスト管理
- クライアントへの進捗報告
- 問題発生時の対応
- クロージング
- 納期の調整
- 成果物の取りまとめ
- クライアントへの成果報告
プロジェクトに関わるあらゆることを調整するので、必然的にお客様（クライアント）、プロジェクトメンバー、下請け、社内の上司などあらゆる人とのコミュニケーションが発生します。したがって、情報をまとめる能力・的確に説明する能力・折衝能力・リスクを察知する力・決断力・問題解決力など、様々な適性が存在します。
技術なしにPMが務まるか？
今回のテーマは、「技術なしにPMが務まるか？」です。「プレーヤーに求められる技術を、マネージャーも有している必要があるか？」と言い換えてもよいです。
- Webサービス開発会社なら、PHP・CSS・Javascript・の知見をマネージャーが有している必要があるか。
- AI会社なら、Pythonや機械学習の知見をマネージャーが有している必要があるか。
- 製造業なら、設計や機械の知見をマネージャーが有している必要があるか。
難しいですね。答えは、半分YESで半分NOです。
- 基本的な用語は知っている：必要
- 基本的な用語の概要を説明できる：必要
- 技術的に踏み込んだ話ができる：不要
- 手を動かして実装することができる：不要
もちろん技術的に踏み込んだ話ができたり手を動かして実装することができるレベルで技術を有していると、メンバーとの会話もしやすいので便利ではあります。タスク依頼がしやすい・報告を理解しやすいなど、メリットは大きいです。
しかし、プロジェクトマネージャーを務める上でこのような高いレベルでの技術が必須かと言われると、それはNOかな、という感じです。
PMのミッションは何か？
ここで考えたいこととして、そもそもPMは何を求められているのでしょうか。PMのミッションはなんでしょうか。
PMのミッションは「お客様に迷惑をかけないこと」
PMのミッションは、「お客様に迷惑をかけないこと」と表現することができます。
どれだけトラブルが起ころうとも、真摯な対応を続けて最終的にお客様に迷惑をかけず、成果物に満足していただいて受注金額を支払っていただける結果になれば、プロジェクトとしては成功と言えます。
紆余曲折あるのは当然です。お手数をおかけすることはむしろ多いでしょう。それが問題なのではなく、最終的に着地すべきところに着地させることが、プロジェクトマネージャーの役割になります。
PMのミッションは「QCDを守ること」
もう少し具体的に落とし込むと、PMのミッションは「QCDを守ること」とも表現できます。
- Quality：品質。成果物の質の高さ。
- Cost：コスト。当初の見込みに対してメンバーの工数や経費をどれだけ抑えられたか。
- Delivery：納期。お客様の期待する期限までに成果物を納められたかどうか。
この3つを全て完璧にこなすのがベストではありますが、そうはいかないのがプロジェクトというものです。どれを重視すべきかはプロジェクトの性質・お客様との関係・会社の方針などによって様々です。もしかすると「年度末だけは納期厳守」かもしれません。
したがって、優先順位づけが重要になります。そのために、状況を把握していることと・決断力が求められます。
プロジェクトマネージャーのミッションとして、QCDを守ること、正確に言えば状況に応じてQCDの優先順位を意識し、プロジェクトをコントロールすることになります。
全ての技術やツールはそのミッションを達成するための手段に過ぎない
さて、PMのミッションを理解できたところで、「技術なしにPMが務まるか？」という問いを考えてみましょう。答えはYESです。
メンバー全員が把握できてて状況を説明できるならBacklogは不要
まず、わかりやすい例を挙げてみましょう。
Backlogというプロジェクト管理ツールがありますね。Redmineもほぼ同じものです。
- タスクチケットを作成
- タイトルと内容を記載
- 担当者・重要度・カテゴリー・期限・タスクの種類を付与
- 親タスクの下に子タスクをぶら下げて、依存関係を表現
- 未着手→進行中→処理済み→完了のようにステータスを設定
- etc.
プロジェクトを遂行する上で、Backlogは必須でしょうか？先程のミッションを達成できるなら、不要かもしれません。状況が全て頭に入っていて、プロジェクトメンバーとも情報を共有できているならば、不要かもしれません。
しかし、よほど小規模な（1人とか2人で完結するような）プロジェクトでもない限り、それは実際には不可能ですよね。だからこそ、一定以上の規模であれば、BacklogやRedmineなどのプロジェクト管理ツールを適切に運用することによって、トラブルの発生確率を下げ、QDCを高め、ミッションの達成確率をあげるのです。
適切なメンバーがいれば、技術は不要
さて、核心です。適切なメンバーがいるならば、プロジェクトマネージャーに技術は不要です。手を動かすのはあくまでもプレーヤーです。必要な知識は自ら補おうとするのではなく、人ごと連れてくればいいのです。（これについて別の記事にて）
場合によっては、プロジェクトマネージャーが自ら手を動かす機会もあるかもしれません。しかし何度も言いますが、プロジェクトマネージャーのミッションは「お客様に迷惑をかけないこと」です。目の前のタスクをこなすことではありません。
プロジェクトマネージャーに求められることの1つとして、「全体を見渡すこと」が挙げられます。
プロジェクトマネージャーが自ら手を動かしているとき、間違いなく「全体を見渡すこと」はできていないはずです。自らの手を動かさずにメンバーにタスクを投げ、リスクやスケジュールや成果物に目を向けることこそが、プロジェクトマネージャーがやるべきことです。
技術はあってもいいが、それをプレイしない勇気が必要
いかがでしたでしょうか。
5分や10分で終わることであれば、PMが自らプレイしても良いです。なぜなら、チケット作成してタスク内容をメンバーに伝える時間が無駄だからです。しかし、30分かかる作業ならどうでしょうか。1時間なら、3時間なら、2日なら、2週間なら？そんなことでずっとタスクに没頭していると、スケジュール管理がほったらかしになってしまいます。
プロジェクトマネージャーをやっていると、「自分でもできることを自分でやらずにメンバーに投げる」という勇気を求められることが必ず訪れます。
技術はあるに越したことはないですが、その技術を自らプレイしない勇気。全てはプロジェクトのため、「お客様に迷惑をかけない」ための最善の選択を模索しましょう。
それでは。
チャイフ
個人的な意見ですが、技術力が無くマネジメント能力のないPMはいらないです。
トラブルの元ですし、右から左に情報を唯渡すだけの人間なんてもっと要らないです。
当然ですが、一定の技術力が無ければメンバーとのコミュニケーションも出来ませんし、お客様の環境に設定を行う上での必要な情報もわかりません。そもそもメンバーが何を言ってるのかすら理解できない可能性もあります。
従いまして、一定の技術力は絶対必要です。
当然ですが、導入システムによっては踏み込んだ技術的な知見も必要になります。
貴重なコメントありがとうございます！
私もメンバーとのコミュニケーションができないといけないので、”一定の”技術力は必要という立場です！
具体的には「基本的な用語は知っている」「基本的な用語の概要を説明できる」までは必須と考えます！