くるのプログラミング記録

プログラミングの感想とか解説とか。

自分思想的マネージャー論

こんにちは、webエンジニアの くる です。

自分の業務の方で、最近マネジメントをするロールになりました。いわゆるマネージャー。それにあたって今の目線を色々メモとしてアウトプット。
忙しくなったり変に視座が上がっちゃう前に今の気持ちを残しておきたい。



プロジェクトマネジメントとかプロダクトマネジメントとか


元々、自分はマネージャーという肩書きに対して疑問が結構あった、プロダクト開発において必要なものではないだろう？と。
そこは正直今でも変わらなくて、肩書きは不要だと感じている。
チームをまとめたり、技術方針を決めたり、プロジェクトを進めたり、他チームとやりとりしたり、などという前に立つロール自体はweb開発において必要とは感じるが、これは自分の中ではプロジェクトマネージャーとか、プロジェクトリードとか、テックリードという呼称かなと思っている。そしてこのロールの人間がいれば開発はそこそこ回るし、プロジェクトリードのロールやテックリードのロールを兼ねないマネージャーという肩書きだけの存在というのは不要と思っている。

改めて見返してみても自分の思想が尖りすぎてて怖い。まあ今も同じ気持ちだけど。マネージャーに親でも殺されたかの勢い。


メンションを向けられたりmtgに出るものの何も自分で答えることができないマネージャーというロールの人間を、自分は皮肉の意味も込めて、プロキシとよく呼んでいる。なんとなくポジションは維持したいが、開発に対するキャッチアップは薄く、せっかくの裁量を全く活かそうとしないような主体性のない人に対してこれをよく言う。実際こういう人は一定数いると感じる。メンバー目線だとやだなあって感じ。いても意味ないから。

別に技術に疎くなるとか、実装をしないことはロール的に全然よくて、でも自分でプロダクトを作っていくっていう気持ちを持ってて欲しいなと感じる。

ピープルマネジメントとか

形式上のマネージャーにおいて、一番大事なのはピープルマネジメントなのかなと思うところはある。前言撤回というわけではないが、ピープルマネジメントが必要な職場では、マネージャーは必要と感じる。
ここでいうピープルマネジメントとは、人事評価、リソース管理などのことを指している。

本来、プロダクト開発において、可能であれば評価制度というのはない方が良いと感じる。プロダクトが良くなることと本質的には関係ないから。

でも実際そうは言ってられなくて、プロダクトを開発するのは「人」なのだ。それも大人数なのである。会社という集団で、給料をもらいながら多くの時間を費やしプロダクト開発をするという場合において、評価制度というのはあまり切り離せないことが多い。

全員に同じ給料を払うわけにもいかず、また全員が時間変化に対してずっと一定の給料で良いというわけでもないため、評価という仕組みは必要になってきてしまう。いわばこれは会社という場所で人間の営みでプロダクト開発をする弊害みたいな位置付けと感じている。

スタートアップとか小規模な開発において、評価という仕組みをなくす、あるいは軽くできているのならそれはとても良いことに感じる。プロダクトをより良くすることに時間をかけることができているから。

でも人が多い職場では、評価制度やリソース管理は必要で、マネージャーというロール自体が必要というのは納得感を持っている。


ピープルマネジメントの引力

ピープルマネジメントの怖さというか、自分目線でよくないなと感じるところに、ピープルマネジメント単体でマネジメントしてる感が出てしまうというところがある。

これはかなり偏見かもしれないが、ピープルマネジメントだけが自分の責務と思い込んでいる人、みたいな人を観測してきた。(少なくとも僕が主観で見た振る舞い目線で)
これももちろんポジションによっては必要な存在という認識はあるが、それはマネジメント対象のメンバーが多い場合の話であって、規模的に余裕がある場合はマネージャーもプロダクトやプロジェクトにもコミットして欲しいという思いがある。
メンバー目線ではピープルマネジメントの場面(1on1, 評価 etc ...)でしか出てこないマネージャーは、現場にいないなという感じがある。そうなると結局は何もしてくれない人、という感情が少し出てしまう。

もちろん、役職が上になればなるほど、1人での作業時間より他人とのコミュニケーション比率が上がることは認識しているので、ピープルマネジメントが100%のロールの人も必要とは思う。ただそれを少ないチームや人数の規模でされると、自分がメンバーなら辛いなと感じる時がある。

これは結局何人ならという話は難しくて、個人のキャパ次第なところかなとは思う。
組織構造にも依存するし、少ない人数だから絶対ダメというのも一概には言えないこともある。

ただ、ピープルマネジメントばかり続けていると、それだけがバリューと捉えてしまい、プロダクトやプロジェクトから離れてしまう傾向の人がいるなと少し感じる。
マネージャーは、実装をする時間がなくなっても良い。最新の技術をキャッチアップできなくなるのも仕方ないと思う。メンバーより手を動かすタスクが遅くても良い。その分の時間を他に割いているのだから。
でも、だからといってプロダクトやプロジェクトから離れていいわけではないのだ。プロダクトに向き合ったり、プロジェクトを進めたり、自分のチームのメンバーが携わっている開発に、主体的に向き合ってほしい。他人事じゃないんだよっていう。

そこらへんの気持ちを失わせるような作用というか引力が、ピープルマネジメントにはあると個人的には感じる。

マネージャーの不可逆性

組織構造上、マネージャーになるとメンバーに戻しにくい/戻りづらいという不可逆性があると感じる。
色々理由はあると思っていて
「実装などの開発タスクから離れたことによる技術離れ」
「組織上昇進しているという名目があるため安易にメンバーに戻してしまうと関係がギクシャクする」
「マネージャーを辞めると給与水準が下がることになってしまう会社のルールであるが、給与を下げることはセンシティブであるため戻せない」
など。

