Developers Boost 2020 基調講演 〜 「マネジメントキャリアパス」を振り返って

12月12日(土)に開催された Developers Boost 2020 にて基調講演を務めさせていただきました。

学生、20代のエンジニア向けの、僕自身が歩んだ「マネジメントキャリアパス」についての話です。

※ ここから先は、あまりオチのない話が続きます

講演の経緯

Developers Boost は30歳以下の若手開発者をターゲットとしたイベントで、運営の方から「ぜひ若手にキャリアの話をしてほしい」とお誘い頂いたのがきっかけです。

僕は「良いマネージャー・良い経営者」ではないかもしれません。うまくう行かなかったなぁと感じることも多く、「マネジメントはかくあるべき」なんて語れません。しかしキャリアの実体験やキャリア選択について語るのであれば、できます。若手エンジニアがキャリアを考えるきっかけになったらいいなぁ、と思って快諾させていただきました。

若手エンジニアの悩み：技術かマネジメントか

僕は技術を突き詰めたいと思って就職したはずが PM をやることになったので、「技術かマネジメントか」というのはずっっっと抱えていた悩みです。今でも悩みますが、マネジメントの道を進んでみるのは良い経験だったなぁと感じます。当時は辛かったんですけど...

何か商売をしたり、生産をする上で、顧客の気持ちを知るのは「お得」です。優秀な上司の元で働いて「顧客の気持ちは知らなくても成果が出る」というポジショニングもありますが、少なくとも、得です。顧客＝利用者様のことですが、顧客の概念を広げてみるのも面白いです。「もしドラ」では野球部の顧客を「教師」「部員」「親」まで広げているんですが、似たように自分の顧客を「上司」「同僚」「株主」とかまで広げてみると、それがきっと「経営視点を持つ」です。

技術と人のマネジメント：違うところ、同じところ

発表後の Ask the speaker では「技術と人のマネジメント、どういうところが違うと思いますか？」という質問がありました。僕は答えに困って「人のマネジメントの方がタフです」とかうっかり答えてしまったのですが、「マネジメントキャリアを選ぶ人を増やしたい！」と発表した後にする回答ではないですね...

答えに悩んだのは「あまり違わない」と思っているからかもしれません。

僕が好きな言葉の一つに「モデリング」という言葉があります。「メンタルモデル」とか「統計モデリング」とかのモデリングで、事象をなんらかの言語・記号・パターンで単純化して説明することを意味しています。例えば、次のようなモデリングがあります。

・機械学習では、人の集団行動を確率分布で表現する
・経営者や投資家は、会社の経営状態を「資産と負債」で整理する
・とんかつ DJ あげ太郎では、DJ を「とんかつ屋と同じなのか!!!???」で学んでいく

エンジニアに身近な例だと、「技術的負債」という言葉もモデリングでしょう。これは開発する上で発生する問題を、経営者向けに「バランスシート(負債と資産)」の考え方に言い直したものです。似たような試みは「技術を財務諸表で表現する」などでも整理されています。この「考え方のモデル」は人によって異なります。桃鉄プレイヤーと社長ではきっと「技術的負債」の解釈が異なるでしょう。

僕にとっては、技術のマネジメントであれ、人のマネジメントであれ、事業のマネジメントであれ、それらを「課題発見」と「意思決定」というモデル化をしています。

エンジニアとして働いていると、日々問題に遭遇します。設計が悪い、システム障害が起きた、引き継ぎをしないといけない、納期に間に合わないetc...そして、問題の目の前に居座っているのは自分です。それが問題であると感じるならば、そこから課題を発見・抽出し、解決策を見つけて、課題を解決しなければなりません(自力・依頼問わず)。これはマネジメントでも一緒です。僕はたまたま人マネジメントの問題の前に座ってしまった結果、自分の意思でマネジメントキャリアを歩むことになりました。

そして「意思決定」とは、デメリットを受け入れながら、メリットを享受するために何かを取捨選択して、選んだ答えを「正解」に導くことです。エンジニアリングでも一緒で、「最適な技術」は存在しません。良さそうな技術選定、言語選択などをしながら、なんとかデメリットを乗り越え、開発プロジェクトを成功に導くわけです。

もちろん、組織や事業は簡単にリファクタリング・リプレイス・プログラミングすることはできません。しかし自分がそれほど苦なく「開発以外」を続けられているのは、「同じもの」を見つけられたからかもしれません。

マネジメントのやりがいとか

自分の半年間の「経営課題」の一つは、新型コロナ関連の情報を多くの方に伝えるプロジェクトなど、複数の開発プロジェクトを成功に導くことでした。その中でやりがいを感じた瞬間は「インターン生の開発でプレスリリースを出す」を実現できたことです。

自分が内定者バイトをしてたときの心残りは、プレスリリースとして成果を出すことができなかったこと。だから JX のインターン生は積極的にプレスリリースに絡めたいと思っていて、今日リリースしたオンライン診療検索はその夢を叶えたものだったりする

— 小笠原みつき / JX通信社 / 70.4㌕ (@YAMITZKY) April 26, 2020

結果的には、平副大臣(当時)にツイートしていただいたり、テレビに取り上げていただいたので、それ以上の結果です。

これは、技術に携わっているだけでは実現できなかったことの一つで、きっと人それぞれ持っていると思います。

Re: 技術かマネジメントかの悩み

自分なりの答えは「両方」です。

趣味でコード書いたことによって、プロジェクト用の CMS が一瞬で作れたり、技術ロードマップを考える上で役立ったりしました。自分の中で、経営課題と技術は、リンクしているのを感じます。

逆に、技術を学ぶ時間を取れてないことで Kubernetes が十分理解できてなくてメンバーと同じレイヤーで会話できてないなぁ、とかの焦りもあります。あるいは、マネジメントに時間を取れてなくて起きている問題もあるはずで、メンバーが「このプロジェクトから離れた方が良いかもしれないっすね」と伝えてくれることもあります(ありがたい)。

...といった感じで、引き続き悩みながらも「両方」を突き詰め、あらゆる「顧客」に還元できるような道を見つけて行くのだと思います。それが自分の意思決定です。デメリットを受け入れながら、メリットを享受するために取捨選択して、選んだ道を「正解」にしたいと思います。