EMConf 2025プレゼン

Takeaways

1エンジニアとして十分なキャリアを積んでいれば、後押ししたい

打診されているなら引き受けることは社会資本がプラスになる

マネジャーのままエンジニアリングスキルを伸ばすことも可能

なぜなら"エンジニアリング"マネジャーだから

その悩みはあなただけのものではない

https://gyazo.com/43c83771a01024e4118a506670f5c974

Story1

これは誰に向けた講演か？

万人に効く処方箋は出せないが...

講演者の経験と反省、二刀流ができそうだと思うこと。そして再現性についての考察

二刀流はプレイングマネジャーを奨励/礼賛するものではない

どちらかに専念する時期があるのは当然

二刀流という生き方、2つの武器を持つ生き方を肯定したい

1つしかない自分のキャリアに意味を与えるもの

人生一回しかないんだしやりたいことやる

過去の選択も未来の選択も自分が正解にしていく

講演者のキャリア（生存バイアス上等）

1社目: 大手SIer

2社目: 教育サービス

(1)いちエンジニアとしてコンフォートゾーンの不安

(2)EMとしてパニックゾーンの不安

3社目: 金融・決済サービス

(3)2週目、振り子の実現性の不安

事例

(1)いちエンジニアとしてコンフォートゾーンの不安

最初の2年を乗り越えて成長の鈍化を感じた

マネジャーになることなんてまったく考えていなかったが、組織の拡大に合わせて必要になった

日常の業務を漫然と続けるだけで成長するフェーズは終わった

という課題意識もあれば、健康に長く働ける組織にもしたかった

結果

(2)EMとしてパニックゾーンの不安

「何をすればいいのか」答えがない

エンジニアリングマネジメントに関するコミュニティをやっているとマネジメントの専門家なのではと誤解されることもあるのですが、逆です。学びたいからコミュニティを作ったのです。

時間軸の意識、抽象度の高さ

(3)2週目、振り子の実現性の不安

とはいえ、自分の技術力が技術領域のマネジメントのボトルネックになっていないか？

ICに戻るパスを探して転職

再びいちエンジニアとして0→1のカード決済システム開発へ

思っていたよりもうまくやれた、磨いたエンジニアリングスキルを外に発表する機会もたくさん得られた

3年ほどグロースに関わったのち、再び組織の拡大に合わせてEMが必要になったのでやることに

同じ仕事は二度とないので実際は螺旋に感じる

3つを通しての発見や学び

マネジャーはまったく別の職種はその通り

でも1個人の道のりとしてどのような意味を与えるかは自分次第

中心にエンジニアリングやビジネスや人間を置く限りはそんなに大きく変わらない

それぞれの学びはコストではなく資産になりうる

すべてを計画することはできない、機会に対して備えてオープンでいることはできる

まとめ

上記Takeawaysの内容

Story2

これは誰に向けた講演か？

同上

講演者のキャリア

1ページでさらっと自己紹介

課題

（マクロ）マネジャーの負荷（課題なのか？は後述）。循環しており相互に増幅しあう

世のEM大半がプレイングマネジャー

人材不足

（ミクロ）エンジニアリングマネジャーのキャリア二大不安。循環しており相互に増幅しあう

技術力の衰えに対する不安

キャリア選択の幅が狭まる (Individual Contributorに戻れない) ことへの不安

今回の発表は後者の不安に対して対峙した一個人の目線からボトムアップで提言する

いきなり世を変えられないが、ここにいるEMや資料を見たEMが同じ不安を抱えているなら解消したい

不安への対峙

技術力

キャリア選択

不安への対峙を通しての発見や学び

マネジャーはまったく別の職種はその通り

でも1個人の道のりとしてどのような意味を与えるかは自分次第

中心にエンジニアリングやビジネスや人間を置く限りはそんなに大きく変わらない

それぞれの学びはコストではなく資産になりうる

すべてを計画することはできない、機会に対して備えてオープンでいることはできる

まとめ

