00:00
株式会社株区スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、マネージャーになってコードを書く機会が減って技術力が下がるのか問題、です。
マネージャーになると、コードを書く機会が減る。そして、コードを書く機会が減ると、技術力が下がってしまう。
これって、ほとんどのマネージャー、エンジニアリングマネージャーの方が抱えている恐怖というか、問題というか、いうことなのかなと思っております。
私自身もこのような経験がありました。
毎回ゲストの方とお話ししてきましたが、趣向を変えて、今回は私一人で、私自身の経験を踏まえてお話ししたいなと思っております。
エンジニアリングマネージャーの問題集
というわけで、マネージャーになってコードを書く機会が減るとか、そういうところをお話ししていくんですけれども、
そもそも私が自分でコードを書いてプレイヤーとしてやっていた時期から、徐々にマネージャーになったみたいなフェーズがありまして、
そのあたりで自分の考えがどう変わっていったのかというところについて、簡単にお話ししてみたいなと思っています。
私はソフトウェアエンジニアとして20年くらいこの業界でやっておりまして、
当然最初の頃、かなり長い間プログラマーとしてバリバリソースコードを書いていましたし、自分で設計もしていました。
自分で言うのもなんですけれども、結構自分はコードを書いたり、システムというかソフトウェアを設計するのが得意なんじゃないかなというか、
少なくともすごく好きだと思って取り組んでいたんですね。
そこはこう言うとすごく傲慢に聞こえちゃうと思うんですが、自分がやるのが一番上手だし、何なら一番早いみたいに思ってやっていたんですよね。
それでたくさんのシステムを作ってきたし、結構成果も上げてたと思っています。
ただやっぱりそういう考え方なので、他の人と一緒にソフトウェアを作ったりだとか、他の人に仕事を任せるだとか、
そういうところが正直なところ全然上手じゃなかったと、下手だったというふうに今では思っています。
この自分でやるのが一番早い病みたいなのって、ソフトウェアエンジニアに限らず、社会人一般にある問題というか病というかみたいなところで広く知られているものだと思うんですが、
私自身もそれにかかって、結構長い間それを患っていたのかなと思っております。
なので本当は自分はソースコードを書くのが好きだし、自分で設計するのが大好きだし、ずっとそれをやっていたいくらいに思ってたんですよね。
03:02
ただある時点というか、いろんな開発に参加していったり、コミュニティに顔を出したりしていく過程で、
そうじゃないだろうということにだんだん気づいてくるわけですよ。
というのがいくつかの経験があって、お話ししたいものとしては3種類くらいあって、
まず1つは30代半ばくらいの時に、そのくらいでも私はまだまだ自分がソースコードを書いていたり設計していたりと思い続けていた頃なんですけれども、
プログラマーのコミュニティに顔を出し始めた時に、同じ年齢でやっている方と出会ってすごく意気投合したんですけれども、
その方は私なんかよりももっと早い時期からソフトウェア工学だとか、オブジェクト思考とかそういったところにすごく注力して学んでこられた方でして、
ただ学ぶだけではなくて、実際にその学んだものを通してご自分のオープンソースのライブラリーとかそういうものを作られていて、
その作っているものにきちんと学んだことが反映されているというか、すごく徹底してやられている方と出会ったんですね。
その方とそういった活動を見たりだとか、その方とお話ししていると、自分なんかとはもう圧倒的に違うレベルでソフトウェアの設計とかソフトウェアに対する向き合い方とか、
そういうのをやっているなというふうに痛感したんですよね。
なので、それがまずかなり大きな経験として、自分が別に一番というわけじゃないよねというところに気づいたというところですね。
で、その方とは実際に意気投合して、一緒にコミュニティ活動を結構長い間やらせていただいて、
僕自身もすごく勉強させてもらって、自分の成長にもつながりましたし、すごくいい経験だったりしました。
というのが一つと、その人を通じてまた多くの方と出会わせていただいた中では、
自分よりも年齢で言うと一回りぐらい年上の世代のエンジニアっていうんですかね、
いう方々と出会う機会がありまして、その方々たちはですね、ソフトウェアというかシステムを作るっていう仕事をものすごくたくさんやってこられた方々で、
ソフトウェアの設計というところを超えて、システムをどう設計するのかだったりだとか、
モデリングみたいな手法を通じてどうシステムを捉えていくのかみたいなところを本当に突き詰めてやってこられた方々と出会ったんですね。
もうなんか自分が本を読んでわかった気になっているような設計論だとか、そういうのとかもう全然違うレベルで、
ご自身で設計手法とかモデリング手法を編み出されているような方々だったので、
これもまた自分とはまるで違う経験を積んできていて、同じ年齢だったとしても全く到達しないだろうなっていうような方々だったわけですよ。
06:08
なのでそういう方々と出会ったことで、もう自分とは全然違う世界があるんだなっていうことに気がついたというか、
そういうところもあって、それもまたその自分自身が一番できるとか、自分自身のやり方が一番早いとかいう考えを完全に打ち砕く経験になったりもしましたね。
あと3つ目は、30代ぐらいになってくると当然自分よりも年齢が下の人たちと一緒に仕事をする機会とかも出てきて、
ある程度までは俺の方ができるぞっていうふうに思ってたんですけれども、やっぱり徐々に自分よりも圧倒的にコードを書くスピードが速かったりとか、
もう自分と同じレベルの設計論みたいなのは一通りマスターしてて、さらにモダンな設計手法とかもどんどんインプットしているようなプログラマーと出会う機会もあって、
これはなんかもう全くスピード的にかなわないなと思った経験もあったりしました。
それ以外にももっといろんな出会いを通して自分自身の目が開いていったっていうことなんですけれども、
こういう経験を通じて自分一人で作れるものってやっぱり限界があるし、必ずしも自分が一番で早いわけじゃないっていうことにもう完全に腹落ちして、
自分だけではなくて、より多くの人とうまくものを作っていく。その中で自分ができる適切な役割、立ち位置っていうのをその時その時に応じて見つけて、
うまく物事が進むようにできた方がいいんじゃないのかなっていうふうに思うように自分の考えが変わってきたというところがあります。
その結果の一つとして、マネージャーっていう役割で仕事をするっていうところにチャレンジする機会とかもあったので、
その選択をしていろいろマネージャーとして振る舞ってきているというところがあったりしますね。
なので、マネージャーになってコードを書く機会が減るのかどうか、書く機会が減って技術力が下がるのかどうかというところと、
ある程度関係がない前提の話みたいなところをしてきているんですけれども、
まずそもそも技術力云々以前にそういう仕事の仕方も面白いんじゃないかという気づく機会があって、私は選択してきているというところがあります。
私の場合、そうこうしてマネージャーという仕事をやることになりまして、
今回のテーマとしているマネージャーになったらコードを書く機会が少なくなって技術力が下がるのかということに関して、
実際私もここ何年かコードを書く機会というのはもう激減しております。
ただし、私自身の主観ではあるんですが、じゃあ技術力というものが下がっているかというと、いやいや下がっていないというふうに言いたいと思っております。
09:06
これって技術力の定義の問題なのかなというところも考えておりまして、
多くの特にプログラマーとして今第一線で活躍している皆さんが技術力という言葉から連想するものっていうのは、やっぱりコードを書く力、コードを書く速さだったり、
それから難しい問題に対してどうソリューションを描いてソースコードに落とし込んでいくのかっていうような設計というんですかね、
いうところも含めた実装力というところが概ね技術力ということで表されるところかなと思っています。
この意味での技術力というところは、やっぱりコードを書く時間というのが相対的に減ってしまうと、その分下がっていくというか、
やっぱり突然何かを作ってって言われてもすぐに手が動かないみたいな状態になってしまったり、
各プログラミング言語の新しい機能だとか、そういうもののキャッチアップとかができない状態になってしまうので、
上手に書けないだとか、黙ってしまうというか、そういう状態になるのはもう事実としてあります。
ただ、私自身が考えるのは、技術力って言った時に、そういうコードを書くって言った一番の具体的な実装力だけじゃないよねというふうに考えているんですね。
技術力って言った時に、これは私の考えなんですが、何らかの問題に対してそれを解くようなシステムというか、
ものを作る力だというふうに捉えていて、少し抽象的な定義なんですけれども、問題を解く、何かを作るって言った時に、ソースコードを書くことだけが全てじゃないというふうに思うわけですよ。
例えば、すごく大きな問題をすごく大きなソリューションで解くとなったら、一人で書くプログラムだけでは解ききれないと思いますので、
チームでものを作るということが必要になってくるといった時には、その技術力の中にチームをうまく作って、そのチームでものを作って解いていくということも含まれると思うんですよね。
ということもありますし、またはそもそも問題自体がすごくふわふわしている時に、じゃあこの問題のどの部分から解いていきましょうというような、問題自体を再定義するような力。
スコープを定義するような力だったりだとか、スコープを定義した後にどういう順番で作っていくのかみたいなスケジューリングみたいな力だとか、そういったもろもろ全般、コードを書くということの周辺にあるものっていうのがすごくたくさんあると思うんですね。
12:01
そういった部分も含めて、今ちょっとプロジェクトマネジメント寄りのことをたくさん言っちゃったかもしれないんですけれども、プロジェクトには限らないシステムを作るというところに関係するようなもろもろのことが技術力という言葉に入ってくるのかなと私自身は考えています。
そういうふうに技術力を捉えた時には、マネージャーになってその技術力が下がるのかというと、コードを書く力っていうのはちょっとずつ下がるかもしれないけれども、コードを書くっていうことを抽象化して、私の定義としての問題を解くものを作る力っていうふうに捉えた時には、むしろその力は上がっていく側面もあるのかなというふうに考えてるんですね。
マネージャーになることによって問題実態をうまく捉えることができるようになったりすることもあると思います。
組織の中でマネージャーとして動いていると、現場の1メンバーとして動いている時よりも、より多くの組織の中の課題だったり情報だったりが入ってくるようになる可能性が高いと思うので、そういった状態だとよりうまく問題を捉えて、問題をどう解くっていう時にもヘルプを得やすかったりだとかするわけなので、相対的にやっぱり問題を解く力っていうのが上がっていくだろうし、
そういうことを繰り返していくと問題を解く、大きく問題を解く経験というのがたくさん踏むことができるので、そういった経験を通して大きな問題を解く力、技術力につながっていくのかなというふうに考えています。
なので、これはテーマに対して私が私の主張で返しているような感じなんですが、マネージャーになっても技術力は下がらないというふうに主張したいというところが今回私が言いたいことですね。
これって人によってやっぱり捉え方はいろいろあるので、そうは言ってもやっぱりコードを書く力は減っちゃうよねというところが否定はできないので、
そこが気になる方はコードを書き続けるという選択も当然必要だとあってもいいと思っています。
ですが、自分一人で解ける問題の大きさっていうのはやっぱり限界があるなとも思っているので、より大きな問題にチャレンジしていくってなった時に、
どんなやり方が必要なのか、そこに対して自分がどんな動きをすると、より自分が…
IT・インターネット業界に強い転職アプリGreenは、今話題のテック企業、プロダクト開発、DX案件などGreenだけの良質な求人を数多く揃えています。
正式応募前に企業の中の人とカジュアル面談ができるので、仕事内容やメンバーのことをしっかり理解した後に先行に進めます。
15:03
カジュアルに始める転職活動にGreenをご活用ください。
作りたい形でその問題を解いていけるのかということを考えた時に、自分自身、一行動各メンバーとして参加していくのもありなんですけれども、
より全体に影響を与えるような立ち位置でそういった大きな問題を解いていく活動をしようと思うと、
マネージャーみたいなところで影響力を発揮していくというのは面白い選択肢なんじゃないかなと考えています。
私自身が一人のプレイヤーをやってたところから、目が開けてマネージャーをやるようになったというところで、
マインドセットが変わったというところのお話をしてきたんですけれども、僕自身そのマインドセットの変化っていうのがだいたい30代の半ばぐらいに起こったわけなんですが、
もうちょっと早くそういった変化を経験できても良かったのかなと思った気もしております。
35ぐらいからもちろんマネージャーチャレンジし始めるというのもいいんですけれども、やっぱりもう少し早くやり始めた方が、
マネージメントはマネージメントでたくさん練習をして、そこ自体の経験を積みながら上手になっていくという過程が必要なので、
あまり遅すぎるとなかなか経験値が上がっていかないというところもあるので、早い方がいいのかなというのは当然思っております。
ただですね、早すぎても良くないなというのも一方で結構強く思っておりまして、特に私の場合エンジニアリングマネージャーというところでお話をしているんですが、
エンジニアリングマネージャーに早くなればいいのかというと全然そんなことはないと思っていまして、私の場合一定ソフトウェアエンジニアとしてコードをたくさん書いて設計もたくさんしてきて、
そこに対して一定の自信というか強みがある状態を経てマネージメントをやっているわけでして、
そういうバックグラウンドがあることによって現場で毎日コードを書いていなくても、何らかの自分のセンスというか肌感覚によって、
今目の前にあるコードのあまり良くないところだったり、そういうものをどういうふうにしていくとみんなが組織がソフトウェアを開発しやすい状態になっていくのかというのを
ある程度経験だったりというところから考えて、自分自身で意思決定できるぐらいのところがあるんですよね。
こういったことができるぐらいのエンジニアリング経験っていうのは絶対必要なのかなと僕自身は思っています。
これがない状態で、自分がコードを書いても一番早くはなれないからもうマネージメントやろうみたいな感じでマネージャーをやっちゃうと、
18:07
それはそれで絶対苦労すると言いますか、結局ソースコードやソフトウェアに対して何の肌感覚も持てない状態で、
それって何が問題なのかとか自分自身で察知することもできないし、メンバーからいろいろ問題をエスカレーションされたとしても、
どっちを先に解いたらいいのかというふうに自分自身で意思決定できないという状態になっちゃったりすると思うんですよ。
っていうのってやっぱりマネージャーとして仕事ができない状態かなと思うので、少なくとも毎日コードは書かなくても問題のありかだったり、
どっちの問題が大事なのかっていうのを自分自身で意思決定できる程度のソフトウェアエンジニアリングの経験というところは積んでいてほしいなと思うので、
そういったものを経た後でマインドセットのチェンジ変化というのがいいタイミングで訪れてマネージャーにチャレンジしていくっていうのがベストシナリオなんじゃないのかなと思っております。
そういったシナリオを経てマネージャーになっていくと繰り返しになりますが、毎日コードを書くみたいなことをしなくても技術力は下がらないばかりか、
より大きなものを作るという経験を通して技術力は上がっていくというふうに私は強く考えています。
今回こんな感じで私自身の経験ですとか、私が今こんなふうに考えているよということをお話ししてみました。
なかなか自分一人だけで長い時間しゃべるっていうのは難しいなと思いながら話しておりますけれども、
話すことによって私自身も考えがまとまる部分もありますし、もしかしたら皆さんの役に立つ話だなって思っていただける部分もあるかなと思っていますので、
今後もまた別のトピックでお話ししてみたいなと思っております。
さて、この番組では感想や質問リクエストなどお待ちしております。番組詳細欄にあるリンクよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株区スタイル、COO兼CTOの後藤秀典でした。