マネジメントの勉強を始める方法
株式会社株区スタイルの後藤英則です。
この番組では、エンジニアリングチームで起きている問題について、
技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、マネージメントの勉強、何から始めたらよいか、です。
実は、最近この番組のお悩み相談フォームというのを開設しておりまして、
そこからいくつかいただいておりますと。
テーマに挙げているのはその中の一つのお話なんですけれども、
それを含めていくつかのお話というのを今日はさせていただこうかなと思っております。
エンジニアリングマネージャーの問題集。
では今回はですね、お便りとしていただいたものがいくつかございまして、
送りいただいたのはありがとうございます。
その中から全部は取り上げられないんですけれども、いくつかピックアップして、
それに関してお話ししていきたいなと思っています。
まず一つ目ですが、この辺から入るのがいいのかなと思って、
こちらを取り上げたんですけれども、
EMに興味があるんだけれども、マネージメントというものに全然関わってこなかったので、
マネージメントの勉強というのを何から始めたらいいんですか、
というような質問というんですかね、いただいております。
これに関してお答えしようと思うんですが、
あくまで私自身の考えみたいな感じなので、
これは王道というか、そういうのはないかなと思っているという前提で、
私なりの回答をしたいと思っています。
とはいえこれ結構難しいですね。
何から始めるのが一番効率がいいのかとか、
いいマネージャーになれるのかとかっていろいろあると思っていますが、
まず一番最初に強調しておきたいのは、
ソフトウェアエンジニアの方であれば、
ある種納得いただけると思うんですけれども、
ソフトウェアを作る、いいコードを書くとかって、
本とか読んだだけでは絶対上手にできるようにならないじゃないですか。
実際にその考え方を自分である程度リアルっぽい問題に適用して、
自分で考えたコードを書いて、それがどうだったのかというのを評価するというか、
そういうサイクルを回すことによって本当にいいコードを書けるようになるとか、
そういう感じだと思うんですよね。
マネジメントっていうのもやっぱり一緒かなと思っていて、
本を読んだりとか、いろんな人から話を聞くとか、
そういうだけでは決してできるようにならないんですよ。
これもやっぱり実践の場でしか本当のマネジメントみたいなものって学べないというか、
上手にならないみたいなところがあると僕自身は強く思っているので、
勉強っていうものの答えではないんですけれども、
まず本当にマネジメントできるようになるためには、
実践しなきゃいけないというところを最初に強調しておきます。
とはいえ何にもインプットがない、
自分の柱みたいな知識がない中で始めるのも非常に難しいとは思うので、
何を柱にしたらいいのかぐらいは持っておいた方がいいかなと思っていて、
これは僕自身も実はさっき紹介した悪い例というか、
めちゃくちゃ本とかに頼りながらマネジメントってこういうものかなみたいなのを
ずっと右往左往しながら苦労してきたというところがあったりするんですが、
その中でこれは多分始めには読まないほうがいいだろうなっていうのがありまして、
それが否定するわけじゃないんですが、
ドラッガーの本はこのマネジメントを始めるというときには、
スタート地点ではないですよっていうのだけはこれも強調しておきます。
マネジメントといえばドラッガーみたいなところがあると思うので、
最初にこのドラッガーのマネジメントみたいなやつを買って、
読む方とかも大勢いらっしゃると思いますし、
ドラッガーの書かれているマネジメント自体は素晴らしいものだと思うんですけれども、
マネージャーとしてのスタート地点で必要なことがコンパクトに書かれているっていうものではなくて、
もうちょっと壮大なというか、
どっちかというと例えば経営レイヤーだったりとか、
そういう会社レベルでのマネジメントイコール経営みたいなニュアンスの
マネジメントのことが書かれたりしているので、
一マネージャーのスタートラインとして読む本ではないとは思っているので、
ここはちょっと間違えない方がいいかなと思っています。
で、じゃあ何から入るのかっていうところも実は、
例えばエンジニアルマネージメントの知識体系みたいなので、
ピープルとテクノロジーと、それから何だっけ、
4章芸みたいな話が今出てこないんですけど、
いろんな方向のことを学んでいかなきゃいけないよとかあって、
本当にキリがないんですけれども、
もしスタート地点の知識というかスキルとして、
一つ拠り所にするものを僕が挙げるとしたら、
ちょっとマネージメントと違うように聞こえるかもしれないんですけれども、
課題解決力なんですよ。
で、マネージャーって一エンジニアと違うのは、
エンジニアであればよりソフトウェアを作ってデリバリーするっていうのが
メインの仕事になるんですけれども、
マネージャーはチームのメンバーたちがソフトウェアを作って、
価値をデリバリーすることをサポートするというか、
より出してくれる成果を大きくするみたいなことが仕事になってくるので、
その時に発生するいろんな課題ですね。
だからソフトウェアで解決する課題というよりは、
そのソフトウェア作りそのものに発生する課題を解決するようなことが
マネージャーの仕事だと思っています。
なのでソフトウェアエンジニアとしては明示的に課題解決っていうよりは、
ほぼほぼイコールソフトウェア作りのような形で仕事をしてこられた方が、
改めて課題解決とは何かっていうことに向き合うべきなのかなと思っていて、
そうした時に課題っていうのはどういうふうに見つけ出してとか、
どういうふうに優先順位付けしてとか、
どういうプロセスで解いていくのがいいのかねみたいな話とかがいくつかあるんですけれども、
ここが一番あらゆるマネージャーの仕事の中でコアになってくるスキルだと思っているので、
本当に抽象化すると課題解決だと言えると思っているんですよ。
なので、課題解決に関する勉強をするのが、
マネジメントを上手になる一番の近道なんじゃないのかなと僕自身は思っています。
その課題解決みたいなタイトルの本部だとかもありますし、
かなりこれに近いもので言うと、コンサル系というかロジカルシンキング、クリティカルシンキングみたいなものだったり、
具体的な書籍の名前で言うと有名な本なんですけど、
イシューから始めようっていう本だとかがあるので、この辺りで課題解決ってだいたいこんな考え方でやると、
効率よくやれるんだよなとか、その辺りを抑えるのが一番いいのかなと思っています。
というのが最初の話ですね。
マネージャーとしての実践
繰り返すと、やっぱりとにかく実践あるのみなので、本を読むだけで終わらせずに、
どのように試せるのかっていうところまで持っていくと、
マネジメントの勉強というか、マネージャーとしての訓練というんですかね、
それをスタートすることができると思っていますので、
これは組織によって何ができるのかっていろいろ違うと思うんですけど、
例えば、すでにチームにEMがいて、そこで自分もマネージャーやってみたいっていうのであれば、
そのEMの補佐的な役割みたいなのを何とか設けてもらって、
一部の役割だけ持たせてもらって、スモールスタートするみたいなこととか、
そういうのを提案したり、もしそういう仕組みがなければ。
何かして実践できる機会っていうのを作っていくのが一番いいかなというところですね。
あと、マネジメントの勉強を何から始めるのかっていうのとちょっとコンテキストが違うんですけれども、
実践でしか学べないっていうようなタイプの知識、スキルというか、こういう分野のことって、
すでにうまくやってる方々の経験から学ぶことが非常にたくさんあると思っていて、
マネジメントに限らずなんですけれども。
そういう時って、やっぱりその経験してる人をうまく見つけてメンターになってもらうっていうのも、
マネジメントを上手になる近道の道具として使える一つかなと思っていますので、
これ本当、いいメンターを見つけるっていうのはそれぞれで結構難しいことなので、
みんながほいほいとメンター見つけれるわけじゃないんですけれども、
そういう人を常に探すっていうような意識を持っておいて、
この人だって思ったら、ちゃんと連絡を取ってつながるとか、
なんか一回、最近だともうネット越しでミーティングするとかって当たり前になってきてるので、
そういった面談をさせてもらうとか、そういうアクションを取っていくとかも結構いいんじゃないのかなと思っています。
次のお話に行ってみますかね。
エンジニアリングマネージャーの役割とバランス
そうですね、このエンジニアリング、手を動かすこととマネジメントとのバランスみたいなところがいくつかもらってまして、
一つあれですね、エンジニアリング、プレイングすることとマネジメント、手を動かさないことの比率って、
どれくらいにするのがいいのか迷ってるみたいなコメントというかご質問というか、
みたいなのをいただいてますと。
これもエンジニアリングマネージャーになってからだったり、なる前とかにも、
そういう不安というか疑問というかを抱くのがあるあるみたいになってる話ですよね。
僕自身もこの話にはすごくわかると思う部分があって、
大前提として僕はエンジニアリングマネージャーであっても、
手は一定動かした方がいいだろうと思っているし、
それは手を動かすこと自体が必要というよりは、
エンジニアリングを主たる領域とするマネージャーであれば、
その領域で発生する課題を解決する、さっきの話じゃないんですけれども、
ことがミッションであって、課題を解決するためには、
そこで何が起きているのか、起きている問題について100%理解していて、
それに対するソリューションというんですかね、
どういうふうに手を打っていくのかという意思決定を自分で行うか、
もしくはチームメンバーがそういった意思決定をして解決をしていくというところを
サポートする必要があったりするんですけれども、
その意思決定自体がいいのか悪いのかだったり、
失敗したときにちゃんと自分が自分の言葉で説明できるとか、
そういった責任を持った状態で物事を進める必要があるので、
そのときにはやっぱりちゃんと現場で何が行われているのか、
どういう状態なのかっていうのを、
自分がしっかり理解できる必要があると思うんですよね。
それに必要なプレイングの量っていうのは人によっていろいろなんですけれども、
そういった量を一定確保しておくほうが、
今話したような求められる責任に対して果たしやすいだろうなというふうには考えています。
エンジニア経験の重要性
っていうのがまず前提の話なんですけれども、
といったときのエンジニアリングマネージャーのプレイングの量と
マネージメントの量の比率みたいなのをどの辺に置くのがいいのかっていう話なんですが、
まあ難しいですね。
正直、ほとんどの人にとって、エンジニア出身のエンジニアリングマネージャーにとって、
手を動かすことから離れる、もしくはもうちょっとでも量を減らすっていうのは、
最初ものすごい恐怖なんじゃないかなと思うんですよね。
やっぱりエンジニア目線からすると、
自分と同じように同じ量だけコードを書いて、
同じレベルで会話ができる人っていうのが、もしくはもっとハイレベルに会話ができる人っていうのが尊敬対象というか、
その人の言うことなら聞こうかみたいに思える一般的なラインかなと思うんですよね。
少なくとも自分たちが抱えている問題に対して、
自分たちと同じ程度に理解できない人の言うことを聞こうとは思わないと思うんですよ。
そういう状態になってしまうんではないかという恐怖がすごく最初芽生えると思うし、僕自身もそうでした。
なので、そういう信頼を失っちゃうみたいな恐怖感があるので、
そもそもその恐怖感からエンジニアリング、プレイングの量を減らせないっていうところがあるのかな。
そういうジレンマみたいなものがあるんじゃないのかなとは思っています。
合わせて、エンジニアリングの時に出してた成果っていうんですかね。
実際に自分がコードを書くことによって出してた価値みたいなものが、
マネージャーになった途端にそれをやることを減らして、
別のやり方で成果っていうものを出さなきゃいけないというようなことが求められるんですけれども、
そっちって明示的にソフトウェアとしてアウトプットされるものではないので、
そちら側の成果の間隔に自分の目凧とかいろんなものが追いついていないと、
単純に自分の出してる価値というか成果が減ってるように感じちゃうんですよね。
これも恐怖の一つですよね。
そんな中でどうプレイングの量を減らしてマネージメントの量を増やすのか、
どれくらいのバランスがいいのかっていうのを自分と折り合いをつけるみたいな話なのかもしれませんけれども。
ここは正直、そういったマネージメントに振り切るための自分自身の準備というか、
マネージメントの慣れみたいな観点の話とそうではなくて、
そもそも自分が担当しているチームっていうんですかね、その場所っていうんですかね。
そこにマネージャーとして仕事をする意義がどれくらいあるのかっていうのも、
客観的に見ておいたほうがいいのかなっていうのは僕の考えで、
その両者のバランスから、今は何ならプレイングをたくさんやったほうがいいだろうなって判断できる場合もあるし、
ここだったらプレイングは一旦ゼロにして、マネージメント100やったほうが今はいいなって思える場合もあると思うんですね。
なのでそこは、この比率がベストみたいなのがあるわけではないです。
自分自身の状態とチームの状態、特にチームの中に絶対に現場のエンジニアたちがコードを書くだけでは解決しないようなタイプの大きな問題が出てきていて、
これはマネージャーなりがある一定期間、100%その問題の解決にコミットすることで、その後チーム全体の生産性なのか何かがものすごい上がるというようなタイプの課題が見つかっているのであれば、
そこは自分がたまたまその時マネージャーという位置にいたり、何か指名されているのであれば、それに取り組むという決意をして、一旦エンジニアリングを手から離すというのは客観的にそこは頭を切り替えるきっかけにできるんじゃないのかなと思っています。
比率どうのこうのという話と若干観点の違うことを僕は話しているかもしれないんですけれども、自分自身の気持ちみたいなものとは別の観点で何がいいのか、どのバランスがちょうどいいのかというのを判断できる軸を持っておくと、
比率云々みたいなところに対して答えを持ちやすいのかなというところで、そういう話をしてみました。これと似たような話がもう1個あって、こっちもほぼ同じかなと思うんですが、将来エンジニアリングマネージャーになりたいと思っているが、
ソフトウェアエンジニアリングにおける考え方
テックリードとかエンジニアとしての経験をちゃんと積まないとエンジニアリングマネージャーになれないものなんですかというようなご質問をいただいていて、これも会社によってだったり、その人のマネージャー像みたいなので違ってくる答えだと思っているので、
全世界共通の答えを僕が言うわけではないんですが、僕であればこのご質問に対する回答はイエスですね。しっかりとエンジニアとしてのエンジニアリング経験を積んでからエンジニアリングマネージャーになったほうが、
より成果を出しやすいマネージメントができるだろうなと思っています。
このポッドキャストの何回かの回で同じような話をしていると思うんですけれども、エンジニアリングマネージャーであればエンジニアリングっていうのがメインの担当領域なので、その領域の問題が何かっていうのをちゃんと理解しなきゃいけない。
2つ前の質問のところでもお話ししましたね。
っていうところなので、そこの問題をきちんと理解するためには、教科書で読んだだけではない、自分が実際にいろんなエンジニアリングの問題と対峙してどう解いてきたのか。
これは成功も失敗もあると思うんですけれども、そういった経験を通して、
自分であればこういう判断をするっていうような判断軸みたいなものが一定、自分の中に形成されていて、
そういったものを使って現場で発生している問題をどういうふうに解くのか、今解くべきなのか、そうじゃないのかとか、
そういうことに対して一定の判断ができてくるっていうところだと思いますし、
そういった判断力を使ってマネージメントしていくチームの課題を解決していくっていうことなので、
ここはやっぱりきちんとエンジニアリングの経験を積んだ後にエンジニアリングマネージャーになったほうが、
いいマネージャーになれるんじゃないのかなと思っています。
もう一ついきましょう。
これちょっと違う観点のものなんですが、僕の好きなタイプの話なので取り上げていますが、
ちょっとマネージメントではない話ですね。
ドメン駆動設計などのソフトウェアエンジニアリングについて、
自分の考えをすごく深めていくっていうか、自分自身での理解というか、
そういうのを持っていくにはどうしたらいいんですか?みたいなご質問をいただいてます。
そういうものって絶対必要なのかどうかって僕もわかんないんですけど、
僕はそういうものをソフトウェア感というかソフトウェアエンジニアリング感というんですかね。
自分はこういう感じでソフトウェアエンジニアリングというのを見ていて、
その中に対してこういういろんな考え方が出てきたときに、
それは自分のソフトウェアエンジニアリング感の中では、
こういう位置づけですよっていうふうにある程度分類して対処できるとか、
そういうふうにできたほうがいいだろうなと僕自身は思っています。
そういうのをどうやって持つのかっていうお話かなと思っていて、
これ何回か前のポッドキャストでもお話ししたことなので、
そちらも聞いてもらえるといいなと思ってますが。
あとこれ今日の最初の質問で答えたこととも関係しますけれども、
結局課題解決というか、
ソフトウェアエンジニアリングもやっぱり何か目的があってやってることですよね、
と思ってます基本的には。
なのでどういう課題に対して、
課題もやっぱり方向性があるというか、
どういう目的を持って何かを見たときに、
課題が浮かび上がってくるみたいなものだと関係性だと思っているので、
そういう課題解決だったり、
それに対して自分がどういう解決方法を仮説として立てて持っていくのかというかですね。
そういったような能力というのはベースで必要になってくるかなと思っています。
ドメイン駆動設計だったりソフトウェア設計だったり、
いろいろそこでの方法論だとか、
そういうことに対する一つ一つのことというよりは、
ソフトウェアエンジニアリングと視野の広げ方
全体を統合した中での理解を深めるというような話かなと思っているんですけど、
なんていうのかな、
結構視野というか、
視野ですかね、広げることが非常に重要だと思っているんですけど、
これでもなかなか難しいかなと思っています。
例えば僕がソフトウェアエンジニアとしていろんな勉強を始めたみたいなときっても、
オブジェクト思考みたいなのは出てきていて、
むしろそれが前世紀みたいなときだったんですね。
なので僕もその流れに乗って、
これが今は一番いいものなんだろうなと思って、
オブジェクト思考みたいなところからソフトウェア設計だとか、
コーディングの仕方とかも学んでいったみたいなところがあったりするので、
僕のベースはそこにあるんですけれども、
僕はオブジェクト思考だけをずっと突き詰めてやってきたのかというと、
そうではないんですね。
もちろんオブジェクト思考自体に、
ソフトウェア作りに対する新しいパラダイムを持ち込んだという価値があるのは、
それはそういうものだと思っているんですけれども、
僕自身はそれだけにとらわれるというのはネガティブな言い方なので、
ちょっと失礼になったかもしれないので、
そういう意図ではないんですが、
その一つのものにこだわるというよりは、
もう少し広くプロフェッショナルとしてのソフトウェアの作り手として、
ソフトウェアエンジニアリングというのをどう見るのかという点では、
一つのパラダイムだったり、
手法にスティックしすぎるというんですかね。
そのものだけを知っていてもやっぱり広がらないというのは当たり前だと思うんですよね。
なので、いかにちょっと違う、もしくはだいぶ違うものを取り入れるのかというところが、
視野を広げることに対しては大事ですね。
僕は運良くオブジェクト思考でずっとやってきたんですけれども、
ある時点でいいきっかけがあって、
データ中心アプローチとかいう方面の方々とすごく接点を持つことができて、
その方々から僕が今までやってきたソフトウェアの作り方と似た部分もあれば全然違う部分もある
ソフトウェア作りっていうのを学ぶことができて、
たまたまその時の方々ってなんていうのかな、
自分でソフトウェア設計方法論とかをデザインされてるような形だったので、
本当に突き詰めていろんなことを考えてらっしゃる方々だったんですね。
そういう方々の考えてるソフトウェア感ですかね、
と自分がその時点で持ってたまだまだ未熟なソフトウェア感みたいなものを比べて、
ある種、いいとこどりって言ったら簡単なんですけど、
一瞬でできるようなことではなくて、ああだこうだ、
その人たちとの議論というか、いろんな意見交換とかしながら、
何年も何年もかけて解釈して、
ようやく今の自分のソフトウェアエンジニアリング感にたどり着いたなみたいなところがあったりするので、
何かある種対立するようなソフトウェアエンジニアリングのパラダイムとか、
そういうものに触れる、触れるだけじゃなくて使うというか、
そちら側の良さ、一つのものの良さじゃなくて別のものの良さみたいなのを、
しっかり身に染みるまで味わうような経験を経て、
何か戻ってくると、ちょっと違う視野で物事を見ることができるようになるものだと思っていますので、
何とかして、どうにかしてそういった経験を得る努力っていうんですかね、
偶然要素が大きいかもしれませんが、
そういったきっかけに目を向けておくと、やっぱり転がり込んでくるものだと思って、
常に視野を広げるためにみたいなことを考えておくことがいいのかなと思っています。
ちょっと何かこれ、方法っていうには偶然要素が強いような僕の回答になっちゃうので、
あれなんですけれども、視野を広げることがとにかく大事ですよっていう話ですね。
終わりの挨拶と感想投稿のお願い
はい、というわけで今日はですね、
視聴者の方からいただいたお便りというかいうものについて、いくつかピックアップしてお話しさせていただきました。
まず送っていただいた方、どうもありがとうございます。
これからもいろいろこういった形で、もっとカジュアルなご質問とかも歓迎してますので、
何かいただけたらなと思っております。
さて、この番組では感想や質問、お悩み相談をお待ちしております。
エンジニアリングの現場で遭遇するあらゆるトピックについて、
番組詳細欄にあるお便りフォームよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。
EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、
こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株区スタイルCOO兼CTOの後藤秀成でした。
以上で終わります。ありがとうございました。
