■ 1. 問題提起と記事の目的
- IT業界におけるプロジェクトマネージャー(PM)に技術力は必要かという議論が存在する
- PMには技術的判断力(技術リテラシー)が必要だが実装スキルとは異なる
- 現場ではPMに過度な業務範囲が求められる「ナンニデモPM」案件が存在する
- 本記事ではPMの役割定義、必要な技術力のレベル、ナンニデモPMの危険性、不適切な求人について建設プロジェクトの例えを用いて整理する
■ 2. ITプロジェクトと住宅建築の類似性
- ITシステム構築は家づくりのプロセスに例えることができる
- 住宅建築における役割分担:
- 施主(クライアント)は要望を出し対価を払う
- 設計(アーキテクト)は要望を構造的に可能な形に設計し設計責任を持つ
- 施工管理(PM)は予算・工期・品質を管理し現場調整を行う
- 職人(エンジニア)は設計図に基づき実際に家を形にする
- 各役割が明確に分かれているのが本来の姿である
■ 3. ケーススタディ:メンバー欠員時の対応の違い
- 住宅建築で大工が1名欠員になった場合の施工管理の対応:
- 追加要員(職人)の手配
- 工程の組み替え(優先順位変更・段取り替え)
- 必要に応じて施主に事情説明し納期調整
- 施工管理が自ら大工作業を代行することはまず無い
- IT業界でアプリエンジニアが1名欠員になった場合:
- 本来は追加要員調整・影響範囲見極め・スコープ優先順位納期交渉を行うべき
- しかし実際はPMがエンジニアを兼務して穴埋めすることが多発する
- PMが自らコーディングしてカバーすることが美徳として語られる
- 一度発生すると常態化し最終的に全部盛り何でも屋さんPM(ナンニデモPM)が誕生する
- ナンニデモPMの状態:
- 本来の管理業務を捨て設計(アーキテクト)や構築(エンジニア)の穴をPMが自らの技術力と稼働時間で埋め続ける
- 若手のOJTまで背負い込みPMのリソースが完全にパンクする末期的状態
■ 4. PMの正しい役割定義
- IPA(情報処理技術者試験のシラバス)によるPM人物像:
- プロジェクトマネージャはレベル4(高度)で実装ではなくプロジェクトを成立させるためのマネジメントを扱う
- 立ち上げ段階では目的・成功条件・体制・制約の定義を行う
- 計画段階ではスコープ・スケジュール・コスト・品質・リスク・調達・コミュニケーション・ステークホルダーを扱う
- 実行監視段階では進捗把握・課題変更管理・意思決定・合意形成・是正を行う
- 終結段階では受入れ・引き継ぎ・振り返り(ナレッジ化)を実施する
- PMが設計実装に深く入りすぎると論文試験の評価が落ちる
- PMBOK(第8版)によるPM人物像:
- プロジェクトマネジメントの標準知識体系を広い文脈で整理している
- 価値提供(Value Delivery)を重視する
- 状況に応じたテーラリング(Tailor)を行う
- 予測型もアジャイルも含めた複数のやり方の取捨選択を行う
- PMCDフレームワークでPMの専門性を知識(ITSS相当)・実行力(成果を出す能力)・パーソナル(リーダーシップ倫理)の3次元で定義している
- 実作業の代行は明記されていない
■ 5. PMに求められる技術力の定義
- 判断できる技術力の要素:
- 専門家や技術者の発言を理解できる(共通言語の理解)
- トレードオフを比較できる(コスト期間品質リスク拡張性など)
- 赤信号を検知できる(やってはいけないことがわかる)
- 質問ができる(何を誰に聞けば不確かさが減るかプロジェクトが前に進むかがわかる)
- 意思決定の前提条件を揃えられる(論点選択肢根拠影響範囲)
- PMが必ずしも持つ必要がないもの:
- 特定言語の実装力(Javaで高速に書ける等)
- 特定クラウドの深い構築スキル(AWSの各種サービスの設計運用を一人で回せる等)
- 特定プロダクト特定領域の属人的な運用ノウハウ(細かなチューニングや手順の暗黙知までを一人で抱える等)
- PMが目指すべきは「スペシャリスト」ではなく「指揮官」のような立ち位置である
■ 6. 判断できる技術力の具体的目安
- IPAのITSS Level3(応用情報)の守備範囲が判断できる技術力のベースとなる
- 応用情報の範囲はテクノロジだけでなくマネジメントストラテジまで含むためPMが判断するための最低限の共通言語共通理解になる
- テクノロジ系基礎理論コンピュータシステム分野:
- アーキテクチャ概念・仮想化クラウド・OSSの基本を理解する
- アーキテクト提案の実現可能性・コスト運用負荷・拡張性をトレードオフ評価できる
- テクノロジ系技術要素分野:
- セキュリティ・データベース・ネットワークを理解する
- インシデント時の初動判断・変更時のリスク特定・非機能(性能可用性)議論の前提を揃える
- テクノロジ系開発技術分野:
- 要件定義からテストの流れ・品質・DevOps・CI/CDを理解する
- 予測型アジャイルの向き不向き・品質確保の打ち手・リリース設計(ゲート自動化)の判断ができる
- マネジメント系プロジェクトマネジメント分野:
- 工程・コスト・品質・リスク・資源・調達・変更管理を理解する
- 気合ではなく数値と根拠で意思決定できる(見積りバッファクリティカルパスリスク対応)
- マネジメント系サービスマネジメント監査分野:
- 運用設計・ITILの考え方・監査内部統制の観点を理解する
- 作って終わりにしないためSLA運用負荷保守体制を踏まえて意思決定できる
- ストラテジ系システム戦略企画分野:
- 目的・ROI・要求の優先順位・調達の考え方を理解する
- やる理由とやらない理由を整理し投資として説明できる(優先順位スコープ調整ができる)
- ストラテジ系企業活動法務分野:
- 契約・個人情報・知財・下請取引・コンプラを理解する
- 契約リスク・情報漏えいリスク・体制責任分界の事故りやすい点を早期に潰せる
■ 7. ナンニデモPMが危険な理由
- PMがPMできなくなることがシンプルな危険性である
- 全部盛りPMが発生しやすい要因:
- そもそもアーキテクトテックリード不在(または役割が曖昧)
- 人手不足で追加要員がすぐ手配できない
- 予算制約が強く「できる人がやるしかない」状態になる
- 兼務の前提でスケジュールが組まれている(最初から無理)
- 技術課題が表面化して火消しが常態化している
- 変更管理が弱く後半に仕様追加が雪だるま式に増える
- ベンダ委託先の責任分界が曖昧で結局PMが吸収する
- ドキュメント標準化が弱く属人化して引き継げない
- 管理が事務作業と誤解され軽視される
- PMが実装側に寄った場合の弊害:
- ステークホルダー調整が遅れる(意思決定が詰まる)
- 進捗の見える化が遅れる(気づいたら手遅れ)
- リスクの早期潰しができない(後半で大爆発)
- 品質ゲートが機能しない(テストレビューが薄くなる)
- メンバーのモチベーションが低下する可能性がある(全部PMで良くなり自分達の存在意義が不明になる)
- 結果としてQCDが落ち炎上しやすくなる
- 炎上すると社内外のエグゼクティブ層の関与が増え更に報告が増える(悪循環)
- 最終的にデスマーチと化する
■ 8. 小規模案件における兼務の妥当性
- 小さい規模の仕事なら1人が複数ロールを兼ねるのは自然である
- 住宅で言えばDIYでありITでも同様である
- 兼務が妥当なケース:
- チーム内の業務効率化の小ツール(ローコードスクリプト)
- 小規模なRPA自動化(定型作業の削減)
- 既存SaaSの設定変更や軽微な連携(影響範囲が限定的)
- PoC(失敗前提で学びが目的でスコープが小さい)
- 高いレベルの品質や厳格なスケジュールを求めない案件
- このレベルならそもそもPMは不要でありリーダー担当者くらいの呼び方で充分である
- DIYレベルなら兼務は問題ないが本当にDIYレベルに限られる
■ 9. 不適切なPM求人の特徴
- 求人票でPM募集と書かれているのに内容はPM兼テックリード兼アーキテクト兼エンジニアのような案件が存在する
- 求めていることを全て書くこと自体は悪くないが役割名がズレていることが問題である
- ナンニデモPMの求人例の特徴:
- 仕事内容にQCD管理・交渉折衝に加えてアーキテクチャ策定・クラウド基盤構築・チューニング・バグ修正・コードレビュー・技術指導が含まれる
- 必須スキルにPMの資格経験に加えてクラウド構築経験5年以上・開発経験5年以上・IaC実装経験・大規模DB設計運用経験・育成経験が要求される
- 求める人物像に「自分が最後の砦である自負」「スピード感を持って自ら手を動かして解決できる」「様々な難問に立ち向かい自分事で成し遂げる」が記載される
- マネジメントのプロと実装のプロを両方求めている状態は両方をプロレベルで同時進行できる人が市場にほぼ存在せず数千万円の年収が必要である
- 「他人に頼らず自分の稼働時間で問題を力技解決しろ」というのはマネジメントの否定でありプロジェクトだけでなくメンバーの心身も危険にさらす
- 健全なPM求人の特徴:
- 仕事内容はQCD管理・変更管理・期待値調整合意形成・技術的リスクの早期検知と意思決定・WBS策定進捗管理・課題解決に向けたリソース再配置・収益利益率管理と予算コントロールに限定される
- 必須スキルはプロジェクト管理手法の体系的理解と実践経験・高度専門資格保持・大規模プロジェクト完遂経験・技術的課題をビジネス的リスクやコストに翻訳できる能力・複雑な利害関係を紐解き着地点を見出すファシリテーション能力・技術の専門家を信頼し適切に仕事を任せるデリゲーションスキルが記載される
- 求める人物像は「個人の技術力ではなくチームの成果を最大化することに喜びを感じる」「不確実な状況下でも冷静に情報を収集し論理的な意思決定を下せる」「技術者への敬意を持ちつつ客観的な視点でプロジェクトの健全性を評価できる」が記載される
- PMに求められるのは自分が手を動かして解決する力よりもチームが解決できる状態をつくる力である
- メンバーを信用し適切に任せ必要な情報と判断材料を揃え合意形成と障害除去を通じて前に進める
- プロジェクトは個人戦ではなくチーム戦として勝つためにPMは自分でやるよりもチームでやるを選ぶべきである
- 「自ら手を動かして解決できる方」という表現はPMの人物像としてミスマッチを生みやすい
- 自ら手を動かすことが必要な場面はあるがそこを前面に出すほどPMが本来担うべきマネジメント(QCDリスク合意形成)が後回しになり結果としてプロジェクトが不健全になる
■ 10. まとめ
- PMに技術力は必要である
- PMに必要な技術力は実装できる力ではなく判断できるための技術力である
- 目安としてIPAレベル3(応用情報)相当の知識を持つことは有効でわかりやすい指標である
- 役割が全部盛りになるとPMがPMできずプロジェクトが壊れやすい
- 兼務が必要なケースはあるがその場合は役割名と期待値を揃えた方がよい(少なくともPMだけでは違和感がある)