マネージャーの役割と責任とは？
「2023 ITエンジニア本大賞」でベスト10に入った著書『エンジニアリングマネージャーのしごと』を上梓するなど、ITエンジニアのキャリアについてさまざまな情報発信を行っている株式会社アトラクタ吉羽龍太郎氏。
「プロジェクトマネージャー、プロダクトマネージャー、エンジニアリングマネージャー、そして単なる『マネージャー』など、IT業界にはマネージャーと名の付く職種が多い。若干の混乱が見られるため、それぞれに整理して紹介し、キャリアを考える上で役に立ててほしい」と語る。
まず、「プロジェクトマネージャー」とは何か。プロジェクトとは、PMBOK第7版にも記されているように、「プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期的な業務」であり、そのマネージャーは「母体組織に任命された人で、プロジェクト・チームを率いてプロジェクト目標を達成する責任を負う」とある。言い換えれば、「予め決められた期間の中で、事前に定めた目標を達成する責任を持つ」ということであり、必然的にプロジェクトが終われば任務が終わる。
一方、「プロダクトマネージャー」は、マーティ・ケーガン著『INSPIRED』によると、「可能性を評価し、何を作って顧客に届けるのかを判断することだ」と書かれている。及川卓也氏他著の『プロダクトマネジメントのすべて』では、「プロダクトマネージャーには2種類の仕事がある。プロダクトを育てることと、ステークホルダーをまとめプロダクトチームを率いることである」と表現されている。つまり「ステークホルダーの承認を得たうえでプロダクトに関係する意思決定に責任をもつ」役割ということになり、プロダクトが続く限り誰かがその任務につくことになるわけだ。
そして「エンジニアリングマネージャー」は、一般的には「エンジニアリング組織のマネージャー」ということになる。ただし、吉羽氏は「業務内容の定義は必ずしも統一されていない」という。ピープルマネジメントとテクノロジーマネジメントの両方を担うとされながらも、組織によっては後者をテックリードに分離し、ピープルマネジメントに特化するケースも見受けられる。いずれも共通してチームの方向付けやパフォーマンス向上に加えて、個々人のパフォーマンス向上や評価、さらに採用など、「持続可能なチーム作り」に責任を持つ。
また、よく見受けられる「単なるマネージャー」については、1910年代にフランスの経営学者であるアンリ・ファヨールも提唱しているように歴史は古く、1950年代にピーター・ドラッカーも著書の中で「投入した資源の総和よりも大きなものを生み出す生産体を創造する＝投資に対する利益の追求」「ただちに必要とされているものと遠い将来に必要とされるものを調和させていく＝優先順位をつける」と記しており、マネージャーの共通の仕事として「①目標を設定する」「②組織する」「③動機づけとコミュニケーションを図る」「④評価測定する」「⑤人材を開発する」の5つをあげている。
アンドリュー・グローブ著『High Output Management』では、マネージャーのアウトプット範囲は「自分の組織」だけでなく、「自分の影響力がおよぶ隣接諸組織」までおよぶとしており、マネージャー個人のアウトプットより重視される。特に他のチームに悪い影響を与えることは、アウトプットの総量を下げるため、避けなければならないものとされている。なお、吉羽氏は「ここでいうアウトプットは、単なる生産量だけではなく、『アウトカム＝成果やインパクト』の意味に近い」と補足した。
以上をまとめると、プロジェクトマネージャーは「プロジェクトの目標を達成する」、プロダクトマネージャーは「プロダクト開発を率いる」、エンジニアリングマネージャーは「ピープルマネジメントとテクノロジーマネジメント」、マネージャーは「投入資源よりも大きなものを生み出す組織を作る」が、それぞれの役割ということになる。
仕事を見直すことの重要性
これまで各種マネージャーについて整理してきたが、実際には「自分の仕事はどのマネージャーに該当するのか」「一般に言われていることと異なる」などと戸惑う人も多い。そこで、吉羽氏は次のようなジョブ・ディスクリプションを示し、「これは何の役割かと思うか」と質問した。
おそらくどのマネージャーの役割・責任が該当するのかの認識は、人によって異なるのではないか。同じ役割の名前でも組織ごとに責任や業務内容が異なったり、実体として複数の役割を担ったりすることも多い。吉羽氏は「名前はどうあれ仕事の責任範囲が曖昧で広い。これを一人ですべて担おうとすると大変なことになる」と問題意識を提示した。
そうした問題意識を持つようになったきっかけは、吉羽氏自身の体験にある。
かつてSIerの新規事業を担う開発部門に配属され、事業の拡大とともに人が増えてグループに分割し、吉羽氏は自然と10人ほどのチームについてエンジニアリングマネージャーとプロジェクトマネージャーを同時に担当することになった。優秀な人が多かったものの、吉羽氏はそもそもマネージャーとしての教育を受けておらず、新設の部署で決まったやり方もなかった。
その結果、障害報告で謝りにいく回数は増え、多数のシステムの夜間コールに入り、夜中に携帯電話が鳴る回数が増えた。事務作業が増え、労働時間は増えた一方で、コードを書く時間は減り、ストレスは増えた。いつも追い立てられている感があり、組織のミッションやビジョンは忘れがちになった。吉羽氏は当時を振り返り、「稼働率100％の消防車」と表した。
そして、対処法として、プロジェクトの選別、チケット管理ツールによる仕事量の可視化、Wikiを使ったノウハウの再利用、品質基準の定義、アジャイル型への変換、兼任を減らすなどをあげた。他にも障害が多い箇所を予防的に改善したり、夜間に動かすバッチ処理を最小限にしたり……ということを数年間行っていた。
このときの学びとして、吉羽氏は「エンジニアリングマネージャーとプロジェクトマネージャーを同時にやるのは無理」と語る。片方で問題が起こると、もう片方にも波及する。この時、ステークホルダーや顧客からの不満や非難を避けるためにプロジェクトのデリバリーを優先し、チームに無理をさせてしまう。吉羽氏は「改善したければ、まず仕事を減らし、問題が起きにくい仕掛けやプロセスを作る必要がある」と語る。
