こんにちは！フロントエンド開発部でマネージャーをしている澁谷(@shibe23)です。
すみっコぐらしグッズで一番好きなのはニフレル限定のすみっコぐらしとニフレルのいきものたちです。よろしくお願いします。
最近はフロントエンド開発部のマネージャーと並行して、開発組織全体のピープルマネジメントにも携わっています。
この記事では、Chatworkが目指すピープルマネジメント体制についてご紹介しながら、ピープルマネージャーというキャリアについてお話をさせていただきたいと思います。
ピープルマネジメント体制とは
現在Chatworkでは、「特定の機能を一つのチームでリリースできる状態にし、開発組織をスケールさせる」ことを目指して、職能型に分かれているチームからFeatureチームと呼ばれる職能横断型のチームに段階的に移行しています。
ChatworkにおけるFeatureチームの一例として、料金プランに関わる領域を専門で扱う「料金プラン」チームが挙げられます。
このように事業における重要ポイントごとにチームとして編成することで、戦略に沿ってデリバリーを加速できるようにすることが狙いです。
移行は段階的に行われており、進んできてはいるのですが、ここでボトルネックとなりやすいのがマネージャーという役割です。
広木大地さんが書かれた記事が非常にわかりやすいですが、マネージャーという役割は潜在的に複数の領域を横断しており、それぞれの領域において専門性は深まり続けている状況です。 これら全てについて理解を深め、リーダーシップを発揮することはなかなか難しいと思います。
特にピープルマネジメントは「技術から離れてしまう」という印象を持たれることも多く、まだまだ専門的なノウハウも一般には広まっていないため、なり手が少ないという問題もあります。
そこで、マネージャーがチームのスケールに対してボトルネックにならないよう、プロダクトに直接関わる部分とピープルマネジメントを切り分け、専門チームとして組織する形にしました。 マネージャーが1つのチームに1人ではなく、複数のピープルマネージャーが複数チームを共同で担当する体制です。
これまでの職能別チームについては変わっていません。 複数のピープルマネージャーが同じチームを担当することで、以下のようなメリットも期待できます。
- ピープルマネジメントにおける属人化を防ぐ
- 複数人が直接メンバーの評価に関わることで客観性が高まり、メンバーの評価に対する納得感が向上する
- マネージャーとメンバーとの間に相性問題が発生しても柔軟にカバーしやすい
具体的には、下記の業務を行います。
- メンバーのメンタリング
- 目標設定、考課査定
- 勤怠管理
- 稟議などの承認
- 予算管理
- チーム間、チーム外に落ちたボールを拾う
- 採用、チームメンバーのアサインメント
DevHRとの違いは？
ChatworkにはDevHRという開発人事全般を担うチームもいます。 詳細は下記の記事をご覧ください。
DevHRとピープルマネージャーの違いは、DevHRが組織開発の観点で組織全体の仕組みを作るのに対して、ピープルマネージャーは評価や稟議承認など、各チームに紐づく直接的な業務を遂行します。
「評価フロー自体の改善」はDevHRで行い、「フローを元にチームメンバーを評価する」のはピープルマネージャーが行うというイメージです。 これらの改善は普段の業務と密接に関わるため、ピープルマネージャーはDevHRのステークホルダーとして、DevHRの活動に関与しています。 もちろん、採用や技術広報などの活動もDevHRのメンバーと協力して取り組んでいます。
キャリアとしてのピープルマネージャー
マネージャーのキャリアについて「コードを書かなくなるからマネジメントはちょっと...」「技術が好きだから開発の現場にいたい」という話をよく耳にします。
私自身も、自分のキャリアについて考えるときにとても大きな葛藤がありましたし、お気持ちは非常によくわかります。
しかし、個人的な意見にはなりますが、マネジメントを長年やってきた身として感じるのは「コードを書くことの面白さと組織開発をすることの面白さは似ている」ということです。
もちろん全てではありません。似ていると感じるのは「問題を抽象化して構造を把握する」「依存関係や仕組みから問題点を読み解いて改善する」といった部分です。
コードを書くというよりは、設計やモデリングに近いかもしれません。
ピープルマネジメントで重要なのは、人を変えようとするのではなく、構造や環境を変えようとすることだと考えています。
組織構成や環境によって、そこで働く人の居心地やアウトプットの質は大きく変わってきます。
目の前で起きている問題から構造を読み解き、様々な人と対話しながら改善をしていくことで、コードを書かずとも「エンジニアリングをしている」という実感を持つことができています。
また、採用や技術広報においても、応募いただいた方々の経歴を適切に判断したり、期待値のすり合わせを行うにはエンジニアとしてのバックグラウンドを持っていることが重要だと考えています。
私自身はフロントエンドエンジニアを軸としていますが、ピープルマネジメントに関わるようになり、改めてバックエンドをはじめとした技術に対する理解を深めることの重要性を感じています。
個人での学習でもインフラやバックエンドについて素振りしたり、JavaScript、TypeScript以外の言語にも積極的に興味を持ったりと、現場でコードを書いているとき以上に技術力を磨くために日々学んでいます。
このように、マネジメントに専念することは技術から遠ざかることではなく、むしろコードを書くこと以外にも技術との接点を深く持つことだと考えています。
以上、Chatworkにおけるピープルマネジメント体制についてお話しさせていただきました。
もしマネージャーに関心がなくても、興味を持っていただくきっかけとなれば幸いです。
もし興味を持てなくても、Chatworkに興味を持っていただけると嬉しいですね。
おっと、こんなところにリンクが... (強引な導入)
Chatworkでは「プロダクトを知り、プロダクトづくりを学び、プロダクトづくりをする人たちにふれる」として、Product Dayを開催いたします。 普段Chatworkを作っているメンバーにふれることができる機会ですので、ぜひぜひお越しください！
