トップ > 入社エントリー > 新参エンジニアリングマネージャーの試行錯誤

新参エンジニアリングマネージャーの試行錯誤

入社エントリー マネジメント

はじめまして。株式会社エス・エム・エスに、2022年1月1日からEM(Engineering Manager) として入社した @emfurupon777です。

少し前からEMという呼称がプロダクト開発、エンジニアリングの話題の中で普通に使われるようになり、SNSやブログ上でもEM自身から、その成果の見えにくさや結果が出るまでの時間軸の長さなどに起因する難しさを意識した発信が多くされるようになってきたように感じています。

今回、私の入社エントリとして、エンジニアリングのトップが存在する組織にEMとしてJOINする際に不安に思った要素と、それに対して取った行動を軽くまとめてみました。

はじめに

エス・エム・エスでのEMの位置付け(私なりの理解)

弊社の人事組織としては部長、グループ長などは存在しますが、EMが会社組織上の職責を担っていないこともありえますし、EMでない者・・例えばテックリードが職責を担うこともありえます。実際、私の場合入社時の人事的な配置としては同じくEMを務める岩田の下につくという形でした。

が、@sunaot が実は自らはCTOと名乗っていないころからも推測できるように、弊社もいわゆる普通のWeb企業。肩書きにこだわらない、ロールベースのカルチャーとなっています。正直、人事組織を気にしている人間はほとんどおらず・・というか組織図をみたことがない人の方が多いかもしれませんw

私は何者なのか

EMを担うようになった経緯として、私の略歴をあげておきます。

所属 経歴概要
学生時代 ・情報工学ではあったが、学部までのため正直かじった程度の、業務の役には立たないレベル
・第1種、第2種、プロダクションエンジニア(どれも今は名称が変わったり無くなったりしている資格)など基本的な知識をえておくかーくらいな学生(SIer向きw)
1社目
SIer 		・新卒入社
・ケータイキャリア向けの開発をC/C++, Javaで経験
・事業から遠くて悶々。。というSIerエンジニアにありがちな思いを抱きつつ勤務
2社目
医療Web
事業会社 		・JavaのWebエンジニアとして謎の会社に入社
・主力サービスをはじめとする複数サービスの担当として開発から運用まで経験
・メンバー => チームリーダー => EMと役割を変えて経験
・急成長事業会社のスピード感とコスト感にカルチャーショックを抱きながら勤務
3社目
動画SaaS
ベンチャー 		・VPoEとしてJOIN
・プロダクトの開発に直接は関わらない、以外はなんでもやる
・資金調達しながら進むベンチャーとしての振る舞いを学びながら勤務

本題

不安要素

さて本題です。今回、ざっと振り返って主に感じた不安は以下のようなものでした。(細かいことまであげるともっと無数にありますがキリがないので、、)

  1. 技術的理解が不十分

    • 開発プロセス、技術スタックを把握していないし、その導入経緯も不明
    • それぞれのエンジニアが書いているコードを(少ししか)見ていない
    • 技術課題の把握やカイゼンの取り組みがどこで誰によって進んでいるか不明
    • 障害対応の役に立てない（SPOF、ボトルネックなどの勘所がわからない）

  2. 事業を理解できていない

    • ドメイン知識の習得に時間がかかる
    • 事業領域が複数あり、そのフェーズもさまざまな会社のため、エンジニア以外のステークホルダー・プレイヤー把握が難しい
    • 収益構造の理解がない

  3. 人が理解できていない

    • 面接で直接お話しした同僚は少数
    • 共通コンテキストがゼロ（に感じる）の人が多数で、それぞれ何をする人なのかわからない

  4. 信頼貯金がない

    • これまで具体的にやってきたこと・得意なことが伝わっていない
    • 同じ課題を乗り越えていないので、心理的距離がある

  5. EMとしての(主たる)ミッションを明確化しにくい

    • 中長期のミッションは、究極的に表現すれば「◯◯なエンジニアリング組織にする」がミッションだが・・
    • 短期のミッションはふわっとしたもの、「要は諸々のバランス」になりがち
    • アドホックなミッション/タスクは、これの優先順位はどう決めましょうね？のような意思決定に関する相談を受けたり、背中を押したりする・・・ことが多いが、ユニバース（全体感）が把握できていない中での振る舞いがむずかしい