色々理由はあると思うけど、不可逆性が起こりやすい力学はあるなと感じる。

個人的には、いつでもマネジメントのロールがコロコロ変えられるような、人の変化に対してロバストな組織の方が強いと自分は思っているので、不可逆じゃなくなって欲しいなとは思う。
まあでも文化的なところもあるので、日本企業である以上は避けられないのかなと感じる気持ちもある。自分も助けられている部分もあるかもしれない。

肩書きの権威性とボトムアップな意識

マネージャーという肩書きを持つと、メンバーでいた時より組織内の得られる情報の絶対量が多くなる傾向があると思う。これはいわゆるマネージャー同士のミーティングや連帯感というか、少しセンシティブな話を先に共有などそういうコミュニケーションパスが出来上がるからだ。

こういうメンバーのロールの人と比べて情報の非対称性があることで、少し俯瞰した目線で意見を言いやすくなれると思う。
またマネージャーは主に他チームとの折衝係というか、窓口になることも多いため、大きなミーティングの場でも少し発言がしやすくなる傾向があると思う。
諸々の要素を兼ねて、自分はこのような作用を肩書きの権威性と捉えている。


新卒すぐの頃の自分は特に、このような権威性を持っている人がもっと頑張って欲しいという思いがあった。プロダクトを実際に進めたい方向へ動かしたり、既存のルールを変えれる立場にあるのだから、と。


実際そういう思いは今でも無くはないのだけど、ここは少し良くない見方だったなと思うことがある。

別にマネジメントロールでなくても、メンバーのロールでもプロダクトを進めていくべきだし、ルールは変えていくべきなのだ。
多くの人に対して発言をしやすいかどうか、というのは確かに権威性がないと少し不安になる部分はあるかもしれないが、それはマネージャーなんて肩書きがなくても良くて、自分の技術や知見でも補えるものなのだ。

1個上のグレードの仕事は、1個上のグレードになってからやるんじゃなくて、そういう仕事が実質できている状態で後から肩書きとかグレードがついてくる、みたいな話に近い。
結局ボトムアップで自分がやるという気持ちが大事。みたいな。




まあ、個人的にはマネージャーの肩書きに権威性があることは今でも感じるから、そういうロールの人はプロダクトを自分で変えたりルールをより良くすること自体が責務にあることを意識して欲しい、ってのは今でも全然思う。


ってなわけで

かなり偏見が強かったですが、自分なりのマネージャー論でした。


自分がやること

最後に、今の視点で自分がやっていこうと思うこととかをメモ。時間が経った時とかマネージャーのロールをやめるときに見返して、気持ちを忘れないようにしたい。

  • 全員の味方

自分がメンバーの時は、自分が何をやってるかマネージャーがわかってないって状態というのは結構辛かった記憶がある。
そういうのは無くしたいなって思いが結構あるので、主体的に人の開発やタスクに関心を持ったり、メンバー目線で何か課題とかトラブルがあったときに他人事にせず一緒に横に立って解決するのを心がけたいなーって。


  • 評価のベクトルの一致

これは人事評価あるあるかもだけど、実際に普段やってるような開発での時間の使い方の方向性と、評価とかに現れる目標の方向性の一致。100%じゃないにしても内積を大きくする必要がある。
目標設定がそもそも微妙なプロダクトだとこの辺辛いなーってメンバーの時から結構思っていたので、なかなか悩ましいところ。


  • 自分も1メンバー

自分も1メンバーという気持ちを忘れずに技術や課題に向き合いたい。
1つのタスクばっかりやっていいロールじゃないので、1人で完結する作業を積極的にやるというわけではないけど、自分のチームのプロダクトやプロジェクトがうまく進むためなら、必要に応じてコードも書くし、テストもするし、プロジェクト進行もするし、なんでもやるべきだなと感じる。
複数のチームを見る立場でもあるので、必要に応じて必要なチームにサポートするリソースプールになっておきたい。

(結局はコード書いたり作業したりしたい気持ちの方便な気もしつつ、そういうことばっかりやってるのは良くないという意識も持ちつつ)


マネージャーなんてただのロールなので、いつでも替われようになっておくべきだなと感じてる。
ここはかなり強い気持ちがあったので、マネージャーになった初日から引き継ぎ書を作って、職務に関しての色々をずっとドキュメントに残している。
初日からいつかやめることのこと考えるのネガティブか？と思いつつも綺麗に引き継げることは組織にとってもポジティブと思って書き留めている。

どの定例でファシリやるとか、mtgあるとか、組織のメンバー構造とか、地味にちゃんと明文化されてて欲しいよね。

  • プロダクトを作る

単に僕がしたいってだけなんだけど、自分の意見をチームメンバーに話す機会があることが多いなーとは感じるので、せっかくだから自分が思う作りたいシステムをチームメンバーみんなに手伝ってもらって、良いプロダクト作っていきたい、というのがある。
業務だからこそ個人開発じゃ作れないような規模のシステムを時間とリソースかけて作ってるので、そこを自分の意思を乗せてやれるのは楽しいよなーって。


おわりに

プロジェクトマネジメント、プロダクトマネジメントは別に肩書きなくても色々やってきてはいたものの、多分今の自分の視座はかなりメンバー寄りなんだろうなとは思う。
やっぱりこのロールを続けていくとプロキシになっちゃうものなのか、実は個人次第なのか。その辺どうなるか気になる。
後、自分目線では良くないと思っていたマネージャーの振る舞いも、実は意味があったりメリットがあったりしたのかとかも、気になる。

まだまだ手探りだし未熟者だけど、時間経過が楽しみなところ。
おわり。