エンジニアリングマネージャを辞めて思ったこと

エンジニアリングマネージャを辞めた。とはいっても、こういうのは自分で決められるものではないので「辞めさせられた」が正しいかもしれない。とりあえずここでは、僕の主観で「辞めてみて思ったこと」を書いておく。今日は41回目の誕生日。本厄怖い。

スポンサーリンク

エンジニアリングマネージャを辞めた理由

それはずばり、まるで解散するバンドのように「方向性が合わなかった」からだ。

たとえば、今の職場に入ったときに、メンバーに対して「できるだけ嘘をつきたくないなぁ」とか「不誠実なのはしやだなぁ」と思い、できるだけ誠実にメンバーと向き合うことをテーマに考えていた。

でも、これはどこでもそうかもしれないし、いたって普通のように聞こえるかもしれないが「誠実にやる」はとても難しい。普通のようだけどとてもチャレンジングなテーマだ。

ある友人が、会社をやめたときの理由について、こう話してくれた。

リーダーになって、リーダーが集まるMTGで、会社について都合の悪いことや、ネガティブなことをを、以下にメンバーにうまく言うか? うまく見せるか? の議論を見ていて嫌になった。

僕はこういうのを不誠実だと思う。なぜなら、「うまく見せよう」というのは、メンバーのモチベーションを考えてくれているようで、実は自分たちのことしか考えていないからだ。

メンバーに向き合うためには、ネガティブなときこそ、真摯に誠実に真剣に話さなければならない。そして、そのほうが「うまく見せる」よりとても難しいのだ。

マネジメントとはなんだろうかと今も日々考えるけど、こういうのがマネジメントであるならば。

僕はやりたくない。

ソフトウェア開発のマネジメントとは何か

リーダーやらマネージャやら、チームで戦う仕事をもう10年以上させてもらっているが、ソフトウェアを開発する企業、特に自社でサービス開発している企業のマネジメントは、従来型の方法では通用しないのではないかと思う。

なぜなら、ソフトウェアエンジニアという特殊なスキルを持つ社員がいるからだ。特殊なスキルとは技術の力。これがあれば、従来の発想にしばられずいろいろできるようになる。

たとえば、管理するだけの管理職を立てて人を管理するよりも、独立して自立して動けるチームを作ったほうが効率的で生産性も高まる。

それなのになぜか、社員に管理職させたり(とくにできる社員に!)、社員がいないときは外注管理させて人力でなんとかしたり。マイクロマネジメントしたり、アサインのやりくりに時間を使ったり。

また、繰り返される作業は、人力でがんばるのではなく、完全に自動化してしまえばいい。

それなのになぜか、「自動化 VS 手動しかできない人たち」という構図が生まれたり、自動化のコストに躊躇して一気にすすめられなかったり、その価値を想像できず、チャレンジの芽をつんでしまったり。

せっかく持っている「技術」というアドバンテージを、活かしきれないのは本当にもったいない。

なぜそうなるのかは未だにわからないけど、普通の会社がやっていることを真似して失敗しているケースが多い気もする。

また、全時代的にリソース効率を主と考える傾向もあると思う(リソース効率 VS フロー効率に関しては『モブプログラミング・ベストプラクティス』が最高)。我々はリソースではなくてピープルなのにだ。

ソフトウェア開発組織でのマネジメントはとても難しい。でも、この難しさが面白い点でもあるのは事実だ。

という話を仲のいい後輩にしたところ「わかるんですけど、なかなかそういう企業ないですよね」と言われた。

「そう、なかなかない。だからチャンスなんだよ」

エンジニアリングマネージャを辞めて、メンバーとの1 on 1などの時間が減ったはずなのに、他社の方に1 on 1を依頼されたり、組織マネジメントの相談を受けたり、エンジニアリングマネージャの旅は別の形で続きそうだ。

10年経っても20年経っても、アジャイルやら生産性やら品質やらといった話がなかなか解決しない現状を打破し、次のステージへの道を切り開いていく・・・。そういうマネジメントや開発組織づくりを今後も目指していきたい。

もちろん、人に対しては誠実に。

タイトルとURLをコピーしました