これはHubble Advent Calendar 2025の13日目の記事です。
はじめに
株式会社Hubbleでエンジニアリングマネージャーをしているokakeeです！
Devチームとしてのアドカレ参加は今年で3年目になりますが、ついに全日開催できるようになり嬉しいです！🎉
初開催時は平日のみの実施で、枠を埋めるために 1人2記事書いていたことを思うと、会社として大きく成長を実感し感慨深い気持ちになりました。
テーマのきっかけ
一昨年、去年とHubbleでアドカレを書かせていただいて、今年はどんな記事を書こうかなと考えていた折、去年の自分の記事を見返していました。
当時の私は、バックエンドエンジニアからエンジニアリングマネージャーへ転身したばかりで、毎日手探りの状態で日々の業務に向き合っていました。
その中で、判断や方針に迷う場面が多くあったり、プレイングマネージャーとして実装者の立場でプロジェクトに参加する期間があったりと、役割の揺れを感じていました。
エンジニアリングマネージャーとして、この進め方で本当に正しいのだろうか。
会社として求められている役割と、自分が思い描くエンジニアリングマネージャー像との間にズレがあるのではないか。
そう感じることが少なくありませんでした。
エンジニアリングマネージャーについて当時の自分なりのスタンスを例えると、ぼんやりした完成形を思い浮かべながら、ひらすらに粘土をこねくり回していたように思います。
それは今でもこね続けていますが、それが少しずつ目指すべき形を作れてきたように感じます。
そして当時の自分と比べて何が変わったのか、なぜ形作れてきたのかを一言で言うのであれば、恵まれた環境を自分なりに活かすことができたからだと思います。
今回は私を取り巻く環境の何が変わったのか、その環境下でなにをしてきたのかについて書いてみようと思います。
開発体制と業務の変化
私にとって何よりも影響がありすべての根幹になっている出来事として、2025年4月から開発体制が大幅に変更されました。
これによりエンジニアリングマネージャーが正式にポジションとして位置づけられ、私はAssistant Backend Engineering Managerとして、主に新規受注獲得のための機能開発やユーザー要望の機能改善など、幅広い開発を担うチームのバックエンド側のエンジニアリングマネージャーとして活動を始めました。
シニアEMのジョインとEMチーム化
開発体制の変更により、シニアエンジニアリングマネージャーとして @yocuki さんが参画されました。
体制変更以前、社内でエンジニアリングマネージャーの働き方をしていたのは自分ひとりだけでしたが、そんな中で、チームの仲間として、また上司として相談や共有ができる存在ができたことは、何よりも心強く感じています。
組織体制変更の目的と意義については、アドカレ1日目の記事で解説していただいています。
「粘土をこねる」手応えが明確になった
それまで私なりに模索を続けていたエンジニアリングマネージャーという役割について、どのように行動をすれば会社やチームに貢献できるのか、その視点が体制変更をきっかけに一気に明確になりました。
Hubbleにおいてエンジニアリングマネージャーに求められることは何か。
問題が発生した際どのように判断し、動けばよいのか。
そうした問いに対して一緒に考え、道筋を示してくれる存在ができたことは、私にとって大きな支えとなりました。
属人化した作業を分解するきっかけに
EMチームとして動けるようになったことで、それまで私ひとりで抱えていた作業を分担したり、一緒に検討してもらえるようになりました。
特に顕著だったのがリリース作業で、2,3年ほど前から私に属人化してしまっていました。
しかしEMチームのメンバーが中心となって、バックエンドメンバー内でリリースサイクルを回せるように仕組み化を進めていただいたことで、作業が可視化され負担が軽減されると同時に、属人化を解消することができました。
周りの環境に支えられながら、自分が取り組んできたこと
新規エンジニアの社内オンボーディング（OBD）構築
Hubbleは組織全体で急成長しており、Devチームでも正社員・業務委託を問わず多くのメンバーが新しくジョインしています。
私はその中でBackendメンバーの受け入れ時のOBDを担当してきました。
OBD自体は一般的な内容も多いですが、特に以下のポイントを意識して資料構築やOBDを行っています。
- 契約業務という業務フローを理解する難易度が高いため、実際にプロダクトを触って理解してもらう道筋をサポートする
- 開発フローやルール（カルチャー）などを丁寧に説明し、実務に入った際の違和感を極力減らす
- 困ったときにどこで誰に相談すれば良いのかが分かりやすく相談しやすい環境をつくる
メンバーがジョインする度にOBD中気づいた点をブラッシュアップしながら、内容も常に最新の状態に保つことを心がけています。
急成長ゆえに新しいメンバーが次々と入ってくるため、良くも悪くも改善の機会が途切れないという一面もあります（笑）
また初日のOBD後、正社員・業務委託を問わず1週間前後のOBD期間を設け、技術・ドメイン知識・カルチャーを集中的にキャッチアップできるようにしています。
OBD内容についてはジョインしたメンバーからも評価していただいており、技術顧問として携わっていただいている卜部さんからもお褒めの言葉をいただけたことで自信につながりました。
Hubbleに入って最初に感じたのは、“導入の滑らかさ”です。
業務委託や技術顧問として関わるとき、最初の1〜2週間はだいたい「どこから手をつければいいか」が分からず迷うんですよ。仕様理解、環境構築、コードリーディング……そのあたりで思った以上に時間を取られる。でもHubbleは、その入口の段階でのストレスがほとんどなかった。「こういう順番で見ていけば、全体像がつかめますよ」という道筋が見えていたんです。オンボーディング資料やSlackチャンネルの整備もそうですが、なにより“人”がちゃんと迎えてくれる。これが一番大きかったですね。
チームとして「いかに早く現場に入ってもらうか」はもちろん大事ですが、それ以上にプロダクトやユーザーフローを本質的に理解し、開発に入る際の疑問点をどれだけ減らせるかを重視しています。
その土台を築くことが、長期的に見てチームにとっても大きな価値になると考えています。
エンジニア採用への取り組み
私の新しい挑戦として採用にも大きく関わるようになりました。
前職ではわずかに関わった程度で、しっかりと面接を担当するのは今回が初めてでした。
面接官同士で質問や認識を揃えるためのヒアリングシートを整備していただき、私はまず面接に同席するところから経験を積んでいきました。
そこから徐々に主担当として面接を任せていただけるようになり、その過程で採用における視点や判断の軸を学ぶことができました。
面接の数も多いと週に2,3回ペースで続くこともあり大変ではありましたが、実戦経験は何よりも成長スピードを上げてくれました。
学んだことを踏まえて自分なりの工夫を面接に取り入れ、実践を重ねる中で、最終的には完全に任せていただけるようになりました。
まさに「守破離」を体現するような形で、自分の面接スタイルを作ることができたと感じています。
さいごに
エンジニアリングマネージャーとしては2年目に入り、ようやく「自分でこねていた粘土の形」が見えてきたと感じられるようになりましたが、決して自分ひとりの力ではありませんでした。
方向性を決めていただき相談ができる上司や、支えてくれるチームがいて、そこから学んだことを自分なりに実践できたからこそ、成長を実感することができました。
エンジニアリングマネージャーという役割は正解が無く、不安や迷いがつきまとう仕事だと思いますが、私にとって今のHubbleの環境で仕事ができることはモチベーションに繋がっているな、と記事を書いていく中で思い返すことができました。
まだまだ勉強不足な点も多く、自分の不甲斐なさを感じる瞬間もありますが、積み上げてきた学びをさらに広げ、チーム全体の力を更に引き出だせるエンジニアリングマネージャーに成長していきたいと思っています。
記事では触れませんでしたが、取り組んだこととしてチームビルディングなど他にも書きたいテーマはありました。
ただ、あまりに風呂敷を広げすぎてしまいそうだったため今回はある程度絞って書かせていただきました。
機会があれば、また別の記事で改めてまとめてみたいと思います。
明日はQAエンジニアの @r_mori7 さんによる投稿です。お楽しみに！