GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

エンジニアがマネージャになることへの憂鬱について

daiksy.hatenablog.jp

既視感があったので反応しちゃう。すげー懐かしいなこの手の話題と思った。

懐かしいと言っているのは、ネット上の議論では誰も肯定的な反応をしていないと思われる「PG→SE→PM」の出世魚キャリアの憂鬱にそっくりだったこと。

技術者とマネージャって職種(ジョブ・ディスクリプション)が全く違うのに、なんでこれが技術者の出世コースになっているのか。でも、ビジネスサイドと話ができるマネージャーは価値高いけど「作りました」ほどわかりやすい評価体系がないし、陸に上がった魚は老害になるんじゃないか・・・みたいな話ですよね。

当時は今ほどITが本業の会社が多くなく、エンジニアの主たる現場は受託開発を中心に行うSIerでした。その内部でも誰もPMになりたがらないのは人材育成上の課題にあげられていた。給料大差ないのに責任は重いので単なる貧乏くじではという風潮でした。

twitter.com

2008年のツイートという所に趣を感じます。

で、2019年のツイートもございます。

問題の構図は変わっていないようです。打つ手が無いもんね。

マネジメントが必要だしビジネスサイドとコミュニケーションをとってチームを率いて行けるマネージャはみんな欲しい。ただ何をどう作るかを判断できる技術力がないと何も出来ないから、まずプログラミングを覚えてもらう。が、陸に上がることを好むエンジニアは非常に少ないので、絶対数が少ない。

この現状認識があっているのであれば、マネジメントを外注することを検討するしか無いのでは? と思います。

僕が考えるマネジメントなるもの

「マネジメント」というやつは企業の中に溶け込んでいくものなで、可視化しにくいと思う。そのチームで、その会社で行っている事業やお仕事そのものが対象になる。薄暗い森のなかにいるようなもので、例えば私にやってくるIT企画的なご相談も、抽象度が高い。プロジェクトを立ち上げたいんだけどどうしていいかわからん、と。何も決めて良いかもわからん、と。

この状態では自分が前に出て手を動かすというよりも、自分の周りの人達とコミュニケーションを取ったり、課題管理をしたり、分かりやすい資料を作ったり、各々の立場に沿った方向性を導き出したりするしかなく、こういうお仕事って定型化するのが困難なので、わかりにくい。

抽象度の高いものを具体的なステップへ落とし込むアプローチを考えること、現場で起こっている不都合な事実を集めて抽象化して、それらのもつ構造や性質を考えてこのアプローチで攻めるべきではみたいな立案をする。僕はこういう事を考えるのが好きですので、苦にならないけど。

正しい方向はどっちなのかを示すのが、一言で言えばマネジメントだと思う。手取り足取りあれやれこーやれってのは、説教でしょ。

こういう仕事であれば外に出せるはず

ソフトウェアを育てていくプロセスは外注によろしくとは言えないから、自社でやるしかない。でも、仕事を円滑に回してチームで結果出す為の仕組みづくりという部分にフォーカスすれば、外に出せると思う。「やっぱエンジニアでよくね?」みたいになる人が多いのであれば、検討の余地はあるはず。実際、自分の周りでもエンジニアの組織づくりやマネジメント系のフリーランスを、何人か知っている。

僕はエンジニアで一本立ちするのはとっくに諦めたので、「エンジニアとしては極めて普通だが、文章を書くのと説明が得意で、企画の立案やロードマップを作ってマネジメントもいける」人材になろうと決めて、その最短ルートが独立だった、という感じです。元々SI時代からPMとかやってて、昔懐かしい「スーツ」の仕事は嫌いじゃないです。やりがいも知ってるし。

まずはディスカッションでもしましょうか

もし「フリーランスだけの会社」を作ったらどうなるのか - GoTheDistanceの記事を書いた時に、ディスカッションでもしましょうと言ったら結構人が集まった。なので、「受託開発だろうがサービス系だろうが、出世魚のジレンマを解消してエンジニアリングを適切に行うための仕組みづくり」について興味のある人で、意見交換でもやりましょうか。5人ぐらい集まればやるので、Twitterでお気軽にどうぞ。

SQLを学習できるWebサービスを作りました。