モード変更


    言語

俺のピープルマネジメントはピープルマネジメントじゃなかった

2025/12/15

この記事は、 開発生産性コミュニティD-Plus🐬 Advent Calendar 2025 15日目の記事です。 14日目の記事は、あれ?いない???

D-Plusには、 今年5月に大阪で Engineering managerのタスク管理 という発表で登壇させていただきました。 この1回しか参加していないのですが、温かみのあるコミュニティだったので、家事育児と折り合いがついたら、また参加したいなと思っています。

はじめに

先日、モンスターラボでミドルマネージャー向けの研修を受けてきました。 研修の中で、自分のピープルマネジメントの経験を振り返る機会があったのですが、そこで衝撃的な気づきがありました。

自分がピープルマネジメントのつもりでやっていたことが、実はパフォーマンスマネジメントだったということです。

この記事では、その気づきと研修で学んだことを共有したいと思います。

モンスターラボのマネジメント4領域

テック界隈でマネジメントというと、広木大地さんの「4つのP」が有名です。エンジニアリングマネージャーの活動領域を、ピープル・プロジェクト・プロダクト・プラットフォーム(テクノロジー)の4つに整理したフレームワークですね。

モンスターラボでは、エンジニアリングに限らずマネージャーの役割を4つの領域に分けて定義しています。

  1. ピープルマネジメント - メンバーの成長を支援する
  2. パフォーマンスマネジメント - 成果・生産性を管理する
  3. ストラテジーマネジメント - 戦略を立案・実行する
  4. フィロソフィーマネジメント - 組織の文化・価値観を浸透させる

(余談ですが、ストラテジーだけ言い換えられたら、こっちも4つのPになるのに...と思ったりしました。Portfolio Managementとかどうだろうか?)

これまでの自分のピープルマネジメント(だと思っていたもの)

エンジニアリングマネージャーとして、自分なりにメンバーと向き合ってきたつもりでした。

  • 1on1を定期的に実施
  • 案件の状況をヒアリング
  • 案件の課題を確認して、解決策を一緒に考える
  • メンバーをぼっちにしないことを意識

以前、人と組織の"エン"を結ぶ - 受託開発EMの価値創出と潜在力の引き出しという発表でも、エンゲージメント・エンパワーメント・エンカレッジメントという3つの「エン」を意識したチームマネジメントについて話しました。メンバーの潜在能力を引き出したり、不安を解消して勇気づけたり、それなりにピープルマネジメントできているつもりでいました。

でも、研修を通じて振り返ってみると、 自分が向き合っていたのはメンバーではなく、メンバーの「仕事」だった ことに気づきました。

チームメンバーの案件の状況や課題にフォーカスしていたので、結果的に生産性やパフォーマンスを上げることに注力していたのです。つまり、 パフォーマンスマネジメントをしていた というわけです。

研修で学んだ本当のピープルマネジメント

ピープルマネジメントとは、 メンバーの成長を支援すること です。そのためには、メンバーの Will(やりたいこと)・Can(できること)・Must(やるべきこと) を理解することが重要です。

Will Can Mustの図

研修では、一緒に参加した別チームのマネージャーがメンバー役のWill・Can・Mustを見事に引き出していました。その方はブランディングデザインに強い人だったのですが、確かにブランディングって、強み・弱みなどを引き出してまとめていく手法です。 そういうスキルがピープルマネジメントにも活きるのかと、なるほどと思いました。

ちゃんとメンバーと向き合い、Will・Can・Mustを引き出し、明確にすることで、メンバーの成長を支援できるのだと学びました。 と、同時に私はあまりメンバーの内面に踏み込むのが苦手なんだなということにも気づきました。

研修後に、思わずブランディングデザインに関する書籍を購入していました。

何かヒントを得て、ピープルマネジメントについて、「苦手でやれていない」から「苦手だけどある程度できる」ぐらいのレベルまで引き上げたいなと思っています。

まとめ

というわけで、マネージャーとしてピープルマネジメントに力を注いでいたと思っていたら、実は生産性 ≒ パフォーマンスに力を向けていた話でした。

もちろん、パフォーマンスマネジメントも大事な仕事です。でも、メンバーの成長を支援するという視点が欠けていたことに気づけたのは大きな収穫でした。

また、研修の中で、別のマネージャーは、自分がマネージャーとして完璧でなくても、他のマネージャーの力を借りてメンバーの力を引き出せれば良いという趣旨の経験談を話してくれました。 ちょうど、自分のピープルマネジメントの課題に気づいたタイミングだったので、とても励みになりました。

これからは、1on1の中でもメンバー自身のWill・Can・Mustにもっとフォーカスして、本当の意味でのピープルマネジメントを実践していきたいと思います。

最後に

こんなまだまだ未熟なEMですが、モンスターラボでは一緒に成長していける仲間を集しています。

特に、社内で↓のような新チーム立ち上げの取り組みをしています。

AI時代の新しいエンジニアの形 - モンスターラボにおけるフルサイクルエンジニアとは

「Turn Vision into Reality」 の精神で、一緒にフルサイクルエンジニアを目指す仲間を募集しているので、ご興味ある方はぜひご応募ください。

株式会社モンスターラボ の求人|FullCycleエンジニア

careermanagement

Author

Kiyotaka Kunihira

Kiyotaka Kunihira

バックエンド/テックリード/スクラムマスター/エンジニアリングマネージャー

新卒でスマートフォン向け乙女ゲーム開発をしつつAWS, Scalaに触れ Scala忍者に。その後、スタートアップを2社経験して、2019年にモンスターラボに入社。 大阪オフィスに所属している2児の父。 去年、認定スクラムマスター資格取得しました。 最近は、エンジニアリングマネージャーとして中間管理職しています。

その他おすすめ記事

2026/04/30

CSS:@property を書くとカスタムプロパティの継承値が変わる

CSS のコンテナクエリを @property と組み合わせたときに予想外の挙動に出会い、原因を追ううちに「CSS のプロパティ値処理」の仕様にたどり着きました。本記事では、その仕様を踏まえて @property 有無で挙動が変わる理由を解説し、学んだ知識で他の CSS 挙動(line-height や width の % 解釈)も読み解いていきます。 前提: @property・コンテナクエリ・cqi まず状況を説明する上で前提となる、@property・コンテナクエリ・cqi の 3 つについて簡単...

Tatsunori Zenko

Tatsunori Zenko

Frontend

2026/04/21

複数案件の経験から得た Java / Spring Boot バージョンアップ実践ガイド

筆者はこれまで複数の案件で Java / Spring Boot のバージョンアップを担当してきました。Java 11 → 17 → 21、Spring Boot 2.x → 3.x → 3.4 と段階的にアップグレードしてきた中で、繰り返し遭遇する問題や、事前に知っておけばスムーズに進められるポイントが見えてきました。 本記事では、それらの経験を案件横断的に整理し、Spring Boot のバージョンアップに取り組むエンジニアの参考になる実践ガイドとしてまとめます。 対象読者 Java / Sprin...

Noboru Mitsuishi

Noboru Mitsuishi

Architecture

サービス開発実績会社情報
採用情報インサイトお問い合わせ
© 2022 Monstarlab
情報セキュリティ基本方針個人情報の取り扱いについて個人情報保護方針