上記Takeawaysの内容

Note

大局的な思考

技術投資には目的がある

実行力

レベルアップ

重要だが緊急でない仕事に投資

会社、チーム、自分という順序のフレームワークもよいが...

自分の経験

悩みやアイデアを理解する必要に迫られる

局所的な解決ではなく時間軸を意識し、長期的に積まれるメリット/デメリットを考慮する

抽象・具体、短期・長期

インプット

マニュアル化してうまくいく部分がほとんどない、効果の実証された方法論などありえない

多くの場合、業界に入って他の人がやっているのを見るまでは、マネジメントについて学ぶことはありません。自分たちの会社でチームを運営する機会があることを知って、初めて学ぶのかもしれません。残念なことに、キャリアアップの唯一の方法として、マネージャーになる選択を強いられることもあります。

つまり、私たちは十分な準備もしておらず、何ら正式な教育も受けておらず、マネージャーとして何をすべきかもわかっていないのです。私たちは仕事をしながら周りの人たちから学ぶことしかできません。自分たちのマネジメントのやり方が適切かどうかの確証も持てません。

15.4.1　マネージャーは両方のトラックにいるのでは？

あなたがいるトラックは、あなたが第一優先すべき職務を定義したものです。マネジメントトラックにいながら、マネジメントの責任を怠ることなくたくさんのコードを書いているというのであれば、素晴らしいことです。しかし、マネジメントトラックにいながらコードを書いて、マネジメントの責任に弊害が出ているのなら、時間の使い方を考え直す必要があります。

本書を読んでおわかりかと思いますが、優れたマネージャーになるには、たくさんの練習が必要です。あなたが優秀で、マネージャーになるべくしてなるような人であれば、コードで貢献する時間をもっと確保できるかもしれません。しかし、まずは自分がマネージャーとして十分な成果を出せているかを確認をすべきです。チームはあなたにその仕事をして欲しがっているのです。

https://gyazo.com/2a3eeedfa82d417d2350902fed9a43b5

大局的な思考

局所最適解を避けるには、複数のチームの目標を俯瞰的に検討し、組織全体またはビジネス全体にとっての最善の道を選択できる、外からの視点を持った意思決定者（少なくとも意思決定に影響を与える者）が必要です。

https://gyazo.com/ab5fcfad3c8183dda5e6fec1ae5acedb

プロジェクトの実行

プロジェクトリーダーであるあなたがどの程度コードを書くかは、プロジェクトやチームの規模、あなた自身の好みによって変わってきます。チームの規模が小さければ、すべての変更に深く関わるかもしれません。

ただし、より困難で重要なことを犠牲にしてコードを書いている場合には注意が必要です。それは、4章で言及した「間食」の一形態です。その場合、あなたは、影響範囲が大きくて難しい設計上の決断や重要な組織的な駆け引きを避け、どうやって取り組むかわかっている仕事（そしてフィードバックループが短い仕事）に逃げてしまっています。

停滞

驚くほど多くのプロジェクトが、あと一歩のところで成功から遠ざかっていたり、素早い修正が行えずに新たなチャンスを逃していたり、ちょっとした会話ができていなくて合意に至れていなかったりします。保持している組織的な特権、社内で築き上げた人間関係、そして経験から得た隅々まで見通す能力をもってすれば、ほんのわずかな労力を投じるだけで、プロジェクトの結果を変えられるかもしれません。それは、あなたが行うことの中で最も価値のある仕事の1つです。

ロールモデル

上級職につくタイミング

エンジニアとして確固たる地位を築くまでは、決して管理職を引き受けてはいけません。確固たる地位を築くには、それは少なくとも7年以上コードを書いて出荷している必要があると私は考えます。間違いなく、絶対に5年未満ではありません。誰かから管理職をオファーされると、褒め言葉のように感じるかもしれません。もちろん褒め言葉として受け取っても良いのですが、あなたのキャリアや能力を発展させるという点で、それは何の役にも立ちません。

