EM業をやりながらエンジニアリングスキル低下に抵抗するために工夫している事
見出し画像

EM業をやりながらエンジニアリングスキル低下に抵抗するために工夫している事

miyamoto

カミナシでEM(エンジニアリングマネージャー)をしている宮本と申します。

EMの主要業務である採用面談・面接、評価業務などのピープルマネジメント系業務は基本的にエンジニアから避けられる傾向にあり、面接や1on1などでスケジュールが埋め尽くされているのを見て「コード書けなさそう」とネガティブなイメージを持たれる方も多いかと思います。

そのイメージはあながち間違いではないですが、個人的には、コードを書く時間が減ることによるソフトウェアエンジニア(以下、SWEと記載)としてのスキル低下の恐れの方が強いです。
(言う程そんなにスキルあるの?と言う声が聞こえてきそうで怖い><)

本記事でその懸念について個人的な見解をお伝えする事で、イメージだけで避けられるEMという職種に少しでも肯定的な考えを持っていただいたり、EMになるか迷っている人が第一歩を踏み出すための参考材料になったり、すれば嬉しく思います。

ソフトウェアエンジニアのスキルとは

まず、一般的に言われるSWEのスキルとは何かという観点で調査しました。こういう分野は海外の方が上手く言語化されているのでは?という偏見のもと、海外のサイトを調べたところ、以下のようなWebサイトがひっかかってきました。

各サイトを覗いてみましたが、「SWEのスキルの定義ってバラバラだな」というのが素直な感想です。

なので、本記事では話を進めやすいよう以下のように定義します。
(賛否両論や抜け漏れなどあるかと思いますが、ご意見がもしあればTwitterなどでご連絡いただければ幸いです)

SWEのスキルの定義(宮本個人の定義)

ソフトスキル・ハードスキルごとに、SWEのスキルを定義しました。
私を含め、SWEが考えるスキルといったワードから連想されるのは、ハードスキルの方ではないかと思います。

EM業をやった後に向上したスキル

最初からネタばらしかよ、というツッコミを受けそうですが、EM業をやった後に明確に向上しているのでは?と感じるスキルがあります。

設計・アーキテクチャーの検討スキルです。

というのも、書類選考、カジュアル面談、技術課題check、面接といったように、候補者の方々のこれまでの経歴を見たり、実際に面接の際にご経験された内容について深掘りさせていただいたり、といった採用関連の業務を行う内に自然と自分の中に情報が蓄積されてきました。

その他、コンウェイ・逆コンウェイの法則を鑑みて、メンバーの増加とプロダクトの実態を比べて、先んじて手を打つなら今何をすべきか?という点を意識して思考を巡らせる事もスキル向上に寄与しているかなと思います。

副業や個人開発などをやっていれば別ですが、毎日長い時間費やしている現職のプロダクトのアーキテクチャー以外には触れる機会が少ないエンジニアが世の中の大半を占めるはずです。

結果論ですが、採用選考対応を多数行うEMであれば、設計・アーキテクチャー検討スキルを向上させられるかもしれません。
(注意: 組織体制・規模によっては全く的外れな話である可能性ございます)

EM業をやりながらスキル低下に抵抗するために

ここからが本題です。
色々と試行錯誤しましたが、実際に自分でやって実りあったなと感じたのは以下です。

(1)難しめな不具合対応を行う

現状、1週間ごとに担当者を交代しながら不具合問い合わせ対応を行なっています。私も担当者の1人に名を連ねていますが、エンジニア側の不具合問い合わせ対応の管理者は私のため、解決できなかった不具合問い合わせは一旦私に集まってきます。

カミナシというサービスは正式にリリースして約2年程度が経ちます。普通に調査して修正できるものは既に対応済みになっているため、基本、容易に解決できないものばかりが残っています。

華麗に不具合を解決できればカッコいいですが、残念ながら実態は、ログとソース、インフラ関係の各種メトリクスを細かく睨めっこして調査し、結局は原因が分からなくて頭を抱えている場合も増えてきました。当然、1人で頭を抱えるだけではなく、社内の有識者を召喚して議論して解決を図るアプローチもやっています。

