HAPPY NEW YEAR 2024
あけましておめでとうございます!
今年もよろしくお願いいたします!
今年も年越しはロンドンの自宅です。どこかへ行こうかという話もあったのですが、去年は春に日本、夏にフランス、秋にベルギー&オランダと、いつもよりも旅行多めな年を過ごしていたため、クリスマス休暇や年末年始はロンドンでゆっくりしよう、という結論になりました。
大晦日は雨でテニスキャンセルになりましたが、休暇中それ以外の日は毎日テニスをして過ごしていました。
最高ですね!
というわけで、例年通り振り返りです!
時系列順に大きな出来事をまとめてみます。
- 4年半ぶりの日本一時帰国
- イギリス永住権取得
- 約一年間で三度目のレイオフ
- WASO でお手伝い開始
- 就職活動無事クリスマス前に終了
ちなみにこれ以外は基本的にテニスして、テニス見に行って、あとはずっとテニスしてました。
基本的に、ほぼ毎日テニスしてます。当然ですが、結構上達してきました。してきましたが、目標としているレベルには全然届いてないので、まだまだ頑張ります。
4年半ぶりの日本一時帰国
2018年の年末依頼となる日本への渡航を行いました!長距離フライト大嫌い(好きな人いるの?笑)なのとコロナで、ものすごく久しぶりの日本となりました。 日本ではテニスして、テニスして、テニスして……テニスしました。
というのは全く冗談ではなく、テニスをしつつ東京では毎日温泉に通い、大阪では妻の実家、広島で私の実家と弟一家、島根で妻の祖父母宅への訪問と、一大ツアーを行っておりました。 2週間で数日おきに別の都市に移動するのは、なかなかハードでした。楽しかったですが、メチャクチャ疲れました!
帰りの飛行機は「旅は最後の最後まで楽しくしたい。帰りも最高にするぞ!」ということで、妻が寝たあとにサプライズでビジネスにアップグレードして帰りました。
広い座席と最高のフランスワインとフランス料理を堪能しながら片道15時間の旅を終えました。
いや、日本遠すぎるって……。
イギリス永住権取得
永住権取得しました!これで会社に縛られることなくイギリスに住めます! ある意味自由の身になったので、ちょっとだけ面接受けたりもしてみました。
とか言ってたら……。
約一年間で三度目のレイオフ
昨年11月、約1年間で三度目のレイオフが決行されました。 最初のレイオフからビジネス上、一切の進捗がなかったので仕方なさすぎます。
そして今回はなんと対象になりました!
クリスマスまであと1か月、次の春には住宅ローンの金利が爆上がりするこの時期になんてっこったい!
ただ、2023年はエンジニアリングマネージャーとして本格的に働いてみた結果、正直熱意もモチベーションも低いなと感じていたタイミングだったので、悪くはないタイミングでした。 永住権も手に入ったし、なんだか熱量も下がってるし、これを気に新たな環境に飛び込むぞ!という、良い方向に考えることができました。
端的に、やっぱり Backend Engineer がしたいな、それをやってる時期が一番モチベーション高かったな、そしてモダンな SaaS 良いよね、と、そんなことを考えていました。
WASO でお手伝い開始
退職日から1週間後、WASO の創業者と縁があり、Ruby on Rails を書ける人が今すぐ欲しいとのことで、12月1日からお手伝いすることになりました。 僕の周りのイギリス在住日本人の認知度100%(流石に利用率は100%ではなかった)の絶賛成長中のサービスです!
ありがたいことに収入源が確保できたので、レイオフでもらった退職金(結構まとまった額)は、住宅ローンの早期返済に全部当ててしまいました。
住宅ローン、このまま放置してたら来春に月々の支払いが1000-2000ポンド増えるところだったので、助かりました。
エンジニアとしての仕事に戻るか~と考えていた時期なので、再びしっかり手を動かし始めるのに良い環境でした。
年末、ギリギリ1か月でやりたかったところまで最低限終わり、少しは貢献出来たと思います。 ほぼ1月もフルタイムで働くので、できる限りの結果を出したいところ!
2月以降は副業として関わることになると思います。
ぜひお互い Win-Win になるよう、成果を出したいと思います!
就職活動無事クリスマス前に終了
12月から就職活動を始め、なんとかクリスマス前にオファー受諾まで辿り着けました! SaaS を提供してる FinTech スタートアップで Senior Backend Engineer として働く予定です!
まだ契約書にサインしていないので、まだ詳細は伏せますが、pre Series A でプロダクトマーケットフィット直後でこれから伸びる可能性が大いにあるサービスです。
少し触れましたが、モダンな SaaS 作りたいな~と思ってたので、最高に楽しみです。
バックエンドは Node.js 上で TypeScript + NestJS だそうです。
就職活動をしてみて、プログラミング言語は明らかに TypeScript と Python の二強だったので、ガッツリ TypeScript を、しかもバックエンドメインで書けるのは、その点でも嬉しいです。
現在は明らかに少数精鋭部隊の状態なので、足引っ張らないように頑張ります!ちょっと不安!
テーマ
毎年恒例の振り返りです。2023年のテーマは、
- 成長(メインフォーカスへの更なる注力)
- 語学(英語とフランス語)
- 健康(睡眠、運動、食事)
でした!
成長(メインフォーカスへの更なる注力)
エンジニアリングマネージャーとして、最低限一通りは抑えることができた一年になったと思います。 やった結果として、Individual Contributor (IC) に、具体的にはバックエンドエンジニアをしようと思えたのが一番良かったと思います。
実際、仕事は12月に WASO でエンジニアをし始めてからの方が、明らかに楽しいです!
そして仕事以外ではテニスですね!ゴリゴリにやってます。このまま頑張ります!
一応 UK ランキングポイントをゲットして国内ランキングが付きましたが、まだまだです。
周りの強い上級者の方々の背中が見えてる気はするので、この調子で頑張ります!
まだまだ遠いけど!コツコツ頑張るしかない!
語学(英語とフランス語)
英語はもう、生活の一部なので、特筆すべきことはありません。 Duolingo での毎日フランス語学習は継続中です!
パリに旅行に行ったときに、Uber ドライバーで超初級フランス語でコミュニケーション取ったのがハイライトです。笑
英語と違って必要になる場面が少ないのでモチベーションの維持が課題ですが Duolingo のゲーム性のおかげで、多少でも毎日は続けれています。
健康(睡眠、運動、食事)
運動はテニスをしている限り問題ないです。 睡眠は本当に課題です。どうして早寝できないのか?どうして翌朝キツイとわかっていて夜更かしするのか?
食事は……まぁ間食の質を変えたほうが良さそうです。ポテチ多すぎる。
運動のし過ぎでカロリー不足なので、間食は必須なので、質の向上が目指す方向性ですね。
皆さん、早寝するコツと、オススメの間食、教えてください!
2024年のテーマ
- 再挑戦(新環境でエンジニアとしてリスタート)
- フランス語(今年も一年間通してコツコツ続ける)
- 健康(睡眠、運動、食事)
としたいと思います!
そして今年ももちろん、
将来の自分が過去の自分に向かって胸張れる存在になれるようにマイペースに生きていきたい
という自分の言葉と、
『小さいことを積み重ねるのが、とんでもないところへ行くただひとつの道』
というイチロー選手言葉を今年も大切にしていきたいと思います!
2024年も最高に楽しんでいきましょー!
ぴーす!
【2023年版】WSL を利用し Windows 上に Ubuntu の開発環境を構築する
2023年も終盤ですが、久方ぶりにフレッシュな環境構築を行いました。 来年4月に Ubuntu 24.04 が出た際に全く同じ手順を辿るかもしれないので、構築方法をまとめておきます。
大部分は過去に行った内容通りです。
ちなみに何故か Mac のセットアップは Gist にまとめています。
Notes to set up macOS · GitHub
WSL の導入
2022年11月に Windows Store で WSL が公式リリースとなっていたようなので、Windows Store からダウンロードします。
既に導入済みの方は wsl --update
で最新のストア版が導入されるようですが、私は Windows Store からダウンロードしてみました。その後 Powershell から wsl --update
を叩いてみたところ、The most recent version of Windows Subsystem for Linux is already installed.
と出たので、このあたりはうまく連携しているようです。
気が付いたら Windows Store 周りがかなり整備されてそうですね。
Ubuntu 22.04 の導入
こちらも Windows Store から導入できます。
WSL と言ったら2023年現在は WSL 2 を指すと思うので確認が必要かはわかりませんが、wsl -l -v
を実行すると WSL のバージョンが確認できます。
> wsl -l -v NAME STATE VERSION * Ubuntu-20.04 Stopped 2 Ubuntu-22.04 Running 2
以前導入した 20.04 に並んで 22.04 が表示されているので、問題なさそうです。
Windows Terminal の導入
こちらも Preview ではく公式リリースされており、導入から設定まで GUI で完結するようになっていますね!
Colour Scheme や Starting Directory が GUI から設定可能になっているので、必要に応じて設定します。私は今回デフォルトで問題ありませんでした。
最近、常にデフォルトを心がけています。笑
Ubuntu の CLI 環境構築
Terminal
開発に最低限必要となるツールをまずは一式導入します。
sudo apt update sudo apt upgrade sudo apt install vim-gtk git tmux xsel curl direct ripgrep tig gh make exuberant-ctags
そして GitHub 公式に従い、新しく SSH Key の生成と登録を行います。
個人的に .ssh
内ではディレクトリによる鍵の管理を行いたいので、以下の設定を .ssh/config
に追記し、ssh -T github.com
による疎通確認を行います。
Host github.com HostName github.com User git IdentityFile ~/.ssh/github/id_ed25519
GitHub へアクセス可能になったら dotfiles 一式を README に従い導入します。
README の記載にある通り、GPG Key の生成を行い、環境変数 export GIT_CONFIG_PARAMETERS="'user.signingkey=<YOUR GPG KEY ID>'"
を利用し、Git の設定に動的に流し込むようにする。
README に記載のあるツール一覧の導入を行えば、基本設定は完了です。
Docker
PostgreSQL などを Docker で使いたいので、Docker を導入します。この方法が一番バージョン管理がしやすいと思います。
その後、sudo
なしで使うための設定を行います。
PostgreSQL Client - psql
PostgreSQL のクライアント psql
は apt
で導入しておきます。
sudo apt install postgresql-client-common postgresql-client
在英6年目に突入し、イギリスの永住権を取得しました!
ロンドン在住が丸5年を突破し、6年目に入りました!
なんとこれでロンドンが人生で二番目に長く住んだ都市に😮🥳
そして、そして、ついに、ついに、
イギリス永住権取得完了!いやっほーい!
— 雀巽(じゃくそん) (@necojackarc) June 28, 2023
🎉🎉🎉🎉🎉
というわけで、これからもロンドンにいる予定です🇬🇧
みんな遊びに来てね✈️🥳
エンジニアリングマネージャーのやさしい定義
ソフトウェア開発に関するジョブタイトルやポジションは多くが英語圏から輸入された言葉で、代表的なものを挙げると、テックリード、プロダクトマネージャー、そして CTO があります。
本記事ではその中のエンジニアリングマネージャーにフォーカスし、役割、責任範囲、必要となるスキルに触れ、エンジニアリングマネージャーというポジションをわかりやすく定義します。
そこそこ長文になってしまったので、時間のない方は最後のまとめだけでも目を通してみてください。
執筆の動機
自分自身がエンジニアリングマネージャーというポジションについて3年目ということもありますが、日本におけるエンジニアリングマネージャーの情報があまりに錯綜している、というのが最も強い動機です。
これらの借用語の中でもおそらく日本で注目され始めたのが近年ということもあり、エンジニアリングマネージャーは、なんだか新しい、従来のマネージャーとは違う魅力的なポジションと捉えられている側面があるように感じます。
筆者はイギリス在住イギリス企業勤務ですが、少なくともイギリスにおいてはエンジニアリングマネージャーは新しいポジションではありません。ただし実際の仕事内容はバラエティに富んだ、モダンで魅力的なものだとみることもできます。それがなぜかについては本記事を読んでいただければわかると思います。
前提知識
- Individual Contributor (IC) vs マネージャー
- マネージャーのアウトプット
- アカウンタビリティ vs レスポンシビリティ
- 権限委譲とそのスケール
これらの知識はエンジニアリングマネージャーの役割を理解するうえで最低限必要な知識であるため、簡単に解説しておきます。
Individual Contributor (IC) vs マネージャー
マネージャーは自分の直属の部下からなるチームを持ち、IC はそうではありません。また、マネージャーとリーダーを区別することもありますが、組織構造の文脈でこれらを区別する利点はないので、本記事では区別しません。
マネージャーのアウトプット
マネージャーのアウトプットは以下の通りに定義されます。
自分のチームのアウトプット + 自分が影響を与えた人のアウトプット
こちらは Become an Effective Software Engineering Manager で紹介されている定義の通りです。
マネージャーとして最も重要な指標になるのが自分のチームのアウトプットとというのはわかりやすいと思いますが、後者の影響を与えた人 (原文では the output of others that you influence) は少しわかりにくいかもしれません。簡単な例は「意思決定への貢献」です。自分のチーム外への貢献度合いと言い換えることができます。
アカウンタビリティ vs レスポンシビリティ
アカウンタビリティとレスポンシビリティに厳密に対応する語彙が日本語にはありません。辞書を引くと最初に「説明責任」と出てくるので、アカウンタビリティを単に説明責任と覚えている方もいると思います。この翻訳は間違いではないですが、これだけではアカウンタビリティの意味を理解するのは難しいです。
- アカウンタビリティ: 結果に対する責任。結果の帰属先(オーナーシップ)。
- レスポンシビリティ: 実行に対する責任。実務の担当範囲。
アカウンタビリティが説明責任と訳されるのも、結果が帰属するからです。そのチームのアウトカムに対してオーナシップ*1を持つということは当然、それらを説明できる必要があります。それに対してレスポンシビリティは担当のタスクをやり遂げる、実行に対する責任です。
いかにフラットな組織でも、会社に代表は存在する*2ので、会社が行ったことに全て対するアカウンタビリティはこの代表に帰属するわけです。
権限委譲とそのスケール
権限委譲とは一言で表すと「アカウンタビリティを保持したままレスポンシビリティを移譲すること*3」になります。
そして権限委譲はグラデーションになっており The Scale of Delegation のように説明されます。
Source: Become an Effective Software Engineering Manager
自分でやる、具体的なやり方を伝える、大まかな方針を伝える、やり方も任せるが適宜確認する、完全に任せるのように推移していきます。完全に任せたとしても、アカウンタビリティは手放さないので、成果や状況など、結果に対する説明責任は負っている*4ことに注意しましょう。
エンジニアリングマネージャーの定義
前提知識をカバーしたので本題に入っていきます。
一言でエンジニアリングマネージャーを表すとエンジニアリングチームの担当範囲の全てににアカウンタビリティを負ったチームリーダーです。
定義はこれで終わりなのですが、抽象的過ぎると思うので詳しく踏み込んでいきましょう。
2つの意味を持つマネージャー
エンジニアリングマネージャーの詳細に踏み込む前に、エンジニアリングマネージャーを掴みどころのない存在としているもう一つの原因にここで触れておきたいと思います。
それは「マネージャーが2つの意味で使われている」ということです。チームリーダーとしてのマネージャーと、チーム以外の何かをマネジメントするマネージャーです。誤解を恐れず言うと上司と専門家になります。
最もわかりやすい後者の例がプロダクトマネージャーになります。プロダクトマネージャーはプロダクトのマネージャーであって、プロダクトチームのリーダーではありません*5。プロジェクトマネージャーも同様の例になります。
エンジニアリングマネージャーのマネージャーをこれらと同等に捉えて「エンジニアリングマネージャーはエンジニアではなく、エンジニアリングをマネジメントする」だから「エンジニアリングマネージャーは単なるエンジニア達のマネージャーではない」と言う方が一定数居ます。
残念ながらそんなことはなく、エンジニアリングマネージャーは基本的にはエンジニア達のマネージャーです。なぜならエンジニアリングマネージャーのマネージャーが表すのはチームリーダーというポジション*6だからです。
エンジニアリングマネージャーが新しいポジションではない理由はこれで伝わったかと思います。なぜならそれはエンジニアリングマネージャーはエンジニアリングチームのリーダーを指すからです。
では、なぜそれが場合によっては魅力的な、人によっては新しいとすら感じるポジションに映るのか、職務を詳しく見ていくことで説明します。
エンジニアリングマネージャーの職務
エンジニアリングマネージャーの担当範囲は、エンジニアリングチームの担当範囲全てに該当します。なぜならばチームの全てにアカウンタビリティを負うからです。
もちろん、エンジニアリングチームの担当範囲全てを自分一人で担当するのは基本的には不可能です。そこで権限委譲が鍵になります。
適切な権限委譲を行うことが、エンジニアリングマネージャーとして最も大切な仕事の一つとなります。
そして何をどのように権限委譲したかによってエンジニアリングマネージャー自身に残るレスポンシビリティが決まります。
これはどういうことかというと、担当範囲全てにアカウンタビリティを持つが、当然一人では担当できないので、レスポンシビリティを渡していくことになります。そして渡さなかったレスポンシビリティや渡し方の度合 (the scale of delegation) により、エンジニアリングマネージャー自身に残るレスポンシビリティが決まるということです。
エンジニアリングチームの職務
エンジニアリングチームの担当範囲を見ればエンジニアリングチームの担当範囲の詳細がわかることになります。
ここでエンジニアリング組織論への招待 で有名な広木さんの書いた人気の Qiita 記事エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイドを見てみましょう。
おそらくこちらがエンジニアリングチームマネージャの日本語情報で最も参照されているものの一つなので、強い EM や弱い EM という単語を聞いたことがある方もいるのではないでしょうか*7。
こちらのスキルセット、ピープルマネジメントを除いてソフトウェア開発チーム*8に求められるスキルセットと同一と言っても過言ではないことがわかると思います。
広木さんの言うところの強い EM はつまり、「ソフトウェア開発チームの担当範囲全てに一定量のレスポンシビリティを残したままのエンジニアリングマネージャー」を指します。
弱い EM を見てみると、一般的に専門家、例えばプロダクトマネージャーやプロダクトマネージャーを抱える分野が削られているのがわかると思います。
どのレスポンシビリティをどれだけ誰に委譲するかは、完全に組織構造とメンバーのスキルセット、そしてエンジニアリングマネージャーの裁量に依存します。
ただし、この中で絶対に権限委譲をしない分野があります。それはピープルマネジメントです。ここを委譲するとマネージャー=チームリーダーで無くなってしまいます。
まとめると「エンジニアリングマネージャーはソフトウェア開発チームの担当範囲の全てにアカウンタビリティ(結果への責任)を持つ。レスポンシビリティ(実務の担当範囲)は権限委譲の度合いにより決まる。ただし権限委譲を含めたピープルマネジメントは最も重要なレスポンシビリティとして必ず残る」となります。
組織構造による職務の違い
ここまでソフトウェア開発チームとひとまとめにしてきましたが、会社によってソフトウェア開発チームの組織構造は大きく異なります。それどころか、同一の会社内であっても、ソフトウェア開発チームの組織構造が異なるということは往々にしてあります。
例えばプロダクトマネージャーがエンジニアリングマネージャーの直属でないケース、テックリードがチーム内に居るケースなど、様々なバリエーションがあります。
またチームトポロジーでいうところのプラットフォームチームにはそもそもプロダクトマネージャーが居ないケースもあるでしょう。
全てパターンをカバーするのは組合せ爆発が起きるので不可能ですが、代表的な例をいくつか取り上げ、具体的にエンジニアリングマネージャーに残るレスポンシビリティを見ていきましょう。
プロダクトマネージャーの有無
プロダクトマネージャーが自チームの直属の部下である場合、プロダクトマネジメントのアカウンタビリティもエンジニアリングマネージャーに直接帰属することになります。この場合、自チームのプロダクトマネージャーにどこまでレスポンシビリティを委譲するかは自己判断になり、さらにプロダクトロードマップなどの最終決定権も帰属するため、プロダクトマネジメントに対する深い理解が求められます。
しかし、プロジェクトマネージャーが直属の部下でない場合、直接的なアカウンタビリティは帰属しません。そのためプロダクトマネジメントは must-have なスキルでは無いとも言えます。ただしここで、マネージャーのアウトプットは「自分のチームのアウトプット + 自分が影響を与えた人のアウトプット」であることを思い出してください。プロダクトマネージャーは最も明確にエンジニアリングマネージャーが影響を与えられる相手であり、職務上プロダクトマネージャーの意思決定に貢献することは期待されることの一つとなります。また、この場合でもプロダクトをどのようにデリバリーするかというのは開発チームの職務になるため、デリバリープロセスマネジメントのアカウンタビリティはエンジニアリングマネージャーに帰属しています。
そしてプロダクトマネージャーがそもそも存在しないケースも存在します。これはプラットフォームチームで見ることが多いです。理由としてはプラットフォームチームはエンドユーザーが自社内のエンジニアや他のソフトウェア開発チームであり、必要とされるプロダクトマネジメントスキルが異なるためだと思われます。この場合は当然、エンジニアリングマネージャーがレスポンシビリティを委譲する相手が居ないので、プロダクトマネジメントを自分で行う必要があります。
テックリードの有無
テックリードは、エンジニアリングマネージャーと混同されることが多いポジション、またはロールです。
テックリードは、エンジニアリングマネージャーが持つテクノロジーマネジメントのレスポンシビリティを大きく委譲したメンバーになります。何をどれだけ委譲するかは当然テックリードのスキル、チーム構成、そしてエンジニアリングマネージャーの裁量に委譲します。
一般的には「チームがオーナーシップを持つプロダクトの How に対するほぼ全権限*9が委譲されたエンジニア」というパターンが多いのでは無いでしょうか。そしてエンジニアリングマネージャーに求められるのは「テックリードが決定権を持つ範囲の定義 = 権限委譲」です。
テックリードが居ないチームであれば、テクノロジーマネジメントに関する大きな権限委譲ができないので、エンジニアリングマネージャーがテックリードを自動的に兼任することになります。そのため、表面上だけ話を聞くと、エンジニアリングマネージャーの仕事とテックリードの仕事がとてもよく似ていることは多々あります。
一番の違いはチームのアカウンタビリティが帰属しているか、言い換えると直属の部下が居るかどうかになります。
エンジニアリングマネージャーはマネジメントパスですが、テックリードは IC パスなのです。
採用人事権
エンジニアリングマネージャーの最も重要な仕事はチームの担当範囲のアウトプットの最大化です。そのため、ソフトウェア開発チームの担当範囲である、テクノロジー、プロジェクト、そしてプロダクトに対する十分な理解、そしてそれらの領域でチームの成果を最大限にするためのピープルマネジメントがエンジニアリングマネージャーには求められます。
ピープルマネジメントには権限委譲も含まれますが、それを最大限に活用するために必要なのはなんでしょうか。もちろん業務内容の十分な理解に加え、メンバーの特性やスキルの把握は必要です。ですがそれだけでは不十分です。そもそも委譲を行うためのメンバーがチーム内に存在しないケースがあるからです。
その場合必要になるのが採用人事権です。
ピープルマネジメントの一環に、権限委譲やメンタリングを通したメンバーのキャリア支援は当然含まれますが、不足しているロールの定義とその採用も含まれます。
日本の採用方式と相性が悪い気はしますが、通常はエンジニアリングマネージャーは自チームの採用責任者になります。
ジョブディスクリプションの作成、面接のプロセスの定義と実践、採用可否判断、試用期間中における本採用の決定などエンジニアリングマネージャーの職務に含まれます。そしてそれを実践するためには、自チームの担当範囲に対する深い理解が求められます。
純粋なピープルマネジメントという幻想
ピープルマネジメントと聞くと一見、対人間のスキル以外を使わない仕事だと捉えてしまうかもしれません。
ですが、純粋な対人間スキルだけを使うピープルマネジメントは存在しません*10。エンジニアリングに対する専門知識が無い状態で、権限委譲、職責定義、メンタリング、キャリア定義や支援などが行えるでしょうか?難しいでしょう。もちろん、純粋な対人間スキルも数多くあります。ただ、専門チームのリーダーとして、それらを活かすには専門知識が欠かせません。
ピープルマネジメントは自分の専門分野とのコラボレーションで初めて力を発揮します。専門分野への深い理解があって初めて、ピープルマネジメントが生きるのです。
まとめ
- エンジニアリングマネージャーは、エンジニアリングチームのマネージャー
- エンジニアリングチームの担当範囲全てが、エンジニアリングマネージャーがアカウンタビリティを負う範囲
- 求められるスキルはソフトウェア開発への深い理解と、その上でピープルマネジメント
- チームのアウトプットを最大化するのが最も重要な責務で、その鍵は権限委譲
- 組織構造と権限委譲の度合に応じて、実務におけるレスポンシビリティは多種多様
おわりに
エンジニアリングマネージャーは、ソフトウェアエンジニアリング領域でのピープルマネジメントがコアとなる、単なるマネージャー職であることがはっきりしたと思います。そして権限移譲をするためにはエンジニアリングに対する理解が必要不可欠なことも伝わったと思います。
一部の日本企業のエンジニアリングバックグラウンドのないマネージャー、例えば開発のことがわからない開発部長、これらが従来のマネージャー職のイメージを作っているのが、エンジニアリングマネージャーという言葉が輸入された理由なのかもしれません。
エンジニアリングマネージャーと開発部長の間に根本的な違いは存在しません。もしあなたの会社に開発のことがわからない開発部長が居るならそれは、組織構造上の不具合です。具体的には、開発部長を任命した人間の明確な過失です。開発のことがわからないのに、開発部の結果に対するアカウンタビリティを持ち、適切な人材を配置していくのは困難です。これはどの組織でも同じだと思います。法務がわからない法務部長、経理がわからない経理部長、それらが存在するなら明らかに配置ミスです。
ピープルマネジメントは専門領域とのコラボレーションにより力を発揮します。
最後に、エンジニアリングマネージャーに限らず、数多くあるロールやポジションも、IC かマネージャーか、所属するチームの担当範囲は何か、そしてどの権限が委譲されてるのかを見れば、名前に惑わされず本質がつかめると思います。
ポジションやロールというのは、権限委譲をパターン化したものと言えるのかもしれません。
*1:余談ですが、コードベースに対する a sense of ownership を持つことが重要という話があります。こちらに a sense of がついているのは、真にアカウンタブルなオーナーは別に居るが、チームメンバーがオーナーシップを感じているというニュアンスが出ていると思います。
*2:このあたりは素人なので、詳しいことは控えます。会社法上、必ず代表が存在するとも言えそうですし、いかにフラットな組織でも3レイヤーが現実的にミニマムとも言えるかなと思います。
*3:ちなみにアカウンタビリティまで手放すとそれは無責任の丸投げになります。絶対にやめましょう!
*4:誰に対するアカウンタビリティか、という点にも少し触れておきます。会社が行ったこと全てに対するアカウンタビリティが代表に所属し、アカウンタビリティは委譲されないならば、代表以外誰もアカウンタビリティを負わないのではないか、という混乱を生むことがないとは言い切れないからです。この混乱を防ぐには、誰に対して説明責任を負っているかに注目してください。会社の代表であれば対外的な全責任、つまり会社外の人全てに対してとも言えます。社内であれば社内の自チーム以外全てに対して説明責任があると言えるでしょう。階層が深い場合はそのチームのマネージャーのマネージャーに対してと言うケースもあります。
*5:もちろんプロダクトチームのマネージャーである例はありますが、一般的なソフトウェア開発チームにおいてプロダクトマネージャーがプロダクトチームのリーダーを指すケースは少ないです。
*6:当然エンジニアリングチームのマネージャーということは、エンジニアリングのマネジメントをチームマネジメントを通して行います。「エンジニアリングマネージャーは単なるエンジニア達のマネージャーじゃない」と言われる理由は、過去エンジニアリングチームのマネージャーが、エンジニアリングのバックグラウンドを持たないケースが一定数あったからなのではないかと推察します。いわゆる「現場を知らない上司」の典型例です。
*7:個人的にこの強い弱いは誤解を与える表現なので、そこまで好きではないですが、便宜上用います。選択と集中という言葉からわかる通り、弱い EM の方が特定スキルでは強い EM より練度が高いことは大いにあり得ますし、そうなるケースが一般的でしょう。その観点からみると強い EM は単なる器用貧乏の可能性もあり、決してどちらかが強い弱いという話ではありません。この強い弱いは定義としての強弱であり、スキルやロールとしての強弱ではありません。実際に該当記事中でも強めの EM 定義、弱めの EM 定義と言った後、それの言い換えとして強い EM と弱い EMが使われています。
*8:本文脈ではソフトウェア開発チームという言葉を、エンジニアリングチームと区別なく利用しています。
*9:具体的にはユーザーストーリーをどう実現するかの決定権。そしてメンバーに対する技術的支援。
*10:そのチームの専門領域が対人である場合、存在すると言えますが、その場合でも必要とされるスキルが「専門領域 + ピープルマネジメント」であることに変わりはありません。
「エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法」を読んだ
「エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法」を読みました。
厳密には原著の "Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs" を読みました。
英語 & 厚めの専門書ということで少し読むの時間かかりましたが、良書でした!
個人用のノートはガッツリ Notion で取っていて公開予定はないのですが、
- エンジニアリングマネージャーの主な責任 (Accountability & Responsibilities) は何か
- エンジニアリングマネージャーとして働き始めたけど IC*1 時代と違って成果を出してる実感がない
- エンジニアリングマネージャーとして必要になるスキル
について一通り知りたい人は目を通してみると良いと思います。チームにエンジニアリングマネージャーが居らず採用を検討している人もオススメです。
内容はソフトウェアエンジニアリングに限定した話だけではないので、どなたでも読み進めることができます。
本に直接書かれているわけではありませんが、EM の強めの定義や弱めの定義という言葉に対する、統一的な定義を個人的に言語化できたが良かったです。
このあたりの情報の、点と点が全てスッキリつながった、というとわかっていただけるかと思います。
これについては別のブログでまとめたいと思うのでここでは深くは言及しませんが、鍵はオーナシップ、アカウンタビリティ、レスポンシビリティ、そして権限移譲です。 マネージャーはチームがオーナシップを持つもの全てにアカウンタビリティを持ち、どのレスポンシビリティを移譲するかによってチーム構成と自分に残るレスポンシビリティが残る、という感じです。そしてこのチームがオーナシップを持つものと、移譲できるレスポンシビリティは組織やチームによって異なるので、必要なスキルセットは組織によるため、同じエンジニアリングマネージャーでもレスポンシビリティが様々、ということです。
これを軸にすると、なぜ 1on1*2がマネージャーとして最も大切な日々の活動の一つなのか、チームのビジョンやゴールを設定することの重要性など、様々なことが線でつながると思います。
もう一つ抜粋しておきたい内容としては、マネージャーの日々の活動のカテゴリです。
IC 時代と違って成果を出せてる実感がないときは、チームのアウトプットが自分の主なアウトプットだと理解したうえで、日々の行動を以下に分類すると、自分がマネージャーとして仕事をしている(もしくはしていない)か客観視することができます。
- 情報収集
- 意思決定
- 他者の意思決定への貢献
- ロールモデルとしての行動
最後に付け加えておきたいことは「マネージャーの真価は悪い状況でほど問われる」ということでしょうか。
簡単な状況や良い状況では誰しも比較的うまくやれるものですが、難しい状況や悪い状況では如実に差がでる、というのはその通りだと思います。
良い本だったので、ぜひご一読ください!
🥳5th Anniversary — ロンドンのスタートアップで働き始めて5年経った🎉
ロンドンのスタートアップで働き始めて5年が経過しました🎉
全社ミーティングで新メンバーと一緒に 5th Anniversary のメンバーとして紹介されて😮😊🥳となりました。
5年間、色々ありましたが、今振り返ってみると、そもそも採用した方も入社を決めたほうも、なかなか勇気のある決断だったと思います。
- 当時 IELTS 7.0 で英語圏の大学院入学レベル到達とは言え、英語は仕事で本格的に使えるレベルではない
- そもそもイギリスに行ったことすらなく、まずはカナダから時差のあるリモートワーク
- 入社時点で会社は設立から5か月でプロダクトが存在せず、一人目のエンジニアとして加入(CTO の次)
正直入社時点ではロンドンに移住できるかも全く分からない、不確実なことだらけの入社でした。
そして半年後に無事にロンドンに移住。とても嬉しかったのを覚えています。
そこからはもう、流石はスタートアップという山あり谷ありでここまで来ました。 入社時はいわゆるシード直後のアーリーステージのスタートアップでしたが、シリーズA、そしてシリーズB突破まで辿り着き、次はシリーズCという段階です!
こちらの記事 によると、
ステージ | 生存率 |
---|---|
シード → シリーズA | 40% |
シリーズA → シリーズB | 23% |
シリーズB → シリーズC | 9% |
とのことなので、まだまだ全く安定とは程遠いですね……! 最近は景気も良くないようなので、本当にどうなるかわからない中での戦いとなります……!
運の要素も間違いなくあるとは思いますが、不況や困難、不確実な中でこそ真価は問われるので精進したいと思います。
この会社の推移と共に、最初は立ち上げ初期のエンジニアとしていわゆるフルスタックエンジニア、そこから成長するにつれてテックリードの役割にシフト、そして現在はエンジニアリングマネージャーとなり、自分の役割も変化してきています。
この変化の速さがスタートアップの醍醐味でもありますね!
2023年も更なる成長ができるように頑張っていきたいと思います!
「しっかり学ぶフランス語」を読んだ
「しっかり学ぶフランス語」に一通り目を通しました。
大学時代は第二外国語として選ぶものの、授業への出席すらせず*1、最終的には2年間で何も理解せず単位を軒並み落とし、三留や除籍の未来が見えたので諦めたフランス語*2ですが、去年から Duolingo でのんびり入門しました。大学時代は入門したとは言えない状態で諦めたので、あえて再入門とは言いません!
フランス語に入門しました!
Duolingo でゲーム形式で色々学び、いわゆる点がたくさん頭に入ってきた状態になったので、入門の入門本あたりを読んで点と点を繋ぎたいなとなってきたので一冊目として読んでみました。レビューにもある通り、初歩の初歩しかカバーしてないのですが、それこそがまさに必要な内容でしたのでドンピシャでした。
初歩の初歩を体系的に学んだことにより脳内にインデックスが張られ、Duolingo で学んできたことがスッと落とし込めた気がします。
最初の地図を手に入れた感じです。もしくはコンパス。
これから立ち向かうことになるであろう大量の文法事項や言語学習のあれこれが少し見えた感じがします。 正直、全体の1%位しかまだ見えてない気はしますが!言語学習は……沼。
もうすでに二冊目に目途はつけてますが、英語学習にかかった時間を考えると焦る気はない……というより、無理すると絶対続かないと思うので、無理せず楽しみながらコツコツやっていきます。
どこかで言った気がしますが、言語学習で個人的に大事だと思ってることは「日々の目標を低くし*3毎日達成すること」だと思うので、その感じで続けていきます。
のんびり楽しみながらゲーム感覚でフランス語入門!
*1:厳密に言うと、フランス語だけではなく、この時期に出席していた授業は多分ほぼなかった気がします。不思議なことに起きたら大体の授業が終わっていました。
*2:どうにかして一留で卒業するため、言語自体は難しいが単位は非常に取りやすいロシア語に変更しました。ちなみに三年次での第二外国語変更は二留確定の状況でしたが、交渉と努力によりロシア語初級と中級を同時取得し一留で済ませることができました。あの時は頑張りましたが、悲しいことにロシア語のアルファベットの読み方以外何も記憶に残っていないです。やはり言語はコツコツ積み上げないと駄目ですね。
*3:当然ゴールに対して一歩でも進む、意味のある目標にする必要はあります。そのためには何をどうやって習得していくか、というロードマップがぼんやりでもあると良いです。