いざ書き出してみると、どれも一人のエンジニアIC(Individual Contributor)として入社した場合にも不安に思う要素かなと思います。では、どのような順番でこれらに取り組めば良いでしょうか？

例えばEMを初めて経験した前々職では、担当するプロジェクトに取り組むことで、1->2->3->4->5のように、ある程度限定された範囲から徐々に広げるステップを踏みながら経験していきました。実際前々職で私の場合は約8年かけてEMに役割が移っていったので、主力サービスのコードは読んだことはあるし、事業構造や社内での人間関係や意思決定のクセのようなものまでそれなりに理解したうえでEM業にあたっていたように思います。

ただ、ここにEMとして入社という前提条件が加わると途端に困ったことになります。いちエンジニアとしての経験から・・となると、さすがに8年は大袈裟ですが同じように経験していったのでは、アウトプットとして期待されているものとは異なると思いますし、アウトカムとしても不十分な期間が長そうです。

ここで一人のEMとしては「今、俯瞰してみて大きな課題になっているのはなんなのよ？誰か教えて！」と考えますが・・・。ただ、世の中でこれが与えられることは稀なんだよな、と今回改めて実感しました。なぜなら！その課題抽出自体がEMのミッションに内包されているからですね。。

取りうると考えた手段・取った手段たち

ひたすら訊く【全体への対策】

何はともあれ訊くことは大事です。相手の時間も使ってはしまうものの、Slackで素朴に聞いてみると、どこの組織でも人/情報をつないでくれるコネクターが存在するもので、そういった存在は非常に貴重です。 また、Slackやチームのミーティング、1on1してもHRTフルに迎えてくれたことが入社後の心理的安全性の確保に非常に寄与したように思います。

ローカル開発環境の構築【1への対策】

EMなので、まずはエンジニアリングを経験してみたいというのは自然なことですね。実際Github権限を得てcloneし、READMEに従って構築してみる・・とやってみることで、今後入社してくる仲間と同じオンボーディング体験をしてみました。どこの会社でもそうですが、独特のクセのようなものが存在しているが、後から入ったものにしか実感できない課題も散見され、カイゼンポイントが多数見つかるとともに理解が深まりました。

ドキュメント /コミュニケーション探索【1,2,3への対策】

弊社での探索対象はドキュメントはesaやgoogle docs、コミュニケーションはSlack、スケジュール管理はGoogle Calendarでした。

esaについては、オンボーディング用のエントリや同僚の自己紹介エントリから始めて、情報を効率よく得ることができます。ただし、重複して書かれていたり鮮度が落ちていたりというどこの会社でも起きる課題も正直あります。ここは読みながら必要に応じて適宜修正していくというのが基本ですね。(それが難しいわけですが)

Slackはリモートワーク中心になった今、EMとしては情報の宝庫です。特定の人物についての「from: @emfurupon777 」のような検索を起点にすることで、誰も資料をまとめていなくても、誰かに聞かなくても、入社のタイミングや、やってきたこと、場合によってはキャラクターの片鱗まで掴むことができる場合があります。今回もSlackリサーチは参考にさせていただきました。

Google Calendarは特に決定権者の予定をみると将来という、時間軸で少し先の見通しに関して得られるものがあります。個人的にはこれを徹底的にやる人と一切気にしない人とはっきり分かれる印象を持っていますが、ハックしていくと非公開設定だけどあの人とあの人が同じ時間を共有してるっぽいからあの手の話題をここで話してるな・・なんてことが推測できたりします。

グループミーティングへの参加【不安要素1,2,3への対策】