これはスタッフプラスレベルの職位も同様です。エンジニアリング職から遠ざかるような職務に就く前に、もう一度よく考えてみてください。そうしないと、没頭して実地経験を積める絶好の時期から目を背けることになりかねません。

学習

役割が学習の継続を妨げていないかに注意してください。特に、技術から遠ざかりすぎて、自分の会社の運営方法しか学んでいない場合には警戒してください。事業理解を深めて賢い選択をすることも重要ですが、技術に根ざしたままでいることが大切です。9章では、学習についてさらに詳しく説明します。

悩みの共有しづらさ

最後に、不安やフラストレーションを共有する場所には慎重になりましょう。問題があると認めるのは構いません。ですが、それについての心配を下位の人々に流出させないでください。彼らにあなたの懸念を背負わせるのは公平ではありません。彼らを動揺させることで、問題を増幅させてしまいます。心配を自分だけで抱え込む必要はありません。心配は、マネージャー、親しい同僚、または5章で選んだプロジェクトの相談役に打ち明けましょう。

他の人があなたと一緒に働きたいと思うかどうかが、成功の指標です。あなたと働きたくない人が多いのであれば、自分のアプローチを見直しましょう。

9章

上司がキャリアの支援をしてくれる可能性もありますが、スタッフエンジニアより先のキャリアでは特に、それは保証されません。スタッフプラスレベルになると、上司はあなたを助ける方法さえ知らないかもしれません。あなたが歩んでいる道を、彼らが経験しているとは限らないからです。上司だからといってすべてを知っているわけではありません。成長に役立つ機会を探すために、必要なアドバイスや教育、ガードレールを他に求めるかどうかは、あなたに委ねられています。

自分の得意なことに集中すべきだ、という意見をよく耳にしますが、私はそれには全く同意しません。自分が得意になりたいことにポイントを投入して、そのスキルを積み上げていくべきだと考えています。

自分が経験したいことができる役割を選びましょう。大企業でしか学べないこともあれば、小さな会社でしか学べないこともあります。マネージャーになれば簡単にできることもあれば、本当に手を動かさないとできないこともあります。

まさにな項

9.3.7　管理職に就く

管理職に興味を感じているでしょうか。スタッフエンジニアの中には、完全に管理職の道に進み、そこで成長を続ける人もいれば、管理職を経験したあとで、またインディビジュアルコントリビューターの役割に戻る人もいます。

世界で最も優秀な最前線のエンジニアリングマネージャーは、実務から2～3年以上離れたことがなく、フルタイムで現場にいる人たちです。世界最高のインディビジュアルコントリビューターは、管理職を経験した人たちです。そして、世界最高の技術リーダーは、多くの場合、その両方を行う人たちです。行ったり来たり。振り子のようにしてその両方を兼ね備えるのです。

Majorsは、管理職になることを決して昇進とみなすべきではないと強調します。それは異なるスキルセットを学ぶ必要がある別の専門職への変更です。ピープルリーダーシップからテクニカルリーダーシップへ、あるいはその逆であっても、ステータスは変わるべきではありません。それぞれが別々のスキルセットを構築し、他方のスキルを強化するでしょう。しかし、彼女は両方を一度にやろうとすることは勧めていません。「一度に本当に上達できるのは、エンジニアリングかマネジメントのどちらか一方だけです」

この種のハイブリッドな役割に就く場合は、それを持続可能なものにするための計画を立てておくことです。おそらく、必要なときに任せたり、頼ったりできる他のシニア人材を揃えておきましょう。

Amazonレビュー

マネジメント系の本は、単なる個人的な運の良さを「自分のやり方が良かったからだ」と誤認して部下に説教する感じで書かれたものや「道徳的に正しいことがマネジメントである」みたいな極端な抽象思考にぶっ飛んでいく宗教みたいな書籍によく当たるのですが、この本はそういうことがなく、現実的で、著者の直面した課題とやったことが事実として書かれているので良かったです。