2021年エウレカエンジニア組織の振り返り
この記事は Eureka Advent Calendar 2021 の24日目の記事です。
こんにちは、こんばんは。エウレカで CTO をしている kaneshin です。今年も去年と変わらずリモートワーク中心の生活となりましたが、緊急事態宣言が明けてから会社にあるカフェへ行くために出社するようになり、クリスマスイブの本日もカフェのコーヒーを飲み納めるために出社をして、本記事の執筆をしています☕️
自分の中では毎年恒例となっているエウレカエンジニア組織の振り返りを本記事を通して行いたいと思います。2020年の振り返り記事では、エンジニア組織のあり方やキャリア戦略について書いているので、もしよければご覧ください。
2021年は、いままでエンジニア組織として積み上げてきた組織としての器が試される年だと考えていました。去年の記事の中で『変化に柔軟でありつつ、頑強なエンジニア組織の確立』を2021年のテーマとして書いていて、100点とまではいかないけれど組織としての強さは飛躍的に上がったと思います。
これは CTO の自分がどうこうしたという話ではなく、エンジニア組織の個人それぞれの専門性を強みをしっかりと深くしていくことと、専門性だけに捉われず知識を水平に広げていくことを自立性を持って動ける集団だからこそ強くなっていると感じます。
エンジニア組織については Jinsei Shima と一緒にワンキャリア様ご協力のもと YouTube で話しているのでぜひご覧ください。
自分の役目（マネージャーの役目）としては、個々人が自立的に動けるようにアレンジし、その上でエンジニアには自分で考え、そして行動に移してもらうことが前提とした組織体制となっているし、エウレカのValueもそれを表しています。また、もしも間違えた方向に物事が進んでしまうのであればそれに対して素早くフィードバックを行い、軌道修正を行ってからまた進んでもらうことを考えています。
変化に柔軟で頑強な組織とは
世の中の変遷や事業の変化に対応していくことに重要なのは、学んだことに捉われず思考をし続ける癖をつけていくことと、必要に応じたリーダーシップスタイルをしていくことだと考えています。ちなみに、単語を使うなら『アンラーニング』と『エラスティックリーダーシップ』でピンと来る人もいるかと思います。
経験を活かすアンラーニング
少し昔の記事を紹介しますが、アンラーニングはただ忘れることを指すのではなく、経験や習慣で得たことを取捨選択しつつ、新しく学習したことを転じさせて今までの経験にあてはめ、これからの行動や習慣をより向上させていくことを目的としています。
Unlearning is not about forgetting. It’s about the ability to choose an alternative mental model or paradigm. When we learn, we add new skills or knowledge to what we already know. When we unlearn, we step outside the mental model in order to choose a different one.
アンラーニングは過去を捨てることではないし、尚且つ、学習をし続けることが大事です。これらを踏まえて戦略であったり事業における変化の物事を語るようにしています。
人は変化に弱いことを前提とする
例えば事業の方向転換などが発生したとして、その変化を促すことは簡単ですが、このような変化は少なからずストレスが伴うものです。頭では理解できるがそれを行動へつなげることはとても難しいものです。
その理由として、今までやってきていたことが無駄になってしまうことや、またゼロから学習をしていくことになると思うからです。ただ、実際にこのような経験を越えてきた人は経験を何かに活かす思考ができているし、無駄とならないようなアンラーニングを行っているものです。
思考は「工夫をして考える」
実際にアンラーニングを認知したとしても、それを実際に行うことは容易くありません。その思考を助けるやり方としてトリプルシンキングを意識することと、その中でもクリティカルシンキングとラテラルシンキングが活かせると思います。
トリプルシンキング（３つの思考法）
- ロジカルシンキング（論理的思考法）
- クリティカルシンキング（批判的思考法）
- ラテラルシンキング（水平的思考法）
その中でもラテラルシンキングは自分の中での常識や概念にとらわれずに様々な角度から物事を考えていくこと組み合わせて全く新しいアイディアを生み出すことができます。
いま知っている情報を完全に抜いて考えていくことや、目の前にある問題のそもそもの背景を疑って課題解決していくことなどとても重要な思考法です。
これらができる人は問題を問題のまま解決するのではなく、問題を課題としてとらえて解決することがうまい印象を受けます。
悩むのではなくて考える
思考法がうまい人の圧倒的な理由は『悩む』のではなくて『考える』ことができている人です。アウトプットに繋がらない『悩む』人は答えを出そうとしていないで負のループに入ったりします。
昔の記事でも同じことを書いているのですが、イシューからはじめよは悩める人に一読してもらいたい書籍です。
また、思考を巡らせるときに『悩む』のではなく『考える』こと。考えるとは、最終的に答えが出るという前提のもと、自身の思考を構造的に組み立てて結論を見出すこと。ただ悩み続けて答えが出ないのは考えていないことと同義です。
多角的に物事を考える癖をつけたい人には、イシューからはじめよ―知的生産の「シンプルな本質」をおすすめします。
リーダーシップスタイル
強い組織には強いリーダーシップが必要ですが『強いリーダーシップとは？』となるはずです。自分の中で必要なリーダーシップは、状況に応じた場をアレンジすることと適切にアドバイスやフィードバックを行うことをし続けることであり、いろいろな指示を出すことや意思決定をすることではないと思っています。
もちろん必要な状況があれば指示を出すことや実際に手を出すことは臆せず実行していきますが、基本的には後ろで構えている状態で何か問題が発生すればそれをフォローする形で座しています。
2年前くらいからこれを意識していますが、この考えに至ったところは『マネジメントに正解はない』と思うようになったのが起因だと思います。参考文献としてはそのままエラスティックリーダーシップを推薦しておきます。
エンジニアのキャリアと役割
このご時世、エンジニアのキャリアはあってないようなものなので、その状況でも『エウレカにいたからこそ成長できた』と感じられるエンジニア組織を構築していきたいと思います。
僕と一緒に組織的なことを論じたことがある人や採用面接でお会いしたことがある人は聞いたことがあると思います。常日頃からエンジニアのキャリアのことを考えていますが、いまの世の中のキャリアなんて時代の流れで変わり続けているものです。それこそエラスティックなキャリアを考えていかねばなりません。
そんなキャリアについて2, 3年ほど考えていたことと、エウレカのエンジニアとしてのキャリアラダーを作成したのはとても良い機会だったと今では思います。そのときはCircleCIのキャリアパスの考えをとても参考にさせてもらいました。
日本でキャリアラダーを制定（途中）したことがある経験は希少かもしれないなと今さら思っています。これから組織で作りたい方がいれば作成方法のアドバイスができるかと思います。
Individual Contributor Career Path
日本でも Individual Contributor (IC) がいろいろな記事などからどんどん認知されてきていると感じた一年でした。
従来のエンジニアキャリアパスは、どこかでマネジメントをしないとキャリアパス上で頭打ちになるというのが認識されているものと感じますが、エンジニアの人は常に違和感を思うひともいたのではないでしょうか。
このように日本の企業でも Individual Contributor のキャリアパスを採用することと、そのような人がもっともっと増えていって欲しいものです。理解している企業はもちろん多いと思いますが、実際の評価制度に反映されているかはまた別の話なので、プロフェッショナルな人が継続的に昇格ができるように評価制度に組み込む企業がこれからも増えていくとよいなと感じます。
（余談）エンジニアのタイトル話
記事中に余談とありますが、ここは昔から気になっていたポイントです。
余談ですが、一般に「Senior Engineer」の次は「Staff Engineer」と呼ばれることが多いようです。カタカナで「スタッフエンジニア」と書くと字面が頼りないのですが、ソフトウェアエンジニアとしてはかなり上位になります。
日本と海外でのエンジニアタイトルの呼称が違う問題があり、あまり知られていないなと感じます。
シニア (Senior) プレフィックスは形容詞的に使うものなので、 Engineer の次が Senior Engineer となります。例えば下記のような順序になったりします。
- Senior VP of Engineering
- VP of Engineering
- Senior Lead Engineer / Senior Staff Engineer
- Lead Engineer / Staff Engineer
- Senior Engineer
- Engineer
また、企業によっては Staff Engineer I, Staff Engineer II, Staff Engineer III のように 1, 2, 3 といった具合にタイトルをつけることもあります。
エンジニアの役割はやるべきことのみ定義
エウレカでは Tech Lead を置いていますが、やるべきことは『チームのもつプロジェクトを前に推進させること』にフォーカスした定義しかしていません。技術的な意思決定をして欲しかったり、プロジェクトマネジメントをして欲しいという具体的なことは定義していません。
定義をした方がスキル開発はしやすいですが、その定義したものが本当にプロジェクトを率いることに必要かどうかは実際に現場でプロジェクトを動かしている人にしかわからないですし、現状に即して必要なものを選択できる人にプロジェクトを推進させる責任を持ってもらっています。例えば、プロジェクトを推進させるために、ときには技術的な意思決定であったり、プロダクトマネージャーと一緒にユーザーシナリオを考えたり、ガリガリとコーディングをしたり、自立的に考えて行動を取ることが一番成果が出ると思います。
チームを越えて必要なリソース調整などは現状は CTO が担っており、プロジェクトが推進するのに必要不可欠なことへのサポートに回っています。
役割は人によって認識が違う
何かしらの役割はその人の経歴や背景によって認識がバラバラなのはよくある話です。役割があるだけで話が特定の人にいくことは物事がとてもスムーズに進むかもしれませんが、人も組織も変化していくものなので一時しか使えない役割に本当に意味があるのか？と考えています。
エウレカのエンジニア組織ではマネージャーから役割をつけたいと言われても『それは期初の期待値として振るべきであって、その役割は本当に必要なのか』を問うたりします。
しっかりと定義されたい人もいると思いますが、定義しても何も変わらないと思うし、むしろ多様な環境で成長する機会をその役割があるせいで奪いかねないとも考えています。
例として、エウレカには CTO / VPoE 体制ではなく CTO の一枚岩ですが、その理由として VPoE の一般的な認識がエンジニア組織を構築するために、採用やキャリア設計など諸々を担う人と思われることが多いことと、その役割の人を置いてしまうとマネージャーの人たちが考える機会を減らしてしまうことと、エンジニア組織はエンジニアメンバー全体で作られていくものだと考えているからです。（もちろん、これも組織の規模や形であり方は全然違うので、今後は VPoE が必要になるかもしれません）
最近は CTO か VPoE どちらかしかいないという組織は上記を意識しているのではないかと思っています。
マネージャーの役割も個々に委ねる
マネジメントに正解はないのと、チームにも個性があるので何か具体的な事柄を定義することはないです。
マネージャーのやるべきことは『事業成長を最大化させていくこと』だと考えています。事業が成長しないと個々人が成長する機会を失うことになるので、まずは事業成長が必要であり、その目的を達成するやり方は各々のマネジメントスタイルで推進していってもらいたいと考えています。
『こうあるべきだ』というのは簡単ですが、そのべき論が通るか通らないかは価値観に合うかどうか、はたまた自分のマネジメントスタイルにあうかどうかが関係してくるのでこのように考えています。
おわりに
エウレカで CTO に就任してから5年が経過し、自分の中では少し節目の気分の2021年でした。組織の今昔で必要となるスキルはガラッと変わるところもあれば、変わらない部分もありますし、それによってエンジニア組織の色も変わっているので組織は生き物だなとしみじみ感じます。
エウレカの昔の話や自分の経歴については少し小粋fmでお話ししたのでこちらもよければ聞いてみてください。
来年も変化を楽しみつつ、より一層強固なエンジニア組織にしていくため、正解のない物事に対してしっかりと意思決定を行なってポジティブにひとつずつ解決していければと思います。
それではみなさま、一足早いですがメリークリスマス🎄と良いお年を🎍
この記事を読んでお話しをしてみたい方がいらっしゃれば、カジュアルにお話しもできますので気軽にお声がけください。