各チームのデイリースクラムを中心に週替わりで参加させていただきました。正直、どこのチームから参加すべきかどのミーティングから参加すべきか・・というのが悩ましいところなのですが、今回キッカケをEMの岩田が作ってくれたためスムーズに開始することができました。

1on1【不安要素1,2,3への対策】

グループミーティング行脚を手がかりにして各エンジニアのみなさんとご挨拶を兼ねた1on1を行っていきました。業務の内容に終始して終わることもあれば、プライベートに近いようなところがメインになることもある・・という感じではありますが、それぞれの人となりを知ってみるというユルいところと、もし相談に乗れることがあればその場で乗ってしまうというスピードをあまりかたく考えずに実施してみるのが重要かなと思って望みました。ただ、完全に行き当たりばったりではなく、前述のSlackサーチを可能な限り行っておくようなことも非常に役に立ちました。

プレイヤーとして振る舞えるポイントを見つけてやってみる【4への対策】

ここは好みの分かれるところです。所属チームが明確なICであれば、そのチームの納期に余裕があり、適度な粒度なタスクを拾ってPullRequest・・といきたいところで、EMでもこういう選択をする方が多いように思いますが、私個人としてはもう少し広く組織に貢献できる可能性を狙って、通常業務を改善できないか探るようにしています。

前職では勤怠のSlack打刻(人事側と調整が必要で意外と手間がかかる)導入をしたのですが、弊社では用語集の改善を選択しました。スプレッドシートで管理されているものがいくつか見つかったのと、ちょうどタイミングよく元同僚の @KawamataRyo が用語集ツールを公開していたので使わせていただくことにしました。

実は、弊社ではAWSを使うことが多いですし、GoogeDriveの外部共有も限定されているのですが、今回Firebase/GCPからSpreadSheetをデータストアとして使う構成というイレギュラーな協力依頼もSRE、情シスの協力をスムーズに得ることができ、今後も業務改善が行えそう・・と実感できました。

他にも勝手にReacji Channelerで情報を集めることなどをトライしています。EMとしてはコミュニケーションの場であるSlackは活用を考えてみる良いフィールドになると考えています。

組織開発アプローチ【4,5への対策】

1,2,3への対策で行ってきたことを総合して、組織開発アプローチで行えることを考え実施します。

  • AさんとBさんが話せる場を持てるようにファシリテーションを行う
  • 普段話をしているマネージメント層にフィードバックを行う(ご本人としても伝えて良いことに限る)

人材開発アプローチ

これは、今回まだ課題の解決としては行っていません。それぞれの関係性の中で学習機会を得たり、輪読会・勉強会などが行われているのを観測しているため、そこにあえて私が追加で働きかけるまで具体的なものを得られていないためです。 Slackで簡単に書籍購入をリクエストできたりするのがうまくワークしているのかもしれません。

tech.bm-sms.co.jp

まとめ

取り止めもなく取りうる手段と私の経験をあげてきましたが、ICと比較して特徴的になる傾向にあるのは組織開発アプローチかもしれません。

天才的に強いエンジニアがいるんだからマネージャーはいらないのでは？という有名なGoogleのProject Oxygenの結論を地でいくようなことを考えている希少種がEMだと思っています。(個人的には、感覚的にも経験的にもEMよりはテックリードと呼ばれたいエンジニアが多いように感じています)

この記事を通してEMが入社する際の参考になったり、EMがどんなことを考えて参加してきているか、をご理解いただくのに資すれば幸いです。

なお、弊社でもEMを積極採用中です。まだ大きくなり切ってはいないが組織開発が不要なほど小さくはない。というフェーズこそ組織開発経験にもってこいなので、興味がある方はぜひカジュアル面談からお話しさせてください。

また、今回はあえて触れていませんが、EMの大きな役割として採用があります。

  • エンジニア経歴をお持ちでキャリアの一環としてエンジニア採用を一緒にやってくれる方
  • あるいは採用人事でエンジニア採用に深くコミットしていきたい方

も募集していますのでこちらも気軽にご連絡いただければ幸いです！