ただしそれでも、すぐには解決できない事が多いです。

そのため、詳細な情報を取得すべく細かくログを仕込んだり、温度感高めで緊急度が高い場合は、不具合の問い合わせをくださったお客様先に訪問したりまでして対応したりします。

結果的に持っている知識は当然の事、新たな知見を持ってコトに当たるため、知識が常に更新されつつ再度定着するキッカケになっています。

超難問ばかりのため、解決できた際はいつも爽快な気分です。

(2)技術情報に検索性を加えて蓄積する

自分が気になる記事だったり、試行錯誤した事をラベルを付けて検索性を持たせながら記録しています。

基本的には細かい事は忘れて、検索すれば調べられる状態を作る事で覚えた事を知識化しているようなイメージです。

EvernoteやBoost Noteなど、様々なツールを使い分けしてきましたが、最近はGoogle Keep1本に絞りました。

Google Keepの画像

マルチデバイスで利用できる事は当然の事、雑に書いたメモを共同編集者として設定すれば別の方とも共有できますし、リマインダーをセットすれば、2週間後、1ヶ月後といった完全に忘れているであろうタイミングで再度目に触れさせる事ができ、記憶に定着させるという変わった使い方もできます。

また、私自身は基本的に使っていませんが、Google Keepには図形描画という機能もあります。これは、手書きで自由に図形を書いて保存する事ができる機能なのですが、なんと、図形描画で作成した画像内に含まれる文字を抽出してテキスト化してくれる素敵な機能が搭載されているのです。

また、作成したメモからGoogleドキュメントを新規作成しつつコピぺしてくれるという機能まで備わっているのです。

個人的には、最近使ったツールで一番操作体験が良かったので、ぜひ利用してみてください。

(番外編)海外のテックブログを読む

エンジニアリングの領域にいる方であれば、今持っているスキルは時代の流れと共に古くなって通用しなくなるため、持っているスキルの棚卸しやアップデートが必要だとお考えの方は多いかと思います。

スキルというのは相対的な優位性も多少あるのかなと個人的には感じていますので、EMやっている間にICとしてのスキルがだだ下がりしないか、という恐れがあります。

そのため、技術的なトレンドを追う、というのをEMやっている間にどうするのが良いのかな?と悩んでいます。

有効かどうかはさておき、個人的にやっている事として、たまに海外のテック企業のブログをざっと斜め読みしています。
(未知の技術流行り始めていないかな?みたいな目線で見ています)

それじゃあ、海外のテック企業ってどこに技術的な情報出しているの?というのが気になるかと思いますが、以前、技術的な調査をしていた際に感じたのですが、海外のエンジニアやテック企業の多くは Medium に記事を寄稿しているケースが多いです。

現状はどうか存じ上げませんが、 Zeals様の以下の記事やZennの記事を拝見しても、Mediumに海外のテック企業がブログを公開しているケースが散見されます。

大量の記事を追うのは大変なため、記事のタイトルのみを斜め読みしていくだけでもオススメです。

最後に

今はSWEだけど人生のどこかでEMもやってみたい、でも、スキルが低下したりするのは嫌だ!みたいな理由でEMを避けていらっしゃる方は一定数いらっしゃるかと思います。

私自身、その点については悩みを抱えていて、完全にその悩みを拭えるまでには至っていません。

ただ、勘違いかもしれませんが、上記に挙げたような事を行う事で、自分自身ではICとして技術的なトレンドから大きく乖離している感覚は無いため、今のところはSWEとしてのスキル低下に抗えているのかと思います。

本記事が、少しでもEMになるのを迷われていらっしゃる方の後押しになりますと幸いです。

P.S.
Meetyやっておりますので、上記のお話を深掘りしたかったり、その他、少しでもお話ししても良いよという方がいらっしゃれば面談しましょう!


この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
miyamoto
(株)カミナシでエンジニアリングマネージャーやってます。 技術的にはGolang/React.js/React Native/Typescript/Docker/GitHub Actions/Terraform/AWS辺りを触ってます。